Many applications face the problem of certain shortcuts being available for application use on some desktop environments, but reserved by other desktop environments (e.g. for controlling windows, virtual desktops, panels/taskbars, desktop gadgets, resolution, screensavers and so on). Now, if an application's defined shortcuts are the same across all desktop environments, there are two choices: * The app limits itself to a smaller number of shortcuts which are known not to be in use anywhere. * The app ships with no shortcuts for some functionality on some desktop environments, and no shortcuts for other functionality on other desktop environments. At the moment, we are somewhere between option (1.) and option (2.); and this has recently come up in the design meeting when discussing bug 158112. I claim, that we should allow shortcuts to differ based on some kind of information regarding the desktop environment. I won't bikeshed exactly what information here (it might even be platform information used as a proxy, e.g. Windows vs MacOS vs Linux, which should be easy to implement albeit inexact) - but it should be _something_. I should mention that apps which use CSS for styling, like Firefox and Thunderbird, often have this capability at least to some extent. Other apps just let the user switch between complete sets of keyboard shortcuts, and some of these are better suited to a given desktop environment than others (e.g. CLion).
Agree. Note that we already vary shortcuts based on language...
(In reply to Mike Kaganski from comment #1) > Agree. Note that we already vary shortcuts based on language... Yes, I know, I marked that as a related issue. In practice, though, the shortcuts which would very by language are probably the ones which are safe on all platforms, and involve letters, while the ones taken by the platform typically involve special keys and numbers or other non-letter symbols. So I don't expect implementing this would really lead to an explosion of shortcuts.
(In reply to Eyal Rozenberg from comment #2) > ... > So I don't expect implementing this would really > lead to an explosion of shortcuts. But it will lead to a maintenance and QA nightmare, each locale and os/DE would likely require templated installation and configuration packaging that would need to be maintained. In fact we already distinguish accelerators/mnemonics from true Shortcuts--both would have to be addressed in any os/DE/locale templating. Already have challenges (dev/translation/QA) with l10n and the language pack model, why choose a path that would exponentially complicate that and require a lot of os/DE native code to implement? But sure, it could be done--with potential to better modularize i18n into the LO core.
(In reply to V Stuart Foote from comment #3) > But it will lead to a maintenance and QA nightmare, each locale and os/DE > would likely require templated installation and configuration packaging that > would need to be maintained. Not necessarily. Let's look at just locale, for example. On Linux, locale support is just one additional package. It could be made that way on other platforms (if one ignores the localization of the installer). So, even with locale you don't need a different packaging of all of LO, just a packaging of the locale. Now let's have a though experiment with OS/DE-specific shortcuts. Suppose we recognize 5 different OS/DE's . So, you have just 5 small additional packages, the effect of installing which is altering the shortcuts to agree with that OS/DE ; and that is _not_ multiplied by the number of locales, if we keep the distinction I mentioned in my last comment. > In fact we already distinguish accelerators/mnemonics from true > Shortcuts--both would have to be addressed in any os/DE/locale templating. I'm not sure I understand what you mean.
(In reply to Eyal Rozenberg from comment #4) > > In fact we already distinguish accelerators/mnemonics from true > > Shortcuts--both would have to be addressed in any os/DE/locale templating. > > I'm not sure I understand what you mean. Well IIRC, Shortcuts are defined (and parsed) for strings [1], while mnemonics are defined (and localized) within the .UI XCU for specific UI components [2] Shortcuts are more stable, and in general will be notated in source with a "~"; mnemonics/accelerators are somewhat dynamic and in addition to semi-fixed in XCU are allocated/generated at compile time, they will be notated in source with a "_". =-ref-= [1] https://opengrok.libreoffice.org/xref/core/include/sfx2/strings.hrc?r=1f440348 [2] https://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu?r=a18174e8
(In reply to V Stuart Foote from comment #5) > Shortcuts are more stable, and in general will be notated in source with a > "~"; mnemonics/accelerators are somewhat dynamic I should have asked: What's the difference between "shortcuts", "mnemonics" and "accelerators"?
You can save/load the shortcut configuration which is suboptimal. And bug 123768 asks to make shortcuts extensionizable (originally "Adding an option to automatically improt MSoffic shortcuts"). => DUP *** This bug has been marked as a duplicate of bug 123768 ***
(In reply to Heiko Tietze from comment #7) > You can save/load the shortcut configuration which is suboptimal. That's nice, but not the ask here. > And bug > 123768 asks to make shortcuts extensionizable (originally "Adding an option > to automatically improt MSoffic shortcuts"). => DUP Can you explain why the bugs are duplicates of each other? This bug asks for the default shortcuts to be different for different platform.
(In reply to Eyal Rozenberg from comment #8) > default shortcuts to be different for different platform. You are building a swiss-army-knife. The idea to combine locale by platform by foo is very far-fetched to me. Feel free to reopen the ticket but I doubt you find a volunteer to do the implementation effort. The better approach IMO is to put this configuration burden on the community shoulder and provide extensions for what is needed.
(In reply to Heiko Tietze from comment #9) > You are building a swiss-army-knife. 1. In theory, perhaps, in practice, not so - like I explained to Stuart. The locale-specific and the platform-specific shortcuts will likely be disjoint. 2. Actually... the implementation could be non-swiss-army-knife even in principle: Just build the per-platform packages with different default-shortcuts files. The C++ code doesn't have to know about this per-platform thing, it will be a choice of build artifact - perhaps similar to a choice of icon themes. > The idea to combine locale by platform by foo is very far-fetched to me. See (1.) above. Also, what is Foo? :-) > Feel free to reopen the ticket but I doubt > you find a volunteer to do the implementation effort. Excessive implementation effort can be a cause for WONTFIX, and even that should be reserved for extreme cases. Here, the implementation may well be rather painless (see (2.) above; and that's just one idea). But can you confirm that the need is legitimate? And that, ideally, default shortcuts should differ on different desktop environments?
(In reply to Eyal Rozenberg from comment #10) > But can you confirm that the need is legitimate? I think I made my POV clear. No to combinations of configurations (in general).
(In reply to Heiko Tietze from comment #11) > No to combinations of configurations (in general). Again, no problem: The configurability will be per-locale, but the (non-configurable) defaults will be per-platform.
We define for example <node oor:name="LEFT_MOD1" oor:op="replace"> <prop oor:name="Command"> <value xml:lang="x-no-translate">I10N SHORTCUTS - NO TRANSLATE</value> <value xml:lang="en-US">.uno:GoToPrevWord</value> </prop> </node> in officecfg/registry/data/org/openoffice/Office/Accelerators.xcu with MOD1 being Ctrl/Cmd. On Windows/Linux you move word-wise with ctrl+left. So what we need is to change the commands/accelerator combination like in <node oor:name="F_MOD1_MOD2" oor:op="replace"> <value xml:lang="en-US" install:module="macosx">.uno:SearchDialog</value> ... <node oor:name="H_MOD1" oor:op="replace"> <prop oor:name="Command"> <value xml:lang="en-US" install:module="unxwnt">.uno:SearchDialog</value> Very much welcome for the macOS users.
Sorry for the noise. My take stands: we have all means to deal with various OS and languages. It's quite tedious to setup and I suggest to provide extensions to easily switch.
Duplicate of bug 123768? Ideally with a more convenient solution...
(In reply to Heiko Tietze from comment #15) > Duplicate of bug 123768? Ideally with a more convenient solution... You asked this in comment #7 and I replied in comment #8. The ask here regards the defaults. And, in fact, I believe it is easier to implement than making shortcuts extensionizable. But it's true that if 123768 were available, the more savvy users could resolve this problem for themselves.