GNOME Bugzilla – Bug 602882
Deprecate GtkTearoffMenuItem
Last modified: 2012-01-13 05:24:44 UTC
As discussed in the GTK+ meeting: http://mail.gnome.org/archives/gtk-devel-list/2009-November/msg00187.html , GtkTearoffMenuItem should be deprecated. Also, gtk_menu_set/get_tearoff_state(), gtk_combo_box_get/set_add_tearoffs, gtk_ui_manager_get/set_add_tearoffs () and add-tearoffs, tearoff-title and tearoff-state properties should be deprecated too See bug #597904 for more info
I am not happy with this. I use tearoff menus regularly in pcb (an application to design printed circuit boards). To me this is a valuable feature of the GUI. ---<(kaimartin)>---
I also find this feature useful. Are there any other problems than the "Need get/set accessors to GtkTearoffMenuItem::torn_off" and the "a bit passé"-comment as stated in https://bugzilla.gnome.org/show_bug.cgi?id=597904#c0 ?
Can you please describe actual usecases and why a Tearoff menu is so important to keep it, compared to a normal menu?
I is all about speed and productivity.
Hmm, that's buzzwords, but no actual arguments... :-( Why are your users unproductive when using a normal menu? Why does it take longer? I don't know your application, but if you want to convince developers to keep the tearoff menu in you should elaborate way more. Thanks in advance. (/me just playing the bad cop here)
(In reply to comment #5) > Why are your users unproductive when using a normal menu? Why does it take > longer? In my case (pcb, see above): This is a settings menu, whose items can be on or off. If a setting is on, there is a little marker in front of the item. The Settings menu looks like this: Settings Auto Swap Line start angle All Direction lines Orthogonal Moves Crosshair Snaps to Pins Crosshair Shows DRC Clearance Auto Enforce DRC Clearance Lock Names Only Names Hide Names (...) These options influence the behavior of the application. There are a few items I like to switch on and off many times per session (e.g. Lock Names). The tear off feature lets me put this set of toggles on the other screen of my desktop for permanent display and instant access. In short: Tear-off menus provide me with the opportunity to tune the GUI in a way I need. Developers of the application don't need to know in advance what my needs are. ---<(kaiamrtin)>--
(In reply to comment #5) > Why are your users unproductive when using a normal menu? Why does it take > longer? I am a user and a developer of GTK based application programs. I use the tearoffs menu features a lot especially in VLSI EDA programs and Gnome Emacs. Just to list a few simple and obvious cases: 1) In VLSI EDA programs, many menus items are grouped based on sequences/sub-sequences of actions(tasks) needed for a particular design phase. Without the tearoffs, the designer would have to do: - select menuX->Action0; Result looks good - select menuX->Action1; Result looks good ...... - select menuX->ActionN oops, ActionN fails, fix the problem, fixed; hmm, was I using menuY or menuX? - redo, select menuX->ActionN - select menuX->ActionN+1 - and so on. With the tearoffs, we save clicks and we don't lose context and visibility of tasks and sequences at hands (the teaoffs-menu is still visible). It also let the designer to focus on the design and reduce mistakes. - select menuX->tearoffs; Move the teared-off menu to a convenient location. - select Action1; Result looks good - select Action2; Result looks good - and so on. 2) In VLSI EDA programs, especially the "Schematic Driven" EDA program requires many "nested submenus" to save window real estate. More clicks can be saved and less annoying to the designer about context. What would a VLSI designer think if he/she has to repeatedly do : - select menuX->submenu0->Action0; check results - select menuX->submenu0->ActionN and so on. He/She might say, "the EDA developer is incompetent" 3) When a context menu-item/submenu-item action depends on first selecting some objects in the main window, the above cases become even more annoying and unproductive for VLSI designers if without tearoffs. Well, we can always emulate the feature by making the first menu-item/submenu-item action to activate a popup menu intead. But that should not be necesary if GTK3 keeps this "essential menu tearoffs feature" which most other GUI toolkits still maintain (Qt4 for instance). I am just curious: a) Is it too difficult to maintain this feature? b) Is it becauce of lack of resources and time to fix it before the release? c) has anyone inform the Emacs developers/users about this feature depreciation?
all the requests for maintaining this feature basically boils down to one specific usage: keeping a toolbox around. there are better (coding-wise and usability-wise) ways to do that with gtk+ *currently* than using a tear-off menu to emulate a toolbox. (In reply to comment #7) > I am just curious: > a) Is it too difficult to maintain this feature? this is a badly posed question: *every* feature has a burden in terms of maintainership. > b) Is it becauce of lack of resources and time to fix it before the release? it's because the lack of resources and the impact of having to keep around widgets that were designed to fit in with applications written in the 1980s, and keep them constantly up to date, while the whole platform moves with the times. > c) has anyone inform the Emacs developers/users > about this feature depreciation? no, but you're welcome to point them to this bug.
(In reply to comment #8) > all the requests for maintaining this feature basically boils down to one > specific usage: keeping a toolbox around. there are better (coding-wise and > usability-wise) ways to do that with gtk+ *currently* than using a tear-off > menu to emulate a toolbox. There is one major difference: With tearoffs, the user has a choice to pick and place anywhere, one or more stick-around menus, at anytime, from any menus and sub-menus listed under the menubar with fewer clicks.
(In reply to comment #9) > (In reply to comment #8) > > all the requests for maintaining this feature basically boils down to one > > specific usage: keeping a toolbox around. there are better (coding-wise and > > usability-wise) ways to do that with gtk+ *currently* than using a tear-off > > menu to emulate a toolbox. > > There is one major difference: > With tearoffs, the user has a choice to pick > and place anywhere, one or more stick-around menus, > at anytime, from any menus and sub-menus listed > under the menubar with fewer clicks. yes, I do know how tearoff menus work, thank you very much. what I'm arguing is: • tearoff menus are used to implement toolboxes; gtk+ recently (and I mean today) merged the toolpalette widget to make it even easier to write UIs with toolboxes; • tearoff menus are used in specific applications, much like other widgets that have been deprecated and are planned to be removed (GtkCurve, GtkHSV); hence, they should be removed from gtk+ 3.0. you are still free to copy and paste the code into your application, if license allows it. or you might wish to re-evaluate the user interaction of your application if you rely on a piece of ancient UI design like tearoff menus.
(In reply to comment #10) > • tearoff menus are used to implement toolboxes; gtk+ recently (and I mean > today) merged the toolpalette widget to make it even easier to write UIs with > toolboxes; When there are basically hundreds if not thousands of frequently changed actions needed to be groups as menus/submenus, with long descriptive menu-item labels, the toolbar/toolbox/toolpalette form only gets in the way and takes up precious real estate in the window. A runtime dynamic loadable menubar/menu/submenu is the right form for our application. The toolbar/toolbox/toolpalette form is most appropriate for commonly used toolbox such as editing schematics and such tasks, where designer can remember relatively few icons/short-label for its action. The menus/submenus form is most appropriate when menus-items are numerous and menu changes are frequent, and needs descriptive labels. Each form has its own use.
Created attachment 148618 [details] [review] Patch Not sure if I'm missing anything here for just a deprecation patch for 2.20. Let me know if I should add anything else to this.
Comment on attachment 148618 [details] [review] Patch Missing some stuff, will file a new patch soon.
Created attachment 148625 [details] [review] Improved
(In reply to comment #5) > Hmm, that's buzzwords, but no actual arguments... :-( > Why are your users unproductive when using a normal menu? Why does it take > longer? > I don't know your application, but if you want to convince developers to keep > the tearoff menu in you should elaborate way more. > Thanks in advance. > (/me just playing the bad cop here) To clarify and elaborate a bit more on our usage of tearoff menus: 1) Tearoff menus may be used to implement toolboxes, but that is not our usage. Here I am talking about tearoffs for menu/sub-menu with descriptive menu-items/submenu-items labels, not about toolbox/toolpalette which we can implement without tearoffs. We do not require VLSI designers to learn any toolpalette "picture/icon language" to use our apps. 2) Our application consists of hundreds if not thousands of contextual nested menu-items/sub-menuitems actions, subsets of which can be runtime dynamically created, configured, scripted, menu-nized, loaded and activated or destroyed. (There is an embedded script interpreter in our C/GTK+ application). Our application must adapt effortlessly to constantly changing design processes, and tools-chain environment. The tearoffs menu/submenu feature allows the designers to pick and place anywhere, one or more stick-around menus, at anytime, from any menus and sub-menus listed under the menubar with fewer clicks. Thanks for listening. Please let me know if I need to elaborate more.
Created attachment 151094 [details] Example submenu. Nicely integrates into menu and also tear-off-able
I've just recently picked up developing of ZeroRadiant aka GtkRadiant 1.6 and further expanded the implementation of tear-off menus within it, based on user feedback. The argument about bad/ancient/legacy GUI design can probably never be won, as it's totally subjective. However what amazes me is how even Windows (!) users got used to this feature in particular; for that one has to know that in ZeroRadiant this is *off* by default (with the argument that Windows users are not used to it), yet everyone seriously into working with that application uses it, I've been told. Those are likely users with very wide screens or even two of them. If deprecated, taking the sources into the application itself will work, no doubt. Yet it would be great if it would stay.
Hi *, I'd like to join the lines of those pleading against the deprecation of tear off menus. I always considered tear off menus as an advantage in GUI design and an special way of user empowerment: It allows users to convert menus and especially sub- (or sub-sub-..) menus on demand to something toolbox like. Now why is this so great? Because menus are good in what they are used for, especially in big applications with _many_ functions like gimp for instance: to make each and every function available in an hierarchic tree with textual descriptions. But they are inconvenient if one wants to use the same (set of) function over and over again. For the later case toolboxes are nice, but they have there downsides too: to make them space efficient they use small icons instead of verbose text -- which is fine once you know them but if you don't you have to wait for pop-up help, their ability to map hierarchic structures are at least limited and they eat up screen space unless you actively close them -- so all in all they are good for quick access but bad for completeness... The thing with applications like gimp is, that functions which most of the time are used only once in a while (and therefore placed in menus) can suddenly become a essential part of a specific work flow -- and then the user wants them more easy access able. Currently this is easy done: tear of the menu and use it like a toolbox. The most cool thing about that it is: the developers don't have to know about the users needs in advance (which they really can not do at all, as the specific uses and work flows are way to manifold with such generic applications). Even better: the user him self does not need to know in advance either -- as he would with solutions like configurable tool boxes and the like. No configuration of custom setups, just the ad-hoc observation that one is going to use the very same sub menu a lot at a given time: tear it of and you save a number of clicks. I'm not to say that tear of menus deprecate other means of customization (as for example user defined key bindings which i find very convenient, too, or customize able toolboxes etc.) but I hope I was able to show that they are a quite unique way of empowering the user to boost productivity on demand in certain situations. Please reconsider your plans to deprecate tear off menus -- they are one of the great features which make gtk+ superior over other toolkits. :) cheers sascha
I do agree with poeple that want tear-off menus to stay in Gtk+. This functionnality goes beyond Toolbox emulation. To keep efficiency of tear-off menus, their use in VLSI application or Gimp are two differents uses cases that can't be emulated via toolboxes. The important thing here is dynamicity. Toolbox aren't dynamic. - Preferences toolbox setup are not a solution for a temporary need of the user for repetitive actions. - toolboxes don't scale with hundreds of dynamic entries (no textual information)
(In reply to comment #19) > To keep efficiency of tear-off menus, their use in VLSI application or Gimp are > two differents uses cases that can't be emulated via toolboxes. > The important thing here is dynamicity. > Toolbox aren't dynamic. why? toolboxes can have new children like any other widget. > - Preferences toolbox setup are not a solution for a temporary need of the user > for repetitive actions. demonstrably false, but I guess you have user testing that proves me wrong for such a strong statement. > - toolboxes don't scale with hundreds of dynamic entries (no textual > information) if your UI has hundreds of dynamic entries then your UI has a problem; if the UI gets better by tearing off a menu with hundreds of entries then your UI has two problems. since TearOffMenus would be simply deprecated from 2.22 and removed from 3.0 you could keep your dependency on gtk+ 2.x (your application use cases are still using concepts from 1991, I don't see a problem with depending on a different version of a modern toolkit); eventually, you could even take the TearOffMenu widget from gtk+ and copy it in your application.
> if your UI has hundreds of dynamic entries then your UI has a problem; if the > UI gets better by tearing off a menu with hundreds of entries then your UI has > two problems. What problems? Hundreds if not thousands of dynamic entries, does not mean literally all of them are presented to GTK+ at the same time. In fact, only a fraction of them need to be presented to GTK+ at a time, and configurable anytime by the users. Please read the sentence I posted before: "Our application consists of hundreds if not thousands of contextual nested menu-items/sub-menuitems actions, subsets of which can be runtime dynamically created, configured, scripted, menu-nized, loaded and activated or destroyed." Please note "subsets" and "menu-nized": which means they are categorized into menus/submenus and can be run-time "DYNAMICALLY" loaded and destroyed as needed. Thus the notion of "dynamic". A reasonable menubar may consist of upto 10 menus. A reasonable menu may consist of upto 10 menu-items/submenus. A reasonable submenu may consist of upto 10 to 15 submenu-items. A reasonable menu system does not bloat the menu/submenu with unnecessary items for a particular design, and does not preclude the user from creating and loading other submenus needed for the tasks, on the fly or not. In EDA GUI application with "Schematic Driven" methodology, not just VLSI EDA, "context", "sequence of actions" and "visibility" are very important to the designer(user). They enable the designer to be more productive, concentrate on the tasks at hands, and avoid making very costly mistake due to misunderstanding and distraction. Here are just the very obvious: 1) Context: These are the different kinds of design or different phases of a design related to the use of our EDA GUI application program. Hierarchical menu/submenu can present the user with clear context of design tasks pertaining to a particular design phase and design processes. TearOffs allows that context to be clearly visible. Different kinds of design: VLSI design, PCB design, CASE design, etc.. Different phases of a design: (for VLSI design in particular): "Architecture design", "Schematic Capture", DRC, "Netlist Generations", "Logic Synthesis", "Simulations" "Layout Synthesis", LVS, LPE back anotation,... ,etc., and many many design processes. Multiply all of those design kinds by all of the design phases for each design kind, then by many downstream tools (to be driven by our EDA programs) available for each design kinds and phases, and with many choices of design processes, hundreds of actions might be an under statement. 2) "Sequences of actions": Each design process of a design phase of a particular kind of design require sequences of actions in some particular order. Menuitem/submenu-items with descriptive labels, is a perfect form to list them in certain preferred order, may be separated by "Separators" for sub-sequences of ordered actions. 3) "Visibility" Menus and submenus can be presented to the user with clear visibility of what tasks(actions) are available for a particular design process of a design phase. Navigate to a particular submenu can give the user a quick grasp of what needs to be done, and in what possible sequences. Menu and submenu can be changed dynamically, may be because of a newly available downstream tool, or because the user/developer found a better way for some new actions, etc.. AS changes to menus and submenu actions are very frequent, visibility can be very important. Once a suitable action group in submenu is identified by the user, the user just tear it off and start performing the tasks in that context. As far as I know, most modern GUI toolkits support tearoffs. I sincerely hope that the GTK+ development team will reconsider this move. If more explanations are needed, I will be glad to provide them.
(In reply to comment #20) > > - Preferences toolbox setup are not a solution for a temporary > > need of the user for repetitive actions. > > demonstrably false, Did you note the key word "temporary"? If I have to find, or set-up a proper toolbox every time I hit a repetitive task, I'd spend way too much time reconfiguring my personal GUI. > > - toolboxes don't scale with hundreds of dynamic entries (no textual > > information) > > if your UI has hundreds of dynamic entries then your UI has a problem; if the > UI gets better by tearing off a menu with hundreds of entries then your UI has > two problems. Widget set desiginers should not try to teach application developers what is best with their specific application. Chancees are, they don't have a clue. > eventually, you could even take the > TearOffMenu widget from gtk+ and copy it in your application. Are you serious? The whole point of widget sets is to not reinvent the wheel for every project again. Now you suggest to implant widget functionality into applications. ---<)kaimartin(>---
(In reply to comment #20) > if your UI has hundreds of dynamic entries then your UI has a problem; if the > UI gets better by tearing off a menu with hundreds of entries then your UI has > two problems. Those "Bookmarks" or "Favorites" menu items/sub-items on our browsers are dynamic entries, and I am sure my "Bookmarks" and "Favorites" menu do contain more than a hundred items/sub-items. I hope you should take an open view on how application developer uses GUI toolkits, not as narrow as you think.
I'm really desapointed with emmanuele who has made his mind with other developpers about Teroff Menus and don't want to understand our arguments. I'm very sad with this decision and nothing we say seems to make them see our point. I really would like to ear the point of view of Matthias Clasen in this subject. I really think that toolbox and tearoff menus have different uses cases. We provided uses cases arguments to make this clear, and i think that the toolkit should not impose what UI design the developper should take. In the mailing list the same argument came to deprecate the StatusBar widget and finally the decision was taken to not remove it because the toolkit should not impose what developpers should do with their UI even if some Gtk developpers think that StatusBar widgets are not a good UI design practice. I think we can come to the same conclusion with tearoff menus. So, i'm asking, who can postpone the decision about this removal, and make a serious discution about this on the mailing list?
(In reply to comment #24) > I'm really desapointed with emmanuele who has made his mind with other > developpers about Teroff Menus and don't want to understand our arguments. that is fully incorrect. I do have my mind made on this matter: I'm one of the people that proposed this deprecation. and I'm sorry to say it, but all your arguments have utterly and completely failed to change my mind because they are artificial and based on your own user experience instead of being backed up by real cases. you also seem to confuse a toolkit as the union of *all* widgets and *all* use cases; that is not true. nothing stops you from creating a small library containing all the deprecated widgets from gtk+. the code is public and should be easily done. if those widgets are using private API then we can discuss about adding it to gtk+ itself so that implementing a TearoffMenuItem outside of gtk+ is possible. > I think we can come to the same conclusion with tearoff menus. that would be very convenient for you. > So, i'm asking, who can postpone the decision about this removal, and make a > serious discution about this on the mailing list? I haven't seen any email on the mailing list. this matter has been discussed in the public bi-weekly IRC meeting, that you have not attended. this bug is 7 months old; if you really wanted to start a discussion you had plenty of time to do so.
Created attachment 161994 [details] TearOff submenu example usage screenshot
(In reply to comment #25) > I do have my mind made on this matter: I'm one of the people that proposed this > deprecation. and I'm sorry to say it, but all your arguments have utterly and > completely failed to change my mind because they are artificial and based on > your own user experience instead of being backed up by real cases. 1) Can you point to our cases where they are artificial? 2) Can you point to our cases where they are not backed up by real cases? Maruks Fischer has already provided you with an example screenshot for his GTK+ application in the attachement at: http://bugzilla-attachments.gnome.org/attachment.cgi?id=151094 Attached is an example screenshot of a very simple beginner's "Schematic driven methodology" usage of gEDA in a particular downstream tools specific Verilog Design and Simulation phase environment, with TearOff submenu to interact with Verilog compiler/simulator and Waveform viewer. Attending IRC meeting at some specific time may not be convienient for some of us, but I am willing to discuss the issue in gtk-devel-list and/or gtk-list mailing list.
Please understand that i'm not a core developper and attending IRC meeting out of my timezone is not easy. I will not bother you anymore with my point of view of what a toolkit should be, it seems that nothing can change your mind.
(In reply to comment #25) > (In reply to comment #24) > > I'm really desapointed with emmanuele who has made his mind with other > > developpers about Teroff Menus and don't want to understand our arguments. > > that is fully incorrect. > > I do have my mind made on this matter: I'm one of the people that proposed this > deprecation. and I'm sorry to say it, but all your arguments have utterly and > completely failed to change my mind because they are artificial and based on > your own user experience instead of being backed up by real cases. lol? if user experiences using real applications are not real cases... what exactly is a real case? do you need a citation from a book by a specific author stating its MANDATORY USER INTERFACE ELEMENT? this conversation was hilarious in a sad way to read. you completely disregard anything anyone has to say on the matter, so it all becomes instantly "incorrect" or "artificial". clearly a third party is needed from inside the GTK team cuz you have no perspective of this issue at all. > this matter has been discussed in the public bi-weekly IRC meeting, that you > have not attended. this would make a good t-shirt. > this bug is 7 months old; if you really wanted to start a discussion you had > plenty of time to do so. There was a lot of discussion here. People just gave up cuz you didn't hear a word they had to say. Very sad ending, so far, to a sad/funny thread.
Do not add rants or insults to this bug. Constructive comments are welcome, but non-constructive comments will get your account disabled. Thanks -- GNOME Bugzilla Maintainers.
This would derail the whole conversation, and lose the point of the whole thing, so I'll only leave one reply. There is no insult in calling someone on losing perspective, who was not hearing anything from people who have a vested interest in keeping this important feature for them. The bi-weekly irc meeting mentioned appears in another bug, but was not even mentioned in this bug. It is very ridiculous to tell users that "they didn't want to start a discussion" when they have been posting some _very_ long replies on this bug report, but fail to show up at some random IRC meeting which _was not even mentioned in this bug_ (I saw it in another bug). Someone had to say something, no insult was implied or intended, but the conversation here was not professional, empathetic, and showed no interest in the users' perspectives.
I tried to post my TearOffMenuItem discussions on gtk-devel-list and gtk-list on separate occasion with different contents, but both bounced back with: "Your message to gtk-devel-list awaits moderator approval" and "Your message to gtk-list awaits moderator approval"
http://mail.gnome.org/ : "The majority of the lists are 'subscriber only'"
(In reply to comment #33) > http://mail.gnome.org/ : "The majority of the lists are 'subscriber only'" I subscribed to both lists, and got acceptance confirmations on both. Only after I got the "Welcome to the "gtk-list" mailing list" and "Welcome to the "gtk-devel-list" mailing list" mails, then I tried to post my discussion. My subscriptions to both lists are still active, since I am getting emails from both mailing lists.
In the first gtk-devel-list reponse to my subscription, it asked me to either visit a confirmation website, or to reply to the email with confirmation code. I did the ealier method, visit the site and confirm. May be that method did not really register me? So I just sent the direct reply email to both now (2nd confirmation method). Well, hope it works.
This is getting *way* offtopic. If you want to continue, please do so elsewhere, not here. Anyway: 1. You need to be subscribed otherwise your message will either be discarded or moderated 2. Even *more* importantly, you need to be subscribed using the email address you're sending the emails from 3. Stuff like "Yes, I totally agree." is NOT appreciated. This is basic mailing list behaviour stuff though. Paul: Regarding #1: accepted the message (though shouldn't have, see #3). Regarding #2: @aim.com vs @aol.com. To clarify what Andre meant: Bugreports are how to solve a particular bug. Discussions about a bug should NOT happen within a bugreport (Bugzilla is not suited or meant for this). FWIW: GNOME sysadmin, bugmaster and so on
2.22 has been released. Change target milestore to 2.24
If you want a few use-cases, I'll cite some (all of them based on my user experience): 1. In Gvim, I open an assembly source-code and it auto-detects the filetype and sets a syntax highlighting for me. However, there are many different assembly languages, and most likely the auto-detect one is incorrect. Thus, I tear off the "Syntax -> AB -> Assembly" submenu and try each one of them, until I find a highlight that closely matches my source-code. After that, I close that submenu and start working. And, before you ask... * No, I can't choose the correct one just by looking at its name. If you want an examples, which highlight would you choose for AVR (Atmel 8-bit microcontrollers) source-code? And how about x86 code for MASM, TASM or NASM assemblers? Each assembler has a different syntax. * No, a toolbox won't help in this case. * The entire "Syntax" menu hierarchy is dynamic, based on installed plugins. * This tear-off is useful for maybe half minute, and then I close it. Even so briefly, it improves the user experience by letting the user do fast what he needs. * A very similar use-case is when the user wants to try different color schemes until finding one that is good enough. 2. Again in Gvim, sometimes I open many files at once (gvim *.c). Even though all of them are open, only one is being displayed at a time (or a few of them, using splits and tabs). Then, I want display one specific file. What do I do? I tear off the "Buffers" menu and have a nice list of open files available at hand. This is specially useful when I don't know for sure which file I need to open. * Again, a toolbox is won't help. * Again, this menu is dynamic. * Again, this is also a "temporary" tear off, something the user opens, uses for a few minutes, maybe, and then close. 3. Gimp has tons of features, and most of them are neatly organized in menus and submenus. Obviously, with so many features, only a subset of them is used at each time. This subset changes with the user and with the images being edited. For instance, sometimes I'm working with "Indexed" images (with a color palette), but I need to convert them to 24-bit RGB before working on them, and convert them back to indexed after I'm done. Sometimes I need to do this with half-dozen images in the same session (manually editing many related images at once - think about editing a icon theme). Then, I just tear off that "Image -> Mode" submenu and leave it there. Similarly, when I'm scanning many documents/images, I'm usually applying the same filters again and again. In this case, I leave some submenus open during this entire session. Finally, sometimes people want to try many different filters and image effects before finding one that suits their needs. Tear off menus here improve the usability a lot (much better/faster/more accurate than re-opening the menus all over again). * Again, a toolbox is not a good solution, because the textual name of each item is much more important than icons that nobody will remember. * Most of the Gimp menus are dynamic, with new items being added by plugins. * Again, all of these use-cases are "temporary". The user thinks "Hey, I'll be using this feature many times during the next minutes, let me keep it handy." and later he closes the menu when it's not needed anymore. I myself really missed tear-off menus in Photoshop. * As "bonus" feature menus (as well as toolboxes) can be shaded if your window manager supports that. Is there any other solution better than tear-off menus? Maybe someday in future, but right now they are the best *currently available* solution. (by the way, I think adding use-cases to this bug is a constructive comment)
tearoff menus have been deprecated in gtk 3.1, and will be removed when we bump major version to 4.0.