Re: Small annoyances with emelfm2

On Fri, 24 Oct 2008 12:38:48 +0200
"Arve Barsnes" <arve.barsnes@xxxxxxxxx> wrote:

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

While it's not the neatest process in the world, there are focus-related 
bindings e.g. from a filelist <Ctrl>Z <Tab> or from the command line: <Ctrl>Z 
<Tab> <Ctrl>Z. If sufficiently motivated, you could define some other binding 
to combine these actions.


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

I've committed a change. Was no big deal to get it work here, which makes me 
wonder whether gtk has changed its processes since this matter was last 
investigated. If so, I can't be sure that the change will work properly with 
older gtk(s).

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: