The way of icon path lookup for `menubar` is enhanced so that it is
based on a theme-oriented way as described in the specification:
Icon Theme Specification, Ver. 0.12
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
To accomplish this:
* Add the two new files `icon_theme.lua` and `index_theme.lua`.
The former implements an icon lookup algorithm suggested in the URL
above. The latter implements a helper object to parse the cache file
`index.theme` of which data is used by the former.
* Modify `menu_gen.lua` to use the new algorithm.
- The implementation of `lookup_category_icons` is changed
accordingly.
- The values of the field `all_categories.icon_name` are changed file
names to icon names, i.e., file extensions which are used to
indicate image file formats are removed.
* Add the new file `icon_theme_spec.lua` for a unit test for checking
if `icon_theme.lua` together with `index_theme.lua` works as
expected.
When a client is not visible, this would adjust its stacking order
still.
This also addresses https://github.com/awesomeWM/awesome/issues/472,
because it raises unminimized clients after they got focused.
This function updates a hierarchy if the layout of some widgets changed. It does
nothing on the parts that did not change. This should be more efficient than
recomputing the whole hierarchy whenever something changes.
Once again, this has some positive results on the "benchmark test":
Before:
create wibox: 0.083016 sec/iter ( 13 iters, 1.161 sec for benchmark)
update textclock: 0.00391091 sec/iter (271 iters, 3.219 sec for benchmark)
relayout textclock: 0.00273234 sec/iter (397 iters, 1.087 sec for benchmark)
redraw textclock: 0.0010191 sec/iter (989 iters, 1.745 sec for benchmark)
After:
create wibox: 0.083146 sec/iter ( 13 iters, 1.163 sec for benchmark)
update textclock: 0.00170519 sec/iter (647 iters, 2.201 sec for benchmark)
relayout textclock: 0.000581637 sec/iter (1880 iters, 1.094 sec for benchmark)
redraw textclock: 0.0010167 sec/iter (997 iters, 1.773 sec for benchmark)
So again no difference for creating wiboxes (100.16% compared to before). This
time we also have no real difference for creating wiboxes (99.76%). Update (44%)
and relayout (21%) are improved a lot.
Closes https://github.com/awesomeWM/awesome/pull/463.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes the textbox' :draw() and :fit() callbacks use the DPI that is
specified in the given drawing context. With this, the textbox now scales
correctly if different screens have different DPI values.
Idea originally from Daniel.
Closes https://github.com/awesomeWM/awesome/pull/457.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This has some positive results on the "benchmark test". Each single number is
the best one out of three runs.
Before:
create wibox: 0.0826502 sec/iter ( 13 iters, 1.157 sec for benchmark)
update textclock: 0.0186952 sec/iter ( 57 iters, 2.473 sec for benchmark)
relayout textclock: 0.0158112 sec/iter ( 64 iters, 1.028 sec for benchmark)
redraw textclock: 0.0015197 sec/iter (662 iters, 1.861 sec for benchmark)
After:
create wibox: 0.0825672 sec/iter ( 13 iters, 1.154 sec for benchmark)
update textclock: 0.00378412 sec/iter (277 iters, 4.216 sec for benchmark)
relayout textclock: 0.00259056 sec/iter (420 iters, 1.09 sec for benchmark)
redraw textclock: 0.00105128 sec/iter (958 iters, 1.79 sec for benchmark)
We see no significant change in the creation of wiboxes (99.9% compared to
before). Update (20% of the previous run time), relayout (16%) and redraw (69%)
are all sped up by this change.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of going through LGI to call cairo, this now implements the various
matrix operations directly in Lua. The plan is to avoid the overhead that we hit
due to LGI.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This (ab)uses the integration tests to run a benchmark. This currently only
measures wibox drawing performance. To avoid wasting CPU-cycles, this does only
a quick run under travis while on "normal" runs the function under test is
executed in a loop to improve the precision of the measurement.
This benchmarks hopefully allow to optimize things in a clear fashion instead of
things like "it feels faster to me".
Results when run against the previous commit:
== Running test-benchmark.lua ==
create wibox: 0.0788958 sec/iter ( 13 iters, 1.103 sec for benchmark)
update textclock: 0.019493 sec/iter ( 56 iters, 2.507 sec for benchmark)
relayout textclock: 0.0160725 sec/iter ( 63 iters, 1.029 sec for benchmark)
redraw textclock: 0.0015601 sec/iter (647 iters, 1.875 sec for benchmark)
W: awesome: a_glib_poll:291: Last main loop iteration took 6.593912 seconds! Increasing limit for this warning to that value.
Results right before the new widget layouts were merged (commit 52154d0f15):
== Running test-benchmark.lua ==
create wibox: 0.0782874 sec/iter ( 13 iters, 1.095 sec for benchmark)
update textclock: 0.00736755 sec/iter (136 iters, 1.346 sec for benchmark)
W: awesome: luaA_dofunction:77: error while running function
[...]
error: /home/psychon/projects/awesome/build/lib/gears/object.lua:30: Trying to emit non-existent signal 'widget::layout_changed'
Closes https://github.com/awesomeWM/awesome/pull/451.
Signed-off-by: Uli Schlachter <psychon@znc.in>
- Remove `-rdynamic` from "CFLAGS" and count on CMake to pass it to
the compiler at the link phase (Issue #450).
- Move the definition of "CFLAGS" from `awesomeConfig.cmake` to
`CMakeLists.txt` and give it a name, `AWESOME_C_FLAGS`, so that the
relation between the target and the flags is made clearer and
manageable.
- Make `AWESOME_C_FLAGS` a cached variable so that the developers can
tweak the flags promptly in accordance with their necessities without
changing the prescribed value.
- Add a logic to cope with the case where CMake fails to set
`-rdynamic`.
Closes https://github.com/awesomeWM/awesome/pull/453.
There is a client window C. Around this window, awesome adds a frame window F.
When the pointer is inside of C and then moves inside of F, we get a LeaveNotify
with detail=Inferior, but from our point of view, the pointer is still inside of
C, because F is contained in C.
Similarly, if the pointer is in F and moves to C, we get an EnterNotify with
detail=Inferior that we should ignore. However, for an EnterNotify the pointer
can now be inside of a titlebar, so this case has to be handled now.
The above explains the enter/leave behavior for clients. Let's now think about
titlebars: When the pointer moves from C to F, it cannot be in any titlebar any
more, so we must generate a leave event on that titlebar. Similar when the
pointer moves from F to C, but in this case we also have to figure out which
titlebar now contains the pointer.
This patch makes the code handle these events with detail=Inferior correctly.
Closes https://github.com/awesomeWM/awesome/pull/461.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a global variable that tracks the drawable that is currently under the
mouse cursor. This new variable is then used so that we get consistent behavior
for enter/leave signals. Such signals are now also generated when a MotionNotify
event tells us that the pointer is now in a different titlebar.
Before this, it was possible that we did not generate a leave event on a
titlebar since the LeaveNotify contains the cursor position after the leave and
we did not manage to figure out which titlebar was left.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this, dependencies between widgets where implicitly discovered by
recursive calls to base.fit_widget() and base.layout_widget(). However, it is
too easy to get this wrong (just call one of these functions from outside of a
widget's :fit() / :layout() function) and the resulting mess would be hard to
debug.
Thus, this commit changes the API so that callers have to identify themselves
and we can explicitly record the dependency between the widgets involved.
This also fixes a bug where no dependencies were tracked for widgets after
:set_visible(false). Whoops...
Sorry for breaking the API for adding this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This is used by `tooltip.place` then to tie the tooltip to the screen of
the mouse. Without this, a tooltip from the tasklist might get moved to
the screen above the tasklist, if it gets considered to be on that
screen given its coordinates.
Closes https://github.com/awesomeWM/awesome/pull/437.
When a complete repaint is scheduled, also do a relayout, because this is also
the case that we go through when the underlying cairo surface is resized. For
example, resizing a client with a titlebar would trigger this.
Also, going through this code path is necessary since this is the only place
where the dirty area is updated so that it includes "everything". Before this
change, nothing was actually redrawn, because the dirty area was empty.
Fixes: https://github.com/awesomeWM/awesome/issues/449
Signed-off-by: Uli Schlachter <psychon@znc.in>
Add a path to awesomeConfig.cmake for searching an iconv library and the
corresponding header file automatically if the build system is on Mac OS
X which needs to pass the header and library paths explicitly to the
compiler to build Awesome successfully.
Closes https://github.com/awesomeWM/awesome/pull/440.
Extend the range of the 'group_names' patterns which is currently
restricted to typical ones like
pc+us+ru:2+de:3+ba:4+inet
to more general ones such as
macintosh_vndr/apple(alukbd)+macintosh_vndr/jp(usmac)+macintosh_vndr/jp(mac):2
so that the keyboardlayout widget can handles all possible patterns
returned by awesome.xkb_get_layout_group().
This accidentally called the draw callbacks with a nil argument instead of the
context. This was introduced in some badly done rebase, sorry! :-(
Signed-off-by: Uli Schlachter <psychon@znc.in>
The default config has this:
awful.key({ modkey, }, "o", awful.client.movetoscreen ),
This moves the client to the next screen and focuses that screen.
But it does not ensure that the client is raised above any existing
windows, e.g. when moving a floating client.
This patch emits the `request::activate` signal if the client is
currently focused, but only if the screen property actually has changed.
Closes https://github.com/awesomeWM/awesome/pull/98.
Uli Schlachter
Kazunobu Kuriyama
Daniel Hahler
Daniel Hahler
▟ ▖▟ ▖
actionless
Alastair Robertson
Clemens Kirchgatterer
Kazunobu Kuriyama
Abdo Roig-Maranges