Re: GtkToolbar drag and drop



Michael Meeks <michael ximian com> writes:

> discussion of some "fake expose" stuff to get an image of a widget
> for

Not in conjunction with the toolbar, I don't think.

> the preview process. If this goes through - it'd be nice to abstract
> the fake_expose thing at the widget level for use in the
> control-center as well ( I guess ).

Yes, you could imagine having that feature in gtk+, but I don't plan
on using anything like it in the toolbar.

You could imagine the toolbar editor using it to generate the
drag-and-drop icon image, but you'd have to ask Marco about that.

> 	It's also unlikely that the fake_expose will ever work properly for out
> of proc controls 

I know practically nothing about XEMBED, but is there any reason this
transaction coulnd't take place:

        socket: "please draw yourself to a pixmap"
        plug: "ok, I have drawn myself to a pixmap with ID <xid>"

> - so, presumably there will always be some way to submit an image
> for a widget in a more obvious fashion ?

If you are talking about images the toolbar would use to preview the
new item, then that's not an issue because

        a) the toolbar just uses blank space to indicate where new
           items will go.

        b) _if_ it would generate preview items, it would just use the
           widget that was passed in to gtk_toolbar_highlight_drop(),
           ie. it would either actually add the widget to the toolbar,
           or it would base the image on the type of the tool item.

           So there is not even hypothetical cause for alarm.

> 	Also - the discussion about merge-id's suggests that there will be some
> places (unusual but possible) where it is not possible to drop an item [
> lack of placeholder / adjacent item etc. ]. Does the API handle that ?

Yes, with the planned API, drag and drop is driven by whoever wants to
drop something on the toolbar, so said whoever can just not drop and
not highlight  if it doesn't like the position of the new item.

Btw. if you need something to be concerned about, consider that I am
seriously thinking about removing support for "pack_end" on tool items
in favor of using expandable, no-draw separators to force things to
the end.

That's item (b) in the mail you are replying to.


Søren



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]