Feedback please - emelFM2 on gtk3

[t***@onepost.net]

Hello all.

I don't much use our favourite file manager on gtk3, but I've noticed a really annoying behaviour. Specifically, the file-pane toolbars scroll out of the top of the main window when the horizontal divider (between files and output) is moved towards the top of that window. Normally, the filelists and related toolbars should just shrink, eventually to nothing.

Actually, a similar thing occurs when the vertical inter-pane divider is moved to the left, but it's not so annoying. And the divider positions are not reverted properly at the start of a new session.

These seem to be a result of gtk3 widgets insisting on a 'noticeable' minimum size (e.g. in the case of toolbar buttons, 24-or-so pixels). When a toolbar size falls to the size of the included items, it's not permitted to get any smaller, and then simply scrolls.

There are a couple of gtk functions and properties which, on the face of it, seem to be relevant to reduce minimum size, but they have no effect, on gtk3 at least. I suspect that gtk3 minimum-sizes are determined by its styling mechanisms. Which is a bug, IMHO.

Can any of you shed any light on this ?

Have any of you seen emelFM2 working normally, on gtk3 ?

Regards
Tom

[Serge]

Hello.
Here's the videos from my desktop-

gtk3:

gtk2:

Only one thing is bothering me right now - list position when refreshing(

Post by t***@onepost.net
Hello all.
I don't much use our favourite file manager on gtk3, but I've noticed a
really annoying behaviour. Specifically, the file-pane toolbars scroll
out of the top of the main window when the horizontal divider (between
files and output) is moved towards the top of that window. Normally, the
filelists and related toolbars should just shrink, eventually to nothing.
Actually, a similar thing occurs when the vertical inter-pane divider is
moved to the left, but it's not so annoying. And the divider positions
are not reverted properly at the start of a new session.
These seem to be a result of gtk3 widgets insisting on a 'noticeable'
minimum size (e.g. in the case of toolbar buttons, 24-or-so pixels).
When a toolbar size falls to the size of the included items, it's not
permitted to get any smaller, and then simply scrolls.
There are a couple of gtk functions and properties which, on the face of
it, seem to be relevant to reduce minimum size, but they have no effect,
on gtk3 at least. I suspect that gtk3 minimum-sizes are determined by
its styling mechanisms. Which is a bug, IMHO.
Can any of you shed any light on this ?
Have any of you seen emelFM2 working normally, on gtk3 ?
Regards
Tom

--
Opera 12.15 Build 1748 for Linux i386.
OS: Linux 3.2.0-4-686-pae
Architecture: i686
Compositor active: Yes
Toolkit: Gtk 2.24.10 using Xfce-orange
Desktop environment: Xfce
Window manager: Xfwm4
Screens:
0: 1280x1024 depth 24,32 (default)

http://goodbye-microsoft.com/

[Arve Barsnes]

The devil is in the details.

Can't say the mentioned problems are something I've noticed at all. There
are two big differences I notice when switching between gtk2 and gtk3 for
my emelfm2:

1. I actually have configured a theme for gtk2 sometime in the distant
past, and I guess no other programs I use regularly are on gtk2, because
emelfm2 then looks completely out of place. My own fault I guess.

2. On gtk3, the horizontal scrollbars at the bottom of the panes are
missing. That's weird as they are clearly visible in the video Serge
linked. On the other hand, with gtk2 when deleting a file, no file is
selected after the operation, where the next one in the file-list (or
previous if deleting last file) is selected on gtk3.

The selection thing after deletion (or renaming) is enough to keep me on
gtk3 at the moment, but without the horizontal scrollbars (or the ability
to resize the columns either, another gtk3 problem?), I can't see stuff
like filesize and dates. Tough choices!

[t***@onepost.net]

On Wed, 2 Oct 2013 21:27:27 +0200

Post by Arve Barsnes
The devil is in the details.
Can't say the mentioned problems are something I've noticed at all. There
are two big differences I notice when switching between gtk2 and gtk3 for
1. I actually have configured a theme for gtk2 sometime in the distant
past, and I guess no other programs I use regularly are on gtk2, because
emelfm2 then looks completely out of place. My own fault I guess.

Find one of the themes that supports both gtk2 and gtk3. However, if you weren't aware, gtk3 has reportedly been breaking its theming, or people's actual themes at least, on every major release to now. I think that's why people are getting variable behaviours on gtk3.

Post by Arve Barsnes
2. On gtk3, the horizontal scrollbars at the bottom of the panes are
missing. That's weird as they are clearly visible in the video Serge
linked.

Same here.

I tried forcing a horizontal scrollbar on gtk3, but it's no use. The 'thumb' extends over the whole width, so it can't be moved to show other columns.

On the other hand, with gtk2 when deleting a file, no file is

Post by Arve Barsnes
selected after the operation, where the next one in the file-list (or
previous if deleting last file) is selected on gtk3.

The rationale is - you select an item, then delete it, and then there's nothing left that YOU selected.

The filelist (treeview) cursor is still there, after the position of the last-deleted item. An up- or down-arrow keypress will select the next item in that direction.

I know that some users prefer to always have something selected. You may recall the config option to select first item in newly-opened directories. Maybe we should relate to that, as a general policy for the post-task state of each filelist.

On the other hand, we can reasonably argue that renaming should not remove the selection. Code to implement that is now in svn.

And, oh joy, on gtk3 it still selects one item too many e.g. select and rename 2 items, end up with 3 selected.

I'm inclined to try to prevent that, even at the cost of removing the post-deletion selection that you favour !

Post by Arve Barsnes
The selection thing after deletion (or renaming) is enough to keep me on
gtk3 at the moment, but without the horizontal scrollbars (or the ability
to resize the columns either, another gtk3 problem?), I can't see stuff
like filesize and dates. Tough choices!

That one, I don't have. However swapping from gtk2 to gtk3 version will sometimes reset some column-widths to 0.

What happens if you disable, then re-enable, the un-resizable columns via a config dialog ?

Regards
Tom

[Arve Barsnes]

Post by t***@onepost.net

Post by Arve Barsnes
The selection thing after deletion (or renaming) is enough to keep me on
gtk3 at the moment, but without the horizontal scrollbars (or the ability
to resize the columns either, another gtk3 problem?), I can't see stuff
like filesize and dates. Tough choices!

That one, I don't have. However swapping from gtk2 to gtk3 version will
sometimes reset some column-widths to 0.
What happens if you disable, then re-enable, the un-resizable columns via a config dialog ?
My fault for not trying enough, I can resize, just not to the right to

make the horizontal scroll bar appear.

I really hope you don't remove the post-deletion selection I prefer, I tend
to rename a lot of files in sequence, and having the selection jump around
to the top or follow the file I renamed to its new position would make the
current gtk2 behaviour much preferred over that. Not that I shouldn't
script all my silly renaming tasks anyway, so if you did I guess that's
when I would get the needed boost to take care of that.

Arve

[t***@onepost.net]

On Thu, 3 Oct 2013 08:17:36 +0200

Post by Arve Barsnes

Post by Arve Barsnes
The selection thing after deletion (or renaming) is enough to keep me on
gtk3 at the moment, but without the horizontal scrollbars (or the ability
to resize the columns either, another gtk3 problem?), I can't see stuff
like filesize and dates. Tough choices!

I really hope you don't remove the post-deletion selection I prefer, I tend
to rename a lot of files in sequence, and having the selection jump around
to the top or follow the file I renamed to its new position would make the
current gtk2 behaviour much preferred over that.

Not sure quite what you mean. Selected items are not automatically shown, except perhaps when a directory is first opened. There should be no "jumping around" during the course of a progressive rename operation.

If files are sorted by name, and you select some then rename, the renamed (and now, reselected) items will probably be relocated, but your view of the filelist would be essentially unchanged, apart from the relocated items. Just select the next one(s) to be renamed, and iterate ...

Not that I shouldn't

Post by Arve Barsnes
script all my silly renaming tasks anyway, so if you did I guess that's
when I would get the needed boost to take care of that.

For now at least, for evaluation purposes, svn code has support for re-selecting the cursor row after move/delete, if the config option "select first item in newly opened directories" is enabled.

Not much tested on gtk3, but for that, the issue really is appropriate un-selection when you don't want that behaviour.

Regards
Tom

[Serge]

On Thu, 3 Oct 2013 15:07:17 +1000

Post by t***@onepost.net
The rationale is - you select an item, then delete it, and then
there's nothing left that YOU selected.
The filelist (treeview) cursor is still there, after the position of
the last-deleted item. An up- or down-arrow keypress will select the
next item in that direction.
I know that some users prefer to always have something selected. You
may recall the config option to select first item in newly-opened
directories. Maybe we should relate to that, as a general policy for
the post-task state of each filelist.
On the other hand, we can reasonably argue that renaming should not
remove the selection. Code to implement that is now in svn.
And, oh joy, on gtk3 it still selects one item too many e.g. select
and rename 2 items, end up with 3 selected.
I'm inclined to try to prevent that, even at the cost of removing the
post-deletion selection that you favour !

Sorry, but problem is not selected/not selected. Filelist position
skips to the top when no item is selected but scrollbar stays on the
right place. This is very annoying. Most file managers keeps filelist
position when refreshing/deleting etc. And this is good.
You can see well known Midnight Commander:
1/after deleting item(s), they removed from filelist and next to last
deleted item is selected;
2/when renaming file, next to renamed one is selected and renamed file
added to right place (maybe outside of visible items);
3/when creating new directory, filelist scrolls to that directory and
select it in the centre of pane;
4/when refreshing, filelist always keeps position.
Very useful)
Sorry about bad English.

[t***@onepost.net]

On Thu, 3 Oct 2013 15:02:51 +0400

Post by Serge
Sorry, but problem is not selected/not selected. Filelist position
skips to the top when no item is selected but scrollbar stays on the
right place. This is very annoying. Most file managers keeps filelist
position when refreshing/deleting etc. And this is good.

Serge, you have something weird going on. I've never seen or heard of behaviour like that.

The user is in control. The displayed position for a filelist is not supposed to move around of its own accord, with or without scrollbar thumb movement. (How is it even possible to move the view with the thumb staying in the same place, I wonder.)

The visible contents may of course change, if you re-sort, or change a property of item(s) which affects the current sorting, or if you add or remove item(s).

Let's start to track it down, with a couple more details:

* gtk version
* emelfm2 version

Regards
Tom

Post by Serge
1/after deleting item(s), they removed from filelist and next to last
deleted item is selected;
2/when renaming file, next to renamed one is selected and renamed file
added to right place (maybe outside of visible items);
3/when creating new directory, filelist scrolls to that directory and
select it in the centre of pane;
4/when refreshing, filelist always keeps position.
Very useful)
Sorry about bad English.
--
Claws Mail version 3.8.1
Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux

[t***@onepost.net]

On Wed, 2 Oct 2013 21:27:27 +0200

Post by Arve Barsnes
2. On gtk3, the horizontal scrollbars at the bottom of the panes are
missing. That's weird as they are clearly visible in the video Serge
linked. On the other hand, with gtk2 when deleting a file, no file is
selected after the operation, where the next one in the file-list (or
previous if deleting last file) is selected on gtk3.

I've pretty much surrendered on horizontal scrollbars. They appear with some combinations of (gtk3 version + theme) and are absent with other combinations.

No amount of pushing, poking, forcing things makes the slightest difference.

Damn shame, really!

Regards
Tom