This is open for debate.  The purpose of the "F10 menu" is to provide a list of features available to the user.  It is present because some gdmgreeter themes do not have buttons to support features that may be turned on in the configuration file.  In other words if "reboot" is turned on in GDM configuration, but the theme has no "Reboot" button, then there is no way to reboot without hitting F10
(or changing the theme to one that supports everything you might want to use).

So, to support such themes that might be missing useful buttons, this is useful.
Any ideas of how to better communicate this functionality to the user would be appreciated.  Also, if the best approach is to use a tooltip on the entry field, should the wording be improved?  As you point out the words "questions" and "menu" are probably poor word choices.

Note we are past string freeze for 2.18, so this can be fixed in 2.20 at the earliest.

I'll ask on the Ubuntu bug if the bug submitter has a better suggestion. The string freeze starts with 2.17.91 in february

Hi, I'm the original reporter. :-)

Tooltips are for offering help on using a specific control, when there is not enough room to provide that help as normal text. Here, neither of those things is the case. If there are features that need to be accessed from a menu, that's fine, but that has nothing to do with the login name field. And there is plenty of room elsewhere on the screen to explain this.

I suggest printing at the bottom of the screen: "For more options, press F10." (Or perhaps announce a deadline for gdm themes to do this themselves, in an appropriate place for their theme.)

Matthew, thanks for commenting on the bug.  However, I think you misunderstand the complexity of this problem.  Remember that the appearance of the GDM GUI when using gdmgreeter is 100% up to the theme, since gdmgreeter is themeable.  While some themes (circles, happygnome, happygnome-list) are shipped with GDM, most distros use their own themes, and most users go to art.gnome.org and download "cooler" themes to use with GDM.

While this is nice, giving users flexibility to make the GUI look the way they want, there is no way to know if any given theme has any given feature.  Some themes do not include a Reboot button, some themes do not include a Halt button, etc.

I agree that adding text as you suggest would be a nicer solution, but I'm not sure how it could be implemented without making the user experience more painful.  Some ideas.

1) We could add a new label to the XML format so that themes could include this 
   text.  However, this would mean that any theme that did not include this 
   label wouldn't include the text.  We could "enforce" that the theme have this 
   label, but this would break all existing GDM themes.

2) We could re-use one of the existing labels that appears in most GDM themes,
   perhaps pam-error, since it normally does not get filled until the user
   tries to authenticate and has a problem.  This might be a workable solution,
   though there is some danger with overloading if, in the future, multiple
   things think it is a good idea to overload the same thing.

3) We could add a pop-up dialog that shows up before the user can authenticate.
   I'm sure people would hate this, but it would work.

Another issue is that the message is a little misleading.  *If* the theme has
all the options on it, then there are *not* any additional options you get by
hitting F10.  So, if using a theme with all options the "For more options"
text would be misleading.  Perhaps the code should be smarter and actually check
if the theme is missing features and only show the message if, in fact, there
are features in the menu that are not in the theme.  This is probably a bit of
work to code since there are quite a few things that can appear in the menu
and different ways of defining how the choices can show up in the theme
(e.g. active rectangles can be buttons, but real GTK buttons can also be used).

I agree that this but is a usability problem, but it is unfortunately one of
those annoying usability problems that is a bit of work to fix.  It is hard to
judge whether the "annoyance" factor of the bad usability is worth the effort
to fix the problem.  

Though perhaps someone will have a more clever idea of how to approach improving 
this.

I think probably the most practical solution is #1, but without the enforcing part. Drop the tooltip, add the new string, place it (in a tasteful way) in the bundled themes, and announce it on any relevant theming mailing lists etc. Then it's up to theme authors whether they add it or not. I can quite imagine some OS vendors choosing not to add it to their default theme, on the grounds that they're already providing buttons for all the functions their OS provides.

(FWIW, I'd be careful about saying "most users go to art.gnome.org and
download 'cooler' themes". I think it quite likely that most Gnome users have never even heard of GDM.)

I would be agreeable to accepting a patch that modified GDM to work in mode #1.  However, I would like some comments on the following:

1) Should GDM check to see if there are any missing options in the theme, and 
   only display the message if there are additional options the user can find
   in the F10 menu?
2) What should the wording of the message be?  "Hit F10 for menu"

For (2), I suggest: "To list all options, press F10" (with no period).

Then when (1) is done, it can be changed to: "For more options, press F10".

My apologies for replying to an old thread, but isn't it possible to add an attribute to the <item> offering the theme builder to suppress the tooltip? Something like <item type="entry" id="user-pw-entry" tooltips="no">?

The gui/greeter/greeter_parser.c code does not currently support a tooltip argument.

Created attachment 102129 [details] [review]
Changes text of tooltip

This patch, created with diff, changes the text of the tooltip to

_("Enter login details and press enter. "
- "Press F10 for more options."),

This seems far more sensible.
https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/70786

This patch changes a translated string.  I'd be agreeable to make this change in the 2.20 branch if someone wants to ask the release team for permission.  We need 2 votes in order to change a string after string freeze.  Would you be willing to do this?  I think it would be nice to fix the string so it is more clear.  

This patch isn't meaningful for GDM SVN head since the code has been rewritten.

Fixed in 2.20 branch.  I got approval to break string freeze to fix this bug and 2 other bugs.