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 349357 - Help buttons don't work.
Help buttons don't work.
Status: RESOLVED FIXED
Product: glom
Classification: Other
Component: general
1.0.x
Other Linux
: Normal minor
: ---
Assigned To: Johannes Schmid
Murray Cumming
Depends on:
Blocks:
 
 
Reported: 2006-07-30 22:46 UTC by Ryan Paul
Modified: 2006-10-14 11:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to display help when help button is pressed (11.17 KB, patch)
2006-10-10 14:53 UTC, Johannes Schmid
needs-work Details | Review
belongs to docs/user-guide/C (834 bytes, application/octet-stream)
2006-10-10 14:54 UTC, Johannes Schmid
  Details
belongs to docs/user-guide/de (843 bytes, application/octet-stream)
2006-10-10 14:55 UTC, Johannes Schmid
  Details
Updated patch to fix the help button and the user-manual generation (11.28 KB, patch)
2006-10-11 09:06 UTC, Johannes Schmid
none Details | Review
glom.omf.in (307 bytes, application/octet-stream)
2006-10-11 09:09 UTC, Johannes Schmid
  Details

Description Ryan Paul 2006-07-30 22:46:54 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.
Comment 1 Murray Cumming 2006-07-31 08:30:27 UTC
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.
Comment 2 Ryan Paul 2006-07-31 08:45:38 UTC
>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.
Comment 3 Murray Cumming 2006-09-09 14:21:07 UTC
So, I think that this (non-focused appliations when started from the terminal) is intended behaviour (wanted by the window manager).
Comment 4 Murray Cumming 2006-09-09 14:22:12 UTC
Reopening so we can fix the other small problems mentioned.
Comment 5 Murray Cumming 2006-09-09 20:52:38 UTC
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.
Comment 6 Murray Cumming 2006-09-18 08:19:36 UTC
This is probably simple. I just don't know how to connect those help buttons.
Comment 7 Johannes Schmid 2006-10-10 14:53:52 UTC
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
Comment 8 Johannes Schmid 2006-10-10 14:54:36 UTC
Created attachment 74410 [details]
belongs to docs/user-guide/C
Comment 9 Johannes Schmid 2006-10-10 14:55:25 UTC
Created attachment 74411 [details]
belongs to docs/user-guide/de
Comment 10 Murray Cumming 2006-10-10 15:08:11 UTC
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?
Comment 11 Murray Cumming 2006-10-10 15:11:29 UTC
Will the dialog be reshown after showing the help? I assume that is what is meant to happen.
Comment 12 Johannes Schmid 2006-10-10 15:29:02 UTC
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.
Comment 13 Murray Cumming 2006-10-10 15:57:54 UTC
That's OK. You might look at how to do this in general for the other dialogs, and the Help menu.
Comment 14 Johannes Schmid 2006-10-11 09:06:52 UTC
Created attachment 74471 [details] [review]
Updated patch to fix the help button and the user-manual generation
Comment 15 Johannes Schmid 2006-10-11 09:09:43 UTC
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.
Comment 16 Murray Cumming 2006-10-11 09:40:45 UTC
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.
Comment 17 Johannes Schmid 2006-10-11 09:56:09 UTC
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...
Comment 18 Johannes Schmid 2006-10-11 17:14:29 UTC
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.
Comment 19 Murray Cumming 2006-10-11 17:44:15 UTC
> 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.
Comment 20 Johannes Schmid 2006-10-12 10:00:31 UTC
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.
Comment 21 Don Scorgie 2006-10-12 11:58:18 UTC
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.
Comment 22 Johannes Schmid 2006-10-12 12:14:40 UTC
Don's changes are now commited. Everything works now except for the documentation which is still missing.

We really owe Don a beer!