A new xfce4-fm GUI with images (Was Re: New file manager (WAS Re: xffm))

[Jeff Franks]

edscott wilson garcia wrote:

>Yes, I agree it is too complex. I'm currently decomplexing it (which is
>in itself a complex task). 
>  
>
Don't make it too simple, otherwise nobody will use it.

>>What I'd love to see is a very basic simple icon view based file
>>manager, to tree view, no plugins, no samba, no nothing but simple file
>>management.
>>    
>>
Users do expect a certain 'basic' level of functionality from there file 
manager, so you just can't leave out everything :-).

>For simplicity, I am thinking of no toolbars and no main menu. Only drag
>and drop and popup menu. That means that the iconview you get when you
>execute xfce4-fm is basically as far as it goes.
>
>  
>
I think that would be a big mistake. You just can't ignore good 'basic' 
tried-and-true user interface design. Popup menus are 'context' menus 
and are not meant to be used as application main menus. This is why I 
don't use Rox-filer, it's menus are unwieldily. When you right click on 
the window background, on a folder, or on a file, essentially the same 
main menu pops up displaying irrelevent menu items. Popup (context) 
menus should only contain menu items relevent to the item right-clicked on.

>>Ideally, I think it should be started from scratch, and designed from
>>the ground up with both user interface and code maintainability in mind.
>>
>>    
>>
I notice that xffm has a lot small libraries. Edscott, why not have one 
a larger library for all file management routines (no GUI stuff or 
widgets) and give it a .pc file, making it easy for xfce4 
user-programmers  to use your file management routines in their 
applications. Then, have a separate library that implements the new icon 
view widget, which could be embedded in other applications (a desktop 
with icons, Xfce4-Settings, and of course the new xfce4-fm main window.

>The iconview code I've written so far (libs/gridview*) was started from
>scratch. The treeview code will be moved aside soon. All the extra
>functionalities will be enclosed in selfcontained optional modules (as
>Jasper once suggested), because if I throw my work away I lose all
>incentive to keep working. 
>  
>
I like the idea of giving users the option to load many of the existing 
xffm functionalities (that work well) as plugin modules. That way those 
that want more - can have more.

>I've announced the iconview at CVS since days after the 4.2 release, but
>so far I have received no comments on the look and feel. Seems that
>everybody is too short on time. 
>
>  
>
See end of email :-)

>>And if you want my point, this should be the only strong goal of Xfce
>>4.4. That's why I'd like to see as many devs involved as possible. Let's
>>put all of our (little) energy in this.
>>    
>>
When talking about big changes like a new file manger, perhaps a desktop 
with icons, and a new fd.o compliant desktop menu, doesn't that sound a 
bit more like Xfce5 than a 4.4 two point increment.

>These are my plans:
>
>4.3.1: (March-05). Iconview release (gridview). The only thing in the
>core is local file management (basic). Everything else (find, samba,
>fstab, etc.) will be in selfcontained modules which may or may not be
>installed. The treeview will still be around in a library somewhere.
>
I never use a file manager's tree view. I find I can work faster and 
more efficiently with two icon view windows side-by-side. I know many 
people like to use the tree view though. Can you make the tree view an 
option, like KDE and Nautilus, so that the default view is just a simple 
icon view window.

A new xfce4-fm GUI design
=========================

Here are a few mock images I put together to give you an idea of what I think the new file manager should look like. xffm has all the file mangement functionality that a file manager needs, and it works very well. From a functional viewpoint xffm is a good application. The problem it has is with its user interface design. xffm breaks 'basic' GUI guidlines by presenting common ideas and tasks in an umfamilar way. You can't do that because it confuses users and they wont use the application.

These images are based on the way I work with my file manager. I use only the icon view and resize the window to one quarter of my screen size, so that 2, 3 or 4 windows can fit neatly side-by-side when I need them to. In this configuration, I think both a menubar and toolbar take up too much space. 

Spatial Nautlius (aaagh!) has no toolbar. When Windows 3.0 came out applications did not have toolbars. It was cumbersome to navigate through the main menu everytime looking for the menu items for commonly performed tasks. With Windows 3.1 the idea of toolbars caught on because it was a convient place to put buttons that accessed commonly used functions. I definitley think having no toolbar is GUI bad design.

These three images are a mock-up using the current xffm and xfce4-fm windows. 

Here's the first image:  

Image: xfce4-fm with menubar

This window displays a separate menubar, toolbar, and GTK statusbar. The icons on the toolbar should only be for non-file-management tasks. The first three icons move up, back and forward. I find having these icons in this position makes it fast and easy to navigate up and down the file system tree. The next five icons are for a terminal, the home directory, refresh the icon view, and increase and decrease icon size. The terminal button should open the terminal window in the same directory as that displayed in the icon view. Currently the increase and decrease icon size functions cycle around which is confusing. The increase icon size button when clicked enough times will jump to the smallest size and cycle through the sizes again. This make the decrease icon size button obselete. I think that these functions should not cycle, but should only increase or decrease the icon sizes, stopping at the minimum and maximum sizes for the range. 

The last three buttons are for quitting the application and for splitting the icon view, either vertically or horizontially. I find splitting the icon view useful for many file management tasks (like moving and copying files). It allows me to say - split the icon view into two identical panes and then using the window manager, maximize the window in only the horizontal or vertical direction. Then using the up, back and forward arrows on the toolbar quickly navigate one icon view to another directory. A 'duplicate window' toolbar button would also be useful because it would let you create a new icon view window rather than split the current view. I don't think you need to split the icon view into more than two panes. I only ever use two, at most. 

Here's the next image:

Image: xfce4-fm with menu on toolbar

The difference in this image is that the main menu is now on the toolbar, using the new GTK+ 2.6 GtkMenuToolButton widget. User's would have the option of either displaying the menu in a menubar or in a pop-up menu on the toolbar. I think this is a great feature because it saves window real estate when your working with smaller sized windows. 

I tend not to use the file manager main menu a lot if the common functions I use are on the toolbar and the appropriate file tasks are in the pop-up context menu. But I think you still need to have a main menu because it's the one widget new users expect find, and expect to be able to access all application functions from.

Here's the last image that just shows the main menu on the toolbar in its opened state:

Image: xfce4-fm with menu on toolbar opened

Well that's it! Many of the other functions that currently exist in xffm are related to launching external tools, so these could be accessed under the tools menu. GTK+ 2.8 is supposed to include a toolbar editor so at some time in the future the file manager could offer a small number of optional toolbar buttons. You might want to carefully think about using GtkIconView. I know Edscott has reservations but the likelihood is that GtkIconView will get used at some point. Why not save a lot of effort up front reinventing wheel and spend your time on more important things. GtkListStore in GTK+ 2.6 has a new function (gtk_list_store_insert_with_values()) that speeds up adding multiple items to a sorted list by emitting only a row_inserted signal, instead of emitting a row_inserted, a row_changed and a rows_reordered signal after each addition. 

Well those are a few of my ideas for your consumption :-).
Regards,

Jeff Franks


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20050202/c8953990/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xfce4-fm-menubar.png
Type: image/png
Size: 30173 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20050202/c8953990/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xfce4-fm-no-menubar1.png
Type: image/png
Size: 29819 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20050202/c8953990/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xfce4-fm-no-menubar2.png
Type: image/png
Size: 34709 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20050202/c8953990/attachment-0002.png>