Put keybindings in binary searchable arrays.
This patch sorts keybindings in arrays by keycode or keysym to speed up look
up using binary searches. This is a preliminary work to enable more powerful
keybindings stuff, where keybindings can be cascaded or why not, attached to
specific clients.
Interstingly enough, this patch saves 100ko of initial memory (Heap) usage here.
The underlying idea is that we should be able to define keybindings_t as
trees of keybindings_t which would then define key sequences.
The OO approach kind of make sense in fact, since you create a base
keybinding (e.g. reacting on Mod4-w) and then you will probably (with
appropriate apis) be able to populate new submaps from that point more or
less dynamically.
And if you have two keybindings on Mod4-w, then adding them will replace the
previous one. This means that you can fake per-client bindings with e.g.:
k_default = keybindings.new({"Mod4"}, "w", something);
k_mplayer = keybindings.new({"Mod4"}, "w", something_else);
k_default:add()
and in your focus hook:
if /* code for testing if it's mplayer */ then
k_mplayer:add()
else
k_default:add()
end
This would not work before, it does now.
It will take way more sense with submaps of course.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2008-06-25 01:00:25 +02:00
|
|
|
/*
|
2008-12-18 11:33:19 +01:00
|
|
|
* key.h - Keybinding helpers
|
Put keybindings in binary searchable arrays.
This patch sorts keybindings in arrays by keycode or keysym to speed up look
up using binary searches. This is a preliminary work to enable more powerful
keybindings stuff, where keybindings can be cascaded or why not, attached to
specific clients.
Interstingly enough, this patch saves 100ko of initial memory (Heap) usage here.
The underlying idea is that we should be able to define keybindings_t as
trees of keybindings_t which would then define key sequences.
The OO approach kind of make sense in fact, since you create a base
keybinding (e.g. reacting on Mod4-w) and then you will probably (with
appropriate apis) be able to populate new submaps from that point more or
less dynamically.
And if you have two keybindings on Mod4-w, then adding them will replace the
previous one. This means that you can fake per-client bindings with e.g.:
k_default = keybindings.new({"Mod4"}, "w", something);
k_mplayer = keybindings.new({"Mod4"}, "w", something_else);
k_default:add()
and in your focus hook:
if /* code for testing if it's mplayer */ then
k_mplayer:add()
else
k_default:add()
end
This would not work before, it does now.
It will take way more sense with submaps of course.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2008-06-25 01:00:25 +02:00
|
|
|
*
|
2009-06-17 17:05:47 +02:00
|
|
|
* Copyright © 2009 Julien Danjou <julien@danjou.info>
|
Put keybindings in binary searchable arrays.
This patch sorts keybindings in arrays by keycode or keysym to speed up look
up using binary searches. This is a preliminary work to enable more powerful
keybindings stuff, where keybindings can be cascaded or why not, attached to
specific clients.
Interstingly enough, this patch saves 100ko of initial memory (Heap) usage here.
The underlying idea is that we should be able to define keybindings_t as
trees of keybindings_t which would then define key sequences.
The OO approach kind of make sense in fact, since you create a base
keybinding (e.g. reacting on Mod4-w) and then you will probably (with
appropriate apis) be able to populate new submaps from that point more or
less dynamically.
And if you have two keybindings on Mod4-w, then adding them will replace the
previous one. This means that you can fake per-client bindings with e.g.:
k_default = keybindings.new({"Mod4"}, "w", something);
k_mplayer = keybindings.new({"Mod4"}, "w", something_else);
k_default:add()
and in your focus hook:
if /* code for testing if it's mplayer */ then
k_mplayer:add()
else
k_default:add()
end
This would not work before, it does now.
It will take way more sense with submaps of course.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2008-06-25 01:00:25 +02:00
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2009-08-17 15:52:41 +02:00
|
|
|
#ifndef AWESOME_KEY_H
|
|
|
|
#define AWESOME_KEY_H
|
Put keybindings in binary searchable arrays.
This patch sorts keybindings in arrays by keycode or keysym to speed up look
up using binary searches. This is a preliminary work to enable more powerful
keybindings stuff, where keybindings can be cascaded or why not, attached to
specific clients.
Interstingly enough, this patch saves 100ko of initial memory (Heap) usage here.
The underlying idea is that we should be able to define keybindings_t as
trees of keybindings_t which would then define key sequences.
The OO approach kind of make sense in fact, since you create a base
keybinding (e.g. reacting on Mod4-w) and then you will probably (with
appropriate apis) be able to populate new submaps from that point more or
less dynamically.
And if you have two keybindings on Mod4-w, then adding them will replace the
previous one. This means that you can fake per-client bindings with e.g.:
k_default = keybindings.new({"Mod4"}, "w", something);
k_mplayer = keybindings.new({"Mod4"}, "w", something_else);
k_default:add()
and in your focus hook:
if /* code for testing if it's mplayer */ then
k_mplayer:add()
else
k_default:add()
end
This would not work before, it does now.
It will take way more sense with submaps of course.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2008-06-25 01:00:25 +02:00
|
|
|
|
2009-08-17 16:38:56 +02:00
|
|
|
#include "common/luaobject.h"
|
2008-06-30 22:49:10 +02:00
|
|
|
|
2008-12-18 11:33:19 +01:00
|
|
|
typedef struct keyb_t
|
2008-06-30 22:49:10 +02:00
|
|
|
{
|
2009-06-16 16:24:58 +02:00
|
|
|
LUA_OBJECT_HEADER
|
2008-06-30 22:49:10 +02:00
|
|
|
/** Key modifier */
|
2009-06-24 17:44:06 +02:00
|
|
|
uint16_t modifiers;
|
2008-06-30 22:49:10 +02:00
|
|
|
/** Keysym */
|
|
|
|
xcb_keysym_t keysym;
|
|
|
|
/** Keycode */
|
|
|
|
xcb_keycode_t keycode;
|
2008-12-18 11:33:19 +01:00
|
|
|
} keyb_t;
|
Put keybindings in binary searchable arrays.
This patch sorts keybindings in arrays by keycode or keysym to speed up look
up using binary searches. This is a preliminary work to enable more powerful
keybindings stuff, where keybindings can be cascaded or why not, attached to
specific clients.
Interstingly enough, this patch saves 100ko of initial memory (Heap) usage here.
The underlying idea is that we should be able to define keybindings_t as
trees of keybindings_t which would then define key sequences.
The OO approach kind of make sense in fact, since you create a base
keybinding (e.g. reacting on Mod4-w) and then you will probably (with
appropriate apis) be able to populate new submaps from that point more or
less dynamically.
And if you have two keybindings on Mod4-w, then adding them will replace the
previous one. This means that you can fake per-client bindings with e.g.:
k_default = keybindings.new({"Mod4"}, "w", something);
k_mplayer = keybindings.new({"Mod4"}, "w", something_else);
k_default:add()
and in your focus hook:
if /* code for testing if it's mplayer */ then
k_mplayer:add()
else
k_default:add()
end
This would not work before, it does now.
It will take way more sense with submaps of course.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2008-06-25 01:00:25 +02:00
|
|
|
|
2009-06-09 12:51:25 +02:00
|
|
|
lua_class_t key_class;
|
2009-08-17 15:52:41 +02:00
|
|
|
LUA_OBJECT_FUNCS(key_class, keyb_t, key)
|
2009-08-14 16:46:35 +02:00
|
|
|
DO_ARRAY(keyb_t *, key, DO_NOTHING)
|
2008-10-31 17:08:32 +01:00
|
|
|
|
2009-06-24 17:44:06 +02:00
|
|
|
void key_class_setup(lua_State *);
|
|
|
|
|
2009-04-29 10:43:54 +02:00
|
|
|
bool key_press_lookup_string(xcb_keysym_t, char *, ssize_t);
|
2008-08-13 10:30:24 +02:00
|
|
|
xcb_keysym_t key_getkeysym(xcb_keycode_t, uint16_t);
|
2009-01-05 16:59:20 +01:00
|
|
|
|
2009-08-14 16:46:35 +02:00
|
|
|
void luaA_key_array_set(lua_State *, int, int, key_array_t *);
|
|
|
|
int luaA_key_array_get(lua_State *, int, key_array_t *);
|
|
|
|
|
2009-08-14 16:52:22 +02:00
|
|
|
void window_grabkeys(xcb_window_t, key_array_t *);
|
2009-04-26 19:41:53 +02:00
|
|
|
int luaA_pushmodifiers(lua_State *, uint16_t);
|
2009-06-17 17:05:47 +02:00
|
|
|
uint16_t luaA_tomodifiers(lua_State *L, int ud);
|
2008-12-18 11:33:19 +01:00
|
|
|
|
Put keybindings in binary searchable arrays.
This patch sorts keybindings in arrays by keycode or keysym to speed up look
up using binary searches. This is a preliminary work to enable more powerful
keybindings stuff, where keybindings can be cascaded or why not, attached to
specific clients.
Interstingly enough, this patch saves 100ko of initial memory (Heap) usage here.
The underlying idea is that we should be able to define keybindings_t as
trees of keybindings_t which would then define key sequences.
The OO approach kind of make sense in fact, since you create a base
keybinding (e.g. reacting on Mod4-w) and then you will probably (with
appropriate apis) be able to populate new submaps from that point more or
less dynamically.
And if you have two keybindings on Mod4-w, then adding them will replace the
previous one. This means that you can fake per-client bindings with e.g.:
k_default = keybindings.new({"Mod4"}, "w", something);
k_mplayer = keybindings.new({"Mod4"}, "w", something_else);
k_default:add()
and in your focus hook:
if /* code for testing if it's mplayer */ then
k_mplayer:add()
else
k_default:add()
end
This would not work before, it does now.
It will take way more sense with submaps of course.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2008-06-25 01:00:25 +02:00
|
|
|
#endif
|
2009-08-21 16:44:30 +02:00
|
|
|
|
|
|
|
// vim: filetype=c:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:encoding=utf-8:textwidth=80
|