RE: [gtkmm] Easier Drag and Drop

[Murray Cumming Comneon com]

erik echohome org
> class MyTargetWidget :
> 	public Gtk::EventBox,
> 	public drag_drop_target<MyTargetWidget>, AcceptList( 
> "MyButton", "MyTreeView" ) {

Firstly, I don't think that's C++, unless AcceptList is some kind of macro.

> 	// CTORs & DTORs
> 
> 	// Optional Overrides for template provided defaults
> 	void drag_drop_enable( bool );
> 	void drag_data_received( ... );
> 	void drag_leave( ... );
> 	void drag_motion( ... );
> 	... - there may be more
> }
> 
> class MyButton :
> 	public Gtk::Button,
> 	public drop_drop_source<MyButton, "MyButton">

And values for template parameters are difficult, though this might very
possibly work.

> {
> 	// CTORs, DTORs
> 
> 	// Optional Overrides for template provided defaults
> 	void drag_drop_enable( bool );
> 	void drag_icon( Glib::RefPtr<Gdk::Pixmap> pix );
> 	void drag_data_get( ... );
> 	void drag_data_delete( ... );
> 	... - there may be more
> }

But even if we could make this work:
1. I don't see how it's any better to define the targets and sources via the
inheritance tree than by using member set_*() methods.
2. This means that you _must_ derive a new widget, and you can't just call
set_*() on a normal Gtk::Button.

>     I guess the idea is to hide, or move, a lot of what the 
> example code does a the dndwindow CTOR.

Well, can you tell me what you want to hide. But please do look at the
versions of the examples in gtkmm 2.4, which have slight improvements.

I would like to make stuff simpler and make is as easy as possible to get
the most commonly-used functionality quickly. I suspect that we do need to
avoid the hardcoding of those strange target type names, or we at least need
to point people to some authorative documentation about them. For instance,
I personally have no idea what is the difference between "STRING" and
"text/plain".

Murray Cumming
www.murrayc.com
murrayc usa net