Awesome: Function to get current theme directory

[daurnimator]

(carrying over from IRC):
It would be great if a theme didn't need to know it's own name.
Add a new function get_current_theme_dir() that returns the current theme's directory

Implementation suggestion:

Strip off the filename off the path passed to beautiful.init and save it somewhere for the duration of the beautiful.init call.

Example usage (in a theme.lua):

theme.wallpaper = beautiful.get_current_theme_dir().."/background.png"

[lcpz]

IMO, a new function is not needed for this.

Since a theme is named by its directory, and assuming that you put your themes in ~/.config/awesome/themes, you can just do something like this:

theme.name = string.gsub(debug.getinfo(1).short_src, "^(.+\\)[^\\]+$", "%1")
theme.dir = string.format("%s/.config/awesome/themes/%s", os.getenv("HOME"), theme.name)
theme.wallpaper = theme.dir .. "/background.png"

[Elv13]

First of all, it exists https://awesomewm.org/apidoc/libraries/awful.util.html#get_themes_dir
But I also use the debug code, similar to @copycat-killer

local path = debug.getinfo(1,"S").source:gsub("theme.*",""):gsub("@","")

[daurnimator]

First of all, it exists https://awesomewm.org/apidoc/libraries/awful.util.html#get_themes_dir

That is the themes directory, not the directory of the current theme being evaluated.

---

I'd like to think use of debug.getinfo shouldn't be encouraged. In particular it means that users cannot write a library of helper functions.

[Sorky]

@daurnimator

First of all, it exists https://awesomewm.org/apidoc/libraries/awful.util.html#get_themes_dir

That is the themes directory, not the directory of the current theme being evaluated.

I'd like to think use of debug.getinfo shouldn't be encouraged. In particular it means that users cannot write a library of helper functions.

This gives the path to the file's dir local path_this = debug.getinfo( 1, "S" ).source:match( "/.*/" ) and I tend to use it fairly often - Just for my education, how does it impact the "library of helper functions"?

[daurnimator]

Just for my education, how does it impact the "library of helper functions"?

That snippet would have to go into the theme file itself. If you moved it to e.g. a "awesome-utils" library, then it would instead return the location of that library (rather than the theme).

[Sorky]

I see what you meant - I think Elv13 meant to use it in the theme itself (which is what I do)

Sorry to bring an old thread back to life, it's just that I'm looking at possible changes in beautiful.init and was reviewing old issues to make sure nothing breaks

If you don't mind me asking, I'm wondering if requiring beautiful in the theme is really a good idea?

PS: G'day from an EE in Sydney

[daurnimator]

I'm wondering if requiring beautiful in the theme is really a good idea?

Why wouldn't it be? How else would a theme use e.g. beautiful.get_font_height

[Sorky]

Interesting - How do you use that in a theme? To set other them variables based on a calculation?

To me the theme file is basically a set of constants that get used in rc.lua or other modules.

None of the sample themes include beautiful - Some do include extra stuff in sub-directories and include functions, but not beautiful itself.

Unless of course you go with the copycatz approach of putting widgets and other stuff in the theme.lua - Personally I'd do what the sample themes do and put anything outside of the standard constants into a separate lua

[Elv13]

Unless of course you go with the copycatz approach of putting widgets and other stuff in the theme.lua - Personally I'd do what the sample themes do and put anything outside of the standard constants into a separate lua

Without giving you a thousand link, the situation can be summarized by: I am a proponent of eventually switching to that and @actionless prefer not doing that. It indeed cause some circular inclusion issues as widgets created in the theme file can themselves load beautiful. It's not undefinable, but will require some design changes. Maybe 2 files is a simpler solution (one for the constants and one for the widgets)

pros of moving widgets to the theme:

• Better separation of concerns
• The theme are not forced to use the "top bar" provided by default
• The themes are more portable since they don't depend on the rc.lua layout
• We don't need to scope creep the API with theme option that could be implemented directly in the themes.
• It enforce modularization and put an end to the mouse.screen.mywibox style "yeah, but, but the default config does that" abuse of implementation details done by some modules / user configs.
• Switching themes are runtime become easier
• Some HiDPI limitations get a cleaner path toward being fixed

cons:

• rc.lua is no longer the only file the newbies have to care about
• Integration between keybindings and widgets suffer from the artificial separation
• Some parts of rc.lua are ambiguous when it come to split them between theme/view and business_logic/behavior

[Sorky]

* Integration between keybindings and widgets suffer from the artificial separation

I use a suggestion you made a while back...

local function my_add_key( mod, key, press, release, data ) 
    lgi.GLib.idle_add(  lgi.GLib.PRIORITY_DEFAULT_IDLE,
                        function()
                            if key ~= "" then
                                root.keys( gears.table.join( root.keys(), awful.key( mod, key, press, release, data ) ) )
                            end
                            return false
                        end )
end

[Sorky]

I am a proponent of eventually switching to that and @actionless prefer not doing that

I did a lot of my early layout on copycatz and agree with having widgets being a theme style topic and having them portable but definitely feel they should be in a separate file (or more - ie: wibar possibly with sub sections for tags, tasks, widgets and layouts)

[Elv13]

I use a suggestion you made a while back...

All my module use this code since more than 5 years. I even do it internally in keybinding.lua. That's not the problem. Also, I actually already developed a solution to fix this limitation of our API in https://github.com/awesomeWM/awesome/pull/2508

The issue is that if you want, let say, a keybinding to hide your wibar and the wibar is internal to the theme and the shortcuts are internal to rc.lua, you have a problem.

[Sorky]

rc.lua is no longer the only file the newbies have to care about

Very true! I'm heading more towards a setup where rc.lua should not be touched and having separate files for separate areas - So far it has had two advantages for me...
1) I can do an error check on the file running and load a fallback
2) Worst case that section doesn't work but everything else does, allowing recovery without quitting

Possibly puts me somewhere between you both ;-)

[actionless]

sorry for offtopic, i was thinking what if we need to find some communication way for separating widgets to a separate file could it make sense to also separate them to a different main loop? or overhead of inter-process communication will be higher than was what saved on this?

[actionless]

and on topic: as far as i remember from original discussion - our main difference in opinion with @Elv13 is what Elv proposing to define in theme.lua whole wibar layout with all its widgets (i oppose what it will make impossible for user to redefine panel layout, ie add widget, without modifying the theme) while i was proposing to define only specific widgets (optionally, and in rc.lua use them if they're defined in theme)

but now i think what mb doing both could be an answer

[Elv13]

sorry for offtopic, i was thinking what if we need to find some communication way for separating widgets to a separate file could it make sense to also separate them to a different main loop? or overhead of inter-process communication will be higher than was what saved on this?

Maybe we should open a new topic for that. Way-cooler "can do it" in the sense it can run multiple independent Awesome instances. Refactoring our (X11) code to allow wibox and naughty to run in their own process without the WM part would also allow them to be used in i3 and corrupt their userbase to switch to full Awesomeness. IPC isn't really an issue if we can get GDBus to not crash. If done correctly it can work. Not as default since it makes a bunch of things more complicated, but it could optionally be done. It would need a nice corountine based high level dbus API wrapper, but that's doable. The second step would be to also allow some kind of wibox.container.layer to allow widgets themselves to be composited from external process and have nice animations and GL shading magic. Way-cooler is more capable in that regard since awesome-x11 has no compositing capabilities and I don't think anyone wants to go that way (including me).

i oppose what it will make impossible for user to redefine panel layout, ie add widget, without modifying the theme

But that's kind of the whole point. theme.lua becomes the new rc.lua. It becomes the file the new users care about the most (assuming they like unixporn more than usability).

[actionless]

But that's kind of the whole point

of your point :P

mine is about exposing only separate widgets' templates, so visual appearance stays in theme.lua and data sources stay in rc.lua; which actually should bring the better picture than now, when we have a lot of visual-related logic in rc.lua, but wihout adding a con of moving any data-related logic to theme.lua

UPD:
but still i think the best approach for everybody would be by default to have it like that in rc.lua:

mywibar = theme.wibar or wibar{
         {
                awful.tasklist{....., template=theme.tasklist_template,
                awful.taglist{....., template=theme.taglist_template,
         }
         somelayout,
}

which will allow to use both

[actionless]

IPC isn't really an issue

my question was about possible overhead in compare to current signal handling inside one event loop

ie mb sending all those signals via dbus could take more time than actual rendering inside one process

[Elv13]

my question was about possible overhead in compare to current signal handling inside one event loop

Irrelevant. There is more overhead in drawing than with an async IPC. The latency would get better, not worst. Also taking into account all these widgets data source would no longer be in the input handling thread also reduce latency. Very few signals need to use dbus from awesome master process itself. The client and tags, but that's about it. A fully independent implementation could even keep its own client list. It's a lot of work and I wont do it, but it's possible and "would be nice to have".

[Elv13]

mywibar = theme.wibar or wibar{

The problem with that is that you are still limited to a single wibar and it would be very confusing to have all those widgets in rc.lua and wondering why they don't exist (because the theme silently overridden them).

https://github.com/awesomeWM/awesome/pull/2507 solves that by using request handlers capable of printing a big warning popup if the are overridden while still allowing the widgets to be in both. It's my "compromise solution" for the time being.

[actionless]

thing with the signals looks useful, though it's not solving the case of overriding only the template of the widgets, without re-defining panel layout(s)

[Elv13]

thing with the signals looks useful, though it's not solving the case of overriding only the template of the widgets, without re-defining panel layout(s)

Assuming the other half is implemented (allow to prevent multiple request:: handler for the same request), it allows to redefine the panel from the theme. This in turn addresses the issue, albeit with the overhead of having to define a custom panel. But sure, as-is, that pull request doesn't solves it, but "there is a plan". The request:: API exists to allow modules to replace Awesome default behavior. This is in the same vein, but it allows themes to replace rc.lua behavior.

The problem with custom widget delegates, as explained before, is that a tasklist can be used both for the bar, the client menu or an alt+tab style center popup. Each of them need different delegates. If you set it in the theme, can other modules can no longer assume the default behavior and have to also provide their own. Having a way for the theme to handle that would be more complicated than avoiding the problem be letting the theme define the bar. The complexity has to go somewhere. I think "have more powerful themes" is better than "adding more theme options in everything".

[actionless]

is that a tasklist can be used both for the bar, the client menu or an alt+tab style center popup. Each of them need different delegate

but in my example, https://github.com/awesomeWM/awesome/issues/1508#issuecomment-455023465, template is feeded to particulra instance of tasklist, not to tasklist constructor

[Elv13]

My fear is that it is a slippery slopes. It starts ok, then after a few PRs, we have:

beautiful.tasklist_default_delegate = ...
beautiful.tasklist_alternate_delegate = ...
beautiful.tasklist_delegate_for_screen2 = ...
beautiful.tasklist_delegate_for_custom_alttab_widgets = ...
beautiful.tasklist_normal_delagate_but_with_unicorns_background = ...
beautiful.tasklist_normal_delagate_but_with_unicorns_background_elv13_alternative = ...
beautiful.tasklist_normal_delagate_but_with_pokemons_background_instead_of_unicorns = ...

[actionless]

even in KDE (which somehow more bells-and-whistles than default rc.lua) not afraid of such problem and have in it's theme not too many elements: https://github.com/PapirusDevelopmentTeam/materia-kde/blob/master/Kvantum/Materia/Materia.svg

i think if having reasonable number of configurable things (at least everything what is currently in default rc.lua) should be a solution for most of the configs

[Sorky]

Not too off-topic, IMHO as this is closed it's probably not so bad and the whole reason for the PR seemed to be putting extra stuff in the theme file ;-)

Refactoring our (X11) code to allow wibox and naughty to run in their own process

That is something that sparks a question on something I've been playing with (so this certainly has the potential to go a bit off-topic)...

I implemented a "pcall_fallback( primary, backup )" that is pretty straight forward - It does a dofile on the primary and if it fails, does a dofile on the backup. Works great, BUT! When I decided it would be nice if it had a naughty notification on going the fallback I got all sorts of issues that seem to be recursion related (even though I don't actually nest the pcall_fallback, I just re-do the call. The reason naughty to run in their own process is that is what the errors mention (...count exceeds limit of 200) and removing it it'd all back to normal

without the WM part would also allow them to be used in i3 and corrupt their userbase to switch to full Awesomeness.

I love a bit of WM rivalry!