Re: Small annoyances with emelfm2

On Fri, 24 Oct 2008 07:06:09 +0200
"Arve Barsnes" <arve.barsnes@xxxxxxxxx> wrote:

Thanks for the feedback, Arve. "Fresh eyes" are a great resource for any work 
like this.

> Disclaimer: I'm only using the 0.4.1 version, and as such have no idea
> if this has been talked about or even fixed in current code,

No.

 but I've
> been lurking on this list for a while and can't remember it having
> been brought up. Also, some of these things might be gtk+ quirks that
> you can't do anything with. Anyways, here goes:
> 
> 1. When renaming a file, that file rightfully jumps to its new sorted
> place in the filelist, but the "focus" of the list disappears,

Strictly, the treeview focus is unchanged, that's why pressing an arrow key 
will select something nearby.

But perhaps you mean that the selection disappears. If > 1 item is being 
renamed, the other items will still be selected of course, until they too are 
processed. Only skipped items stay selected, so that the user can see what was 
skipped.

You might argue that when the last item is processed, then the focus should 
change. But IMHO it's just as valid to not move anywhere. Depends on what's 
actually being done.

In general, items are not selected automatically. There are some exceptions to 
this, such as when opening a dir for the first time with the relevant config 
option set.


 and
> you'll have to press down twice to get to the next file. There's two
> better ways here, in my opinion. The first is as it was in emelfm1,
> where the focus was on the newly renamed file. The other is if the
> focus moved to the next filename in the filelist after the one you
> moved, or one up if there is none, or maybe just stick with the same
> position as the one you renamed and see if it moves up or down, or
> maybe even stays on the file you renamed (if the renaming didn't
> change the sort order)
> 
> 2. Also when renaming, a nice little renaming box pops up. In this
> box, the whole file-name is marked, for convenience if you want to
> make a completely new name. The annoying thing here is that if you
> press the 'left' key, the cursor jumps all the way to the start of the
> filename, and the opposite for the 'right' key. If I press the left
> key, I want to move left on the filename until I get to where I want
> to edit, not to the start, that's what the 'home' key is for. Likewise
> with the 'end' key, although having it default to the rightmost
> position for editing might be fairly consistent with other programs,
> I'm not sure

Gtk manages this. When there's a selection, we have to <Right> then <Left> as 
appropriate (or vice versa).


> 
> 3. Clicking the 'up' icon above the filelist, to go to the parent
> directory, should, in my opinion, put focus in that pane. Discuss?

Now that you mention it, the various change-dir operations in inactive pane are 
inconsistent.

IIRC the logic went something like ... since it's so easy to explicitly swap 
the active pane, and since the inactive pane is often the 'recipient' of a file 
operation in the active pane, then the various inactive changers (arrow 
buttons, mirror button, ../ activation) should not implicitly change the active 
pane. But a bookmark choice will do so if corresponding config option is set 
(reason for this lost in ancient history) and entering/activating something in 
dirline always changes focus (probably because nobody ever bothered to 
differentiate between the 2 dirlines).

The most consistent UI would see the config option for bookmarks abandoned, and 
the dirline handling fixed, so that the focus never changes upon any cd.

Would that annoy users too much ? Feedback please.

> 
> 4. When going up one directory, if you recently came from that
> directory, focus will be on the directory you just left, which is
> great. But its position in the filelist will more than not be at the
> bottom of the filelist, sometimes at the top, whereas it would be
> great if it centered on the entry that has the focus, like it was in
> emelfm1.

Long ago, it used to work like this (we were cute, used the 'golden ratio' for 
positioning). But found that scrolling the treeview to an item within the last 
'screenfull' behaves badly. The way around this (a 2-step scroll) didn't seem 
to be capable of moving the selected item away from top or bottom, except in 
the last screenfull. Maybe this is worth another look.


> 
> 5. Editing boxes could be made to stretch a little longer, for those
> really long filenames. Might ruin something for smaller screens
> though, and I guess it would be a little awkward checking the screen
> resolution of the machine. Maybe check emelfm2's own size, and make
> something slightly smaller the maximum stretch size? I have no idea
> how this stretching works, I just noticed that it does sometimes
> stretch, but when editing names that are too long, it works less than
> optimal. Maybe there's some other solution to that.

Dialog sizing is mostly handled by gtk. Width seems to depend on prompt size 
and icon size and buttons size. Gtk/pango will wrap long prompts (e.g. with 
long filenames), I'm not aware of its rules for doing so.

I confess I'm not much interested in interrogating pango to find an actual size 
of a displayed string and comparing that with the entry's allocation and with 
window- or screen-size.

Regards
Tom


-- 
Users can unsubscribe from the list by sending email to 
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by 
logging into the web interface.

Other related posts: