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 386950 - Notebooks need to be able to reject dragged tabs
Notebooks need to be able to reject dragged tabs
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: GtkNotebook
2.10.x
Other All
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2006-12-17 21:32 UTC by Christian Hammond
Modified: 2015-03-08 16:02 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Hammond 2006-12-17 21:32:02 UTC
In some applications, there are tabs that you would want draggable but you'd only one one of them per notebook. An example of this is the Home tab in VMware Workstation.

It would be very nice to have a way to prevent a tab from being dropped onto a notebook under certain conditions as defined by the program. At the time the tab hovers over the notebook, a signal should be emitted, allowing callbacks to return TRUE if the drag is allowed or FALSE if it's disallowed. If any handler returns FALSE, the user should get some visual indication that the tab can't be dropped on the notebook. At that point, if you user attempts a drop, we should either create a new window or just cancel the whole operation.
Comment 1 Carlos Garnacho 2006-12-23 15:36:19 UTC
Tabs detaching feature is just some sugar on top of drag & drop API, IMHO its behavior should be overridden by connecting to the "drag-*" signals.

In this case, you may connect to "drag-motion" here and call gdk_drag_status (context, 0, time); to tell that you don't want to drag the tab there.
Comment 2 Christian Hammond 2006-12-23 20:57:36 UTC
Sure, from a GTK+ development standpoint, it's clear that this is just extra sugar on top of the drag and drop API. However, it's 1) not enough sugar for large, real-world applications, and 2) not something third party developers should ever have to know or care about. GTK+ is a toolkit for making user interfaces and should give developers decent flexibility to do what they need instead of giving them bare-minimums and making them work around limitations in the API.
Comment 3 Carlos Garnacho 2006-12-27 10:23:01 UTC
IMHO, adding extra API is OK if the feature is popular enough, but if GTK tried to satisfy everyones' demands, there'd be "double-clicked", "right-clicked" and "triple-clicked" signals for GtkButton, "row-clicked" and "maybe-drop-row" signal for GtkTreeView and so on, when underlying events and DND signals are powerful enough to let API users tweak stuff to match their needs.

Said this, I'm not a GTK dev, if Matthias or any other considers it's a worthwhile addition, I'm more than OK with this :)
Comment 4 Matthias Clasen 2015-03-08 16:02:01 UTC
didn't happen