[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