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 602882 - Deprecate GtkTearoffMenuItem
Deprecate GtkTearoffMenuItem
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.21.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
deprecations
Depends on:
Blocks:
 
 
Reported: 2009-11-24 23:51 UTC by Javier Jardón (IRC: jjardon)
Modified: 2012-01-13 05:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (3.23 KB, patch)
2009-11-27 20:39 UTC, Cody Russell
needs-work Details | Review
Improved (15.22 KB, patch)
2009-11-27 22:10 UTC, Cody Russell
none Details | Review
Example submenu. Nicely integrates into menu and also tear-off-able (50.75 KB, image/png)
2010-01-09 15:28 UTC, Maruks Fischer
  Details
TearOff submenu example usage screenshot (390.08 KB, image/jpeg)
2010-05-26 07:28 UTC, Paul Tan
  Details

Description Javier Jardón (IRC: jjardon) 2009-11-24 23:51:06 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
Comment 1 Kai Martin Knaak 2009-11-25 16:57:27 UTC
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)>---
Comment 2 Karl Hammar 2009-11-25 22:41:25 UTC
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

?
Comment 3 André Klapper 2009-11-26 15:49:50 UTC
Can you please describe actual usecases and why a Tearoff menu is so important to keep it, compared to a normal menu?
Comment 4 Karl Hammar 2009-11-26 19:58:19 UTC
I is all about speed and productivity.
Comment 5 André Klapper 2009-11-26 20:06:49 UTC
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)
Comment 6 Kai Martin Knaak 2009-11-26 23:26:36 UTC
(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)>--
Comment 7 Paul Tan 2009-11-27 01:15:42 UTC
(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?
Comment 8 Emmanuele Bassi (:ebassi) 2009-11-27 02:19:39 UTC
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.
Comment 9 Paul Tan 2009-11-27 04:01:32 UTC
(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.
Comment 10 Emmanuele Bassi (:ebassi) 2009-11-27 13:36:14 UTC
(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.
Comment 11 Paul Tan 2009-11-27 20:09:40 UTC
(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.
Comment 12 Cody Russell 2009-11-27 20:39:30 UTC
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 13 Cody Russell 2009-11-27 21:30:43 UTC
Comment on attachment 148618 [details] [review]
Patch

Missing some stuff, will file a new patch soon.
Comment 14 Cody Russell 2009-11-27 22:10:57 UTC
Created attachment 148625 [details] [review]
Improved
Comment 15 Paul Tan 2009-11-30 21:18:39 UTC
(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.
Comment 16 Maruks Fischer 2010-01-09 15:28:59 UTC
Created attachment 151094 [details]
Example submenu. Nicely integrates into menu and also tear-off-able
Comment 17 Maruks Fischer 2010-01-09 15:29:15 UTC
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.
Comment 18 Sascha Wilde 2010-04-26 10:11:24 UTC
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
Comment 19 ecyrbe 2010-05-12 23:17:12 UTC
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)
Comment 20 Emmanuele Bassi (:ebassi) 2010-05-13 07:31:12 UTC
(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.
Comment 21 Paul Tan 2010-05-13 14:51:23 UTC
> 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.
Comment 22 Kai Martin Knaak 2010-05-13 18:45:38 UTC
(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(>---
Comment 23 Paul Tan 2010-05-15 00:55:42 UTC
(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.
Comment 24 ecyrbe 2010-05-20 02:52:03 UTC
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?
Comment 25 Emmanuele Bassi (:ebassi) 2010-05-25 20:42:52 UTC
(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.
Comment 26 Paul Tan 2010-05-26 07:28:21 UTC
Created attachment 161994 [details]
TearOff submenu example usage screenshot
Comment 27 Paul Tan 2010-05-26 07:30:09 UTC
(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.
Comment 28 ecyrbe 2010-05-29 01:56:30 UTC
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.
Comment 29 danakj 2010-05-29 12:52:11 UTC
(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.
Comment 30 André Klapper 2010-05-29 13:14:51 UTC
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.
Comment 31 danakj 2010-05-29 13:33:16 UTC
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.
Comment 32 Paul Tan 2010-06-01 17:59:10 UTC
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"
Comment 33 André Klapper 2010-06-01 18:38:17 UTC
http://mail.gnome.org/ : "The majority of the lists are 'subscriber only'"
Comment 34 Paul Tan 2010-06-01 19:37:23 UTC
(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.
Comment 35 Paul Tan 2010-06-01 19:55:36 UTC
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.
Comment 36 Olav Vitters 2010-06-01 21:34:01 UTC
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
Comment 37 Javier Jardón (IRC: jjardon) 2010-09-24 15:23:30 UTC
2.22 has been released. Change target milestore to 2.24
Comment 38 Denilson F. de Sá 2010-09-28 14:40:12 UTC
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)
Comment 39 Emmanuele Bassi (:ebassi) 2011-10-01 07:23:57 UTC
tearoff menus have been deprecated in gtk 3.1, and will be removed when we bump major version to 4.0.