berry
berry copied to clipboard
JLErvin
Suggestions
Please comment any suggestions you have to improve the window manager below. I can't promise that I will be able to implement everything, but I'm curious what people have to say!
I don't know whether I'm just missing something but I can't figure out how to make use of the mouse-controlled window moving - right now it feels like everytime I alt+click the window moves in a random direction. It'd be much easier if it was more like a click and drag functionality.
EDIT: Another enchancement could be to adjust the window decorations a little. For example, when you hover over a link in a web browser, the URL will pop-up in the bottom left corner of the window. Currently, it seems that the window decoration covers it a little bit. Happy to provide screenshots of what I mean if it's not clear.
EDIT2: Also giving an example on how to fix the "X" mouse cursor when not over a window.
@nan0s7 For the first issue, this should be fixed by using sxhkd version 0.5.5 or earlier. Later version don't add motion support which is why it is all funky.
I'll investigate the window decorations issue as well as the mouse cursor and get back to you.
Hi, Thanks for your WM, it's very nice. My suggestion would be to have the possibility to set in config a particuliar mode by default for windows for example having all new windows in monocle mode (specially my workflow) Thanks
I love very much in general the software that allows to remote interact via bash scripts, so I can only love berry, that I just found out today!
proposal 1/2: Windowchef adds to each window the WINDOWCHEF_STATUS property whose value is a JSON object that returns a bag of information not otherwise available via xprop; for example
WINDOWCHEF_STATUS(STRING) = "{\"window\":\"0x01c00006\",\"geom\":{\"x\":4,\"y\":602,\"width\":1902,\"height\":584,\"set_by_user\":false},\"state\":\"normal\",\"min_width\":135,\"min_height\":37,\"max_width\":2200,\"max_height\":0,\"width_inc\":1,\"height_inc\":1,\"mapped\":true,\"group\":-1}"
I have always found in WINDOWCHEF_STATUS a very useful resource for my scripts so, since berry is inspired (also) by windowchef...
proposal 2/2: Again in the name of the pleasure for hacking: since in berry is already configurable a title area at the top of each window, it would be interesting to allow the user to be able to freely -for position and quantity- create some hotspots -small buttons even with only textual label- clickable via button1 event to be bindable with berryc command???? (...the historic TWM window manager allowed this already at the dawn of X era but such intuition was then unfortunately -I say- lost...) A solution, in full *nix philosophy, that could allow to build some menus with external tools -jgmenu for example- without having to burden the berry code for this kind of task...
PS: @nan0s7, if not already settled:
EDIT2: Also giving an example on how to fix the "X" mouse cursor when not over a window.
this line added in ~/.xinitrc before running berry should fix it:
xsetroot -cursor_name left_ptr &
@paoloschi
These are both excellent suggestions. I'll look into implementing both of these.
Number 1 should be fairly simple to implement since berry already maintains the internal state of each of its clients - I really just need a way to report this information to clients.
Number 2 might be a little trickier - I would like some time to think about the best way to implement this cleanly. I have stayed away from clickable decorations before as I feel that there isn't a convenient way for users to define their shape. Openbox, for example, uses .xbm files which aren't super easy to create yourself. Although I do really like the idea of being able to link custom commands to clickable buttons (users could create their own tiling script, for example, and add a tiling button to each window. That would be so cool). I'll look into this and keep you posted.
Number 1 should be fairly simple to implement [...]
That's great! ...and also consequently collect all JSON objects from all existing clients (mapped & unmapped) in a single JSON array available via xprop -root <PROP_NAME> would it be equally easy to achieve?
(paradoxically, from bash thanks to tools like jq I find it has become more handy to acquire data from JSON documents rather than parsing STDOUT columns from xprop itself or from wmctrl & C.)
Number 2 might be a little trickier [...]
Personally I have never used the desktop toolbar yabar but I was reading the features today and I wonder if the technique it adopts could be inspiring: https://github.com/geommer/yabar/blob/master/doc/yabar.1.asciidoc
Among other features
- A growing set of ready-to-use internal blocks developed in plain C.
- Entirely clickable.
no dependence on any toolkit while, where it is required to add a bit of aesthetics
- Pango font rendering with support of pango markup language.
...a similar "blocks" concept could that be a viable approach inside of berry?
Maybe add a way to configure a set workspace to not have any window decorations for windows spawned in that workspace. This would help with steam because the decorations make the program act a little buggy.
Another thing which might be nice as a supplement to my earlier suggestion would be to add a way to only allow for window decorations on certain windows spawned by programs you allow to have window decorations.
@Ergo0 I'm going to look into your second suggestion. Being able to blacklist certain applications from drawing decorations would be helpful. I'm sure there's a way to automate this if a client wants to draw its own decorations, but I'm unfamiliar with the protocol as of now. In the meantime I can try adding a berryc command to not decorate windows from a certain process name (i.e. steam)
Another suggestion would be a Workspace quick switcher, (kind of like i3's back-and-forth).
Also, making monocle and fullscreen toggles, so that the windows can return to the dimensions they were before going fullscreen.
@StrangeAmoeba good idea, added as of f7f066632c0a205d35a0a38b68723f6bee4fada0
A reverse-cycle-focus function would be convenient if you have many windows on a workspace.
When a window is in fullscreen, I sometimes move the window by mistake with the mouse. I would like to lock a window in fullscreen.
Add hooks on open and close window events, so we can create rules for different apps on it. For example I want my browser always opens on monocle mode without decorations at workspace 3, or messanger app opens at workspace 9 and snapped to right.
p.s. Sorry for my english
:+1: for allowing decorations to be disabled by default.
Request: allow programs to manage their fullscreen state, eg pressing F11 in Firefox makes it think it's fullscreen, but it doesn't change size.
@aeosynth
Default decoration behavior is very easy to implement, I can do that in the latest release.
With regards to fullscreen behavior, perhaps I have been a bit too opinionated. Personally, I want to be able to "trick" programs into behaving like they are fullscreen while keeping their size fixed. For example, having firefox fill the screen with a youtube video while remaining small is a nice way to watch media while working on something else. However, this is clearly an EWMH violation and not something everyone needs. I'll consider having an option to toggle this behavior.
Rofi has a Windows mode which allows to select a window and apply a custom command with Shift+Return. By default, the command is wmctrl -i -R {window} in the config file, where {window} is the numeric identity of the selected window.
I would like to pass a command to berryc directly. However, berryc only targets the currently active window. Would it be possible to target a window given by its numeric identity?
Rofi also closes a selected window with Shift+Delete but it does not seem to work with berry.
Would be usefull if some features like the hability to play videos on full screen would implemented on the code of actual version.
https://github.com/JLErvin/berry/issues/39
So, I think that some interesting modifications just exit as suggestion and no all people can see it.
Maybe a simple menu... I can't remember all the keys configured :P
This can be done with rofi and a simple shell script
Would be nice if it didn't create windows outside of the designated screen space when edge_lock is set to "false"
I've just made an issue about a feature which i would like to implement. More info in #197. If you want me to explain it a bit better just let me know
