A nil-value is no longer simply passed through, so this has to do some "special
things" to work properly.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this, calling one of the loading functions with a nil argument always
made it return the default 0x0 surface. With this change, the passed-in default
value is now properly applied.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of throwing a Lua error, the code now just prints an error message to
stderr on invalid markup. For callers which want to handle this case specially,
we add :set_markup_silently() which returns error messages.
Fixes: https://github.com/awesomeWM/awesome/issues/546
Signed-off-by: Uli Schlachter <psychon@znc.in>
While setting up an environment to run the integration tests in, the run.sh
script uses sed to generate versions of several files that refer to the
not-installed version of files. One of these needs to replace the call to
beautiful.init().
Before commit 20c9723c5b, the corresponding line was:
beautiful.init("@AWESOME_THEMES_PATH@/default/theme.lua")
Now this wants to find and replace the following:
beautiful.init(awful.util.get_themes_dir() .. "default/theme.lua")
To handle both versions, this commit adds some wildcards to the sed-expression
so that any line containing a call to beautiful.init is found and replaced.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Oh hey, Pango exports an API that allows to query for named colors based on the
famous rgb.txt! Let's use that!
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds support to gears.color.parse_color to parse things like "#fff" (one
character per color component, without alpha) and "#ffff0000ffff0000" (four
characters per component, with alpha).
This makes sense on its own, but should also help with
https://github.com/awesomeWM/awesome/issues/585.
Signed-off-by: Uli Schlachter <psychon@znc.in>
*WARNING* This introduce a minor API break as awful.tag.setscreen
arguments are now swapped for consistency
This allow to introduce logic for each properties and improve
awful.tag.add and execute logic when setting properties.
The code here doesn't always work, so it's best to just don't mess with
awesome.version, but return it directly.
Fixes: https://github.com/awesomeWM/awesome/issues/569
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code doesn't check the type of any of the values that it converts. However,
string elements are silently skipped if they cannot be converted.
The proper fix would be to make this code check types. For now, it will be ok to
"convert" non-strings to an empty string.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since some commits, surface.load_uncached() handles errors itself and thus we
don't have to print an error message here any more.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, a Lua error was thrown when loading a file failed. Most callers are
not prepared for this and the result is less than optimal.
This commit makes the functions print the errors and return nil instead. For
callers that want to handle errors themselves, "_silent" variants of the
functions are introduced which just return errors to the caller.
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
Uli Schlachter
Emmanuel Lepage Vallee
Daniel Hahler
actionless
Tristan B. Kildaire
Kimball Thurston
Daniel Hahler
Dario Gjorgjevski