GNOME Bugzilla – Bug 349357
Help buttons don't work.
Last modified: 2006-10-14 11:06:18 UTC
The Connect to Server dialog often starts in an inactive state. By default, the dialog should always be active when it appears and an empty textbox in the dialog should have focus. Having to use alt-tab to get to the dialog right after it opens is somewhat frustrating. Other issues with the Connect to Server dialog: * The individual fields need to have associated access keys * The Connect button also needs an associated access key (maybe alt-o?) * The dialog should have a title * Make it so that Glom doesn't crash when I click the Help dialog Feature requests for the Connect to Server dialog: I would be really nice if the dialog could eventually support the GNOME keyring so I don't have to type in login information every time I open the program. If using the GNOME keyring isn't feasible, perhaps there is some way for Glom to store that information securely.
Thanks. What version of Glom, on what distro is this? Are you saying that the dialog sometimes has focus, but sometimes not? Could you experiment to discover when it does not? For instance, maybe it is a problem when starting from the terminal instead of the menu. Regarding the dialog title, I have tried to follow the HIG, which seems to say that there should not be a window title: http://developer.gnome.org/projects/gup/hig/2.0/windows-alert.html I also would like to use the GNOME keyring.
>What version of Glom, on what distro is this? 1.0.3 in Ubuntu >Are you saying that the dialog sometimes has focus, but sometimes not? Yes. >For instance, maybe it is a problem when starting from the terminal instead of the menu. I just did a few tests, and it turns out that your guess is correct. It seems like it is only happening when I start Glom from the command line. >Regarding the dialog title, I have tried to follow the HIG, which seems to say that there should not be a window title Thanks for bringing that to my attention, I wasn't aware of that particular HIG recommendation. I apologize for characterizing that feature as a defect.
So, I think that this (non-focused appliations when started from the terminal) is intended behaviour (wanted by the window manager).
Reopening so we can fix the other small problems mentioned.
I have made the navigation/accessibility changes to that dialog. I'd welcome similar patches for other parts of the UI. I am changing the title of this bug to indicicate that it's just the help button that's still a problem.
This is probably simple. I just don't know how to connect those help buttons.
Created attachment 74409 [details] [review] Patch to display help when help button is pressed Additionally two other files belong to this patch glom-C.omf and glom-de.omf which belong in docs/user-guide/C and docs/user-guide/de! The patch should display help for the dialog mentioned in the bug and install the help files correctly. The latter is true for at least the english manual. Anyway gnome_help_display() still does not find the help though it is availible in yelp. I will have to investigate this further
Created attachment 74410 [details] belongs to docs/user-guide/C
Created attachment 74411 [details] belongs to docs/user-guide/de
Please try to mention the filename in the description when you upload files. bugzilla doesn't remember it otherwise. I would expect these .omf files to be generated by the documentation translations system. Could you please check whether that is the case?
Will the dialog be reshown after showing the help? I assume that is what is meant to happen.
You are right, these files are generated somehow, I will update the patch. The dialog remains open while the help is shown because otherwise glom would quit while the user reads the manual.
That's OK. You might look at how to do this in general for the other dialogs, and the Help menu.
Created attachment 74471 [details] [review] Updated patch to fix the help button and the user-manual generation
Created attachment 74472 [details] glom.omf.in This is the omf.in file which is used to generate the omf files for the different languages. In belongs in docs/user-guide.
I was thinking, maybe we should add a convenience method and use it all over the place: int dialog_run_with_help(dialog, help_id) { int response = dialog.run(); if(response == GTK_RESPONSE_HELP) { show_help_somehow(help_id); //Re-reun the dialog: response = dialog_run_with_help(dialog, help_id) } dialog.hide(); return response; } That would reduce the if/else indenting and avoid some copy/pasting of code. BUT: I'm not 100% sure if this is really a) How Help buttons are meant to behave? Should we hide the dialog afterwards, or keep showing it? Could you ask on usability list, or otherwise investigate, please? b) If this is really the correct GTK+ way to do it? Could you investigate, please, on an appropriate mailing list. Sorry for micromanaging.
So far I added Glom::Utils::show_help(id="") to avoid having to copy the error handling all the time. Your idea with the conveniece method is also not bad. I will see if I can implement that. And ask on the lists of course...
I looked at the gedit code. As they use non-modal dialogs (and therefore not gtk_dialog_run() they handle help buttons in the response-handler of their dialogs and stop signal emission if respose was GTK_RESPOSE_HELP. Nautilus seems to always use a switch statement for every modal dialog. I have started implementing everything in Glom using Glom::Utils::run_dialog_with_help() which works. I was also thinking about overriding the run() method in all affected dialog which would be a bit cleaner: int Dialog::run() { return run_dialog_with_help(dialog, "dialog_id"); } Of course run_dialog_with_help() would have to call dialog->GtkDialog::run() in this case. Please tell me with solution you would prefer.
> I was also thinking about overriding the run() method in all affected dialog > > which would be a bitcleaner. That's a nice idea. But it would require us to use derived dialogs everywhere. Let's just use the run_dialog_with_help() idea instead. Could you also please make sure that there is some section in the help document for each of the current help buttons. I'll fill the text in later. Thanks. Feel free to commit.
The changes are now commited to CVS. All help button should be connected in case I did not miss any. The is still an issue with scrollkeeper, but I hope that can be solved soon.
As per discussions on why this doesn't work on IRC: The problem is in the call to gnome_program_init. In config.h, PACKAGE_NAME and PACKAGE_VERSION are both empty. gnome_program_init uses these to set the "help domain" - where it looks for help files [1] The solution is either to define and export PACKAGE_NAME and PACKAGE_VERSION in the configure script OR change the gnome_program_init call to use PACKAGE and VERSION, which are already defined and exported. In addition, the gnome_help_display should not have "glom.xml", but just "glom" as its first argument. Doing this, libgnome can find the help files and launch yelp correctly. [1] I have no idea why libgnome tries to find the file. It's not like yelp has a much more efficent way of searching for help files, presents nice dialogs etc.
Don's changes are now commited. Everything works now except for the documentation which is still missing. We really owe Don a beer!