Re: [gcmd-dev] User configurable shortcuts

[Piotr Eljasiak]

> > >> 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 variable definition, you would 
> apply a variable shortcut to the invariant action title: action := shortcut
> Just a matter of taste, baybe...nonetheless, ....a mess....

If we do the other way (ie. assigning key shortcuts to actions) we'll
get problems with handling multiple key values assigned to actions (how
to handle actions with the same keys assigned?). The actual way allows
to avoid these kind of problems... ;o)

> 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 users 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.

Well, probably you are right here, but... I plan to release 1.2.4 as
soon as we manage to get rid of the reported problems (the most
irritating bug is Magnus' one)

> > 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 ;)

Yet Another Good Idea (TM) - any volunteers? ;o)

> 
> 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. 

Vertical toolbars are the song of the (distant) future...


Piotr