[Thunar-dev] feasibility of ExoIconView feature improvements

[Brian J. Tarricone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Benny (and all),

I finished implementing most of the framework for Thunar's desktop view,
but I'm hitting a big roadblock with the icon view itself.  I was
already aware that ExoIconView doesn't support arbitrary icon
positioning, so I started playing with it to see what it would take to
extend it.

And it's pretty nasty.

- From what I can understand, each item is eventually assigned a row and
column, and the layout function basically just lays out the icons in a
grid based on these row/col coordinates.

I was thinking of some nonintrusive ways of changing this.  My first
thought was to add an API ("_set_allow_positioning()" or similar) which
basically turns (row,col) into (x,y).  That turned out not to be so
useful, since then it's not so straightforward to get and set the
positions of the individual item positions.

So, I figured we could add a couple columns to the model the iconview
uses, and then we add:

exo_icon_view_set_pos_x_column()
exo_icon_view_set_pos_y_column()

And then we can define a value (say, G_MININT) that means "this icon's
position is unset", in which case it falls back to the grid layout for
that icon.  Of course it'll also fall back to grid layout if the
pos_x_column and/or pos_y_column are unset.  This seems like it would
work fairly ok, though exo_icon_view_layout() and
exo_icon_view_layout_row() will need to be tweaked a bit.

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).

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.

Here are my basic assumptions:

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.

2) ExoIconView should be extended to allow arbitrary positioning of
icons, because, again, a custom icon view just for the desktop would
reimplement a lot of functionality.

3) ThunarListModel should maybe become an interface.  The current
ThunarListModel should perhaps be moved to ThunarListStore (or
something), which implements ThunarListModel.  Then ThunarDesktopStore
could also implement ThunarListModel.  ThunarIconView could continue
requiring a ThunarListModel.  I'm not sure what the best way is to
define the columns in ThunarListModel to do what the regular icon view
and desktop icon view needs.

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?

	-brian


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC4tOP6XyW6VEeAnsRAuKGAJ919vf2I8Wu7+qf0HmoY7m7i9JzpwCggcYd
OQPtv81sQv9dqn0yZAVW+08=
=N4oQ
-----END PGP SIGNATURE-----