Re: [gcmd-dev] User configurable shortcuts

[Michael]

Piotr Eljasiak <address@hidden>:

> >> The shortcuts are read at start-up only, so you have to reload
> >> application to see the changes.
> 
> >That's at least the legacy way.
> >Still something to solve some day... e.g., how could a shortcut editor
> >get a running instance reload the table ? Can we have different running
> >instances get notified ?
> 
> Of course it's  possible, but requires too much coding to be worth of
> implementing...
> 
> >> Config file syntax:
> 
> >>     [<shift>][<control>][<alt>]key_name=action[|options]

This is a typical programmers-point-of-view, in the code you receive a key and 
lookup the action.
From the semantic logic, it's just a kind of varianble definition, you would 
apply a variable shortcut to the invariant action title: action := shortcut
Just a matter of taste, baybe...nonetheless, ....a mess....

For example, this is Windowmaker's syntax 
(excerpt): 

  ClipLowerKey = None;
  ClipRaiseKey = None;
  ClipRaiseLowerKey = None;
  CloseKey = "Control+Mod1+C";
  FocusNextKey = "Control+Up";
  FocusPrevKey = "Shift+Up";
  HideKey = None;
  HideOthersKey = None;
  HMaximizeKey = None;
  LowerKey = None;
  MaximizeKey = None;
  MiniaturizeKey = "Control+Down";
  ModifierKey = Mod1;
  MoveResizeKey = None;
  NextWorkspaceKey = "Control+Right";
  NextWorkspaceLayerKey = None;
  PrevWorkspaceKey = "Control+Left";
  PrevWorkspaceLayerKey = None;
  RaiseKey = "Control+Return";
  RaiseLowerKey = "Control+Shift+Up";
  RootMenuKey = "Mod1+Escape";
  ScreenNextSwitchKey = None;
  ScreenPrevSwitchKey = None;
  ScreenSwitchKey = None;
  SelectKey = None;
  ShadeKey = None;
  ToggleKbdModeKey = None;
  VirtualEdgeDownKey = None;
  VirtualEdgeLeftKey = None;
  VirtualEdgeRightKey = None;
  VirtualEdgeUpKey = None;
  VMaximizeKey = None;
  WindowListKey = "Control+Mod1+space";
  WindowMenuKey = "Control+Mod1+W";

The auto-rewrite also eliminates tabs. (Does the config accept them at all ?
They would be useful, however, to have the list more clean.)

> >Another way would be to provide a default full shortcut section (derived  
> >from
> >an normally unused default table) which is created at installation. I mean 
> >the
> >local user home installation here - A Good Thing anyway, to see what 's 
> >available, 
>  >and more easy hacking.

> 
> This is the way it works now. The first run writes all default bindings
> to ~/.gnome2/gnome-commander

> 
> >> A few key bindings have been removed from code:
> >> Now gcmd looks for the above actions in config, and if any one is
> >> missing - it will be redefined with its defaults.
> 
> >How about users who need to disable some shortcut generally ?
 
> So 'none' should rather refer to NoAction instead of NoKey...
> If you want to block access to certain key shortcuts -> it should be
> something alike:
> 
>     <shift>f5=no.action
> 
> What about it?

Not exactly....i was thinking of blocking an action, not a key.
So it's rather: <none>=file.edit
On first sight it may be pointless since you still can get the action via 
mouse. But you can add new available actions to the config file in such a 
neutral way. Only then users don't need to search the source code or some other 
helpfile to see what's new.

But let's keep the goal in mind. Some day you would think hey i want to have 
this feature on that key. So úsers don't want to know the actions strings. They 
want to apply a shortcut to some already available *action* directly - that is, 
a mouse or key command.

> in case of actions not being present, gcmd adds them with their default key 
> bindings. 

As a special case, after i updated from svn i couldn't find any new 
key_bindings section. I added it manually. The update was from a version 
without key_bindings to the newest. I think we can ignore that special case.

> The list is rather long - IMO it'll be better to have it in help files.

as well, ok
 
> I can add small cmdline tool scanning pressed key combination and
> printing out its description as it should appear in config file...

Yes please. Maybe as python plugin? to encourage extending it as a first user 
plugin ;)


Aprpopos emelfm2, the gtk2 version has one good feature, central vertical 
menu/action bars
http://emelfm2.net/files/ScreenShots/attachments/e2-0.3.3-main.png
Consequently, it needs to be symbols only, of course. Usually they open a 
rightclick menu.

Central+vertical is always shortest way with mouse, and also for the eye.
Firefox, for comparison, at least has the very handy all-in-one sidebar (aios)
http://firefox.exxile.net/aios/index.php
where you can also sort in any of the main menu bar on top.
Krusader has no vertical sidebar, but Konqueror has one. 

greets

 m°