After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 116297 - Handle pack_end in gtktoolbar.c:find_drop_pos()
Handle pack_end in gtktoolbar.c:find_drop_pos()
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.2.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2003-06-29 23:24 UTC by Soren Sandmann Pedersen
Modified: 2011-02-04 16:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Soren Sandmann Pedersen 2003-06-29 23:24:24 UTC
Quoting Owen from

http://mail.gnome.org/archives/gtk-devel-list/2003-June/msg00135.html

- I don't see handling of pack_end in gtktoolbar.c:find_drop_pos();
  in fact, there seems to be some conceptual difficulty with
  drag-and-drop editing and pack_end. Perhaps easiest is to have an
  additional boolean out and let the toolbar editor figure it out.
  Dragging a pack end item before the first pack end item is
  a tricky situation (it isn't distinguishable from dragging after
  the last pack start position), and probably should just be impossible.
Comment 1 James Henstridge 2003-06-30 06:32:28 UTC
CC'ing Anders on this too, since he did the pack_end implementation.

The idea of items packed at the end was to support things like
throbbers in nautilus or web browsers.  If you are customising the
toolbar of apps like this, you most likely want to ignore the throbber
completely, which is why I implemented find_drop_pos() as it is.

Do you agree with this reasoning?
Comment 2 Anders Carlsson 2003-06-30 07:37:32 UTC
FWIW, OSX does this by having a "flexible space" toolbar item. It's
pretty different from what gtk+ usually does, but could make things
easier.
Comment 3 Owen Taylor 2003-08-04 15:20:23 UTC
Anders comment does make me one if we actually need
pack_end at all for the toolbar, a hypthetical

  gtk_separator_tool_item_set_draw()
  gtk_tool_item_get_expand()

seems like a relatively fine way of forcing things to
the end and definitely simpler. Though different from GtkBox, 
I'm not sure that's a problem.

(On the other hand, the pack_end stuff is working now,
so may be best not to change if we can find some
reasonable way of representing it in find_drop_pos)
Comment 4 Soren Sandmann Pedersen 2003-08-26 15:43:00 UTC
I think Owen's suggestion makes a lot of sense. Anders, do you know
what Mac OS X does if there is not enough room on the toolbar for the
new item?

Comment 5 Anders Carlsson 2003-08-26 16:02:20 UTC
Do you mean when editing or otherwise? I know OS X has an overflow
menu, just like GtkToolbar.
Comment 6 Soren Sandmann Pedersen 2003-08-26 17:20:40 UTC
Yeah, I mean when editing. (I asked on the wrong bug, sorry)
Comment 7 Soren Sandmann Pedersen 2003-08-28 13:42:00 UTC
On second thought, if we had expnd + no-draw separators, how would
size_allocate() decide which items to unmap?
Comment 8 Soren Sandmann Pedersen 2003-10-25 20:28:01 UTC
Thu Oct 23 21:55:10 2003  Soeren Sandmann  <sandmann@daimi.au.dk>

	* gtk/gtktoolbar.c (gtk_toolbar_highlight_drop_location): Make
	this function take an index and a GtkToolItem.

	* tests/testtoolbar.c (main): Make "Show Arrow" default to
	true. Make one of the separators !draw and expand.
	Update for new highlight_drop_location() API.

	* gtk/gtktoolitem.[ch]: Remove "pack_end" property

	* gtk/gtktoolbar.h: Formatting fixes.

	* gtk/gtktoolbar.c: Remove "pack_end" child property. Allow
	separator tool items to expand.
	(logical_to_physical, physical_to_logical): Fix off-by-one errors
	(Fix #125472, Marco Pesenti Gritti)

	* gtk/gtkseparatortoolitem.[ch]: Add new "draw" property.
	(gtk_separator_tool_item_expose) only draw if "draw" is TRUE. Also
	return FALSE, not TRUE.
	(gtk_separator_too_item_{set|get}_property,
	(gtk_separator_tool_item_{set|get}_draw): new functions