According to EWMH, the window manager is responsible for removing the
urgent state of a client. Also, this commit adds a new
client_seturgent(client_t *, bool) function to set the urgent state if
needed.
Signed-off-by: Julien Danjou <julien@danjou.info>
here is a little patch which fix the unresizeable window bug. This bug is due
to some windows, like firefox, having XCB_SIZE_HINT_P_MAX_SIZE and
XCB_SIZE_HINT_P_MIN_SIZE on and all related values to 0, which makes
client_isfixed believe that the windows are of fixed size.
Hope this is the right way to fix it. Anyway now you know where this bug comes
from.
Signed-off-by: Julien Danjou <julien@danjou.info>
- From now on clients shall remain mapped for their entire lifetime.
- This should seriously boost tag switching speed with composite active.
- A lesser improvement may be noticed in non-composite situations.
- Titlebars that are set to invisble are still unmapped.
Since it would clutter the implementation and titlebars are cheap to render.
Not to mention that invisible titlebars are pretty rare.
- It's safe to attach titlebars while the client is banned.
- Titlebars are explicitly removed at exit.
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
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 avoid flickering when you repeteadly click on a client.
Also make the function client_focus void, it always returned true, and
nobody cares about the result.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
Gregor Best
Maarten Maathuis
Julien Danjou
Maxime COSTE
Arnaud VALLAT
Arnaud Fontaine
Konstantin
Pierre Habouzit
Michael Gehring