Re: Small annoyances with emelfm2

On Fri, Oct 24, 2008 at 11:32 AM,  <tpgww@xxxxxxxxxxx> wrote:
> 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.
>
Thanks for answering :)

>> 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.
That's what I meant yeah, sorry. I know that emelfm1 selected the
newly renamed file and focused on it, but after having used emelfm2
for a while I'd rather the focus didn't move, but I would love it if
the next file/dir in the filelist was selected instead of nothing.

> 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.
Personally, the way it is now is fine except for what I mentioned. The
usecase that provokes the annoyance is if I've done some commands on
the commandline in the active pane, and then go up one directory, I
often then want to do something with the directory I was in, like
deleting it or renaming it, and since the focus then is somewhere else
(probably still on the command line) I have to click on it again
before pressing F2 or something else.

>
>>
>> 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.
>
Would love it if this worked, it might just be the most annoying thing
about emelfm2.
>
>>
>> 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.
>
While this is probably the least annoying thing.

> 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.
>


-- 
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: