In order to use the tabbed modules pick function, you need to install xwininfo.
Contributing
Contributions are welcome ๐
Before requesting changes, makes sure that your editor has an "editorconfig" extension installed, this will use our code style everytime when you edit in the bling folder.
When adding a layout/module/signal/widget, please add theme variables for customization and add the according documentation under docs.
stack traceback:
[C]: in function 'assert'
/usr/share/lua/5.3/lgi/namespace.lua:158: in function 'lgi.namespace.require'
(...tail calls...)
...umph/.config/awesome/external/bling/signal/playerctl.lua:22: in main chunk
[C]: in function 'require'
/home/grumph/.config/awesome/external/bling/signal/init.lua:1: in main chunk
[C]: in function 'require'
/home/grumph/.config/awesome/external/bling/init.lua:8: in main chunk
[C]: in function 'require'
/home/grumph/.config/awesome/rc.lua:54: in main chunk
error: /usr/share/lua/5.3/lgi/namespace.lua:158: Typelib file for namespace 'Playerctl' (any version) not found
Of course one way to avoid this could be to install playerctl on my system, but I don't want to because I don't need it.
There should be a way to avoid loading this playerctl module, with a warning somewhere to inform the user to install the playerctl package when explicitly using the playerctl module.
Hello,
im super-new to awesomeWM and already use bling, because i love the centered-layout.
What i don't get to work is the function, which the standard-layouts support: Right-Click and hold on the Titlebar can then resize the windows by mouse draging
Maybe there is something that i dont get, but would be very nice to have this feature also in the bling layouts
I found a little typo in the documentation while reading up on it.
Here's the file: https://github.com/BlingCorp/bling/blob/master/docs/module/wall.md
The line (set_function = bling.module...) should have a , at the end of the line.
-- A random wallpaper with images from multiple foldersbling.module.wallpaper.setup {
set_function=bling.module.wallpaper.setters.randomwallpaper= {"/path/to/a/folder", "/path/to/another/folder"},
change_timer=631, -- prime numbers are better for timersposition="fit",
background="#424242"
}
Just thought I would point this out so it could be fixed.
Currently, the wallpaper module does not work well with multiple monitors. The main reason for this is the function that handles both wallpaper requests from awesome, as well as the timer expirations. This causes alteration of global state, and calling setup multiple times with different screens does not work. Also, it would be nice if we could directly pass in a table of screens (the way gears supports) to setup for multiple screens more easily.
Solution
I already worked out a fix for myself for the first issue, and I'd be happy to share it if you'd like. I'd also like to work on the second one if you feel it's a useful addition to the module
I would like to create an AUR package for this plugin. Plugins for awesome in AUR are installed in /usr/share/awesome/lib directory, where they are available to all users. When I packaged and installed this plugin this way, I've got multiple errors in log:
2021-11-05 13:15:55 E: awesome: Failed to load '/home/nawordar/.config/awesome/bling/icons/layouts/deck.png': Failed to open file โ/home/nawordar/.config/awesome/bling/icons/layouts/deck.pngโ: No such file or directory
stack traceback:
/usr/share/awesome/lib/gears/surface.lua:99: in function </usr/share/awesome/lib/gears/surface.lua:91>
(...tail calls...)
/usr/share/awesome/lib/gears/surface.lua:146: in function 'gears.surface.duplicate_surface'
/usr/share/awesome/lib/gears/color.lua:340: in function 'gears.color.recolor_image'
(...tail calls...)
/usr/share/awesome/lib/bling/layout/init.lua:19: in main chunk
[C]: in function 'require'
/usr/share/awesome/lib/bling/init.lua:6: in main chunk
[C]: in function 'require'
/home/nawordar/.config/awesome/rc.lua.test:19: in main chunk
i have this issue within in tabbed layout theme variables don't work and it results into default theme. .
i'm not sure whats causing this issue , can anyone relate to it or have a fix ?
this is what is in my theme.lua .
As bling grows, we need to get rid of the readme and make actual documentation. Any ideas on what to use or generate? If we choose on one, I can get started.
We've had that idea before, I'll communicate it in this issue so that we don't forget about it and in case someone is interested in contributing.
It would be cool to have scratchpads support some basic signals such as open and close so that the user might intervene in some scratchpad actions and customize it even further from there on. For example the use case of an "option to disable the client floating state when closing the scratchpad" as mentioned in #63 should be achievable by doing something like my_scratchpad:connect_signal("close", function(c) c.floating = false end) which would be very intuitive to awesomewm users.
Adding basic signals would probably not even be that hard. We could just keep a list of functions for each signal as an object property that are run when the scratchpad opens/closes. connect_signal would then just add a function to the corresponding list. There are some implementation details to work out though but the concept should be clear.
If I have a scratchpad defined to animate up or down and I open and close it on my main monitor then none of the other clients on that screen gain focus. If the scratchpad is defined to animate left or right things work correctly - a client gains focus after scratch animates off screen.
I am guessing this has something to do with animating into a screen area that is not covered by a monitor output.
I was trying to use playerctl module , however it does seem to work for some reason and it only shows a empty dot as notification.
in play_ctl.lua there's the following
We should have added a license at the very beginning of the project, but we missed out on that. So I'll just ask all contributors, @javacafe01, @Grumph, @branwright1 and @Bysmutheye, whether or not you all agree on placing the project (which includes your work) under a FOSS license.
The particular license that we should use can be debated on this thread, but I'll just start by throwing the MIT license into the discussion.
There is probably an easier way of doing this, but if you are hovering on a client in the taskbar and close the client you get an error. Additionally, since closing removes the item from the taskbar the preview does not disappear. This is easily solved by making a check for if c.content is a valid field. Interestingly you cannot simply check if the client exists as I guess there is a timing issue where the client exists but client content does not.
Btw a side question. Maybe im dumb but i couldnt find out how to use the keybind tabbed.pick mentioned in ToDo and #13
can you clarify what function i need to bind for that?
Hello, I found a way how to implement scratchpad as keybind or button, default awesome titlebar has "pin" icon which exec function "ontop". This function keep "pinned window" on top of other windows and it is visible on other tags. I think we can implement it as "keybind" like bling.scratchpad_toggle() in order to use focused window as scratchpad e.g. with selected geometry and on screen position
The window swallowing module currently doesn't work right as it swallows every client no matter whether or not it should be seen as a child window of the previously focused client. That didn't used to be the case. I think it stopped working properly when I moved some functionality to the helper functions. Reverting to a previous commit in that file might already solve it but a more clean approach would be welcomed.
Maybe it already exists . In that case i am extremely sorry for my ignorance , but it looks like a client for bling.module.tabbed.pick() can only be picked with a mouse click which is a slight bummer for my workflow . Is there a way around this ?
I'm not sure if I'm the only one finding this would be helpful:
I would like to have a layout similar to the centre layout already provided by bling with the difference:
With my Ultra Wide screen ( in case I have only one window open) I like to have the first window not fully maximized because then I have to turn my head to the very left and very right of the screen
But this would mean that there is some unused space at the left and the right side of the screen until you add more and more windows
I think it's easy to understand what I mean
If not I can try to provide some screenshots
If you view the tag_preview for a tag that contains client(s) on multiple tags, the tag_preview doesn't show correctly in some cases.
Demos
At 0:00, tag 1 has discord and watch nvidia-smi and tag 2 has cava and zsh. Everything works as expected at this point.
At 0:08, I add watch nvidia-smi to tag 2 (so it is on tag 1 and 2)
At 0:14, while on tag 2, I show that tag 2's tag_preview is correctly displayed. If the tag currently being viewed is the one you're attempting to view the tag_preview for (or was the last viewed tag which contains client(s) with multiple tags) then it displays correctly. (So hypothetically, if I were to switch to tag 3 at this point, tag 2's tag_preview would still display correctly.)
At 0:15, while still on tag 2, tag 1's watch nvidia-smi is completely missing from tag 1's tag_preview
At 0:19, I switch to tag 1, and show that tag 1's tag_preview is correct while viewing tag 1
At 0:21, while still on tag 1, I show that tag 2's tag_preview shows the content for watch nvidia-smi in the wrong place, obscuring the other clients in the tag_preview
tag_preview_weirdness.mp4
Unlike the example above, if the geometry and position of the client is exactly the same between its tags, it shows correctly in all tag_previews. You can see here, watch nvidia-smi is tiled on the left of tag 1 and 2, and displayed on the left side of both tag 1 and tag 2's tag_preview, as expected:
tag_preview_with_client_in_same_position.mp4
Another more severe example, with more clients. In this case, zenmonitor is the client on tags 4 and 7. You can see when on tag 4, viewing the tag_preview for tag 7, there is content from chromium, despite chromium not even being on tag 4 or 7, and content from zenmonitor is missing. The tag_preview is completely mangled too. Same problem when on tag 7 and viewing tag_preview for tag 4, the tag_preview is completely mangled:
After moving to arch and also using the playerctl module to show music now playing I noticed that there was very high memory usage (awesome using 60% of my 4gb ram overnight)
Disabling the playerctl module reduced the overnight growth but it was still 14% which it should not be near.
I am creating a custom title bar and would like to add support for displaying tabs in the mstab layout, but I can't find an option to disable the Bling's built in tab bar. I tried to set theme.tabbar_disabled to true, but it seems that it only works for the tabbed container.
I use NixOS, and I believe it uses the 4.3 release from github, but the wallpaper module didn't work, after looking at the code I found that it's because the module waits to hear the request::wallpaper signal to apply the wallpaper on the first time the config loads (the timer works because it doesn't depend), and this signal doesn't exist in the 4.3 tag, only in later commits.
On my system, I configured it to compile awesome using a commit from the master that had the signal, and it worked
That's really weird since everytime when I saw people using this module there wasn't any problems but I have tried it on my laptop with intel gpu and VM on macbook pro with intel and amd, same problems on both when you use intel gpu, doesn't matter if I'm running compositor or not. Also just noticed that sometimes scratch window "lost focus state" then it is opened multipe times and cannot be focused. ๐ค
It just might be problem from Xorg site since we move windows outside of visible are then they are not rendered at all and server need to render window content when they appears. those animations aren't from compositor so server becomes dumb when window is animated and have too small amout of time to render content before window get selected position.
Lately, I wrote a declarative wallpaper setter module.
It can do:
sequential or random from a list, with a "change every" timer
schedule based change (as seen in dynamic-wallpaper), you can have a safe for work wallpaper from 09:00 to 18:00 and a random wallpaper form the NSFW folder the rest of the time for example.
the list can contain what gears.wallpaper supports (color, cairo stuff, image file), directories containing images, functions (with this you can use a list of different bling.module.tiled_wallpaper for example)
a pre-configured beautiful.theme_assets.wallpaper with standard theme colors by default
I was thinking about making it a standalone module, but I discovered bling a few days ago, and I think this module could fit in bling.
Should I use my time to write a PR here, or would it be better for me to continue in the standalone path ?
Note: my module is for awesome-git, I think I use some functions/mechanisms that are not available in 4.3, I did not test it with multiple screens yet, and the code needs some optimizations.
This signal appears to be running in a loop for each titlebar tab getting created. Wouldn't it create a lot of duplicate signals over the same client? The situation appears to be getting worse if you detach and reattach the same client to the tab group.
I tried to go around it by assigning some if checks but that takes away the functionality of updating the tabs with the changed titles. I tried adding an id field to be used with get_children_by_id but I haven't succeeded on that yet. This get_children_by_id is a bit twilight zone to me.
local wid_temp = wibox.widget({
id = c.window .. idx
text_temp,
buttons = buttons,
bg = bg_temp,
widget = wibox.container.background()
})
idx was basically something I passed along to the create during iteration. It appeared to work, but I couldn't access anything.
Hey, instead of adding new names to licenses, I would recommend something similiar to what river provide.
License provide name of maintainer, which in this case would be BlingCorp, and additional file authors which provide names of people which contributed bigger changes.
In my opinion it makes more sense since bling was moved from personal repo into organization.