The motivation behind this patch is my distro moving to a multiarch
layout. While binaries, libraries, etc. are are installed into
/usr/{host}/{bin,lib,...} architecture-independent data should still
go to /usr/share.
When minimizing a client, we temporarily ignore events for the client window (so
that we don't get the UnmapNotify event that we are causing for the unmap) and
for the root window (I don't actually know why, no "harmful" events should be
caused...).
However, we weren't ignoring events on the frame window itself. This commit
fixes that oversight.
The problem here is that the pointer could be inside the window that is being
minimized. When we then unmap said window, the pointer will now be inside of the
frame window and the X11 server will thus generate an EnterNotify. When we
handle this event later on, we emit mouse::enter on the client and e.g. the
default config then focuses this client, which undoes the minimization.
This fixes a regression introduced in commit 3aeac3870c and fixes#92.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This reparents all clients back to their proper position during shutdown, so
that their top-left corner is now where their titlebar's top-left corner was.
Hopefully, this fixes floating clients moving around across a restart.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Let's just quote a mail I received from Rastislav Barlik:
I tried to make use of awful.mouse.finder but I found out that it's not working
as supporting functions rounded_corners were removed with commit
03e0ee53d2.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Because ICCCM pretty much mandates that minimized (aka "iconic") clients are
unmapped. In detail: To go back to normal state, the client should map its
window and for this to work, the window needs to be unmapped.
Thanks to Oleg Shparber for reporting some issue he had with a self-written Qt
program and for providing a simple and short test case.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously we would get a short black flicker when a client closes. This
happened because first the client's window would get hidden and only a short
moment later would awesome react to this and close its own window. In the mean
time, the X server filled the frame window with its background-pixel which was
black.
Just removing the background-pixel means we get the default value which is None.
This means that the content will be left untouched and the client's window will
be visible for a moment longer.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Fun fact: ICCCM specifies that icon_pixmap must have depth 1. Xterm uses a
pixmap with depth 24. Yay... As such, I don't have any test for the depth == 1
case and will just assume that it does the right thing. If it doesn't, I bet no
one will notice anyway.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Conflicts:
property.c
I never saw a single program that set a border on its own windows. However,
awesome commonly sets borders on its clients and the position of a client is the
part outside of the border. So when processing a position request from a client,
we also have to include this border and fix things up correspondingly.
However, the same isn't needed for the client size, because the size does not
include the borders, but just the titlebar plus the "real" client content.
Thanks to Daniel Hahler for providing a simple test case based on urxvt for
debugging this!
Signed-off-by: Uli Schlachter <psychon@znc.in>
This patch allows 2 things to be done:
* Write unit test to validate layouts using fake clients and tags
* Query the current layout geometry from another tag
The advantages of the former are clear and simple. Those of the later include:
* Creating a screenshot of another layout
* Display the layout wireframe in the tag list (like KDE2-3, Gnome2)
* Having and 'ALT-tab' like visual popup for tags
* Move the "index" setting burden to individual functions
instead of gettags().
* Add some properties earlier so the signal hooks will be called
with valid data.
The old code transformed the top-left and bottom-right corner of the rectangle
to device space and calculated a rectangle based on these two points. However,
if you rotate a rectangle by 45°, these two points will be directly above each
other and thus the old code would calculate a width of 0.
Fix this by transforming all four corners of the rectangle into device space and
calculating a rectangle based on this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This fixes the following code:
local d = drawin({})
d.visible = true
The drawin now has a cairo surface assigned
d.visible = false
d.width = 1234
d.visible = true
The width change while the drawin was not visible would not get propagated to
the drawable because of the code that this patch removes. The expectation was
that drawin_map() would update the drawable later.
However, because the drawin was already visible, its drawable also already has
a surface assigned. Thus, drawin_map() wouldn't update the drawable either.
Fix this by just removing this optimizations.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code in drawin_moveresize() tries to be clever and only updates the drawing
state of the drawable when it is resized, not when it is moved around. This used
to be necessary because once upon a time, drawin_update_drawing() threw away all
of the drawing state and thus forcing a repaint. These days it just calls
drawable_set_geometry() as well and that function special-cases moves.
So this old code in drawin_moveresize() is no longer necessary and actually
caused problems.
These problems occurred because drawin_update_drawing() is being clever and
doesn't do anything for .visible = false drawins, because their drawing state
will be updated once they become visible. However, not skipping
drawable_set_geometry() means that this broke, because drawin_map() thought that
the drawing state was up to date while in reality it wasn't.
References: http://article.gmane.org/gmane.comp.window-managers.awesome/10852
Signed-off-by: Uli Schlachter <psychon@znc.in>
Let's just save the systray atom and keep it around. Why should we redo this
every time this atom is needed?
Signed-off-by: Uli Schlachter <psychon@znc.in>
When we get an event due to a previous GrabButtons call, we have to continue
normal event processing again, because the server froze the input device for us.
Without this, everything appears to freeze.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Setting a tag's screen to what it already is shouldn't have any bad effects.
However, this code messed up the tag order and selection status.
Fix this by returning early if the tag already has the right screen.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since commit 9c69e857ed, awful.tag.setscreen() unsets a tag's index to make
sure things end up in a sane order on the new screen. Thus, the call to
setscreen() removed the "index" property that tag.move just set.
Fix this by setting the index after the screen.
Signed-off-by: Uli Schlachter <psychon@znc.in>
It doesn't make sense for surface.load_uncached() to load a file without
inserting into the cache. The next "cached" load will have to load it again.
So move cache insertion into surface.load_uncached() and the only thing that
surface.load() does differently is checking if we have a suitable cache entry
before calling load_uncached().
So load_uncached() does the cache insertion and load() reads from the cache.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When an imagebox was drawn with width or height zero, it tried to calculate the
needed scale factor for making the image fit. Sadly, this would be a division by
zero aka infinite in this case.
Fix this by just not drawing anything if there is no space available.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This reverts commit c1cb7883b5.
The cairo surface used for uploading the wallpaper doesn't use a temporary
connection but is on our main connection since commit 5024843e9. Thus, the above
commit broke all of our cairo drawing instead of just making cairo not touch our
temporary connection.
Since commit 5b4666432f, we use set_text() instead of set_markup()
on the tooltip's textbox. This means it is no longer possible to use pango
markup in the tooltip which was not intended.
Fix this (properly) by introducing a :set_markup() function on tooltips (and use
it in the timer function to restore the old behavior).
Signed-off-by: Uli Schlachter <psychon@znc.in>
This inlines the set_defaults() function into its only caller and makes us less
stupid with the font property.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes gears.color() cache patterns in a weak table and returns that cached
pattern when we get called with the same argument again.
To benchmark this change, the following code was used:
local time = require("socket").gettime
function benchmark(func)
local begin = time()
local iter = 0
while time() - begin < 1 do
func()
iter = iter + 1
end
return iter
end
for _, arg in pairs({
"#00aa00",
"solid:#00aa00",
"radial:50,50,10:55,55,30:0,#ff0000:0.5,#00ff00:1,#0000ff",
"linear:1,2:3,4:0,#000000:1,#ffffff",
"png:/home/psychon/Wallpaper/Bars.png",
{ type = "solid", color = "#00aa00" },
{ type = "radial", from = { 50, 50, 10 }, to = { 55, 55, 30 }, stops = { { 0, "#ff0000" }, { 0.5, "#00ff00" }, { 1, "#0000ff" } } },
{ type = "linear", from = { 1, 2 }, to = { 3, 4 }, stops = { { 0, "#000000" }, { 1, "#ffffff" } } },
{ type = "png", file = "/home/psychon/Wallpaper/Bars.png" },
}) do
collectgarbage("collect")
print(benchmark(function() gears.color.create_pattern(arg) end), arg)
end
Before this change (larger numbers are better, this measures how many times we
can create the given pattern per second):
29525 #00aa00
29344 solid:#00aa00
3446 radial:50,50,10:55,55,30:0,#ff0000:0.5,#00ff00:1,#0000ff
4845 linear:1,2:3,4:0,#000000:1,#ffffff
32855 png:/home/psychon/Wallpaper/Bars.png
29883 table: 0x1bb67e0
3868 table: 0x1bb6830
5339 table: 0x1bb6c60
32772 table: 0x1bb6fe0
After this change:
126188 #00aa00
125962 solid:#00aa00
125125 radial:50,50,10:55,55,30:0,#ff0000:0.5,#00ff00:1,#0000ff
125213 linear:1,2:3,4:0,#000000:1,#ffffff
113659 png:/home/psychon/Wallpaper/Bars.png
125586 table: 0x1232680
125249 table: 0x12326d0
125468 table: 0x1232b00
113711 table: 0x1232e80
As you see, this makes some cases about 35 times faster (although I have to
admit that something like this can be expected from such a synthetic benchmark).
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of loading files from disk every time we need them, add a cache to
gears.surface as a weak table that maps strings to cairo surfaces.
If this cache should be avoided, there is a new gears.surface.load_uncached()
function which works just like gears.surface.load() worked before.
Signed-off-by: Uli Schlachter <psychon@znc.in>
By default, tag.history.restore switches between the previous history
states, which is not what should get done when deleting a tag.
Without this, deleting multiple tags in a row, will jump back to the
first/fallback tag, instead of the older history entries.