[Gtk-sharp-list] Gtk-sharp-list Digest, Vol 43, Issue 3

Adam Tauno Williams adam at morrison-ind.com
Tue Nov 18 15:29:56 EST 2008


On Tue, 2008-11-18 at 13:42 -0500, Vladimir Giszpenc wrote:
> >> This is a follow up to:
> >> http://go-mono.com/forums/#nabble-td19464372
> >> Mike Kestner wrote:
> >> > Now that we have GInterface registration, I think I'd like to move
> >> > NodeStore to use an internal managed TreeModel implementation and get
> >> > rid of the glue model it currently utilizes.  Then the TreeSortable
> >> > interface could be implemented in managed code as well to provide
> >> > sorting on the NodeStore.
> >> > Maybe I'll make that an evening and weekend project, or of course, I'd
> >> > be happy to work with anyone who wants to take a stab at it and provide
> >> > a patch.
> >> Any luck?
> > Nothing to my knowledge.
> > I'm wondering if it wouldn't, in the end, be easier just to kick
> > TreeView and NodeView to the curb and try to use the ListView
> > implemented by Banshee (the Hyena subproject)
> > <http://www.koders.com/csharp/fid17F12F323AA7D9B9E693343447AF53895134E809.aspx>.
> I went to look in svn and a lot of comments say "still under very
> heavy development."
> Are these comments out of date?

Beats me!  :) I'm not a Banshee developer,  I just found a BLOG post
about how much he/she/they [don't recall] dislike TreeView while looking
for how on earth you get TreeView to... I don't know.... work.   So it
has been on my list of things to try out.   Would probably be best to
try and just lift the widget parts out into a separate assembly since it
doesn't feel like it is really setup for general use.  Maybe start a
project called "Stolen Widgets" or "Red Hot Widgets" on Google Code. :)
There are other Gtk# that need plundering as well;  the calendar view
<http://www.iola.dk/nemo/> from nemo, for example.

> It seems that way given how long these files have sat around.

I assume that.   I generally disregard commit comments,  especially when
dealing with code that itself doesn't have *any* inline comments at all.

> Also, would it make sense to allow right clicks?  This is very handy
> for adding context menus.  It is all done in code by creating
> MenuItems right now, but one could probably associate actions to the
> widget for a nice generic context menu display.  This code was mostly
> stolen from somewhere.  Anything I added is as free as it was
> before...
> On line 461 of ListView.cs.
> if(evnt.Button == 3) {
>   OnMouseButtonClick(new MouseButtonPressedEventArgs(evnt));
>   return true;
> }

OnPopupMenu only fires if right button was clicked and an item is
selected.  So it essentially does this.  One can, of course, connect a
button press event handler using ConnectBefore and override the default
behaviour.   But the processing of a button click/release on the widget
actually turns out to be pretty complicated.  Since you must inherit
from ListView<T> anyway just performing an override of OnPopupMenu seems
correct,  your OnPopupMenu could invoke an event handler if that suits
the purpose.

public EventHandler PopupDelegate;

protected override bool OnPopupMenu()
{
  if (PopupDelegate == null) return false;
  PopupDelegate(....
}

> Oh and don't forget
>  public event EventHandler MouseButtonClicked;

I don't know,  you can already attach a press/release handler, it is
widget after all.  The Hyena ListView provides a much higher-level model
of RowActivated, SelectionChanged, and PopupMenu events which is what,
IMO,  applications want 99.999999% of the time.   My little demo code
certainly doesn't demonstrate everything the ListView supports.



More information about the Gtk-sharp-list mailing list