Re: questions about features
- From: bulia byak <buliabyak@xxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Thu, 2 Feb 2006 15:07:18 -0400
On 1/31/06, tpgww@xxxxxxxxxxx <tpgww@xxxxxxxxxxx> wrote:
> Very true. But that's all we got from emelfm1, and nobody (to now) has found
> a need to upgrade. Look forward to seeing your work on that ??
As I wrote from the start, there are things that I cannot go into. I
am a UI person and I cannot commit myself to work on things like vfs
support or fully-integrated search plugin display. That's why I
started by asking how close were these core features to implementing.
I cannot do vfs myself, and without it, I still will not be able to
use emelfm2 in daily work, and therefore will not be motivated to work
on that.
> > > > - Panel listing modes with more than one column for names
> > >
> > > To show what ?
> >
> > To show just names, without sizes etc., in two or three columns in
> > each panel. Very useful as an optional mode for long dirs. FAR on
> > windows does that, and I miss it a lot.
> In the config dialog, for pane 1 and/or pane 2 settings, hide the columns you
> don't want.
And then, I want to have the single names column wrapped 2 or 3 times
within the same panel, to fit 2 or 3 more filenames in the same space.
> The viewer is essentially a gtk textview widget, and as such, it expects its
> contents to be encoded in utf-8. e2 is supposed to convert non-utf-8
> encoding. Does that not work ?
It works, if the source is in the system encoding. But it may be not.
Anyway, can you just add an option to pass the file through a filter
before displaying? I will then add enconv (from enca) and it will work
for most files automatically.
> > > > - Syntax coloring in the viewer (using colorer library?)
> > >
> > > The internal viewer is deliberately simple. There is a config option
> > > to use an external viewer for more sophisticated purposes.
> >
> > Running external viewer is slow and it's not integrated all that well.
> I have to admit, I've never done it. But, apart from time taken to start the
> external application, how is it not integrated ?
There are many aspects to integration:
- The viewer window and the emelfm2 window are under one common icon
in the taskbar.
- When I switch to them, both windows go to the foreground together,
and the viewer is always on top.
- The viewer starts quickly and is closeable by Esc.
There are however aspects in which this integration can be still improved:
- Since the viewer window is always on top, it must grab focus
completely. Right now you can see the viewer on top but the focus is
still on the main window, and you can't activate the viewer without
clicking on it, which is very annoying. As an option, please allow the
user to disable both viewer-on-top and viewer-grabs-focus if he so
desires.
- In addition to the ability to specify size of the viewer window, can
you please add an option to open it maximized.
> Remembering between separate viewing sessions ? If so, why is it reasonable
> to assume that the user wants a re-opened file to scroll to the middle, say,
> instead of somewhere else ?
For small files it's not often that you'd want to scroll to the same
place, indeed. But with small files, scrolling has little or no effect
anyway. With large files, much more often than not I want to go back
to the place I was in last time. Good text editors implement this, and
good filemanagers also have this both for the editor and the viewer.
> Second, I want to change the behavior of many actions in
> > various ways.
> Examples ?
One example is seaching files on the panel. When you type letters a
small field opens for typing the name you want to scroll to,
incrementally - that's perfect. However, when I have found the file, I
want to press the key to do something to it, I cannot, because that
search field grabs it. So for example instead of f - i - l [Enter] to
activate a file starting with "fil" I have to press Enter twice, once
to close the search and then on the file. The fix is to make that
field watch what keys are pressed and only react to alphanumeric keys.
If any other key is pressed, it should close itself and pass that key
to the main window.
> > Anything else?
> see www.softpanorama.org/OFM/index.shtml
I know that site very well, and by the way it has a lot of sensible
ideas that we should think about implementing. For example it lists
the traditional keys:
F1 - help, F2- user menu, F3 file view, F4 - file edit, F5 - file
copy, F6 - file move/tree move, F7 - make a directory, F8 - file
delete, F9 - top menu, F10 - exit.
Emelfm2 is mostly compliant, but f3 for search and f4 for view struck
me as weird. Can we change the default for f3 to be View?
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
--
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:
