[Thunar-dev] feasibility of ExoIconView feature improvements

[Artem Vakhitov]

Hi,

sorry for cutting in, since I'm just a lowly user and all, but still: 
shouldn't icons indeed be laid out in rows and columns? Wouldn't it look 
untidy otherwise? Why exactly is such a flexibility needed?

Regards,
Artem Vakhitov

Brian J. Tarricone wrote:
> -----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-----
> _______________________________________________
> Thunar-dev mailing list
> Thunar-dev at xfce.org
> http://foo-projects.org/mailman/listinfo/thunar-dev
>