Re: Hack away with Nautilus! (Re: [Usability] Alternatives to nautilus for two paned file management)

[Tomasz Janowitz <logan77 o2 pl>]

Christian Neumair wrote:
> Am Montag, den 19.12.2005, 09:54 +0000 schrieb Richard Hebert:
> 
>>I have followed the threads about Gnome with interrest.
>>I share a lot of views with the members here.
>>For two paned file managers i looked a lot and found
>>a few. I dont like to use them , but Nautilus's team is
>>insensitive to their users.I dont know who runs that box
>>but since the beginning i hated it. GMC was a way better
>>manager imho.Faster,lighter and did all i needed it to do.
>>When they switched to Nautilus i really started to have
>>trouble with Gnome.
>>
>>
>>Anyways  :
>>for a two paned file manager check this one.
>>
>>http://xnc.dubna.su/  that's XNorthernCaptain.
>>i havent had trouble with it .. works nicely.
>>
>>
>>I got trouble with Gnome the way it's gone the past few years.
>>The way of " we know better than our users what they want "
>>has given me no choice but to look at the alternatives.
>>Not that i like it one bit.Perhaps Linus is right ..
>>KDE seems like an alternative.Though it's hard for me
>>to wave goodbye to Gnome ..
>>
>>If Gnome is to survive a radical change is needed.
>>Kicking whole teams/projects out of it like nautilus and a radical
>>change in philosophy.Why not start by listening to their users ?
>>
>>I have lost hope to see Gnome evolve in a direction that
>>will allow me to enjoy it.Looks like a few hours of KDE debug
>>( wont start atm ) might be paying off ..
> 
> 
> I don't think that a previously discussed and ironed out more
> sophisticated extension framework will be rejected. It would be nice to
> have some more high-level APIs/hooks like Epiphany has. I've also read a
> bug request today where a user requests terminal integration. We just
> don't have to enable/ship it by default, and as long as the wrapper
> layer is cleanly designed and doesn't cause new mess and design
> headache, I think Alex and the rest of the Nautilus maintainer team is
> also open to your ideas.
> 
> As a starting point, we might have to add support for multiple content
> views to NautilusWindow, add get_active_contents_view API and maybe tune
> the menu layout. I think this is really doable with the current Nautilus
> architecture. :)
> 
> 
That would be good "start"I also think that this shouldn't be _that_ hard
to do. Probably this is the most important part that has to be written.
Presumably the main toolbar should get smaller to about 50% of its current
hight with added some locations (like '/','cdrom').
   But what about list view ? Currently it is implemented with stripes of
grey color. It kind of differs from what one would expect from two paned
file manager. The default zoom is also extraordinary. In fact this view
resembles sth. usefull only after setting zoom on 25%. Right now there is
fixed minimal 'Octal permissions' column to the width of title...surprise
surprise.."Octal permission". While this sounds reasonable it eats to much
space. Octal permissions have width that of word "Octal" at most. Another
thing: current list view look like some kind of tree (not sure if its a
good or a bad thing here....I lean a bit to 'good' side). Next: in column
'user' there is not only login, but a real name too. Which makes it also
very wide.
   I notice strange things when having the option of 'one click to open' on
- the cursor flashes etc. The question arises, wouldn't it be better to
have separate setting of the cursor for icon mode and for list view mode.
   Question: what kind of way of managing simple file processes should be
implemented (the same as in MC F1-F10 ?). I think it's a reasonable default.
   Conclusion: nautilus as it is doesn't seam to be particualarly well
suited for commander-like file manager, although everything what is needed
is there, just needs some refinement in few places. And the main question:
will someone write the code for 'multiple content view'. If so, than there
is nothing that could prevent commander-like nautilus being a reality.