[Thunar-dev] feasibility of ExoIconView feature improvements

[Benedikt Meurer]

Brian J. Tarricone wrote:
> Hey Benny (and all),

Hey Brian,

> [snip]
> So, stopping at this point: is this a good idea?  Implementing a totally
> new icon view widget just to allow positioning seems wasteful, and
> "breaking" ExoIconView's current behavior sounds like a bad idea as well
> (assuming we want to keep this current behavior for the normal Thunar
> icon view).

ExoIconView has several issues, which makes it (a) not suited to manage 
the backdrop and (b) causes problems even in windowed-mode (I'm not 
going into the details here). For windowed-mode there'll be a 
replacement once I get some spare time, hopefully by the end of the next 
week.

The problems for the desktop are:

(1) ExoIconView requires it's own window (for scrolling and button/key 
event handling), which means that you'd have two fullscreen windows to 
manage the desktop. This is a real waste of resources on the 
Xserver/grahpics card (esp. with high-resolutions/xinerama). And there's 
no way to avoid that, if you want to use it as a regular widget as well.

(2) ExoIconView doesn't support positioning items at arbitrary 
locations, and it has no concept of a "grid" to which items can be aligned.

(3) ExoIconView is already very slow. Adding support for "freely movable 
icons" and "grid based alignment" would make it even harder to optimize.

(4) The desktop view shares only a small amount of code with 
ExoIconView. If you check the source, you'll notice that most of the 
code (if you leave out the a11y stuff) is about scrolling and layouting. 
The "data access" and "paint routines" make up only very few lines.

In the end (if you forget about the keyboard and a11y support for a 
second), the desktop view takes only a few 100 lines to implement.

> Ok, moving on.  ThunarListModel.  In order to use
> ThunarView/ThunarIconView with ThunarDesktopView, I need to pass it a
> ThunarListModel.  ThunarListModel, of course, lacks columns for the x
> and y positions, which I need.  It also has a small and large icon,
> which I don't need, and functions for setting item sorting and showing
> or hiding hidden files, which again I don't need.  So I make a copy of
> ThunarListModel and rename everything to ThunarDesktopModel.  In order
> for ThunarView/ThunarIconView to accept it as a model, I make
> ThunarListModel subclassable and make ThunarDesktopModel a subclass.
> 
> But now there's a problem.  By removing the small and large icon
> columns, the columns that ThunarView/ThunarIconView expect to find at
> certain indices is broken.  I suppose I could re-add the large and small
> icon columns, and that would fix that problem, but I'm starting to get
> the feeling that I'm just going about this the wrong way.

My first idea was also to derive ThunarDesktopModel from 
ThunarListModel, which can be done w/o problems (I guess you forgot to 
override the interface methods on the parent's interface), but looking 
at it right now, it seems that it would be better to apply the "delegate 
pattern" here; that is, ThunarDesktopModel has a reference to a 
ThunarListModel and keeps track of changes to the referenced model 
(you'll need to do that in either case), then if the view asks for a 
value, the ThunarDesktopModel checks whether the requested column is in 
the range of the ThunarListModel columns and if so it forwards the 
requests to the list model, else the request must be on the position and 
the ThunarDesktopModel can answer it. Therefore the ThunarDesktopModel 
only needs to maintain a list of tuples (GtkTreeIter, 
ThunarDesktopPosition).

> 1) I should reuse ThunarView and ThunarIconView because not doing so
> would require reimplementing a good amount of functionality, such as
> file metadata and context menus.

ThunarIconView (the real work is done by ThunarStandardView) doesn't buy 
you much. It's targeted for window-mode. The context menus and all other 
actions are based on a GtkUIManager. The ThunarStandardView's UI 
description can only be merged with a UI description for a ThunarWindow.

 From the context menus, you'll only need the Cut/Copy/Paste stuff, the 
properties (which will be provided by ThunarFile soon) and the Open/Open 
With stuff, which will most probably be provided by a module in ThunarVFS.

The "file metadata" is associated with files, and is thereby provided by 
ThunarFile, as it has nothing to do with the view (atleast if I got you 
right here).

> So...  I'm kinda just throwing out thoughts right now.  Am I going in
> the right direction?  Any ideas for a better direction?  Implementation
> hints?  Anything?

I've hacked up a simple implementation of how I'd address the issue. It's in

http://thunar.xfce.org/download/snapshots/devel/thunar-0.0.2.0097svn-20050724.tar.bz2

The interesting parts are:

(1) ThunarDesktopModel, which implements GtkTreeModel and provides a 
ThunarDesktopPosition column for each file. The implementation should be 
changed to use ThunarListModel as outlined above.

(2) ThunarDesktopView, which displays the data from a tree model and 
takes the position requests into account. The view is based on a grid. 
The view paints on the parents window.

(3) ThunarDesktopWindow, which is the controlling unit here. As you 
suggested earlier, it is derived from GtkWindow.

(4) ThunarDesktopPosition, which is a boxed struct that contains 
information where to place an item (screen number and x, y coordinates).

It's just a proof-of-concept and far from being nice code. It lacks 
support for pretty much everything, but I think you'll get the idea.

You can run Thunar with the "--desktop" parameter to get the desktop 
view instead of a regular window.

What do you think?

BTW: Auke, do you have some spare time monday evening, so we can migrate 
the repository?

> 	-brian

greets,
Benedikt