Add help buttons to various dialogs

[b4n]

Add a Help button to Find, Replace and Find in Files dialogs.

The Replace dialog might be a problem because it has many buttons, so it takes a lot of place. It's a little better when icons on buttons are not shown (which is the default under GNOME, but not MATE AFAIK), but it's worse in some locales where the Search & Replace label takes more space. Opinions?

---

BTW, one can see that we have a Close button for Find and Replace, but a Cancel one for Find in Files. Looks odd.

[elextr]

Since this is no longer used anywhere else, why no just add utils_open_browser() at the end and make this utils_open_help() instead of adding another bit of spaghetti?

[elextr]

Nice idea.

LGBI but for one comment.

Replace is a bit crowded, but not much other choice where to put it.

Yeah fif cancel s/b close IMHO.

[codebrainz]

-1, it's too crowded and a slippery slope. Also some dialogs which could actually benefit from this (ex. Build Commands) don't even have it.

IMO, it would be more useful to just make the dialogs accept F1 to open the help. If people don't know that shortcut, they can use the help menu in the main window so easily.

[eht16]

I like the idea.

The Replace dialog is indeed a bit problematic.
Maybe it would help a bit to put a vertical separator between Help and the rest of the buttons. Though this would require even more space.
Or maybe having two rows of buttons like

"Help" |        "Find"    "Replace"
                "Close"  "Replace & Find"

Not sure whether this would make things better :).

Oh and yes, let's change Cancel to Close.

[elextr]

@codebrainz is right there are other places this can be added. But this is a start.

[b4n]

Also some dialogs which could actually benefit from this (ex. Build Commands) don't even have it.

This isn't a reason not to add it here just because it's missing some place else. But yeah, we should have it in other dialogs, good point.

IMO, it would be more useful to just make the dialogs accept F1 to open the help. If people don't know that shortcut, they can use the help menu in the main window so easily.

The point is that these buttons open the help specific to that dialog. But yeah it'd probably be nice to have the help shortcut work too indeed.

[b4n]

Maybe it would help a bit to put a vertical separator between Help and the rest of the buttons. Though this would require even more space.

I'm not sure how easy it'd be (all is mostly handled by GTK here), and it would not be better if the dialog is wide enough for showing the extra space between the 2 sets of buttons.

Or maybe having two rows of buttons like

"Help" |        "Find"    "Replace"
                "Close"  "Replace & Find"

Not sure whether this would make things better :).

Hum… interesting, but I'm not sure how easily feasible that would be -- nor if it'd really be a better UI.

[codebrainz]

IMO putting Help buttons all over the place is massive overkill. It might be OK on Windows to use the window manager help button though, that actually provides additional value.

[b4n]

FTR, with Adwaita theme on MATE, with button icons, I get those widths (px)

	C	fr	de	ru
Without help buttons:	618	874	786	694
With help buttons:	765 (+147, 24%)	1090 (+216, 25%)	980 (+194, 25%)	865 (+171, 25%)

[edit: obviously, the other dialogs sizes aren't affected by the additional button)

[b4n]

IMO putting Help buttons all over the place is massive overkill.

The initial reason that made me think of adding it was the discussion on what the regex toolip referred to as "the documentation". That made be realize that we do suggest to look at the docs, but we don't have a simple and easy way to look it up, hence the idea of adding the fairly common help button.

IMO, if it wasn't for the Replace dialog fattiness we probably wouldn't really be discussing about it, would we? :)

[codebrainz]

but we don't have a simple and easy way to look it up

I do like context-dependent help, I just think putting buttons everywhere to access it is a bad idea. Better would be if whichever dialog/window/etc has focus F1 opens the help file at the right place.

IMO, if it wasn't for the Replace dialog fattiness we probably wouldn't really be discussing about it, would we? :)

I would've still mentioned it as I think it's too cluttered adding big buttons for something used so rarely.

An alternative that wouldn't clutter the dialogs so much would be to use a link label in another location, rather than a help button. For the Build Commands dialog it could replace the less than helpful existing label too. It might look kind of ugly and scattered though, not sure without seeing it.

[elextr]

F1 is not helpful, nobody will know it provides context sensitive help, useless.

Whilst buttons are not style du jour, flat, pretenting-to-be-web UI they work, are simple and helpful.

I say its a good idea, just do it.

[b4n]

An alternative that wouldn't clutter the dialogs so much would be to use a link label in another location, rather than a help button. For the Build Commands dialog it could replace the less than helpful existing label too. It might look kind of ugly and scattered though, not sure without seeing it.

I'd see it like that:

The Help button goes to Build menu commands dialog and the link in the label to Substitutions in commands and working directories.

[codebrainz]

F1 is not helpful, nobody will know it provides context sensitive help, useless.

Actually it's a universal key for Help and is every bit as likely to open the help file in the correct place as a button is. A button really doesn't add anything other than visual clutter for a feature that will rarely be used (more than once).

[codebrainz]

@b4n that dialog is a bad example for clutter :)

The link label is quite nice though, and for a big complex dialog like that the help button isn't horrible.

[elextr]

@codebrainz yes I'm sorry the build dialog isn't anywhere near complex enough, @eht16 stopped me 😄

Well, the preference seems to be for help buttons, and the link in the text is good too.

This would be a good think to put on an omnibus Issue where we can list places to put help and adding one or two it is a possible simple thing for anybody who wants to get started with Geany development or who is bored.

[codebrainz]

Well, the preference seems to be for help buttons, and the link in the text is good too.

Definitively not my preference, but so long as there's a setting to disable them, I guess it's fine :)

[codebrainz]

The more of these buttons we add, the more careful we have to be when editing the manual, since AFAIK the named anchors are based off of section titles. Any commit that edits the manual should be checked (as with existing prefs dialog help button).

[elextr]

The more of these buttons we add, the more careful we have to be when editing the manual, since AFAIK the named anchors are based off of section titles.

Yes, good point, maybe we should be adding permanent anchors to the manual as we add the buttons.

[b4n]

Good point.

Also, the help button should be added to the project dialog. it's a bit trickier, but surely doable.

[codebrainz]

Also, the help button should be added to the project dialog. it's a bit trickier, but surely doable.

Yeah. It might require some additional function/mechanism to make it tab-specific, and plugins can and do add tabs in there. What if the code in Geany looked at the current tab page widget for a GObject data list item called "geany-help-uri" or something, and then opened that. Would be simple to implement in Geany and plugins, and wouldn't add burden to the ABI.

[b4n]

Yes, good point, maybe we should be adding permanent anchors to the manual as we add the buttons.

Done in 51f4091

[b4n]

Yeah. It might require some additional function/mechanism to make it tab-specific, and plugins can and do add tabs in there. What if the code in Geany looked at the current tab page widget for a GObject data list item called "geany-help-uri" or something, and then opened that. Would be simple to implement in Geany and plugins, and wouldn't add burden to the ABI.

Yeah, I was thinking about doing it that way. I'm not sure if we should advertize it to plugins, but yeah it'd work for them too.

[codebrainz]

#define ui_add_tab_help(page, uri) \
    g_object_set_data(G_OBJECT(page), "geany-help-uri", uri)

or maybe even

#define ui_add_tab_help(page, uri) \
    g_object_set_data_full(G_OBJECT(page), "geany-help-uri", g_strdup(uri), g_free)

[elextr]

Well, for the project dialog, there is plenty of space in the tabs to put a help device in the tab where they can have the right URL statically (except for build, but its getting the link in the text note, so its ok).

[b4n]

Implemented the project dialog in 9d42ded. The target help URI are not all perfect because we don't seem to have specific help for all of them, so I pointed them to what seemed the most appropriate place. Documentation improvement welcome :)