Re: Sharing the places sidebar between Nautilus and GTK+

[Cosimo Cecchi]

Hi Federico,

Generally, this sounds like a good plan to me. I have some comments
below.

On Tue, 2011-09-06 at 17:44 -0500, Federico Mena Quintero wrote:

[...]

 4. See what common, public interfaces we need.  For example,
 
   nautilus_window_set_initiated_unmount (sidebar-window, TRUE);
 
 seems like it could be replaced with a signal on the GtkPlacesSidebar
 class, and then Nautilus can start a spinner or whatever when an unmount
 operation starts.  Another common interface would be something like
 gtk_places_sidebar_select_path (sidebar, file:///foo/selected) to
 highlight a particular item.

IIRC nautilus_window_set_initiated_unmount() is basically a hack to
redirect a specific NautilusWindow to $HOME instead of closing it when
it's opened at a mount location and the mount disappears as a
consequence of being unmounted from inside the same window (as there can
be multiple windows in Nautilus pointing to a mount at the same time),
so probably this is not something useful to replicate in the
single-window GtkFileChooser.

 5. See what nautilus-isms *should* be doable with plain GIO, and see if
 there is anything else that Nautilus needs to do about them via signals;
 maybe for something like
 
   nautilus_file_operations_mount_volume_full (NULL, volume,
   volume_mounted_cb,
   G_OBJECT (sidebar));

As far as I remember, the only thing that those nautilus wrappers add to
using plain GIO is checking for trash files on the mounted volumes (and
prompting to the user a dialog asking if the trash should be emptied
before unmounting if so).

 6. See what things should be available or not in the file chooser...
 when dropping files on the shortcuts bar, Nautilus can do
 
   nautilus_file_operations_copy_move (uris, NULL, drop_uri,
   real_action, GTK_WIDGET (tree_view),
   NULL, NULL);
 
 
 Same thing for
 
   nautilus_file_operations_empty_trash (GTK_WIDGET (sidebar-window));

So, first of all we should think about whether this kind of interactions
are desirable in a file chooser. I don't think GtkFileChooser should be
a full-fledged file manager, so I would just disable e.g. copy/move
while porting code to GTK+.

On the other hand, other operations like emptying the trash might make
sense and exposing them in GTK+ currently means either copying a lot of
file operations code from Nautilus into GTK+, or using the DBus
org.gnome.Nautilus.FileOperations interface as Alexander suggested.

[ I think what I would love to see in my dreams for this is a stateful
file operations stack in GIO, allowing to have a central GTK+ UI to
display completed/ongoing transfers and notifications embedded in the
shell (to be used e.g. for browser/IM file transfers as well), but it
looks like a lot of work :) ]

 One little caveat: that part of Nautilus is GPL, and GTK+ is LGPL,
 although it *seems* that the places sidebar code may initially have come
 from GTK+ and then reworked heavily.  I haven't checked the history
 closely.  What do we do about this?

The git history suggests the initial code for the sidebar was
contributed by Jamie McCracken, but it doesn't mention whether it comes
from GTK+ [1]. As far as my contribution to that code goes, it's fine
for me to relicense those parts to LGPL, but maybe we should ask the
other contributors as well.

[1]
http://git.gnome.org/browse/nautilus/commit/src/nautilus-places-sidebar.c?id=977c0f99380c111749b04c20b34113f635d1d0e7

Cheers,
Cosimo

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Sharing the places sidebar between Nautilus and GTK+

[Cosimo Cecchi]

Hi Jannis,

On Wed, 2011-09-07 at 01:53 +0200, Jannis Pohlmann wrote:

 To be honest, I think we can do better than this. The user experience
 offered by the current places sidebar is far from ideal IMHO. In
 Nautilus 3.x 
  
   * the sidebar has no mount/eject progress indicators,
   * the eject buttons do not look/feel clickable, i.e., they don't
 change their appearance on hover events, 

[ This should have been fixed now if you use a recent enough GTK+ and
Nautilus ]

 I realize that, aside from the code still being somewhat rough and
 imcomplete, this is nothing we'd want to stuff into GTK+. In
 particular, faking the look of a tree view with custom widgets may seem
 like a hack to most people (even though standard GTK+ drawing routines
 are used). On the other hand it is fun to use and shows how the places
 sidebar *could* work IMHO:
 
   * progress indicators for async operations, 
   * real mount/eject/cancel buttons ('cuz spinners alone are not
 enough),
   * individual row/button highlighting on hover,
   * keyboard navigation works (even switching between rows and
 buttons is possible), 

I agree with these points, even if some of those might be possible to
implement with cell renderers and a tree view; to me, another added
bonus of not using a GtkTreeView but a custom container and a separate
widget for each row is it allows themes to easily style different rows,
which is used e.g. in the Documents mockup [1] and might not be very
easy to do otherwise.

[1]
http://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/documents/documents-sidebar.png

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Sharing the places sidebar between Nautilus and GTK+

[Milan Bouchet-Valat]

Le mercredi 07 septembre 2011 à 01:53 +0200, Jannis Pohlmann a écrit :
   * the sidebar has no mount/eject progress indicators,
There's a rough patch for it, maybe it will be committed soon:
https://bugzilla.gnome.org/show_bug.cgi?id=619665

   * the eject buttons do not look/feel clickable, i.e., they don't
 change their appearance on hover events, 
This was apparently committed before 3.0, but I don't see it. Bug is:
https://bugzilla.gnome.org/show_bug.cgi?id=544103

 Of course, some of these missing features are due to cell renderer
 limitations, e.g. last time I tried, I couldn't get hover-in/hover-out
 events for individual cells to work good enough to implement a
 fully-working button renderer. But still, the places sidebar has more
 potential and the current implement feels somewhat half-baked.
Yeah, GtkTreeView would need some changes to implement this properly,
but a hacky solution works currently (see patches). I had filed this:
https://bugzilla.gnome.org/show_bug.cgi?id=586458


Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Sharing the places sidebar between Nautilus and GTK+

[Tristan Van Berkom]

On Wed, 2011-09-07 at 11:27 +0200, Milan Bouchet-Valat wrote:
 Le mercredi 07 septembre 2011 à 01:53 +0200, Jannis Pohlmann a écrit :
* the sidebar has no mount/eject progress indicators,
 There's a rough patch for it, maybe it will be committed soon:
 https://bugzilla.gnome.org/show_bug.cgi?id=619665
 
* the eject buttons do not look/feel clickable, i.e., they don't
  change their appearance on hover events, 
 This was apparently committed before 3.0, but I don't see it. Bug is:
 https://bugzilla.gnome.org/show_bug.cgi?id=544103
 
  Of course, some of these missing features are due to cell renderer
  limitations, e.g. last time I tried, I couldn't get hover-in/hover-out
  events for individual cells to work good enough to implement a
  fully-working button renderer. But still, the places sidebar has more
  potential and the current implement feels somewhat half-baked.
 Yeah, GtkTreeView would need some changes to implement this properly,
 but a hacky solution works currently (see patches). I had filed this:
 https://bugzilla.gnome.org/show_bug.cgi?id=586458
 

I just added some comments to that bug, I *think* the solution will
be much less 'hacky' after introducing GtkCellArea (the patches on
that bug seem to sadly predate GtkCellArea by only a couple of months).

Cheers,
 -Tristan


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Sharing the places sidebar between Nautilus and GTK+

[Alexander Larsson]

On Tue, 2011-09-06 at 17:44 -0500, Federico Mena Quintero wrote:
 Hi, everyone,
 
 There is a patch in [1], by Jon McCann, to make the shortcuts bar in
 GtkFileChooser be pretty much the same as the one in Nautilus.
 
 Rather than patch the wobbly edifice that is gtkfilechooserdefault.c,
 this sounds like the perfect time to actually pull out the shortcuts bar
 as a public class of its own, that is shared by both the file chooser
 and Nautilus.
 
 My plan is this:
 
 1. Copy nautilus-places-sidebar.[ch] into the GTK+ sources.
 
 2. s/nautilus/gtk
 
 3. Remove obvious nautilus-isms like the use of nautilus_bookmark, which
 should be easy enough to replicate in GTK+ (or with things which already
 happen through the file chooser's code).

NautilusBookmarks is a horrible API that should be taken out in the
backyard and be put down quitely.

 4. See what common, public interfaces we need.  For example,
 
   nautilus_window_set_initiated_unmount (sidebar-window, TRUE);
 
 seems like it could be replaced with a signal on the GtkPlacesSidebar
 class, and then Nautilus can start a spinner or whatever when an unmount
 operation starts.  Another common interface would be something like
 gtk_places_sidebar_select_path (sidebar, file:///foo/selected) to
 highlight a particular item.

Sounds cool

 5. See what nautilus-isms *should* be doable with plain GIO, and see if
 there is anything else that Nautilus needs to do about them via signals;
 maybe for something like
 
   nautilus_file_operations_mount_volume_full (NULL, volume,
   volume_mounted_cb,
   G_OBJECT (sidebar));

I did a sweep through it and it seems that the sidebar isn't doing much
actual I/O and thus does not really touch the nautilus async I/O
machinery. That means it should be quite doable to untangle it from
nautilus like this. I might have missed something though.

 6. See what things should be available or not in the file chooser...
 when dropping files on the shortcuts bar, Nautilus can do
 
   nautilus_file_operations_copy_move (uris, NULL, drop_uri,
   real_action, GTK_WIDGET (tree_view),
   NULL, NULL);
 
 
 Same thing for
 
   nautilus_file_operations_empty_trash (GTK_WIDGET (sidebar-window));

These are availible via dbus on org.gnome.Nautilus.FileOperations, so
could potentially be used from Gtk+ too. That sort of places a
dependency on nautilus from Gtk+ though, and it will only work under
Gnome.

 I'm starting a branch in GTK+, places-sidebar to do this.  Comments
 are appreciated, especially from Nautilus hackers who may know dark
 places in this code well.
 
 One little caveat: that part of Nautilus is GPL, and GTK+ is LGPL,
 although it *seems* that the places sidebar code may initially have come
 from GTK+ and then reworked heavily.  I haven't checked the history
 closely.  What do we do about this?

Hmm, cosimo would know this best.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Sharing the places sidebar between Nautilus and GTK+

[Alexander Larsson]

On Wed, 2011-09-07 at 01:53 +0200, Jannis Pohlmann wrote:
 On Tue, 06 Sep 2011 17:44:01 -0500
 Federico Mena Quintero feder...@gnome.org wrote:
 
  Hi, everyone,
  
  There is a patch in [1], by Jon McCann, to make the shortcuts bar in
  GtkFileChooser be pretty much the same as the one in Nautilus.
  
  Rather than patch the wobbly edifice that is gtkfilechooserdefault.c,
  this sounds like the perfect time to actually pull out the shortcuts
  bar as a public class of its own, that is shared by both the file
  chooser and Nautilus.
  
  My plan is this:
  
  1. Copy nautilus-places-sidebar.[ch] into the GTK+ sources.
 
 To be honest, I think we can do better than this. The user experience
 offered by the current places sidebar is far from ideal IMHO. In
 Nautilus 3.x 
  
   * the sidebar has no mount/eject progress indicators,
   * the eject buttons do not look/feel clickable, i.e., they don't
 change their appearance on hover events, 
   * and the categories are a bit messed up (e.g. I have a few disks in
 Computer, other in Devices; mounted archives pop up in
 Network) and so on.
 
 Of course, some of these missing features are due to cell renderer
 limitations, e.g. last time I tried, I couldn't get hover-in/hover-out
 events for individual cells to work good enough to implement a
 fully-working button renderer. But still, the places sidebar has more
 potential and the current implement feels somewhat half-baked.
 
 For Thunar, I'm currently working on a widget to replace the
 GtkTreeView in the sidebar:
 
   
 http://mocha.xfce.org/~jannis/screenshots/xfce/thunar-shortcuts-pane-custom-20110604-1.png
 
 This sidebar consists of four classes (ThunarShortcutsModel
 and ThunarShortcut for modeling the data, the custom widgets
 ThunarShortcutsView and ThunarShortcutRow for representing the view
 with its rows). You can already check out the current state here:

I agree that these things would all be nice to have, and I don't
necessarily think that it is a bad idea to just not use the list view
for this. It doesn't really act or look much like traditional listviews
anyway, nor is it typically large enough that we can't just instantiate
normal widgets for all the entries in it. I'm all for that.

I'm not sold on having a complex view-model separation for the
underlying data like you imply above though, but I didn't really look
much at the code.

There is also the issue of look and behaviour. From a quick look at the
screenshot thunar seems pretty similar to nautilus, but I'm pretty sure
we can find places where they diverge. We would need to agree then which
behaviour to pick and be forever bound to that (or at least to agree on
further changes).


 In
 particular, faking the look of a tree view with custom widgets may seem
 like a hack to most people (even though standard GTK+ drawing routines
 are used).

I don't think this is the right way. We should define new style classes
and what not for the parts we require, then the themes should be made to
theme them to look like they want (which incidentally may be somewhat
like treeviews).

 I guess what I'm trying to say is... if you merge something like the
 places sidebar into GTK+ (as part of the public API), don't just take
 the existing sidebar as it is; please improve it to make really useful.
 I'd be happy to drop our sidebar if there's a good one in GTK+ (and if
 there's anything I can do to help with that, let me know).

I agree.


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Sharing the places sidebar between Nautilus and GTK+

[Jannis Pohlmann]

On Wed, 07 Sep 2011 15:24:48 +0200
Alexander Larsson al...@redhat.com wrote:

 On Wed, 2011-09-07 at 01:53 +0200, Jannis Pohlmann wrote:
  For Thunar, I'm currently working on a widget to replace the
  GtkTreeView in the sidebar:
  

  http://mocha.xfce.org/~jannis/screenshots/xfce/thunar-shortcuts-pane-custom-20110604-1.png
  
  This sidebar consists of four classes (ThunarShortcutsModel
  and ThunarShortcut for modeling the data, the custom widgets
  ThunarShortcutsView and ThunarShortcutRow for representing the view
  with its rows). You can already check out the current state here:
 
 I agree that these things would all be nice to have, and I don't
 necessarily think that it is a bad idea to just not use the list view
 for this. It doesn't really act or look much like traditional
 listviews anyway, nor is it typically large enough that we can't just
 instantiate normal widgets for all the entries in it. I'm all for
 that.
 
 I'm not sold on having a complex view-model separation for the
 underlying data like you imply above though, but I didn't really look
 much at the code.

Neither am I, actually. This separation only exists because it made
sense with the old sidebar. Now that file information is resolved
asynchronously in the background it's starting to become awkward to
keep model and view synchronized. (Our model not only contains the
GFile for each row, it also holds the volume, mount, ThunarFile and
whatnot.) This is the part that I don't really like and I'm considering
to just drop the model entirely.

 There is also the issue of look and behaviour. From a quick look at
 the screenshot thunar seems pretty similar to nautilus, but I'm
 pretty sure we can find places where they diverge. We would need to
 agree then which behaviour to pick and be forever bound to that (or
 at least to agree on further changes).

Yep, that's a problem. ;)

Its hard to predict the future of entirely unrelated pieces of
software from different projects, so maybe forcing a uniform UI for
this makes little sense at all? 

Here's a stupid idea: wouldn't it be possible to drop the file chooser
dialog entirely and have different file managers implement certain
D-Bus methods to show their own flavors of file and directory choosers
whenever GTK+ needs them? (Perhaps this could be implemented in the
form of a file chooser extension point, as is done in GIO, and
different desktop environments could ship individual implementations
for this.)

Again, this is probably stupid as the file chooser is so important to
GTK+ that we don't want to risk setups where no extension is available
and an error dialog pops up instead of a file chooser...

  In
  particular, faking the look of a tree view with custom widgets may
  seem like a hack to most people (even though standard GTK+ drawing
  routines are used).
 
 I don't think this is the right way. We should define new style
 classes and what not for the parts we require, then the themes should
 be made to theme them to look like they want (which incidentally may
 be somewhat like treeviews).

Sure. (Although, all it uses is a gtk_paint_flat_box() call. Anyway, I
get what you mean.) 

  - Jannis
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Sharing the places sidebar between Nautilus and GTK+

[Alexander Larsson]

On Wed, 2011-09-07 at 16:31 +0200, Jannis Pohlmann wrote:
 On Wed, 07 Sep 2011 15:24:48 +0200
 Alexander Larsson al...@redhat.com wrote:
 
  On Wed, 2011-09-07 at 01:53 +0200, Jannis Pohlmann wrote:
   For Thunar, I'm currently working on a widget to replace the
   GtkTreeView in the sidebar:
   
 
   http://mocha.xfce.org/~jannis/screenshots/xfce/thunar-shortcuts-pane-custom-20110604-1.png
   
   This sidebar consists of four classes (ThunarShortcutsModel
   and ThunarShortcut for modeling the data, the custom widgets
   ThunarShortcutsView and ThunarShortcutRow for representing the view
   with its rows). You can already check out the current state here:
  
  I agree that these things would all be nice to have, and I don't
  necessarily think that it is a bad idea to just not use the list view
  for this. It doesn't really act or look much like traditional
  listviews anyway, nor is it typically large enough that we can't just
  instantiate normal widgets for all the entries in it. I'm all for
  that.
  
  I'm not sold on having a complex view-model separation for the
  underlying data like you imply above though, but I didn't really look
  much at the code.
 
 Neither am I, actually. This separation only exists because it made
 sense with the old sidebar. Now that file information is resolved
 asynchronously in the background it's starting to become awkward to
 keep model and view synchronized. (Our model not only contains the
 GFile for each row, it also holds the volume, mount, ThunarFile and
 whatnot.) This is the part that I don't really like and I'm considering
 to just drop the model entirely.

Yeah, i see no reason for this kind of setup at all. If we have real
widgets for each row then all dynamic behaviour can be handled by each
row-widget rather than having to be triggered by the model and then
having some view propagate the new value for something into the row
widget.

All we need is a gtk container widget that sorts its children by some
property (and uses notify::property signal to cause a resort). Then all
the magic involved with updating the ui as things change can be fully
implemented in the row widgets. Then we just need a way to enumerate and
produce row widgets for each type of data, and a way to get signaled
when new rows should be added.

 Its hard to predict the future of entirely unrelated pieces of
 software from different projects, so maybe forcing a uniform UI for
 this makes little sense at all? 

On the other hand, we need a fileselector on unix and there is none, so
we must have *something*. And its while the sidebars may be different
they will not be vastly so, since we use a common base in GVfs.

 Here's a stupid idea: wouldn't it be possible to drop the file chooser
 dialog entirely and have different file managers implement certain
 D-Bus methods to show their own flavors of file and directory choosers
 whenever GTK+ needs them? (Perhaps this could be implemented in the
 form of a file chooser extension point, as is done in GIO, and
 different desktop environments could ship individual implementations
 for this.)

 Again, this is probably stupid as the file chooser is so important to
 GTK+ that we don't want to risk setups where no extension is available
 and an error dialog pops up instead of a file chooser...

Also, it makes it very very hard to do things like custom preview
widgets. I don't think this is really doable...


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Sharing the places sidebar between Nautilus and GTK+

[Federico Mena Quintero]

Hi, everyone,

There is a patch in [1], by Jon McCann, to make the shortcuts bar in
GtkFileChooser be pretty much the same as the one in Nautilus.

Rather than patch the wobbly edifice that is gtkfilechooserdefault.c,
this sounds like the perfect time to actually pull out the shortcuts bar
as a public class of its own, that is shared by both the file chooser
and Nautilus.

My plan is this:

1. Copy nautilus-places-sidebar.[ch] into the GTK+ sources.

2. s/nautilus/gtk

3. Remove obvious nautilus-isms like the use of nautilus_bookmark, which
should be easy enough to replicate in GTK+ (or with things which already
happen through the file chooser's code).

4. See what common, public interfaces we need.  For example,

  nautilus_window_set_initiated_unmount (sidebar-window, TRUE);

seems like it could be replaced with a signal on the GtkPlacesSidebar
class, and then Nautilus can start a spinner or whatever when an unmount
operation starts.  Another common interface would be something like
gtk_places_sidebar_select_path (sidebar, file:///foo/selected) to
highlight a particular item.

5. See what nautilus-isms *should* be doable with plain GIO, and see if
there is anything else that Nautilus needs to do about them via signals;
maybe for something like

  nautilus_file_operations_mount_volume_full (NULL, volume,
  volume_mounted_cb,
  G_OBJECT (sidebar));

6. See what things should be available or not in the file chooser...
when dropping files on the shortcuts bar, Nautilus can do

  nautilus_file_operations_copy_move (uris, NULL, drop_uri,
  real_action, GTK_WIDGET (tree_view),
  NULL, NULL);


Same thing for

  nautilus_file_operations_empty_trash (GTK_WIDGET (sidebar-window));

I'm starting a branch in GTK+, places-sidebar to do this.  Comments
are appreciated, especially from Nautilus hackers who may know dark
places in this code well.

One little caveat: that part of Nautilus is GPL, and GTK+ is LGPL,
although it *seems* that the places sidebar code may initially have come
from GTK+ and then reworked heavily.  I haven't checked the history
closely.  What do we do about this?

[1] https://bugzilla.gnome.org/show_bug.cgi?id=642712#c4

  Federico

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Sharing the places sidebar between Nautilus and GTK+

[Jannis Pohlmann]

On Tue, 06 Sep 2011 17:44:01 -0500
Federico Mena Quintero feder...@gnome.org wrote:

 Hi, everyone,
 
 There is a patch in [1], by Jon McCann, to make the shortcuts bar in
 GtkFileChooser be pretty much the same as the one in Nautilus.
 
 Rather than patch the wobbly edifice that is gtkfilechooserdefault.c,
 this sounds like the perfect time to actually pull out the shortcuts
 bar as a public class of its own, that is shared by both the file
 chooser and Nautilus.
 
 My plan is this:
 
 1. Copy nautilus-places-sidebar.[ch] into the GTK+ sources.

To be honest, I think we can do better than this. The user experience
offered by the current places sidebar is far from ideal IMHO. In
Nautilus 3.x 
 
  * the sidebar has no mount/eject progress indicators,
  * the eject buttons do not look/feel clickable, i.e., they don't
change their appearance on hover events, 
  * and the categories are a bit messed up (e.g. I have a few disks in
Computer, other in Devices; mounted archives pop up in
Network) and so on.

Of course, some of these missing features are due to cell renderer
limitations, e.g. last time I tried, I couldn't get hover-in/hover-out
events for individual cells to work good enough to implement a
fully-working button renderer. But still, the places sidebar has more
potential and the current implement feels somewhat half-baked.

For Thunar, I'm currently working on a widget to replace the
GtkTreeView in the sidebar:

  
http://mocha.xfce.org/~jannis/screenshots/xfce/thunar-shortcuts-pane-custom-20110604-1.png

This sidebar consists of four classes (ThunarShortcutsModel
and ThunarShortcut for modeling the data, the custom widgets
ThunarShortcutsView and ThunarShortcutRow for representing the view
with its rows). You can already check out the current state here:

  http://git.xfce.org/xfce/thunar/log/?h=jannis/new-shortcuts-pane

I realize that, aside from the code still being somewhat rough and
imcomplete, this is nothing we'd want to stuff into GTK+. In
particular, faking the look of a tree view with custom widgets may seem
like a hack to most people (even though standard GTK+ drawing routines
are used). On the other hand it is fun to use and shows how the places
sidebar *could* work IMHO:

  * progress indicators for async operations, 
  * real mount/eject/cancel buttons ('cuz spinners alone are not
enough),
  * individual row/button highlighting on hover,
  * keyboard navigation works (even switching between rows and
buttons is possible), 
  * a GtkTreeModel is used to model the data,
  * all file information is resolved asynchronously, and
  * categories are less cluttered and messed up (every location pops up
only once; archives and devices appear in Devices,
personal folders and bookmarks appear in Places, remote locations
and the Network button show up in Network).

I guess what I'm trying to say is... if you merge something like the
places sidebar into GTK+ (as part of the public API), don't just take
the existing sidebar as it is; please improve it to make really useful.
I'd be happy to drop our sidebar if there's a good one in GTK+ (and if
there's anything I can do to help with that, let me know).

  - Jannis
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Sharing the places sidebar between Nautilus and GTK+

[Jannis Pohlmann]

On Wed, 7 Sep 2011 01:53:44 +0200
Jannis Pohlmann jan...@xfce.org wrote:

(snip)

 On the other hand it is fun to use and shows how
 the places sidebar *could* work IMHO:

(snip)

BTW, here's a (possibly incomplete) list of features we're aiming at
with the new Thunar sidebar. I think they are really worth working
towards:

http://wiki.xfce.org/design/thunar/shortcuts-pane#summarized_requirements_list_and_implementation_status

  - Jannis
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list