[Thunar-dev] next step in thunar development

[Benedikt Meurer]

Brian J. Tarricone wrote:
>>>Oki doki, let's see. First of all, attached to this mail is short
>>>summary (generated with umbrello, but since it's XMI, other UML tools
>>>should (in theory) be able to read it as well) of what I have worked out
>>>so far, which presents the important parts from my point of view.
> 
> Ok, cool.
> 
> So, what I want to work on now (unsurprisingly), is ThunarDesktopView.
> Aside from some VFS-related stuff that can just remain as stubs for now,
> I need ThunarDesktopModel, which relies on an interface definition for
> ThunarListModel (sub-interface of GtkTreeModel, if I'm reading this
> correctly).  It's not clear to me what ThunarListModel is supposed to
> provide exactly...
> 
> Also, why is ThunarDesktopView separate from ThunarView?  It seems to me
> that TDV should implement TV.  Is there a reason it doesn't?  It seems
> like it might even work as a subclass of ThunarIconView, though it might
> make more sense just to make use of ThunarIconView, or do somthing
> completely different.

ThunarDesktopView could implement ThunarView, tho I don't see any 
benefits here. ThunarView is the glue between the folder view and the 
surrounding window. ThunarDesktopView is not meant to be put into a 
ThunarWindow.

ThunarDesktopView cannot derive from ThunarIconView, as it has some 
special requirements (free placement of icons, remember icon positions, 
etc.), which ThunarIconView (actually ExoIconView) will not provide for 
performance reasons (atleast for now).

ThunarListModel provides a list interface to a folder (through the 
GtkTreeModel API) and some additional functions, that will be required 
for list (and icon) display of folders. For example, the ThunarListModel 
can be queried for additional actions that should be displayed in the 
menu (e.g. 'Empty trash bin' in case of a ThunarTrashFolder, tho trash 
is mostly undefined). But ThunarListModel does not maintain information 
about the positions of icons, etc. that will be required for the desktop 
display. So, ThunarDesktopModel extends the ThunarListModel, for example 
by 2 columns, which include the x and y coordinate of the icon on the 
desktop. And in additiona, ThunarDesktopModel provides a way to store 
these settings to permanent storage (something that has to be defined). 
ThunarDesktopView itself provides only the display functionality and 
basic controlling functionality in that it "forwards" user-actions to 
the appropriate components (some actions will be handled locally, like 
the "Cleanup icons" actions, etc.).

A few details about ThunarListModel: ThunarListModel implements the 
GtkTreeModel interface and contains a list of ThunarFile's (actually 
provided by ThunarFolder), which can be sorted (sorting happens in 
ThunarListModel). ThunarView uses the GtkTreeModel interface to access 
data from the model (there'll be some cases where this is not the case, 
but the common case will be GtkTreeModel functions, just because 
GtkTreeView and ExoIconView use GtkTreeModel functions to access their 
data). If for example ThunarListModel is queried for the value of the 
THUNAR_LIST_MODEL_COLUMN_DISPLAY_NAME in the 5th row, ThunarListModel 
calls thunar_file_get_display_name() on the 5th ThunarFile in the 
(sorted!) list (ThunarDesktopModel will simply extends the number of 
columns provided by ThunarListModel appropriatly and forward all queries 
on columns provided by ThunarListModel to the superclass).

> While I'm there, I might as well take a crack at ThunarVFSInfo and
> ThunarVfsURI  (maybe change the former to ThunarVfsInfo for
> consistency?).  I already wrote a GObject ThunarFileInfo, which can be
> de-GObject-ified and made thread-safe.  Any gotchas there?

I'm working on the ThunarVfs module already (actually that was the first 
thing I did). ThunarVfsInfo is mostly finished. You can send me the 
ThunarFileInfo, maybe there are some ideas, which we can pickup for the 
ThunarFile class.

BTW: The ThunarVfs module should only be used by ThunarFolder and 
ThunarFile if possible, to make sure that it can easily be replaced for 
example by D-VFS. High-level components like ThunarDesktopView should 
use ThunarFile and ThunarListModel to access file system data, tho that 
may not always be possible.

> 	-brian

greets,
Benedikt
_______________________________________________
Thunar-dev mailing list
Thunar-dev at xfce.org
http://foo-projects.org/mailman/listinfo/thunar-dev


-- 
Xfce  --  small, stable, fast  --  http://www.xfce.org/

           (__)
           (oo)
     /------\/
    / |    ||
   *  /\---/\
      ~~   ~~
...."Have you mooed today?"...