[Thunar-dev] Unification of Treeview and Sidepanel

[Brian J. Tarricone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Ori Bernstein wrote:

> On Thu, 12 May 2005 16:52:12 +0200 Jasper Huijsmans
> <jasper at xfce.org> said:
>
>> Ok, guys, I don't think the next step in thunar development
>> should be more mockups of the GUI. One comment on that: the goal
>> is to make a 'simple' file manager; this doesn't mean complete
>> lack of features, it mostly means no user interface overload.
>> Combining trees and shortcuts in one view sounds like xffm to me,
>> we already have that and that is not the goal. Keyboard shortcuts
>> to switch between shortcut and treeview will hopefully be enough
>> to satisfy the power users among us.
>
>
> Ok, I can see where you're coming from.
>
> However, I'd still like the treeview to have the roots in the
> bookmarks, since I see myself - and probably other users - wanting
> a treeview in bookmarked directories more than the roots that are
> currently there.

I personally find 'bookmarks' of limited utility when working in a
file manager.  In a file *chooser*, I think they're great.  When I'm
looking for an mp3 file in xfmedia, for example, it's nice to be able
to click the shortcut to my music folder.  But when I'm in a file
manager, it's usually more about unrelated tasks, or one-shot actions.

I'm just trying to point out that "I see myself - and probably other
users" is pretty meaningless when you're trying to do "real" UI
design.  Unfortunately, it's often all we have, since true usability
studies take time (and usually money), and aren't things your normal
software dev even knows how to do.

> One option that I can see is instead of having the option
> 'treeview' and 'bookmarks', call it 'show subdirectories in
> sidebar'.

Yuck.  This just obfuscates the UI.  I'm of the opinion that we should
just stick with what we had before: it's much cleaner, much simpler,
and much clearer.  If that means an extra mouse click or two for some
actions - actions that may or may not be common use cases - then so be it.

>> Now, the way forward, IMO, is for one or more people to try and
>> implement backend code based on the interaction diagram created
>> by benny.
>
> I don't mind working on any of the stuff, but I have to brush up on
> the specs being adhered to.
>
> Also, possibly a list of the libraries used/target versions that
> we'd be coding to would be nice (correct me if I missed it in the
> wiki)

Not sure if this is listed anywhere, but I believe we're targetting
gtk 2.4, and libxfcegui4/libxfce4util in SVN trunk (meaning, we don't
need to compile against 4.2.x, and we can add stuff to the core
libraries as needed).

IPC should use D-BUS, and I think for now we should probably write a
(small!) compatibility layer between the 0.2x and 0.3x APIs.  However,
we'll need to define a D-BUS interface first, which will take time,
and can probably wait.

If there's any must-have functionality in glib/gtk 2.6, we can talk
about importing it into libexo.  Ah, that's another thing: feel free
to use libexo 0.3.

As for other dependencies, we can deal with them as they come up.

    -brian


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
 
iD8DBQFCg7nO6XyW6VEeAnsRAig1AKDHOUIyJiIyB8//H1yXV8cVx1eeiQCgmIyZ
+eBN+356IKO3Nar5Bu+Gt3Y=
=ptAD
-----END PGP SIGNATURE-----