Bug 158355 - Support per-platform/per-desktop-environment variation of keyboard shortcuts
Summary: Support per-platform/per-desktop-environment variation of keyboard shortcuts
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility, needsDevAdvice
Depends on:
Blocks: Shortcuts-Accelerators
  Show dependency treegraph
 
Reported: 2023-11-24 12:10 UTC by Eyal Rozenberg
Modified: 2024-05-23 07:55 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2023-11-24 12:10:37 UTC
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).
Comment 1 Mike Kaganski 2023-11-24 12:12:43 UTC
Agree. Note that we already vary shortcuts based on language...
Comment 2 Eyal Rozenberg 2023-11-24 12:28:19 UTC
(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.
Comment 3 V Stuart Foote 2023-11-24 13:24:52 UTC
(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.
Comment 4 Eyal Rozenberg 2023-11-24 14:44:57 UTC
(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.
Comment 5 V Stuart Foote 2023-11-24 15:30:59 UTC
(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
Comment 6 Eyal Rozenberg 2023-11-24 20:03:20 UTC
(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"?
Comment 7 Heiko Tietze 2023-11-27 11:50:15 UTC
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 ***
Comment 8 Eyal Rozenberg 2023-11-27 13:30:36 UTC
(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.
Comment 9 Heiko Tietze 2023-11-27 13:54:01 UTC
(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.
Comment 10 Eyal Rozenberg 2023-11-27 14:33:49 UTC
(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?
Comment 11 Heiko Tietze 2023-11-27 14:40:50 UTC
(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).
Comment 12 Eyal Rozenberg 2023-11-27 14:51:53 UTC
(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.
Comment 13 Heiko Tietze 2023-11-28 11:06:43 UTC Comment hidden (off-topic)
Comment 14 Heiko Tietze 2023-11-28 11:09:02 UTC
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.
Comment 15 Heiko Tietze 2024-04-23 07:49:08 UTC
Duplicate of bug 123768? Ideally with a more convenient solution...
Comment 16 Eyal Rozenberg 2024-04-23 09:23:22 UTC
(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.