Re: questions about features

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

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.

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

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

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

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

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

> > - 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? This must be a universal action applicable (via
different helpers) to all files, same as view or open.

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

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

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

> > - 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.
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. Second, I want to change the behavior of many actions in
various ways.

> > 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 and convenient, with step-by-step workflow
illustrations? Pointing out that all good filemanagers do this?
Anything else?

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!

> 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. But yes, this is inevitable: letting
other people in will change the direction of the project to some
extent. But this is normal. In fact, it's a good thing. It's a sign of
a project which is live and developing.

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