I have included two small .png image files that illustrates the problem. They are just 2kB each so hopefully that is okay with the mailing list RR On Wed, Jul 23, 2025 at 7:04 AM Reik Reid reikred@gmail.com wrote: Hi folks, When I recently updated ubuntu from 22 to 24, the visual of the vtwm icon managers changed drastically, adding a lot more space inside and between the entries, and possibly changing the font. The net result was impractical (size increase), and visually bothersome, to the point...
Hi folks, When I recently updated ubuntu from 22 to 24, the visual of the vtwm icon managers changed drastically, adding a lot more space inside and between the entries, and possibly changing the font. The net result was impractical (size increase), and visually bothersome, to the point where I went back to ubuntu22. Has anyone else observed this? The pitch of each icon manager entry changed from ~7mm to ~10mm on my display. I should mention that I am using the exact same compiled binary /usr/local/bin/vtwm...
Compile error: wait4 undeclared
Teach vtwm about Column Major Order IconManager Display
Merge remote-tracking branch 'origin/master' into dev
correct the types, not that the compiler seems to care
fixed
Seems that some systems drag in time.h elsewhere, but I've added explicitly here now.
Fixed, better late than never.
Fix compiler warnings, prompted by Ryan Carsten Schmidt
document XineramaScreens option
new XinteramaScreens option to allow ultrawide monitors to be treated as multiple virtual panels
This error occurs when compiling vtwm 5.5.0 on macOS 12 with Apple Clang 14: add_window.c:463:19: error: implicit declaration of function 'time' is invalid in C99 [-Werror,-Wimplicit-function-declaration] int curtime = time(NULL); ^ To fix it, add #include <time.h>.
Newer compilers like llvm.org clang 18 consider this to be an error, not a warning: add_window.c:460:12: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int] 460 | static lastwingroup = 0; | ~~~~~~ ^ | int add_window.c:461:12: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int] 461 | static lastwin = 0; | ~~~~~~ ^ | int add_window.c:462:12: error: type specifier missing, defaults...
This warning occurs when compiling vtwm 5.5.0 on macOS 12 with Apple Clang 14: add_window.c:490:32: warning: converting the result of '<<' to a boolean always evaluates to true [-Wtautological-constant-compare] tmp_win->hints.flags &= !PPosition; ^ /opt/local/include/X11/Xutil.h:105:23: note: expanded from macro 'PPosition' #define PPosition (1L << 2) /* program specified position */ ^
These warnings occur when compiling vtwm 5.5.0 on macOS 12 with Apple Clang 14: add_window.c:460:12: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] static lastwingroup = 0; ~~~~~~ ^ add_window.c:461:12: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] static lastwin = 0; ~~~~~~ ^ add_window.c:462:12: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] static lasttime = 0; ~~~~~~ ^
Thanks, Callum, for being so helpful and understanding. I'll post the topic on vtwm-hackers tomorrow when I have time. I just made another blunder doing some edits to improve the clarity of the question, and of course that generated more posts and more emails. Ugh. I'll just stop now.
Ok, I thought it might have been disabled due to spam, and I did get a bounce message before, but this time it seems to have worked. I don't have any further thoughts however. And like I say, if you want wider visibility of the issue you'll need to raise it on the list because I'm pretty sure only I'm going to see it here.
I can't even tell whether what I run is X or Wayland or xwayland. This is how I start X (?) from the "console", no display manager involved, I think. I am specifically running init 3 on the kernel command line to prevent gnome from starting. xinit xterm -- vt2 -depth 24 > & ~/logfiles/log.X11 & I know that xwayland exists (some packages are installed) on my ubuntu system, but not sure if it is being used. I tried some of the suggestions for determining whether wayland, using https://unix.stackexchange.com/questions/202891/how-to-know-whether-wayland-or-x11-is-being-used...
I can't even tell whether what I run is Xorg or Wayland or xwayland. The below is how I start Xorg (?) from the "console", no display manager involved, I think. I am specifically running init 3 on the kernel command line to prevent gnome from starting. xinit xterm -- vt2 -depth 24 > & ~/logfiles/log.X11 & I know that xwayland exists (some packages are installed) on my ubuntu system, but not sure if it is being used. I tried some of the suggestions for determining whether wayland is active, using...
I can't even tell whether what I run is X or Wayland or xwayland. The below is how I start X (?) from the "console", no display manager involved, I think. I am specifically running init 3 on the kernel command line to prevent gnome from starting. xinit xterm -- vt2 -depth 24 > & ~/logfiles/log.X11 & I know that xwayland exists (some packages are installed) on my ubuntu system, but not sure if it is being used. I tried some of the suggestions for determining whether wayland is active, using https://unix.stackexchange.com/questions/202891/how-to-know-whether-wayland-or-x11-is-being-used...
I can't even tell whether what I run is X or Wayland or xwayland. The below is how I start X (?) from the "console", no display manager involved, I think. I am specifically running init 3 on the kernel command line to prevent gnome from starting. xinit xterm -- vt2 -depth 24 > & ~/logfiles/log.X11 & I know that xwayland exists (some packages are installed) on my ubuntu system, but not sure if it is being used. I tried some of the suggestions for determining whether wayland, using https://unix.stackexchange.com/questions/202891/how-to-know-whether-wayland-or-x11-is-being-used...
I can't even tell whether what I run is X or Wayland or xwayland. This is how I start X (?) from the "console", no display manager involved, I think. I am specifically running init 3 on the kernel command line to prevent gnome from starting. xinit xterm -- vt2 -depth 24 > & ~/logfiles/log.X11 & I know that xwayland exists (some packages are installed) on my ubuntu system, but not sure if it is being used. I tried some of the suggestions for determining whether wayland, using https://unix.stackexchange.com/questions/202891/how-to-know-whether-wayland-or-x11-is-being-used...
Yes, I sent a mail reply to the notification and it didn't work. This is only a web interface to the discussion, not the proper mailing list. There is a separate tab for that and you should post general discussion to vtwm-hackers. Hardly anyone will be subscribed to updates to the sourceforge discussion page. In terms of emacs, an unhelpful reply would be that vtwm hasn't changed. Is this a pure Xorg system or is wayland involved?
I use emacs -g PARAMS or emacs --geometry=PARAMS to place my emacs instances on the screen in vtwm. Sometime fairly recently (last year?) this stopped working, and emacs just starts in some fixed position that is NOT +5+5 (or whatever other value was prescribed) . The size portion of the parameters works ok. Any additional emacs instances get staggered relative to the original faulty position. Not specifying a position at all gives the same result as specifying a position. In gnome desktop, the geometry...
use emacs -g PARAMS or emacs --geometry=PARAMS to place my emacs instances on the screen in vtwm. Sometime fairly recently (last year?) this stopped working, and emacs just starts in some fixed position that is NOT +5+5 (or whatever other value was prescribed) . The size portion of the parameters works ok. Any additional emacs instances get staggered relative to the original faulty position. Not specifying a position at all gives the same result as specifying a position. In gnome desktop, the geometry...
I just wanted to mention that currently, with telegram-desktop v3.6.1 , the problem is gone: The telegram-desktop app stopped ringing after I answered telegram on the phone. Still using vtwm-5.5.0. Ubuntu 22.04.4 was up to date as of 2 days ago.
That did it! Thanks. Three cheers to the greatest window manager ever!
That did it! Thanks.
(I also replied via email, but not sure it will make it here.) This was discussed on the mailing list over quite a few months and finally "resolved" in October. Here is the relevant post: https://sourceforge.net/p/vtwm/mailman/message/45582975/ TLDR; go to about:config and set widget.gtk.grab-pointer=1. This also works with Thunderbird.
Has anyone else had trouble with VTWM and recent versions of Firefox where the drop-down menus vanish when the mouse is moved onto them? It has been a problem recently. It seems to be a side effect of the focus-follows-mouse aspect of VTWM. When the mouse moves onto the menu, the focused main Firefox window blurs, the menu vanishes, and then the main Firefox window focuses again. I tried calling VTWM's f.focus function on the Firefox window and this fixes the problem. However, this isn't a real solution...
Check the BUILD HINTS section in the INSTALL document. There are some instructions for various lex errors in there.
Coming back to vtwm after a few years. Tried a configure, make and got this? /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../lib/libfl.so: undefined reference to `yylex' collect2: error: ld returned 1 exit status make[1]: [Makefile:560: nexpm] Error 1 make[1]: Leaving directory '/home/Downloads/vtwm-5.5.0/vtwm-5.5.0' make: [Makefile:463: all] Error 2 rm version-tmp.c uname -a Linux arch.cpcnw.co.uk 6.2.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 30 Mar 2023 14:51:14 +0000 x86_64 GNU/Linux...
I am playing with the latest scribus and notice that clicking/holding right button pops up a menu, but it quickly disappears. anybody know what is up? the menu works properly with both fvwm/xfwm, but not twm/vtwm even without an rc file.
Hello Thank you for your answer not only did it allow me to understand how vtwm works but I could very easily understand to launch my xterm in the right workspace windows Didier
As per the manpage, each item in the door-list has the following format: "winname" "location" "jumpTo" The "jumpTo" is an absolute geometry specification. It looks like you've used workspace numbers, but vtwm doesn't have a concept of workspace numbering, it just has a large virtual area which is some multiple of your physical screen(s). Thus, for a typical dual 1080p panel setup arranged with a 3x2 virtual desktop (ie. 6 workspaces), you might have something like (numbering here just for clarity...
As per the manpage, each item in the door-list has the following format: "winname" "location" "jumpTo" The "jumpTo" is an absolute geometry specification. It looks like you've used workspace numbers, but vtwm doesn't have a concept of workspace numbering, it just has a large virtual area which is some multiple of your physical screen(s). Thus, for a typical dual 1080p panel setup arranged with a 3x2 virtual desktop (ie. 6 workspaces), you might have something like (numbering here just for clarity...
As per the manpage, each item in the door-list has the following format: "winname" "location" "jumpTo" The "jumpTo" is an absolute geometry specification. It looks like you've used workspace numbers, but vtwm doesn't have a concept of workspace numbering, it just has a large virtual area which is some multiple of your physical screen(s). Thus, for a typical dual 1080p panel setup arranged with a 3x2 virtual desktop (ie. 6 workspaces), you might have something like (numbering here just for clarity...
Hello how to use doors and f.emterdoor in .vtwmrc file this is what i got and it doesn't work doors { "ws1" "100x100+0+0" "1" "ws2" "100x100+100+0" "2" "ws3" "100x100+200+0" "3" } f.enterdoor 3 nothing is happening can you help me ? Thanks Didier
Hi Callum, (Let's see if this gets to the vtwm-hackers@lists.sourceforge.net when I respond this way.) For sure, Windowsization is a terror upon the land :-). And I am indeed only making an educated guess that vtwm does not quite do what telegram-desktop needs, but I think it is a fairly solid hunch as far as hunches go. I wonder if there is some NETWM open-source code from another window manager that could somehow be added into vtwm without too much line-by-line splicing of code. I guess that is...
For sure, Windowsization is a terror upon the land :-). And I am indeed only making an educated guess that vtwm does not quite do what telegram-desktop needs, but I think it is a fairly solid hunch as far as hunches go. I wonder of there is some NETWM open-source code that could somehow be spliced into vtwm... (I'm now also replying by email to try and move this discussion to the vtwm-hackers@lists.sourceforge.net mailing list--I hope that works).
Hi there. [ I'm not sure how many are subscribed via sourceforge - there are a few more on the regular mailing list. ] vtwm development really only progresses due to contributions from users. A couple of us are the "maintainers" in that we have access to the repo, but we don't have time to do active development any more, so it's just a case of making it work for us. Your guess as to weird telegram behaviour is a definite possibility. I haven't seen anything similar with any of the apps I use, but...
When there is an incoming call on the popular telegram-desktop messaging program, vtwm is missing some functionality. the telegram window does not open and pop to the foreground. In fact, the cursor seems hijacked and I can't even open the window manually. if you answer the call on your phone, telegram-desktop should stop ringing, but it does not. With gnome as desktop, the above problems do not occur. The problem is probably related to missing NetWM/Extended_Window_Manager_Hints and/or Inter-Client...
When there is an incoming call on the popular telegram-desktop messaging program, vtwm is missing some functionality. the telegram window does not open and pop to the foreground. In fact, the cursor seems hijacked and I can;t even open the window manually. if you answer the call on your phone, telegram-desktop should stop ringing, but it does not. With gnome as desktop, the above problems do not occur. The problem is probably related to missing NetWM/Extended_Window_Manager_Hints and/or Inter-Client...
Allow resizeto more flexibility/power in assigning size (including partially off screen)
Provide example font syntax.
Oh man, that is outstanding!!! I missed the setting in the manual because I searched on "dots" and "ellipsis" but not "ellipses". Maybe add a keyword string (dots, ellipsis, ellipses) in the manual, if you care to? Thanks for finding the answer.
Hold on, I found something out. Having * (star) in IconfiyByUnmapping works differently in vtwm than in twm. I inherited that setting from my old .twmrc file. IconifyByUnmapping { # "*" # BAD to have * here, it will unmap even iconmanagers in vtwm, but not in twm. "tk" "Firefox" "blah" } Does this explanation make sense? I hope so.
Oh man, that is outstanding!!! I missed the setting in the manual because I searched on "dots" and "ellipsis" but not "ellipses". Maybe add the string (dots, ellipsis, ellipses) in the manual, if you care to? Thanks for finding the answer.
I went to see if I could quickly make a patch, but someone already thought of it: NoPrettyTitles
Hold on, I found something out. Having * in IconfiyByUnmapping works differently in vtwm than in twm. I inherited that setting from my old .twmrc file. IconifyByUnmapping { # "*" # BAD to have * here, it will unmap even iconmanagers in vtwm, but not in twm. "tk" "Firefox" "blah" } Does this explanation make sense? I hope so.
Is there way to turn off the padding with dots (...) in the names that appear in iconmanagers? It just wastes space for me. Example: I may have an xterm named root1@localhost, which vtwm will truncate to root1@... so that I cannot see what machine I'm logged in to. In contrast, good old twm will show root1@loc , which is just enough for me to tell what I need to know. Yes, I can make the iconmanager wider so hat it shopws root1@loc... (say), but I'm trying to save space, which is why I'm addicted...
Hold on, I found something out. Having * in IconfiyByUnmapping works differently in vtwm than in twm. I inherited that setting from my old .twmrc file. IconifyByUnmapping { # "*" # BAD to have * here, it will unmap even iconmanagers in vtwm, but not in twm. "tk" "Firefox" "blah" } Does this my explanation make sense? I hope so.
Hold on, I found something out. Having * in IconfiyByUnmapping works differently in vtwm than in twm. I inherited that setting from my old .twmrc file. IconifyByUnmapping { # "*" # BAD to have * here, it will unmap even iconmanagers in vtwm, but not in twm. "tk" "Firefox" "blah" } I hope I am making sense with this.
Hold on, I found something out. Having * in IconfiyByUnmapping works differently in vtwm than in twm. IconifyByUnmapping { # "*" # BAD to have * here, it will unmap even iconmanagers in vtwm, but not in twm. "tk" "Firefox" "blah" } I hope I am making sense with this.
Hold on, I found something out. Having * in IconfiyByUnmapping works differently in vtwm than in twm. IconifyByUnmapping { # "*" # BAD to have * here, it will unmap even iconmanagers in vtwm, but not in twm.` "tk" "Firefox" "blah" } I hope I am making sense with this.
Hold on, I found something out. Having * in IconfiyByUnmapping works differently in vtwm than in twm. IconifyByUnmapping { `# "*" # BAD to have * here, it will unmap even iconmanagers in vtwm, but not in twm.` "tk" "Firefox" "blah" } I hope I am making sense with this.
Hold on, I found something out.
IconifyByUnmapping option says to use icon managers instead of icons, including for the icon managers itself, Using DontIconifyByUnmapping does not work for me. I tried DontIconifyByUnmapping { "xterm Icon Manager" "VTWM Icon Manager" } Result: Both of these iconmanagers disappear without a trace when iconified, no green icon placeholder. Must invoke f.showiconmgr (via some menu) to get them (ALL) back. Have you tried what I did and seen a different result? Have you seen a green icon when closing...
IconifyByUnmapping option says to use icon managers instead of icons, including for the icon managers itself, Using DontIconifyByUnmapping does not work for me. I tried DontIconifyByUnmapping { "xterm Icon Manager" "VTWM Icon Manager" } Result: Both of these iconmanagers disappear without a trace when iconified, no green icon placeholder. Must invoke f.showiconmgr (via some menu) to get them (ALL) back. Have you tried what I did and seen a different result? Have you seen a green icon when closing...
By way of further explanation, IconifyByUnmapping option says to use icon managers instead of icons, including for the icon managers itself, since it's just another window. Then you can create exceptions to that with DontIconifyByUnmapping. Both of these options take an optional window list parameter.
See the DontIconifyByUnmapping option. (Yes, most support is done via the mailing list)
Difference between vtwm and twm: When closing an icon manager in vtwm, the iconmanager disappears completely, whereas in twm it leaves a small green icon that can be reopened. In vtwm, to make the iconmanager visible again, use f.showiconmgr . Then ALL iconmanagers become visible again. Is there a way to get vtwm to work the same way as twm does? (i'll try here first, then mailing list)
Difference between vtwm and twm: When closing an icon manager in vtwm, the iconmanager disappears completely, whereas in twm it leaves a small green icon that can be reopened. To reopen, use f.showiconmgr to get ALL iconmanagers to become visible again. Is there a way to get vtwm to work the same way as twm does? (i'll try here first, then mailing list)
Difference between vtwm and twm: When closing an icon manager in vtwm, the iconmanager disappears completely, whereas in twm it leaves a small green icon that can be reopened. To reopen, use f.showiconmgr to get ALL iconmanagers to become visible again. Is there a way to get vtwm to work the same way as twm does?
(wrong place)
Difference between vtwm and twm: When closing an icon manager in vtwm, the iconmanager disappears completely, whereas in twm it leaves a small green icon that can be reopened. To reopen, use f.showiconmgr to get ALL iconmanagers to become visible again. Is there a way to get vtwm to work the same way as twm does? (I'll try here firstm then, mailing list)
Add MenuHighlight keyword to enable legacy method of menu item highlighting.
update latest changes
Ignore more files
Provide sane window manager hints if none provided
Fix lack of flex's -lfl for people who need it
Remove pointer hints from XGrabPointer
An improvement to GetColor()
Apparent fix to the menu problem
Revert "Hack: Grab pointer because sometimes t...
Improve font spacing on small screens
Add comments and no-op code tweaks
RESIZETO done twice will reset the saved geometry
Hack: Grab pointer because sometimes the point...
Hi, Not 100% sure about the reason sourceforge asked people to change their password...