Re: questions about features

On Tue, 31 Jan 2006 14:20:21 -0400
bulia byak <buliabyak@xxxxxxxxx> wrote:

> On 1/31/06, tpgww@xxxxxxxxxxx <tpgww@xxxxxxxxxxx> wrote:
> > There is a plugin that sort-of replicates what you want, by unpacking
> > the archive into a temp directory, and going there, and offering to
> > delete/leave/repack when you depart.
> 
> That's extremely clumsy.
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 ??

 All this must be done in memory,
> transparently. All decent file managers do this.
> 
> (Sorry to sound like that. I hate myself when someone comes to
> Inkscape and says, hey, all vector editors have this and you don't,
> what's the matter? And yet, sometimes it's true and we must accept
> that.)
> 
> > There is a severe aversion to supporting yet another
> > application-specific, incompatible, vfs mechanism. When the folks
> > posting about vfs at freedesktop.org finish their work on D-VFS, we'll
> > look at this matter again.
> 
> Sure, I understand that implementing all this yet again in another
> file manager is a dead-end. So, does that D-VFS (or gnome-vfs, or
> whatever) support FTP and browsing inside archives? If so, I would be
> happy to use it when it's available. If not, we have to do something
> about it.
I don't closely follow the D-VFS stuff, but IIRC the debate went along the 
lines of: gnome-vfs sucks in some respects, the kde equivalent likewise, and 
we're going to to a better one that all desktops can use.

In due course, more linuxers will have fuse, and related filesystems (avfs, 
gnome-vfs-fuse etc etc), to play with. IIRC FreeBSD also can use fuse. But e2 
users don't necessarily fit into those categories. There's a utility 
gnomevfs-mount somewhere about the place (its URL has recently gone missing), 
which may be (I've never tried it) the most convenient solution for right now.

> Alternatively, you could borrow the vfs code from mc. It's reasonably
> well-developed and usable there, and will give you support for a lot
> of archive types for free.
IIRC gnome-vfs was built from that base. And in spite of a lot of work there, 
it still sucks ? (hey, what do I know ?)

> > The find plugin allows detailed searching, but not inside archives
> > (it's really just a glossy front end to the shell 'find' command). I
> > would have thought that the find plugin is on the default plugins
> > menu, but if not, edit the plugins config to make it so.
> 
> Yes, I now found how to enable that plugin. But it seems to only write
> its output to the output pane. Or can this be changed somehow too?
No

 The
> minimum UI is a dialog with the scrollable list of files found, each
> file viewable right from there, ideally with a button to move this
> temporary list to a panel (see mc).
Again, go ahead and make it happen ...

> 
> > In the filelists we distinguish, by colour, 6 broad categories of
> > item. That seems a reasonable compromise between ease-of-use and speed
> > (which is a priority, I work with dirs that contain up to 2,000 items,
> > and I know that some e2 users have slow hardware). There is currently
> > no infrastructure (and in particular, fast infrastructure) in e2 for
> > distinguishing items in finer detail e.g. mime-type.
> 
> I think you're going into a premature optimization.
The application has been in use for almost 2 years, and quite stable for over a 
year.

 My self-patched mc
> with file type coloring has no problem with 2000 file directories. And
> this is VERY important from UI viewpoint. In fact this is MORE
> important than coloring file categories. I very rarely use sockets or
> hard links, so coloring them is scarcely helpful. But I want to be
> able to tell my images from my XML and C++ files at once, they are
> always before my eyes and coloring them differently is way more
> important. I consider this a major can't-live-without feature.
Well, it's worth a try. But I have to say, IMO current e2 filelist refreshing 
is bordering on unacceptably slow, for large directories. Gtk2 is going to make 
things a lot slower than mc

> > > - The ability to change background color everywhere (at least in the
> > > panels and output pane and viewer) - I love black background
> >
> > Background color is intentionally not set by e2. It should match the
> > installed gtk theme. Tell us if if does not.
> 
> OK, I'll explore that path. I found no standard themes with black
> background. Looks like I'll have to do my own.
e.g.
http://gnome-look.org/content/show.php?content=14642
http://gnome-look.org/content/show.php?content=33649
 
> > > - 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.

> 
> > > - A way to select files in the current panel based on a mask, which
> > > mc does on pressing gray + or gray -
> >
> > Use the filters that are provided in the respective file-panes' filter
> > menus.
> 
> That's a different thing. I want to quickly _select_ some of the
> files, not _see_ only some of them.
Misread, sorry. Easy enough to add that.

> > > - A file.edit action for opening external editor (different from
> > > file.open)
> >
> > There's an 'edit with' dialog associated with e.g. *.c. Custom
> > commands and custom filetypes can readily be created.
> 
> Why only *.c?
It's not, that was an example. Filetypes and associated applications can be 
configured however you want.

 This must be a universal action applicable (via
> different helpers) to all files, same as view or open.
Disagree. Editing is not so important. e.g, before, when we made editing 
commands the default for some filetypes, users complained.

If an activated item is of a type NOT currently configured, there's an "open 
with" dialog. For filetypes that you might want to edit, add an 'edit-with' 
alternative command for that filetype.

> > > - Incremental search in viewer
> >
> > Not sure what this is ...
> 
> See Firefox. You type, and the search is redone live for each letter
> you type. Much more interactive and saves a lot of useless typing.
I see. 15 lines of code. Done now.

> > > - Switching source encoding in the viewer
> >
> > You mean source code ? Or character encoding ?
> 
> That's a feature specific to Russian users (as well as other
> non-English users I think). We have several different character
> encodings for Cyrillic, and lots of files in different encodings, so I
> want to be able to switch quickly between them inside the viewer. All
> that's needed is just running the file through different iconv filters
> before displaying. This can be made into a plugin, if the viewer
> supports plugins.
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 ?

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

> In fact I like your viewer, it's a good starting point. But, IMHO, the
> best software is not that which _is_ simple, but that which _looks_
> simple but has a considerable power under the hood. All my proposed
> features would be optional, so if they slow you down, you can turn
> them off.

> By the way, here's one more must-have feature for the viewer:
> remembering and restoring the point in the file which you were
> viewing.
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 ?

> > > - Lots of new keyboard shortcuts, including Lynx-like directory
> > > motion
> >
> > Feel free to develop and apply your own (well, to v.0.1.5 there was a
> > bug preventing addition of more bindings). But there's no evident
> > clamour to make any such things default. Has been a little bit of
> > recent talk about vi bindings.
> 
> I don't want to sound like bragging, but before I came to Inkscape,
> there was "no evident clamour" to improve its keyboard shortcuts. I
> completely reworked this part of the UI and increased the total number
> of shortcuts by an order of magnitude (literally). Now, Inkscape is
> TOTALLY keyboard controllable, it's way ahead of even commercial apps
> on that aspect. People rave about it. It IS important, believe me.
I agree. Well, more or less, on the TOTALLY bit. Apart from a few less-used 
things, AFAIK, e2 pretty much achieves that too. And it can do so if a user 
wants.

The questions for a user are - what are the actual bindings, and how do I make 
them suit me, if not already so.

> It's a major selling point of Inkscape. People get addicted to it and
> can't get back to their old apps, even though Inkscape still misses
> many features.
> 
> Changing shortcuts in prefs does not quite cut it. First, I want to
> add keys for lots of actions which are currently not controllable from
> keyboard.
Go ahead. As I suggested before, make it easier to do a lot at once ...

 Second, I want to change the behavior of many actions in
> various ways.
Examples ?

> 
> > > And my final question is, what is this project's policy and general
> > > attitude towards patches and contributions?
> >
> > Fixes always welcome, of course. Anything substantially increasing
> > application (as distinct from plugins) size would need to be justified.
> 
> And what is sufficient justification, from your viewpoint? Explaining
> why it's important 
of course
> and convenient
for many users (ask them, we've had complaint about creeping featuritis)
> , with step-by-step workflow illustrations?
no big deal
> Pointing out that all good filemanagers do this?
irrelevant, good is in the eye of the beholder ...

> Anything else?
see www.softpanorama.org/OFM/index.shtml

I'm sure that when I ponder for more than 20 seconds, more sense will emerge ...

> As for plugins, generally I favor this path as well. But plugins
> usually have their limitations. We'll see what it takes to make
> plugins really first-class citizens, so that the fact that it's a
> plugin does not present an obstacle to smooth UI.
 
> >In fact I'm on the lookout for things that can reasonably be removed
> (we do not aim to to all things for all (wo)men, there are lots of
> other good tools out there).
 
> The only more or less usable fm for linux is mc, currently.
> Unfortunately it's too old, limited by console quirks, and its code is
> a dreadful unmaintainable mess. I use it but I want something better.
> Emelfm2 is the best thing I found so far. Please let me make it even
> better!
Happy for that to happen !
 
> > To now, code committed only by me or tooar. Never been any request for
> > other arrangements, but I'm sure something can be worked out.

> This is good. I don't think I can contribute if I'm limited to patches
> - unfortunately I have had bad experience with that in other projects
> (my patches to mc were ignored for years).
 
> I totally understand that you may be reluctant to let other people
> deep into the heart of your project. I am willing to spend any amount
> of time to convince you that I am not a jerk or control freak and that
> my improvements are beneficial.
Actually, I'm an optimist, I expect the best of people (but if that turns out 
wrong, assassination is the only viable fallback ...)

 But yes, this is inevitable: letting
> other people in will change the direction of the project to some
> extent.
No big deal.

 But this is normal. In fact, it's a good thing. It's a sign of
> a project which is live and developing.

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: