It is necessary to have it beforehand when creating layout objects
for unselected layouts.
In the current layout system, there is no layout object, but to allow
tabs and dynamic tagging features like ion3, layouts cannot be stateless.
The new widget layout code was created because we needed to support partial
redraws (only redraw the parts that were changed). Thanks to this, the code also
skips drawing widgets of size 0x0. Thus, when the systray becomes empty, it's
:draw() callback isn't invoked and thus our systray container window stays
visible.
Fix this by making the C code unconditionally hide the systray when it becomes
empty. There's nothing to display anyway.
Fixes https://github.com/awesomeWM/awesome/issues/624
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a client is unmanaged, we know emit mouse::leave on its titlebar before the
client object is invalidated, so that Lua can still work with it. Before, this
event was emitted only when we got a LeaveNotify from the X11 server.
Fixes: #620
Signed-off-by: Uli Schlachter <psychon@znc.in>
When there are multiple X11 screens (i.e. :0.0 and :0.1) for zaphod mode
style X setups, this triggers a refresh of focus when the instance
running on a particular root receives the mouse
Fixes https://github.com/awesomeWM/awesome/issues/599.
luaA_warn() prints a Lua backtrace and thus generates more useful output. warn()
should only be used in awesome-internal places (e.g. receiving an error from the
X11 server).
Closes https://github.com/awesomeWM/awesome/pull/608.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since commit ea94f7f7e6, the code has a preferred icon size and it tries to
find the closest matching icon. However, the default size of 0 and thus this
never returned any icon at all (no icon matches better than an icon of size
0x0).
Fix this by saying "every icon is better than no icon at all".
Signed-off-by: Uli Schlachter <psychon@znc.in>
These fields were only ever written to since commit 19137a55c3.
This commit removes the fields and the code that sets them.
Signed-off-by: Uli Schlachter <psychon@znc.in>
In commit 532ec0cd, we started grabbing keys on the client window directly
instead of its parent window (the frame window). This commit fixes one place
which was overlooked back then.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Some words about X11 event handling: Every X11 client can select input on any
window. For this, inside the X11 server each window has for each client a
bitmask for the kind of events that this client is interested in. When a mouse
button is pressed inside of a window, a corresponding event is generated for
that window and sent to all X11 clients which asked for
XCB_EVENT_MASK_BUTTON_PRESS. When no client is interested in this event, the
event is propagated to the parent window and the same procedure is done again
here. This continues up until the root window is reached.
Some words about the event masks that awesome uses: For clients, we ask for
button press events on the frame window that we reparent the client window into
so that we get any kind of press on the titlebar (and also events inside of the
client window if the client itself doesn't care for click events?). We are also
interested in button presses / releases on the root window. However, before this
commit, we didn't actually ask for button events on drawins (e.g. the wibox).
This worked fine, because no one asked for these events and the event propagated
to the root window where it was then sent to awesome.
However, newer Qt versions do something weird and the above broke. I don't
actually know what is going on. I know about the above propagation rules, but
looking at protocol traces of what Qt does, awesome should still get the button
events. During startup, Qt asks for button events on its own windows. After a
hotplug event, it asks the same again, but now also includes the root window.
So... how can Qt asking for button events on the root window cause awesome not
to get them? I have no idea.
(And yes, I guess that Qt asking for mouse events on the root window is a bug,
but I have no idea how exactly this happens nor about any other side effects of
it).
This commit makes us ask for button events on our drawins so that the server
will send them to us. This is the right thing to do anyway and it was reported
to have some positive effects.
Ref: https://github.com/awesomeWM/awesome/issues/415
Signed-off-by: Uli Schlachter <psychon@znc.in>
I didn't (and couldn't) actually test this in any way, but hopefully this makes
it easier to edit awesome's source without vim.
Thanks to Daniel Hahler for telling me about this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Having many arguments can easily get confusing and hard to understand. This
commit uses a table instead so that we have names that identify what each
callback does.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Without this fix `wibox.widget.textbox` ignores current theme font
setting and resets it to the initial one.
It becomes handy when the initial theme is tweaked during runtime, ie.
in `rc.lua`. Other AwesomeWM components like `awful` (taglist,
tasklist, menu) are aware and do respect the actual theme settings.
Closes https://github.com/awesomeWM/awesome/pull/89.
Lua will remove objects as values from a weak table before these objects are
finalized, but as values only in the next garbage collection cycle after the
object was finalized. Up to now, gears.object uses a table with weak keys so
that :disconnect_signal() works. This means that a signal can still call methods
which were already considered garbage by the garbage collector and thus can use
userdata from the C side which was already finalized. Crashes and other bugs
result.
This commit changes the code so that the function is also a value in the weak
table. Thus, the GC will remove the entry before the object is finalized.
Special magic is needed for Lua 5.1, because there only userdata has the
behavior that we want while we have a function. We do some magic with function
environments to make this work...
Closes https://github.com/awesomeWM/awesome/pull/567.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a cyclic dependency between the function used for the weak signal and
an object with a __gc metamethod. The problem occurs since the GC will first
finalize the object (call its __gc metamethod) and only in the next generation
will it actually collect the garbage and remove the functions from weak-tables
using it as a key.
And yes this needs special code for Lua 5.1 because there __gc doesn't work on
tables. :-(
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since weak signals specifically exist to do magic with the garbage collector, do
a couple of garbage collection cycles and verify that this does not disconnect
the callback function prematurely (the function is kept alive since it is a
local variable).
(I actually did a mistake that makes this enhanced test fail and fixed it before
committing)
Signed-off-by: Uli Schlachter <psychon@znc.in>
_NET_WM_ICON contains a list of icons and until now, the first one was
picked without regard to it's size. This adds a global option to set
the preferred icon size. When getting the client icon, the best size
match is picked. The size can be set via
awesome.set_preferred_icon_size() and the default is 0, which will pick
the smallest non-zero size icon available.
Signed-off-by: Lukáš Hrázký <lukkash@email.cz>
This adds new functions to all widgets that allow to force a specific
width/height. These values override the result from :fit().
Signed-off-by: Uli Schlachter <psychon@znc.in>
Most of this information isn't interesting. If you are getting awesome from a
distro, then the time, hostname and username of the build are likely 'random
stuff' and if you are building awesome yourself, then the hostname and username
are obviously yours and the time can still be interfered based on the awesome's
binary ctime.
The GCC version shouldn't make any difference at all.
Closes https://github.com/awesomeWM/awesome/pull/566.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When emitting layout_changed, the widget is relayouted. If this doesn't actually
change anything, nothing will be redrawn. Thus, this also emits redraw_needed to
force redraws.
This fixes a race condition with some weird tray icons. A new tray icon is
created and the systray is updated. Then this new icon is destroyed immediately
again and at the same time another icon is created. Then, the systray isn't
updated since the number of icons (=the layout) did not actually change.
However, it needs to be updated and so we ended up with broken/missing icons.
Fixes: https://github.com/awesomeWM/awesome/issues/487
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallee
Daniel Hahler
Uli Schlachter
actionless
Tristan B. Kildaire
Kimball Thurston
Daniel Hahler
Dario Gjorgjevski
Barlik
Lukáš Hrázký
ShadowKyogre
dyslesiq