They currently fit the general concept of a `request::` in the sense
that they are not property related and have "request handlers".
The commit also add deprecation for signals.
The reason for this fits within the larger standardization project.
Non-namespaced signals will eventually be renamed. This has started
a long time ago.
What is old is new again. Once upon a time, there was a `startup`
parameter to the `manage` signal. It is now back in the form of
a context.
Finally, this commit removes the `manage` section of `rc.lua`. It no
longer did anything worthy of being in the config. Each of its
important parts have been moved out over the years and the last
remaining bit is always required anyway. The code has been moved
to `client.lua`.
While this is a bit more memory intensive because it created the objects
per screen, it is more self contained. If the objective is to have well
defined sections that can be cut/pasted into new files, this change is
a net win.
This commit moves the previously hardcoded client button list
to the `awful.client` default button set. This will allow modules
to add their own buttons.
In later commit, those default buttons will also be added dynamically
to existing clients.
As visible in various modules and even built-in components like
`awful.keygrabber`, it was previously necessary to work around the
fact that keybindings could not be added later without using some
low level API hacks.
From now on, `rc.lua` will be a good citizen and use the same APIs as
the module to manage keybindings.
For a long time, it was deemed overkill and made rc.lua less readable
without the documentation.
However it is now clear that it's handling of unfocusable clients and
general bypassing of both `awful.client.focus.filter` and
`awful.ewmh.activate` filters causes bugs. Fixing them individually
in each instance of `rc.lua` `client.focus = c` would add so much code
that all the clarity provided by not using request::activate would be
burried in boilerplate code.
Fix#2328
* Default config: Unify mouse dragging behavior
When moving or resizing a client by dragging its titlebar with mouse,
the client is automatically focused and raised. However, this behavior
is not replicated by tne other dragging method, i.e. grabbing it with
mouse while pressing the modkey. Sometimes, this causes a client to
disappear below another one while moving.
This commit unifies handling of dragging clients with mouse, by ensuring
that the client is focused and raised, whichever dragging method is
used. The fix applies both to moving and resizing clients.
Signed-off-by: Piotr Śliwka <contact@psliwka.info>
* Default config: Fix clientbuttons style
This commit unifies code style of click handling functions defined in
`clientbuttons` table, to match the style introduced in a228696.
Signed-off-by: Piotr Śliwka <contact@psliwka.info>
* default config: floating windows: fix pinentry-gtk-2
We have class "pinentry" there already, but it seems to have changed to
"Pinentry"?! This uses "instance" instead, which hopefully works in the
old case also.
pinentry 1.0.0-1, gnupg 2.1.23-1
Also adds Blueman-manager and ConfigManager.
Running eval $(luarocks path --bin) before running awesome is not all
that easy. It's a lot easier to do the equivalent for this in rc.lua.
Plus, if LuaRocks is not installed, this will silently do nothing.
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Move table functions out of awful.util into new gears.table
* travis: Use v9999 prefix for full requests
Make sure no newly deprecated functions are used
* Move all `awful.util.table.*` calls to `gears.table.*` calls
Move table test functions from awful/util_spec to new gears/table_spec
Change awful.util.subsets call to gears.math.subsets in awful/key.lua
These files do not need to be executable and the commits which made
these executable apparently only did so accidentally (Commits
37684abe33 and bfc6065ad9).
Signed-off-by: Uli Schlachter <psychon@znc.in>
The default config had tables like mywibox and mywibox[s] was the wibox
that is visible on screen s. When a screen is removed, nothing cleans up
these tables and so the screen and the wibox could not be garbage
collected. The same applies to the layoutbox, taglist etc.
This commit removes the global mywibox table and instead saves it as a
property on the screen. This way, the screen is not explicitly
referenced and when it is removed, the screen, its wibox and all of its
widgets become unreachable and can be garbage collected.
This commit also updates the docs and the tests that referenced things
(mostly the wibox) via mywibox[s] to now use s.mywibox.
Fixes: https://github.com/awesomeWM/awesome/issues/1125
Signed-off-by: Uli Schlachter <psychon@znc.in>
This meta-lua script takes the "raw" awesomerc.lua and turn it
into the final file and generate a documentation page from its
parsed content. It support
* Turn {{{ into markdown categories
* Turn top level comments into documentation
* Add custom documentation sections
* Parse the code to add links for each API calls
This helps generate a good entry point for new users wanting to
understand the content of rc.lua without searching the API by
hand.
Over time, this will also become the basis of the documentation.
If `rc.lua` is separated into several files, this will be easy to fix
this script. It could even do the separation itself from a monolitic
file using the already implemented {{{ parser.
Imagine that you have two screens of different resolution and you change their
position (xrandr --output first --left-of second). Of course, the wallpaper has
to be updated afterwards.
This commit makes the default config do that.
Fixes: https://github.com/awesomeWM/awesome/issues/1102
Signed-off-by: Uli Schlachter <psychon@znc.in>
A client is supposed to go to a screen when:
* It has been started using `awful.spawn` with explicit instructions [1]
* An `awful.rules` rule **or any of its callbacks** set the screen [2]
* When something handle `request::screen` and/or `request::tag` in some
custom ways. [3]
* Some clients can request a screen and mean it (like MythTV/Kodi/XBMC and
some multi-window DAW) [4]
A client is supposed to go to the focused screen when none of the above are
true [5].
Other constraints:
* The screen need to be set only once, anything will will emit
`property::screen` many time and cause side effects.
* There has to be a single entry point to the algorithm, no multiple
"manage" handler.
* Awesome internals must use the `request::` signal API and not force
their decision outside of request handlers.
* Restarting Awesome must not change the client screen
Commit 2178744 fix use case number [1] and [2]. It actually fix [4] too, but
it is an accident and I am not sure we care about [4] anyway. Use case [1]
and [2], however, are very important.
Fix#1091