Previously, it would use the "real" args passed to the constructor.
It was a bad decision since:
* It doesn't allow the tag/tasklist to add properties internally
* It forces the widget to be created with a constructor rather than
the alternate declarative syntax
* It doesn't allow a tag/tasklist to be part of a widget_template
Technically this is a behavior change, but I doubt anybody will notice
given it is a dark and little documented corner of the API. Chances are
nobody have been using this API for years.
With this helper, it becomes possible to avoid manually setting common
properties such as the client in the tasklist of tag in the taglist when
the children widgets of the template have a set_+property_name.
This decision was taken out of necessity. While adding more style
elements to `awful.widget.common` isn't something I want, there is
little else to do here. The problem is that popup based lists only
have size constraints in one direction. So without a way to limit
the icon size, it will take 9999 pixels.
Instead of having the default template hardcoded as code, this turns the
template into a descriptive version. This makes it easier to come up
with own templates: Just copy the default template and make a slight
change to it.
No functional changes are intended, but I cannot rule out that I did no
mistakes.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The current `awful.widget.layoutlist` is a fork of the so far uncommitted `naughty.widget.actionlist`. It was created because some of the support code for the new `naughty` implementation needed "easier to merge" usage examples. The `layoutlist` was chosen because it was both a low hanging fruit and genuinely useful.
The current taglist/tasklist allow filter function to remove elements
from the list. However they don't allow sorting or additional entries
to be listed.
This commit introduced such a concept. It will later be used by the
layoutlist where it becomes more relevant since layouts are used created
"objects".
The code here has things like "if cache.bgb" which suggests that "bgb"
(great name, by the way) is supposed to be optional. However,
31b8623ff6 made this thing definitely not optional by making it
*the* widget that is displayed. That feels wrong.
Also, after the above commit, the ".primary" entry is no longer used,
which is at least surprising for something which is called "primary".
None of this is explicitly documented (I didn't find anything when
looking for "primary" in common.lua nor tasklist.lua; I know that there
are examples for using this, but still that doesn't say how this is
supposed to work), so I'm not quite sure how this was intended to work.
Instead, I am just proposing this commit as a better fix with the above
rational and see what feedback I get...
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit allow user defined delegates to be used as list elements.
This put an end to the endless attempt to cram more features into this
code.
A widget template (non-instantiated) is passed to the arguments and
is created by the common code. It also supports "roles" where some
user defined widgets can replace the old textbox or imagebox.
The old function didn't scale at all. As no replacements are going
to be merged anytime soon, start to make it meta-extensible.
This is the first step to be able to let the widget be extended
directly from rc.lua without adding yet more silly parameters.
It never scaled and has reached the point of no return a very long
time ago.
My first ever contribution to Awesome was to attempt to fix this,
but the solution was a bad hack. The radical module later solved
this by delegating the style, layout, theme, item layout and item
style to various "visitor" objects. While this is superior to this
commit, it was also a very large and complicated codebase. After
5 years, it is now obvious it will never be merged "whole".
Once upon a time, beautiful.xresources.get_dpi was added to query
Xft.dpi. That made sense since this queried an xresources property. Over
time, other, non-xresources-based ways to query DPI were added to this
function. Now, it makes no more sense to have this function here.
Also, recently it became possible to add new properties to C objects
from Lua code. Thus, we no longer need to have a get_dpi() function
somewhere, but can add s.dpi directly.
Thus, this commit adds s.dpi and makes everything use it. No functional
changes are intended.
Signed-off-by: Uli Schlachter <psychon@znc.in>
* feat(awful: widget: calendar_popup: attach): implement 'on_hover' option
* feat(awful: widget: calendar_popup): smarter handling of click and hover at the same time
I am not sure what exactly goes on in the below bug report, so this will
just paper over the problem. I still think that this patch is a good
idea even when it is not a proper fix, since keyboard layouts are
complicated and so this code should be robust and hard to break.
Fixes: https://github.com/awesomeWM/awesome/issues/1933
Signed-off-by: Uli Schlachter <psychon@znc.in>
There were multiple things which stood out to me, as I was trying to setup a simple calendar popup for my textclock:
1.: The functions in https://awesomewm.org/doc/api/classes/awful.widget.calendar_popup.html#Functions were not named correctly (calendar vs calendar_popup) which (naturally) produced an error when used as awful.widget.calendar.month() .
2.: The example for calendar_popup.month() was obviously missing a line (where does the month_calendar come from?) . Resolved by copying the line from the attach-example
3.: The same examples also only refer to the function as calendar.month() which should be changed to awful.widget.calendar_popup.month()
fREW Schmidt
Emmanuel Lepage Vallee
Uli Schlachter
Aire-One
Yauhen Kirylau
Kevin Zander
Kirill Funtov
Uli Schlachter
Daniel Hahler
getzze
SpiritCroc
mqus
Tim Roes