My initial implementation was overly optimistic. It turns out there
is no end in sight to "correctly" support icons. Apps randomly use
XDG name, paths and URLs. Rather than baloon the size of the
implementation, this commit moves toward to request:: pattern
found in other APIs. This will allow people who wish to "fix"
specific icons to do so in a way that scales.
The next 2 commits will move the current implementation to request
handlers.
The tag history kept a strong reference to a screen even after that
screen was removed. This prevented the garbage collector from cleaning
up.
Fix this by getting rid of the tag history on screen removal.
Related-to: https://github.com/awesomeWM/awesome/issues/2983#issuecomment-584249568
Signed-off-by: Uli Schlachter <psychon@znc.in>
Right now, there is still a memory leak *only* when there is active
`box` notification when the screen is removed. I failed to identify
where *this* leak is comming from. The previous few commits fix
~5 other leaks.
The API level concept is something used by other projects such as
Android and iOS to allow deprecated features to be removed and the
bahavior to be altered without breaking compability with existing
code.
The same will apply to AwesomeWM. The current API level is "4" and
as long as config use this, no deprecation or bahavior change will
be exposed. If the user sets it to an higher value or we release
the next major version and new users start to use the, then current,
default config, they will use the new API level.
The the far future, if ever, we could fork the entire Lua libraries
to support legacy APIs. This would only require to keep the core
API support for those legacy calls. In the meantime, `gears.debug`
will use this to manage the deprecation and some conditional code
will be added as a last resort attempt to preserve behavior
compatibility while moving forward with breaking changes.
The next commit will add modeline support. By default, modelines have
the final work on which options to set. However, mostly for testing,
this isn't flexible enough.
From now on, all core object will have their own rules. `awful.rules`
hardcodes some client specific code. All `rules` module have some form
of class specific code. This code will now be part of a new module
called `ruled`. Since a year or so, a lot of work has been done to
refactor the rules on top of the shared `gears.matcher` class. This way
there wont be as much duplication.
The default `rc.lua` was using the focus/unfocus signals to set
the border color along with `awful.rules`. This logic block was
no longer aligned with the rest of `rc.lua` since it was
the only place where `beautiful` variables where only used by
`rc.lua`.
On top of this, the new request handler also has extra contexts
for the urgent and floating/maximixed use cases. So it can be used
by themes to implement much smarter borders than just focus based
ones. They were previously limited by the fact most of the
(un-monkey-patchable) logic was in `rc.lua`.
Note that this commit also shuffle the awful.rules order between
the titlebar and the border and changes the tests accordignly.
After some consideration, I came to the conclusion the previous
behavior was bogus and the fact that the placement tests required
to know about the titlebar height is simply a proof of that. The
change was required in this commit because since the border is no
longer in the default rules, a new buggy edge case surfaced.
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`.
* Add a better descrition for the `imagebox` role in the wiboxes system ;
* Improve image + code render and integration into the descrition ;
* Add a second code exemple to show both coding style (imperative and declarative).
I think the user can now have a better overview of what's a `wibox.widget.imagebox` and how to use it.
Change how wibox are drawn to build a more flexible function reusable in the context of clients.
Add `clients` option to the template. This new option needs an associative table `{ ['label'] = client }` to work. Where label will be a text rendered on the middle of the client area.
Add a new example: `texts/examples/screen/tiled_clients.lua`.
Rulers insertion order impact the result of the bubble sort algorithm.
By inverting the order, we can make the output image looking more natural.
Awesome's screen properties can be seen like this:
* The screen has a geometry (its size) ;
* Inside there is the workarea ;
* Inside there is the tiling_area.
It seems better to draw rulers in this order.
Another step in moving these APIs toward the common object oriented and
declarative paradigms used by other APIs.
This commit introduces the `awful.keyboard` module. It currenly only
exists as a placeholder for the first few append/remove function, but
will grow in scope in another pull request to expose the currently
private modifier APIs and to provide keybindings collision detection
and replace some of `awful.hotkey_popup` business logic.
The `keygrabber` tests which uses root keybindings are disabled for
now to keep the commit size small. This is necessary since the shims
will need many iterations of changes before this work again with the
new syntax.
Try both legacy and standardized code paths. Also try invalid mixes of
them in case some modules abuse of rc.lua and ingest the wrong format
by accident.
There is no better place to put it and need to always be required
for backward compatibility. Given Awesome no longer works properly
without `awful`, I put the code there.
This isn't very nice and pulls all sort of almost useless code into
the shims, making them less atomic. However the next few commits
will start another round of API standardization and the compatibility
layer wont be optional anymore.
This template allows to display a sequence of events for the clients,
tags and screens. Currently, it is hard to display images where the
state of an object is more complex than "here how it was before" and
"here how it is now". With this template, it is possible to have a
timeline of events from the initial states to the final states.
Now, as the line count shows, this isn't small. It is in fact an
enormous template. Worst still, this commit is the first *half* of
it. The second half adds the ability to `print()`, display
inline code and support mouse and keyboard events. The code also isn't
world class. Maintaining this template might be non-trivial in the
long run. I am fully aware of those issues. On the other hand, there
is ~100 places where this will be used once the entire
"new rule library" project is completed. This will bring the ~1.2k
line of code to ~12 lines per consumer. From that point of view,
it makes a lot more sense to merge this given how useful it is
at explaining changes within the "core objects".
It is also important to keep in mind that there is currently very
little or no documentation (beside the mandatory one-liner summary)
for these concepts. Those are the most important aspects of AwesomeWM
API and they are the least documented. This is just wrong.
Previously, it would create screens outside of a visible output area. In
the following commit, this will be tracked and a warning is printed when
it happens. This makes the test fail.
Both commit 44e6b2d24e and 4eda67ce54 added the same function to this
file (and by the commit message, the later was intended to do so, while
the former has an unrelated commit message (but does not contain any
other changes)).
Signed-off-by: Uli Schlachter <psychon@znc.in>
* test-selection-transfer: clarify comment / condense
Noticed this via flaky coverage for the check after the "wait_a_bit"
block.
Ref: https://codecov.io/gh/awesomeWM/awesome/pull/2872/changes#L193
* tests/_runner.lua: add support for wait_per_step
Might be good to have a short version of it (single line), but extra
lines are indented, so this seems to be OK.
This helps / shows when the built version is not up-to-date (e.g. after
git-bisect), and serves as a basic check that it can be run in the first
place.
In case of error, well, make an error, but update the content anyway.
This will be enough for the CI but makes development less painful.
Also update the cmake targets to re-generate them more often.
Previously it was possible to manipulate deleted screens and that
made debugging harder down the line. By catching this early, it
wont be as nightmarish.
The way background are rendered changed to accomodate issues regarding
cliping and border. However this broke the documentation examples.
This commit fixes this in the least hacky way I found.
Fixes#2727
* action icons
* persistence
* residence
* categories
* animated icons
* more ways to get icons
In addition, the commit also tries its best to attach notifications to
objects using various dubious semi compliant hints or the DBus PID. It
works often enough to be useful.
Add a test which recreates the titlebar for an existing client and
checks that widgets from the old titlebar instance can be GC'd.
Signed-off-by: Sergey Vlasov <sigprof@gmail.com>
Test the behavior of awful.placement.no_overlap when placing clients on
unselected tags. Currently this tests only the most common case with
only a single selected tag and a single tag set for each client.
Signed-off-by: Sergey Vlasov <sigprof@gmail.com>
Clients which are sticky should be taken into account by
awful.placement.no_overlap even if they seem to be on a different tag;
add a test to verify this behavior.
Signed-off-by: Sergey Vlasov <sigprof@gmail.com>
Clients which are hidden or minimized should be ignored by
awful.placement.no_overlap; add a test to verify this behavior.
Signed-off-by: Sergey Vlasov <sigprof@gmail.com>
In order to test the behavior of awful.placement.no_overlap with
unselected tags, the test sequence must be able to run multiple times.
Fix the test code to make this possible (currently it just performs the
same sequence 3 times, the code to actually test the behavior with
different tags will be added later).
Indentation is unchanged to make the changes obvious in diff; the next
commit will contain formatting changes without anything else.
Signed-off-by: Sergey Vlasov <sigprof@gmail.com>
This commit also add some "magic" comments to existing tests so they
render correctly. Note that some older commits predates these "magic"
comments, which is why they are not there.
This way their name doesn't get mangle by the broken magic. It will also
eventually allow to `error()` in the template when the implicit
`@function` is used.
This commit also fixes a large number of issues found while
proof-reading everything.
- Fill slider bar with a linear pattern based on current value (if `bar_active_color` and `bar_color` are correctly provided)
- Add examples for the apidoc
hung
mergify[bot]
Seth Barberee
Emmanuel Lepage Vallée
ArenaL5
Uli Schlachter
Aire-One
actionless
Xinhao Yuan
Daniel Hahler
Daniel Hahler
Aire-One
Sergey Vlasov
Uli Schlachter
Michael Beaumont
worron
Hùng