Hi all,

Since we like the "write once, compile anywhere" concept, might it not also be usefull if we can share (in code) common shortcut-keys between Mac and non-Mac platforms?

For example, on many OS's running on PC's Ctrl+C, Ctlr+V and Ctlr+X, Ctrl+Home are used for copy, paste, cut and "goto the very beginning". On a Mac (AFAIK) the Meta key is used instead of the Ctrl key for this purpose. (I was told that a Mac can also have a Ctrl-key. I'm poor, so I don't have a Mac, and so I can't tell.)

Some LCL controls have hardcoded Ctrl+C, Ctlr+Home (etc.) for this, but that makes them incompatible with Mac standards.

Would it be a bad idea to define a constand that equals ssCtrl on non-Mac and ssMeta on a Mac?
This would avoid having to write widgetset implementations for DoKeyDown/DoKeyPress of LCL controls that have build-in support for these key combinations.

If so, should this be an LCL feature (since it mostly concerns GUI widgets), or should it be done in the classes unit?

I value your opinions.

Bart

Bart wrote

Would it be a bad idea to define a constand that equals ssCtrl on non-Mac and ssMeta on a Mac?

...

If so, should this be an LCL feature (since it mostly concerns GUI widgets), or should it be done in the classes unit?

I think this new constant would be useful. You should first try to get it included in the classes unit. If this is rejected, then we have now lazutf8classes where it can be placed.

That's up to the low-level keyboard functions, which translate physical keys into ssCtrl etc. But then ssMeta also could map to the Apple and Windows key, depending on the platform.

This would avoid having to write widgetset implementations for DoKeyDown/DoKeyPress of LCL controls that have build-in support for these key combinations.

Key combinations are a different topic, more subject to Actions, where standard Actions can have their platform specific shortcuts. Then the question were, whether the LCL maps the platform-specific shortcuts to a predefined constant (VK_CUT, VK_COPY...), or whether comparisons should be made against something like CutAction.Shortcut.

If so, should this be an LCL feature (since it mostly concerns GUI widgets), or should it be done in the classes unit?

Regardless of where such mapping is done, how can a user find out which shortcuts are *not* already assigned, free for use with his *own* actions?

What about menu-provided shortcuts, when ALT-F-X maps to Exit on an English system (File-Exit), while a German user had to use ALT-D-B (Datei-Beenden) instead?

DoDi

Hans-Peter Diettrich wrote

That's up to the low-level keyboard functions, which translate physical keys into ssCtrl etc. But then ssMeta also could map to the Apple and Windows key, depending on the platform.

Personally I would only want this feature for common cross-platform GUI commands that are similar on Man and non-Mac
- Copy, Cut, Paste
- GotoEof, GotoBof (for instance SynEdit maps this to Ctlr+Home, Ctrl+End)

Regardless of where such mapping is done, how can a user find out which shortcuts are *not* already assigned, free for use with his *own* actions?

That wouldn't really matter would it.
When properly implemented the OnKeyDown event gives aneough possibilities to verride the default behaviour of the component.

Bart

That's my gut feeling too. Do you think implementing the missing TStandardActions and handling their default ShortCut accordingly would suffice?

-Fl?vio

Fl?vio Etrusco wrote

That's my gut feeling too. Do you think implementing the missing TStandardActions and handling their default ShortCut accordingly would suffice?

I do not think solving this _only_ in TStandardActions is the way to go. I specifically would use something like ssModifier (=ssCtrl, or =ssMeta) in LCL components (e.g. TMaskEdit which by design handles all key input by itself, and there are other LCL examples like SynEdit, TreeView (IIRC) and DBGrid).

This is a chunk form a proposed patch for TMaskEdit:

 procedure TCustomMaskEdit.KeyDown(var Key: Word; Shift: TShiftState);
+const
+  ssModifier = {$if defined(darwin) or defined(macos)} ssMeta {$else}
ssCtrl {$endif};
 begin
   Inherited KeyDown(Key, Shift);
   // Not masked -> old procedure
@@ -1662,7 +1664,7 @@
       begin//Cut
         CutToClipBoard;
       end
-      else if (Shift = [ssCtrl]) then
+      else if (Shift = [ssModifier]) then
       begin//Clear
         DeleteSelected;
       end

This is the way I would see it being helpful for cross platform code for built-in key shortcuts.

StandardActions then could benefit from such a ssModifier constant as well.

Another approach might be to have a widgetset function like:

function KeyCombo_IsCut(const Key: Word; const Shift: TShiftState): Boolean

or something like:

type
  TCommonShortCut = (tcsUnknown,tcsCut, tcsPaste, tcsCopy, tcsBof, tcsEof);
function KeyComboToCommonShortcut(const Key: Word; const Shift:
TShiftState): TCommonShortCut;
begin
  //default to tcsUnKnown;
  Result := tcsUnKnown;
  ...
end;

Bart

This is a very good idea.
Check/Test/IsStandardShortCut? ;-)

-Fl?vio

You can do it this way, ignoring any platform standards. But this is not what I expect from a cross-platform library or component.

This comes much closer to my expectations :-)

DoDi

Where (in what unit) should something like this be implemented then?

Bart