This removes the C implementation of taglist and tasklist widgets and
use a Lua one.
This works by letting .widgets property of wiboxes to be a table with
table, and setting a special metatable on them which notify awesome on
newindex events, updating wiboxes.
Signed-off-by: Julien Danjou <julien@danjou.info>
Based on the original idea of Nathan Huesken, which was then implemented by
Gwenhael Le Moine, I completed and corrected the layout.
I added icons for the layout and modified the makefile and the aweseomerc.lua.in
to include the fair layout.
In the process I also decided to modify layoutgen.sh and tag.c, so that in the
future new layouts can be added without touching tag.c.
Signed-off-by: Julien Danjou <julien@danjou.info>
The patch is mainly to export client_array_t object to Lua,
but can be used to export any ..._array_t object.
The idea: export to Lua not a table, but userdata with
metamethods to get/set/define length of ..._array_t object
directly.
Now when I get clients field from tag object C code
creates full copy of client_array_t structure into Lua table.
It takes traversing a whole array of data.
I did it in other way: userdata is exported, with __index,
__newindex, and __len meta-methods defined, and Lua
script gains direct access to client_array_t C-array:
it can get client object, get length of array and assign
client objects to some index in C-array.
Pros:
No overhead of creation a copy of C-structure into Lua-table:
if I want just to test a number of clients for a tag, I don't need
a whole loop to build table, I just want to read clients->len field,
and I do so via __len meta-method.
Also if I want to get some client from tags.clients, I don't need
to create ALL clients Lua-objects, I just get client_t C-struct
and create Lua-object from it. Just in place.
So Lua-loop enuming all tag.clients is not 2 loops internally
(first create copy of tag.clients into Lua-table, then enum this table),
but only one, and if I break out of loop in the middle, I create
only some client Lua-objects, not all of them from tag.clients.
Contras:
As far as clients field is not a table, I cant use pairs/ipairs
and other table functions for it.
But it can be implemented in other way:
for k,c pairs(tag.clients) => for k = 1, #tag.clients,
table.insert(tag.clients, client) => tag.clients[#tag.clients+1] = client
etc.
One more Pro now:
As far as tag.clients in current implementation returns copy of data
table.insert doesn't do what's expected: it doesn't really add client
into tag.clients "array".
With my implementation client is added as expected, as we work with
client_array_t structure directly.
Signed-off-by: Julien Danjou <julien@danjou.info>
This improves lots of code efficiency (we *know* how many tags we have
now, YA'RLY).
Also fix a \todo in client.c: since knowing the number of tags is cheap,
ignore props that don't match it.
Use many p_alloca for things that depends on the number of tags (no sane
user will have *thousands* of tags. This saves a few more mallocs.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Julien Danjou
Alex Cornejo
Konstantin
Pierre Habouzit