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 _______________________________________________ Thunar-dev mailing list [email protected] http://foo-projects.org/mailman/listinfo/thunar-dev
