Review of attachment 153438 [details] [review]:

Mutter patches must be submitted as patches against GIT using 'git format-patch' (or equivalent - such as using git bz to attach them), and should have an appropriate subject and body message. (The format of the commit message is subject/blank-line/body, see http://lists.cairographics.org/archives/cairo/2008-September/015092.html for what should be in the subject and body.)

But I'd also like to see more explanation of in what circumstances this patch could be used. I could, I guess, see where some people might be mildly annoyed by the tooltips, though with an 0.45 second timeout, it's pretty hard to trigger them if you are an experienced user. But I'm not sure that annoyance would be enough for someone to search on the internet and find out about a GConf key they could set with gconf-editor to remove them.

Oh, and the thing at the top of the window is the 'title bar'

This is not about functionality that a user would turn on themselves but rather something a distribution would due to a design decision.

Created attachment 153459 [details] [review]
[PATCH 1/2] Switch title bar tooltip (pref part)

I tried to reformat the patch to git format-patch with relevant subject/body. Do not hesitate to ask me if you need further changes (for instance, the key name, which has been already submitted to other WM).

Thanks a lot and sorry for the bad format of the first patch.

Created attachment 153460 [details] [review]
[PATCH 2/2] Switch title bar tooltip (activation part)

(In reply to comment #2)
> This is not about functionality that a user would turn on themselves but rather
> something a distribution would due to a design decision.

That's useful information. Is there a reference you can provide to a concrete plan to do this for a distro, or is this a theoretical consideration? Is this something that would be done for a general purpose distribution, or or something planned for a specialized distribution?

The metacity bug is bug 609555
What's the bug number that adds /desktop/gnome/interface/hide_decorator_tooltip to the GNOME schemas? This bug would block on that. (Though it's unclear why it's a /desktop/gnome preference and not a Metacity prefernece)

Any chance to answer my questions? - marking NEEDINFO, since we're not going to do anything further without that background.

Yes, we are doing it in Ubuntu :-)

The reason why we put that in /desktop/gnome/interface/hide_decorator_tooltip is that we can maybe make it theme dependent as we did with a patch in g-c-c for the button layout order, but I have no strong opinion about the path to use.

[ Broadening this discussion to really be more about the Metacity change than the Mutter change; the Mutter change here is really just shadowing the Metacity change ]

(In reply to comment #7)
> Yes, we are doing it in Ubuntu :-)

OK, thanks for the information. (Checking shows this patch was added to the Lucid Ubuntu package of Metacity.)

Can you point me to the design discussion behind this change? (IRC logs, whatever.) I don't see anything in the Launchpad bug https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/519856, though maybe I just don't know how to read it.

The basic, fundamental concept of Metacity is that it is a window manager, not a window manager construction toolkit. The defaults of Metacity are supposed to be the right defaults for general desktop use. Configuration options are there to accomodate personal preference or specialized environments.

So, if some people did some thinking about design and decided that it would be better for general desktop usage if there were no tooltips on the title bar buttons, then likely the right thing to do would be to submit a patch upstream that removes the tooltips. 

If there are reasons that an individual would have a strong preference for tooltips (to the extent that they would go and research how to change GConf), or there are specialized environments were the tooltips are more necessary, then the patch might also include a GConf key that would turn the tooltips back on. But the default behavior value of the key would be to have the tooltips off.

(In reply to comment #8)
> The reason why we put that in /desktop/gnome/interface/hide_decorator_tooltip
> is that we can maybe make it theme dependent as we did with a patch in g-c-c
> for the button layout order, but I have no strong opinion about the path to
> use.

I'm not familiar with this patch for g-c-c. Can you provide a reference?

This doesn't really seem to be a "theme" issue - themes are about visual appearance, and presumably if there was such a preference for the user, it would cut across how they wanted title bars to look. You wouldn't want to have one theme with tooltips on and another off. (Maybe a theme where all the buttons look identical? :-)

Also, it's unclear what the path has to do with making this controlled by the theme.

Finally, can you answer my question about where the schema for this key is being added to GNOME?

I will let kwwii answers from the design perspective, answering it on the other.

> I'm not familiar with this patch for g-c-c. Can you provide a reference?
sure:
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=614014
Bug-Ubuntu: https://bugs.launchpad.net/bugs/535322

The patch is now applied on Ubuntu (the rational was that moving the buttons to the left broke a lot of themes that weren't graphically prepared having different layout), so, we add this key in

sorry, stroke commit…

I will let kwwii answers from the design perspective, answering it on the
other.
(just as an input, the "indicators" doesn't have any tooltip as well).

> I'm not familiar with this patch for g-c-c. Can you provide a reference?
sure:
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=614014
Bug-Ubuntu: https://bugs.launchpad.net/bugs/535322

The patch is now applied on Ubuntu (the rational was that moving the buttons to
the left broke a lot of themes that weren't graphically prepared having
different layout), so, we add this key in a similar way to what was done for font size, and so on…

> This doesn't really seem to be a "theme" issue - themes are about visual
> appearance, and presumably if there was such a preference for the user, it
> would cut across how they wanted title bars to look. You wouldn't want to have
> one theme with tooltips on and another off. (Maybe a theme where all the
> buttons look identical? :-)

Make sense, didn't thought about that. I was just thinking about not making people upset for those who really rely on tooltips and provide a way to change the behavior.

> Also, it's unclear what the path has to do with making this controlled by the
> theme.
We discussed the path with seb128, but didn't take a long time to decide on one. Again, I have no valuable opinion on that and prefer to take yours as a reference :)

> Finally, can you answer my question about where the schema for this key is
> being added to GNOME?
I didn't added the schema yet (as I wasn't sure if the bug will be looked at before dconf and don't know about the new schema layout), I can add it once we decide about the path to use.

The idea behind the design in Ubuntu is to make the usage of tooltips as strong as possible by removing the unnecessary ones. 

I have no opinion on how to do this, but I do think that adding the functionality somewhere is a solid decision :-)

(In reply to comment #12)
> The idea behind the design in Ubuntu is to make the usage of tooltips as strong
> as possible by removing the unnecessary ones. 
> 
> I have no opinion on how to do this, but I do think that adding the
> functionality somewhere is a solid decision :-)

Can you elaborate more? What other tooltips are you removing? What tooltips do you want to keep?

[ If someone sent me a patch that was just:

 Subject: Fix crash
 
+ if (x != NULL)
+    return;

I might be able to figure out what it was doing, how to reproduce the crash, and whether there were better ways about going about it, but it wouldn't be an OK patch submission.

This is similar - you've started out with a patch that is purely functional, and has no motivation behind it, and I've had to dig like crazy to get even a few drops of information about the motivation. And that motivation is essential if I'm going to figure out if the GConf key makes sense or we should just kill the tooltips. I can obviously ask other designers to explore the question or even think about it some myself, but I shouldn't *have to*. After all, apparently design work has already been done here...

Use, design is partially intuitive; I'm not expecting a mathematical proof that the tooltips would be better eliminated. But I'm sure the thought process must have been more extensive than the one sentence you've provided so far. And sometimes working with an open source upstream does require articulating a thought process in writing. ]

I do not have a list of tooltips we would like to "turn off" but I know that there are other candidates for it. The idea is to use tooltips as a truly informational tool on subjects hard to understand. The window decoration buttons are one of the first places to start as 99.9999% of people understand the icon context

OK, here's my take on the situation:

Benefits of the tooltips
========================

Particularly with the "Close" button a tentative user might have an idea that the X closes the window, but be nervous about clicking it. The "Close Window" tooltip provides some assurance that yes, it does what they think it will do. Now the number of users that are entirely new to computers is certainly steadily decreasing. (Except for the constant stream of young children who don't read and don't have any hesitation to click and see what happens.)

The Minimize and Maximize tooltips seem less useful to me - because the words themselves don't really say much. The only function I see for them is to give the user the vocabulary.... that what they are doing is "minimizing" (not sure if users pick that vocabulary up in any case.)

Disadvantages of the tooltips
=============================

It's actually pretty hard to trigger these tooltips unless you are really moving slow. But if you are moving slow and the tooltips pop up then the natural thing to do is to read them. Since "Maximize window/Restore window" "Minimize window" aren't very informative messages to the users who need them, this reading is likely a distraction and the user would be better off clicking and seeing what happens.

(Both Vista and OS X provide a visual hint that the other two buttons are less scary than the close button - the close button is red for both, and the other buttons are green/yellow on OS X and uncolored on vista.)

Other operating systems
=======================

OS X has no tooltips for these buttons. (It's hard to even find names for what they do - if you dig around enough in the online help, the green (+) has the function of "Zoom".) Windows Vista has tooltips, somewhat more abbreviated than what we use - "Minimize" "Maximize/Restore Down" "Close"

The GNOME 3 perspective
=======================

GNOME Shell is currently very light on tooltips. Partly because we haven't gotten around to implementing them in the places that do need them. But also because we do want a clean look and to encourage an explorative mode for the user - the idea that it's safe to explore and click on the things - the Undo area in the overview is an example of that. (We actually discussed being able to undo closing windows, but it was hard to think of how that could be implemented in a sufficiently reliable way.)

One side advantage of getting rid of the tooltips would be that the Minimize button no longer minimizes to a taskbar in GNOME Shell, it hides the window to the Activities Overview. So getting rid of the text sidesteps the issue of coming up a name for what the button does.


I think on balance I'd be in favor of eliminating these tooltips, but I'll let the designers decide.

If we decide to get rid of them by default, then I don't really see a reason for a GConf option - any user that can articulate the need to turn on that option will already know what they do. And from the analysis above, I think they are most useful on the general desktop - what the Metacity defaults are supposed to target. Other specialized niches - workstation, educational, small screen, etc, will have *less* of a need for them.

I am personally not convinced about the benefits of turning the tooltips off en mass; seems to me that tooltips as a concept only work well if they are used universally, i.e., a user who finds out that a particular item does not have a tooltip will be precisely the user who was needing it; as such not finding a tooltip seems to me more of a problem than triggering it by accident (which can be better addressed differently, and as Owen said, Mutter tooltips are not that easily triggered by accident to start with).

Furthermore, both the location of the buttons and the symbols used by them are provided by the theme, and are far from universal (e.g., the close button on the theme I am using does not show an 'x' symbol). When trying out different themes the tooltips are an important hint as to what each button does. I think if this was to be a customizable feature, it would be better controlled by the theme, not by a user preference (in which case it could be possible to disable/enable only specific tooltips, or even specify the trigger timeout on per-button basis).

> OS X has no tooltips for these buttons. (It's hard to even find names for what
> they do - if you dig around enough in the online help, the green (+) has the
> function of "Zoom".)

Note, however, that every Mac application has a Window->Minimize and a Window->Zoom menu option.

The Gnome designers actually agreed on removing the tooltips, so we killed them in bug 645101. So closing as obsolete.