herbstluftwm / herbstluftwm Goto Github PK
View Code? Open in Web Editor NEWA manual tiling window manager for X11
Home Page: http://herbstluftwm.org/
License: Other
A manual tiling window manager for X11
Home Page: http://herbstluftwm.org/
License: Other
As per Florian's suggestion, am posting this request submitted to the mailing list:
One feature I find convenient (coming from bspwm) is the ability to rotate a grid, much like the rotate (frame) action. I am hoping your rotate frame facility might make this easy enough to implement (with value +/- 1 for bi-directional control, of course)!
[ Regarding the "rotate" command, a nice-to-have would be a +/- 1 value to specify the direction of rotation, if possible. Reverse rotation (effectively 270 degrees) is easy enough to script but causes extra screen redraws and a noticeable flickering effect (system dependent). ] Just reread the detailed docs.. and found the lock/unlock example for rotate frame! Nice!
Having a blast with herbstluftwm coming from bspwm. Kudos to developers!
Regards, Steven
Jump to the next/previous tag with/without a client shown
Some people want that feature, and implementing it in a script with wraparound etc. is possible but ugly
There should be a command to re-apply all rules to all current clients (suggested by rudi_s).
There is a herbstclient command for use_previous
, but not one for move_previous
. I expected that option to exist since there are both a use_index
and move_index
.
Could we add the use_previous
function?
Having some hidden-attribute for special tags/monitors so they don't show up in the panel and are ignored when cycling, for floatmon, etc.
There are some home-brewed solutions (custom attribute) but it'd make sense to have something standard here.
Also, IMHO these should not show up in tag_status
or list_monitors
unless some --all
flag is passed.
Instead of "idle", the herbstclient -i
option should correspond to "interactive". That means that it receives commands, like in a basic interactive shell. The idea is that scripts can use hold a connection open for a longer time and perform atomic operations. They can also directly respond to hook messages.
To perform an atomic operation, there need be a new locking/unlocking command. This would hold back processing of all other party's input until the operation is finished. An exception is any single reload commands. Keybindings could also be made a general exception as an option to the locking command.
This makes it possible to perform more complex and atomic operations with herbstluftwm outside of hlwm's shell-like capabilities, by using a scripting language of choice.
While this feature can also be implemented in the main branch, it was derived in a discussion about winterbreeze, where mktemp
might not be implemented.
We should be able to focus empty frames with click, or with the mouse if focus_follows_mouse is on
We could probably check how other tiling WMs with an internal tree (i3/bspwm come to mind) solves this issue.
When you remove a tag the tags.focus object gets deleted:
See the bug in action:
$ herbstclient chain , add testtag , merge_tag testtag
$ herbstclient attr tags.focus.name
Invalid path "tags.focus.name": No child "focus" in object tags
Invalid path "tags.focus.name": No child "focus" in object tags
And this patch seems to fix it:
diff --git a/src/tag.cpp b/src/tag.cpp
index d731819..a041b60 100644
--- a/src/tag.cpp
+++ b/src/tag.cpp
@@ -375,6 +375,7 @@ int tag_remove_command(int argc, char** argv, GString* output) {
ewmh_update_desktops();
ewmh_update_desktop_names();
clientlist_foreach(client_update_tag, NULL);
+ tag_update_focus_objects();
tag_set_flags_dirty();
hook_emit_list("tag_removed", oldname, target->name->str, NULL);
g_free(oldname);
There would be no need for this call when you remove an unfocused tag. But I couldn't find out how the tags.focus object gets deleted.
Some windows really want to have a size which is a multiple of a given cell size (e.g. terminal). We probably should give them the size they want and just display a gap for the rest.
e.g. hc resize exact 400x300
People sometimes ask how they get the correct frame ID for a rule.
Having a frame id (or with frame object, the object) as attribute/child of a client object might make this easier.
Some clients have problems creating windows. This seems to be related to Java UI. Observed and reproducable with IntelliJ IDE, MySQL Workbench (both Java).
I observe two problems:
In the second/third cases, this means that the client both only draws and accepts mouse input on a part of the window, as if it does not realize the window's real size. In some cases the window is also completely empty. It all can happen also in floating mode and it is pretty random (opening the same window several types leads to several different outcomes).
To investigate this further, I had the idea of maybe the window manager providing several window sizes to the application which might not keep up with the changes.
Below is some xev output (filtered all property setting etc. messages). The main difference I see is that hlwm reconfigures the window after it is already visible (but doesn't really change anything). Another observation is that in tiling mode, the window is first configured in the size requested by the client several times before it is eventually configured to fit into the layout.
For now I don't see a specific reason for the clients stumbling.
CreateNotify event, serial 11, synthetic NO, window 0x5e00001,
parent 0x5e00001, window 0x5e00002, (10,10), width 50, height 50
border_width 4, override NO
ConfigureNotify event, serial 28, synthetic NO, window 0x5e00001,
event 0x5e00001, window 0x5e00001, (0,0), width 178, height 178,
border_width 0, above 0x5600007, override NO
ReparentNotify event, serial 28, synthetic NO, window 0x5e00001,
event 0x5e00001, window 0x5e00001, parent 0x6466e4,
(40,40), override NO
ConfigureNotify event, serial 28, synthetic NO, window 0x5e00001,
event 0x5e00001, window 0x5e00001, (3,3), width 178, height 178,
border_width 0, above 0x6466e5, override NO
ConfigureNotify event, serial 28, synthetic YES, window 0x5e00001,
event 0x5e00001, window 0x5e00001, (0,0), width 178, height 178,
border_width 0, above 0x0, override NO
ConfigureNotify event, serial 28, synthetic NO, window 0x5e00001,
event 0x5e00001, window 0x5e00001, (3,3), width 1672, height 1041,
border_width 0, above 0x6466e5, override NO
ConfigureNotify event, serial 28, synthetic YES, window 0x5e00001,
event 0x5e00001, window 0x5e00001, (1924,4), width 1672, height 1041,
border_width 0, above 0x0, override NO
VisibilityNotify event, serial 29, synthetic NO, window 0x5e00001,
state VisibilityUnobscured
ConfigureNotify event, serial 29, synthetic YES, window 0x5e00001,
event 0x5e00001, window 0x5e00001, (1924,4), width 1672, height 1041,
border_width 0, above 0x0, override NO
Outer window is 0x6200001, inner window is 0x6200002
CreateNotify event, serial 11, synthetic NO, window 0x6200001,
parent 0x6200001, window 0x6200002, (10,10), width 50, height 50
border_width 4, override NO
ConfigureNotify event, serial 28, synthetic NO, window 0x6200001,
event 0x6200001, window 0x6200001, (0,0), width 178, height 178,
border_width 0, above 0x5e00007, override NO
ReparentNotify event, serial 28, synthetic NO, window 0x6200001,
event 0x6200001, window 0x6200001, parent 0x64698a,
(40,40), override NO
ConfigureNotify event, serial 28, synthetic NO, window 0x6200001,
event 0x6200001, window 0x6200001, (3,3), width 178, height 178,
border_width 0, above 0x64698b, override NO
ConfigureNotify event, serial 28, synthetic YES, window 0x6200001,
event 0x6200001, window 0x6200001, (0,0), width 178, height 178,
border_width 0, above 0x0, override NO
ConfigureNotify event, serial 28, synthetic YES, window 0x6200001,
event 0x6200001, window 0x6200001, (3,3), width 178, height 178,
border_width 0, above 0x0, override NO
VisibilityNotify event, serial 28, synthetic NO, window 0x6200001,
state VisibilityUnobscured
ConfigureNotify event, serial 28, synthetic YES, window 0x6200001,
event 0x6200001, window 0x6200001, (3,3), width 178, height 178,
border_width 0, above 0x0, override NO
CreateNotify event, serial 11, synthetic NO, window 0x400001,
parent 0x400001, window 0x400002, (10,10), width 50, height 50
border_width 4, override NO
ReparentNotify event, serial 18, synthetic NO, window 0x400001,
event 0x400001, window 0x400001, parent 0x200534,
(0,0), override NO
ConfigureNotify event, serial 20, synthetic NO, window 0x400001,
event 0x400001, window 0x400001, (0,0), width 178, height 178,
border_width 0, above 0x200560, override NO
ConfigureNotify event, serial 20, synthetic NO, window 0x400001,
event 0x400001, window 0x400001, (1,20), width 178, height 178,
border_width 0, above 0x200560, override NO
ConfigureNotify event, serial 21, synthetic YES, window 0x400001,
event 0x400001, window 0x400001, (409,418), width 178, height 178,
border_width 2, above 0x0, override NO
VisibilityNotify event, serial 34, synthetic NO, window 0x400001,
state VisibilityUnobscured
I've been working on frame objects for the object tree - we merged the code at 30c3 but it turned out there was some bug.
WIP code:�http://git.the-compiler.org/herbstluftwm/log/?h=frame_objects
Bug:
When splitting a frame many times there was a segfault.
The code also should be rebased on master.
Switch to another monitor if Mod+hjkl is pressed on the edge of an existing one.
Suggested by eto and others.
The commands/settings get a bit much in the manpage. It might make sense to split them into logical groups (e.g. frames/tags/monitors/scripting/... commands)
Currently commands which take a layout expect a hard to remember integer - we should be able to use layout names instead (or both, to not break backwards compatibility)
When focusing a window, the contents briefly move their positions and then move back which is a bit irritating. It's as if the thicker border caused the window to get a wrong size/position for a very short time.
When you remove a tag, you need to update the _NET_WM_DESKTOP atom for all clients.
I couldn't find a way to ignore clients on tags with a lower index than the removed one.
This patch fixes the bug for me:
diff --git a/src/tag.cpp b/src/tag.cpp
index 8869bd0..d731819 100644
--- a/src/tag.cpp
+++ b/src/tag.cpp
@@ -301,6 +301,15 @@ int tag_rename_command(int argc, char** argv, GString* output) {
return tag_rename(tag, argv[2], output);
}
+static void client_update_tag(void* key, void* client_void, void* data) {
+ (void) key;
+ (void) data;
+ HSClient* client = (HSClient*)client_void;
+ if (client) {
+ ewmh_window_update_tag(client->window, client->tag);
+ }
+}
+
int tag_remove_command(int argc, char** argv, GString* output) {
// usage: remove TAG [TARGET]
// it removes an TAG and moves all its wins to TARGET
@@ -365,6 +374,7 @@ int tag_remove_command(int argc, char** argv, GString* output) {
ewmh_update_current_desktop();
ewmh_update_desktops();
ewmh_update_desktop_names();
+ clientlist_foreach(client_update_tag, NULL);
tag_set_flags_dirty();
hook_emit_list("tag_removed", oldname, target->name->str, NULL);
g_free(oldname)
Is it possible to have the a real time view of the window when you re-size applications? Currently mouse left click and drag tries to resize it but it fills a color. Is it possible to make it real time?
Whenever the focus is changed, the client under the mouse cursor temporarily gets focus. That is, it is sent focus in and focus out events.
This seems to happen on all focus changes, even if they happen in other frames etc.
It is easy to test this behavior with an application that reacts to focus (e.g. a terminal that changes the cursor shape) or xev.
There could be tags.N.clients
in the object tree so one could easily get all clients on a tag.
Compile herbstclient as a library and add python bindings.
WIP - not sure what the state here was at all:
Open questions:
A command like fullscreen, but still leaving padding intact.
WIP: http://git.the-compiler.org/herbstluftwm/log/?h=pseudofullscreen
Rough todo:
Sometimes, dwb or mpv steal the focus, and switching keyboard focus does not work (immediately focuses back to dwb/mpv again).
Maybe related (?): Some clients (steam) create windows which have focus without having the focus borde
Compiling with -Wextra
gives us some additional warnings - maybe we should fix/workaround them and then compile using -Wextra
for additional warnings? I caught some bugs in the wild in some of my programs this way.
Also, -Wextra
still doesn't mean "all warnings"...
It'd be nice to have an example script which is essentially a REPL/shell for herbstclient.
Resizing splits by dragging them with the mouse
I implemented a simple hide window function which simply moves the focused window to (tick) 'tag
Subsequently restoring the pseudo hidden window from 'tag to the tag in focus with
herbstclient chain . lock . use "'$tag" . move $tag . use $tag . unlock
occaisionally results in the "restored" window not in view. Clicking the mouse in the resulting empty window region, focuses the window into view. This doesn't happen all the time and appears to be tied to ncurses terminal apps and the last remaining window moved from 'tag (though, I haven't run enough scenarios to be 100% certain it's always the last remaining window).
The problem is solved simply by bringing the window instead with:
herbstclient chain . lock . use "'$tag"
winid=$(herbstclient attr clients.focus | grep 's - winid' | cut -d'"' -f2)
herbstclient chain . use $tag . bring $winid . unlock
Not sure if this is a bug or not (I would think the window should at least be in view). As reported, MOST of the time, the moved window to the tag in focus, was visible and had focus (without the raise command). Bring made this 100% reliable.
Example:
1) hc keybind $Mod-e focus_monitor +1
2) hc keybind $Mod-w focus_monitor -1
In case 1)
when current monitor is the last one, +1
will match monitor with index 0
(wraps around end of the "list"). In case 2)
when current monitor is the first one (0
), -1
would not wrap around to match last monitor as one would expect from consistency point of view.
Even though a window might have a WM_NAME property, XFetchName doesn't always return a name - for some reason. Googling around a bit I couldn't figure out why though. I noticed that herbstluftwm didn't name Steam's windows. Steam windows don't have a _NET_WM_NAME property, so herbstluftwm falls back to calling XFetchName to get the WM_NAME property.
Running herbstluftwm in verbose, it prints that "no title for window xxx found, using ''" when a Steam window is focused, where xxx is the ID of a Steam window. This means that XFetchName returned 0, even though using xprop shows the window to indeed have a WM_NAME property.
I did a test of the XGetWMName function, using code from this stack overflow thread [1], which returned the correct name, where XFetchName returned no name.
I propose to change XFetchName to XGetWMName.
[1] https://stackoverflow.com/questions/8825661/xfetchname-always-returns-0
By milomouse in the Arch forum:
I notice that some commands always return 0 even if they've already been issued such as "lock_tag" and "unlock_tag", but I expect it's because they ran without error. This is fine but would it be possible for these commands (and maybe other similars I haven't checked yet) to return a non-zero exit status if they've already been executed correctly once before?
Many people want a tray, but like the default panel.sh
otherwise. We should provide some option to add a stalone
/trayer
with panel.sh
.
With frame objects, there are some custom attributes (notably layout
) for which it would make sense to make it writable - but that's currently not possible.
As by title. Is possible to have in the next release the dialog windows float?
When a Qt application changes its window title, somehow hlwm doesn't recognize the title has changed. I can reproduce this with PyQt5 (qutebrowser) and Qt4 (otter browser) applications.
PyQt example:
import sys
from PyQt5.QtCore import QTimer
from PyQt5.QtWidgets import QApplication, QWidget
app = QApplication(sys.argv)
w = QWidget()
w.setWindowTitle("Hello")
w.show()
QTimer.singleShot(1000, lambda: w.setWindowTitle("World"))
app.exec_()
After a second, the title changes from "Hello" to "World". What I found out so far:
xprop | grep '^_NET_WM_NAME'
shows the updated titlewindow_title_changed
hook is never emitted.focus_changed
is emitted with the old title ("Hello")focus_changed
with "World" when focusing it)e.g. hc set_monitors name:tag@1024x768+0+0
(or just name:...
or tag@...
)
I would like to have an option added to herbstclient to close all open windows. Something like
herbstclient close all
This would make it easy to gracefully close all windows before issuing a reboot or shutdown command.
Some people wanted a hc foreach tags ...
to do some action for each child of an object in the tree. This pushes one step closer to a turing-complete hlwm but still should not cause any possible hangs.
Using 2 screens, you can have all workspaces on whatever monitor you desire. I would like an option so lock a workspace to a specified monitor. Say workspace 8 to monitor 2.
If you press the key combination to get to that workspace, it would move your mouse and focus to the workspace on the screen it's locked to. This makes it for example easy to have a web-browser on a second monitor at all times (except when you manually move the window to a different container/workspace of course).
We should have some kind of automatic testbench using Xephyr.
We could probably get some ideas from i3 and other tiling WMs with testbenches.
I'd imagine using libherbstclient from #4 with python's unittest, but probably something else is possible as well.
When there's a frame with a single window and it's closed, the title of that window persists in the panel.
window_title_changed
is not emitted, and the panel doesn't update the title on tag_flags
because that'd be too much noise.
We probably should emit window_title_changed
without arguments in that situation.
original mail:
Simplest case: a tag, one frame and an xterm in it. I am running panel.sh,
to display tags, window title, date and time. For xterm, the window title
is the shell prompt string and current directory. If you simply exit from
the shell, say with ctrl-d, the window title remains in the panel. Switch
to another tag and then back to the original tag, and the title gets
updated correctly. I note that panel.sh does look for the
window_title_changed event, so I'm guessing that the window manager itself
is failing to generate the event in this case, but I haven't researched
this carefully so it's just a guess.
Note that if you have two xterms in the frame with different current
directories and thus different window titles, if you exit from one, the
window title in the panel gets updated correctly.
This is not an xterm-specific problem -- I'm just using xterm as a simple
way to reproduce this. If you have just a browser in a frame and close it,
the same problem occurs.
I'm running herbstluftwm 0.6.2-2 on an up-to-date 64-bit Arch Linux system.
discussion:
21:56 <The-Compiler> thorsten`: what do you think about the bug on the ML? Should hlwm emit title_changed when a window gets closed and none is active? Should panel.sh update the title on tag_flags?
22:00 <thorsten`> The-Compiler: Either window_title_changed or a new window_closed (which is only emitted if the focused window is closed). panel.sh shouldn't update the title on tag_flags because then, panel.sh has to think too much
22:01 <ypnos> do you really want to introduce new hooks at this point
22:01 <ypnos> it is getting pretty random
22:01 <thorsten`> yep
22:02 <thorsten`> so you prefer re-emitting window_title_changed?
22:02 <ypnos> if the current window disappears because it is moved to another tag window_closed might be expected but is not the right hook
22:02 <thorsten`> oh right
22:02 <thorsten`> then window_closed isn't the right way
22:03 <The-Compiler> +1 for window_title_changed fwiw
22:04 <The-Compiler> damn, that has a WINID
22:04 <The-Compiler> just emit window_title_changed with WINID 0 or -1 or so?
22:04 <ypnos> 0 is the root window, right?
22:04 <thorsten`> or without any arguments
Suggested by eto and others
Some people find tag switching with multiple monitors confusing. Some ideas:
hc load
could have an index argument which loads a layout into an existing frame instead of the root-frame.
Aligns windows either horizontally or vertically, depending on what's the longer side.
Not sure if it's too confusing though.
xrandr is probably more standard, but it seems rather hard to use it...
Some pointers:
Also it'd be nice if the monitors get auto-named based on their connecors (vga1
, lvds1
, etc.)
It is not possible to set the window size for a pseudotile window. A current workaround is to switch to floating mode, resize the window, switch back.
In winterbreeze we should add width, height attributes that are exposed and can be set via object tree. Setting them needs to trigger the resp. updates.
A typical use-case is file open dialogs. Dialogs are pseudotile in many configurations, and the default dialog window size is unnecessary small. Blowing it up to the whole frame might also be inconvenient. Another example is a GUI calculator.
As a bonus, we could implement increment/decrement operation to the integer attribute setter. E.g. setting the attribute width to "+10" increases the window size by 10 pixels. However, this would not work when negative values are allowed.
According to some standard (I don't remember which one it was...) HxW+X+Y
also should accept negative offsets.
Probably minor, feel free to close if you disagree ;)
Raise the affected window above others in floating mode (suggested by nullie)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.