[Added] Allow editing menu names

[es]

You have a lot of menu items, which is great! However, some of them are too wide, e.g., I don't need to have 'GraphicConverter 11' that has nothing I use frequently (except for the "Edit Shortcuts", but only because I can't use a shortcut for it).
So I'd like to rename it to GC so that it takes very little space.
Similarly I'd like to rename all other menus and maybe replace some lengthy names with shorter unicode symbols

[porg]

FYI: GraphicConverter has just these recent weeks revamped its "Edit Shortcuts" dialog.
• Just search the forum for Edit Shortcuts.
• Reminder @forum_adm: Sadly still Forum search doesn't work which makes it hard for people to help themselves.
• Workaround: Open section GC → Suggestions and there do a browser search (⌘ F for "Edit Shortcuts").

My opinions on your proposal
1) Customizing the commands in the menu will realistically NOT be possible, because they are used as the unique identifier to which you can assign shortcuts.

2) But shortening the application name in the main menu is a common practise on macOS apps, e.g. "Visual Studio Code" shows as "Code" in the main menu, but as "Visual Studio Code" in the application switches, see screenshot:

macOS app name - Full name in app switcher but short name in main menu - Is possible.png (91.86 KiB) Viewed 1025 times

• Pro: As GC has quite a massive menu structure, shortening the app name would improve the situation on smaller displays.

• Con: "GraphicConverter" → "GC" is a certain loss of branding value. I would understand if the developer does not want to give that up.

• Compromise: At least drop the version number from the app's main menu representation.
Because for the rare case of running multiple main versions of GC in parallel (e.g. during a transition period, where you rely on the recent major version for productive work, but want to try out the new/next generation) then still cmd-TAB and also the slightly different window look/feel would give you certainty which one is which.

[es]

As you correctly mentioned, it's very hard to search on this outdated forum

1) Customizing the commands in the menu will realistically NOT be possible, because they are used as the unique identifier to which you can assign shortcuts.

But there is a real solution that exists in other apps, so it's not impossible:

• You could add a unique ID uid then use these uids for shortcut assigning while leaving the name free for edits. For example, in Vivaldi browser (see the screenshot below) I can change the menu names and it doesn't affect any keybinds, same for Sublime Text, this is a snippet of their menu text file that you can manually edit

  Code: Select all

  {"caption":"Sel","mnemonic":"S","id":"selection","children"

And even without the uids:

• That's not that big of an issue, with the current ability to export shortcuts to a text file I can easily search&replace old→new menu name and maintain all the shortcuts (although it currently doesn't export empty shortcuts, but that could also be fixed). After all, I only plan to do the menu renaming maybe once or twice, so this isn't a huge chore (though that's not ideal, of course).
• Of course, the best way would be to right click on a menu, select rename and change the name (or invoke some "Change UI" command and then click&rename), but that level of awesomeness in UI modification is too rare, so editing some text would suffice

• Con: "GraphicConverter" → "GC" is a certain loss of branding value.

In what way? For example, I'll value the brand more if I could fix the menu (also, I already see the full name when I launch the app)

[porg]

Offtopic: I really hope that @forum_adm may better realize that every minute he puts into improving/fixing forum search will save him 10x minutes spent on helping out users, which then can help themselves much better by finding "How Tos" more easily themselves, or don't make proposals as they already find a post with a similar proposal and a clear reason why it was not implemented, or an info that this is currently in progress es.

Ontopic:

"Viv" for "Vivaldi"

Let's see if "GC" instead of "GraphicConverter" is deemed enough "on brand"

Customized menu labels, e.g. Sublime Text

Cool, did not know that! Thanks for the real world examples!

level of awesomeness in UI modification is too rare, so editing some text would suffice

• I agree.
• To ease assignment in the UI I had proposed Edit Shortcuts: Dialog gets filters (search fields)
• Ofc knowing that it's likely not worth it.
• But if the developer deems "customizing command names and menu structure" worthy, which would be reasonable for such a feature rich app like GC, then a dedicated sophisticated customization UI may become a necessity. Showing original vs customized menu path/labels could be integrated into that design proposal.

doesn't export empty shortcuts

Interesting new take! A 3rd possibility! So now we have 3 approaches:

a) Export all commands with shortcuts (default ones and customized ones, @forum_adm went that way).
Con: When defaults change on the next update you have to resolve conflicts between old and new defaults, which is an unnecessary user effort.

b) Export only customized ones (recent proposal of me @abitofmind)
Pro: Defaults which change most likely don't cause conflicts, unless the overlap with your few customized shortcuts.
Con: Which I now realize thanks to your input: It is not suited as a complete catalog for manual editing as a viable alternative to GUI editing.

c) Export all shortcuts (assigned and unassigned ones, proposal of @es ).
Pro: Full catalog available for manual editing.
Cons: Update conflicts get maximized (with the current mechanism at least).

[es]

Let's see if "GC" instead of "GraphicConverter" is deemed enough "on brand"

Just to clarify: I'm fine with the default to be whatever, even the current "GraphicConverter 11", I don't need my force my customizations onto anyone!

Interesting new take! A 3rd possibility! So now we have 3 approaches:

I think the best nonGUI approach is also the one implemented in Sublime Text and it's about "cascading" shortcuts: you have user shortcuts file that gets merged with the default shortcuts file and then only override the shortcuts that exist in both, leaving all the other (current and future) defaults as is

For example, you have the default list that has 100 shortcuts, you can

• copy 10 and REbind them
• copy another 5 and UNbind them (bind them to "noop" to do nothing or "" to let the default OS shortcut work, not block)
• ignore the other 85

So your export/import file only contains the 10+5 shortcuts you've manually changed, not the full list, nor the full empty list
Then whenever the defaults change, you get all those changes automatically since your 15 shortcuts only override the 15 in the default, and if the defaults get another 50 shortcuts, you'll get them all as well!
Now, if the defaults remove some commands, yours will simply fail to work (and a warning would be nice), but then this also shouldn't require any involvement until you have time to fix it, everything else will continue to work.

• Then if you want to add shortcuts to commands that currently have no binding, you'd open another helper list of all the possible commands (with UIDs so they would be menu-name-independent) and paste the ones you need to rebind to your config.

So that's how the changes will be reflected in the file system: one user file containing only the commands that the user changed. This would also be a "live document", meaning you can actually ignore the GUI and edit it directly, and for some operations it might be even more convenient than a GUI, you can also group shortcuts how you like it, add comment/explanations there, etc. (the GUI changes should roundtrip those comments). Then you don't even need to import/export, just open a Finder in ~/Library/Application Support/GraphicConverter/Keybind and find your keybind.yaml


Now, in the GUI the best solution would be to just allow to enter the "change GUI" mode, double/right-click or something on a menu command (which you should also be able to find via Help→Search) and then press your keybind to rebind.
Or the current approach is ok if only search functionality were added.

So that would be my proposal

[forum_adm]

That would require a major change of the complete menu and app.

I add that to the wish list.

[es]

That would require a major change of the complete menu and app.

I add that to the wish list.

Thank you. By the way, is command palette viewtopic.php?t=6907 easier to implement than this major menu change? Because command palette is way more powerful and convenient (e.g., in Sublime I rarely use the menus (though did rename them a bit), but use the command palette all the time), so if it's also easier might be worth doing that first or even instead of this redesign...

[forum_adm]

The menu title can now be shortened with the latest BETA:
http://www.lemkesoft.org/beta.html

Screenshot 2024-01-30 at 09.19.jpg (498.31 KiB) Viewed 352 times

[porg]

GC 12.1 (6407) on macOS 11.7.10

I can toggle on/off the icon menus. After changing the checkbox and closing with OK the change gets effective.
Abbreviating "GraphicConverter 12" to "GC" does not work. Also not confirming it with OK. And then restarting the app. It always remains in the long form.

[forum_adm]

Yes, the app name in the finder is not related to the menu item.
That is the intended behavior.