Re: GtkToolbar drag and drop

[Michael Meeks <michael ximian com>]

Hi Marco,

On Fri, 2003-10-03 at 22:32, Marco Pesenti Gritti wrote:
> in short ... it doesnt. This is a serious shortcoming in current implementation.

	Great - as long as that's on your radar, I'm happy :-)

> To make it play nicely with merge it would probably be necessary to use GtkUIManager
> data model instead of our own. I have the impression this would result in moving most of the drag
> and drop code in gtkuimanager itself.

	Yes - something like that; possibly it'd be worthwhile reserving
slightly more than 4 class slots in the GtkUIManager - since it's not
really inherited from a lot, and they are fairly cheap.

> Another issue to solve is the user interface implementation. I'm
> not sure how drag drop and merged toolbars could interact (for example
> in which "layer" has the item been dropped ?).

	Right; so I guess there are perhaps 2 problems; one is that some items
will not be editable - simply because either the system is locked down,
or the remote component doesn't support the right interface; so those
need to be handled.

	It's certainly true that detecting where the item has been dropped is
pretty interesting :-) I guess you need to associate actions with a
layer (or merge-id) - which makes sense conceptually. Then we get to
look at the tree and do some fun things; I guess you need to seek up /
down the tree from the insertion point to find the nearest sensible
placeholder with the same merge_id.

	Of course - the problem with all these schemes is that it's impossible
to predict what order the items will be in when you next merge /
de-merge since our item sorting is not stable over those operations[1];
so I guess you can only do a 'good enough' type job to try and get some
sanity into the ordering; either that or intelligently disallow a set of
places to drop the new icon [ but then displaying where they are is an
interesting problem perhaps ].

	Then - I guess with serialising there is the problem that at some
stage, up-stream actions change / are removed etc. and over time the
default UI changes very much from what we've saved as a snapshot to the
point where the app is unusable ;-) I guess some sort of serial number
that can be compared and (infrequently) bumped to override that prolly
makes sense (?).

	Anyway - I think in all the problems are surmountable, but it just
needs some careful thought - and it's not quite as easy as it might seem
initially [ which is ultimately why no-one has ever got around to a
Bonobo UI toolbar editor I guess ].

	HTH,

		Michael.

[1] - the problem of stability still concerns me slightly; the only way
I can think of to get repeatable ordering is to have an integer index
per item that we sort by (in the absence of anything else). Perhaps it's
not really worth worrying about though;
-- 
 michael ximian com  <><, Pseudo Engineer, itinerant idiot