GNOME Bugzilla – Bug 386943
GtkNotebook's page-added/page-removed signals are not specific enough
Last modified: 2015-03-08 15:10:22 UTC
GtkNotebook's page-added and page-removed signals are not always informative enough. There are many cases in an application (and we've hit this with VMware Workstation 6) where you want to distinguish between a tab that was simply added to a page and a tab that was attached to a page through drag-and-drop. Likewise with removed and detached. We could add new tab-detached and tab-attached signals. They would be essentially the same as page-removed and page-added. However, the problem now is that for backwards-compatibility, we'd probably need to continue calling page-removed and page-added, but that can lead to further frustrations as the program now has to keep state to find out if it already handled an attached/detached tab. Another option is to provide a gtk_notebook_get_tab_floating or similar that would return if the widget is still in its drag operation. It would be set to TRUE at the beginning of a drag operation and while page-added/page-removed is called. Afterward, it would be set back to FALSE. This would allow page-added/page-removed signal handlers to query the state and handle the operation properly.
Wouldn't connecting (after or before) to "drag-data-received" tell you when you're dropping a tab to a notebook (and thus, removing it from the source notebook)?
Sure, but that only tells you when a drop occurred and still requires that the calling app keep track of state to tell the difference between drops and regular page adds. It doesn't tell you a thing about removes though. Sure, the handler for the drop can detect the remove from a different notebook, but that function shouldn't know about the other notebook specifically. Imagine if both notebooks are in different parts of the codebase but just happen to be compatible, drag-and-drop-wise. I wouldn't want parts of libmywidgets1 knowing about parts of libmywidgets2 in that way. It's also just not friendly enough. There isn't a huge effort involved in making this API just work in this way, as opposed to the burden we're putting on developers to work around it. As an app developer trying to use this feature, I know such a change would be most welcome by developers of large codebases trying to implement this.
probably "drag-data-delete" is what you may use in the source side.
nothing ever happened here, sadly