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...
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.
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...
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.
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).
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...
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.
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...
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)
Thanks, I discovered that with a newer version of clonezilla there is actually a /var/log/clonezilla.log that is fairly complete. Still got some other problems but logfiles good for now, thanks!! (newer clonezilla-live-20180812-bionic-amd64.iso rather than older clonezilla-live-20180812-bionic-amd64.iso)
Potential workaround: Right this minute I am running sudo env CURRENT_TTY=/dev/tty1 ocs-live-general 2>&1 | tee /tmp/ocs-live-general.log Perhaps this will generate a more complete and substantial logfile. The ascii progress graphs and such may mess up the file content a bit, but I exepct at least SOME more log information to come out of this run. We'll see in 30min :). Note: How was I able to run the cmdline? Well, one of the partclone commands failed and that led to a debug shell option at the...
Could you please make so that we get a full set of /var/log/{ntfsclone,partclone,dd,etcetc}.sdX{1,2,3,4,5,....}.log files? It is so much easier to debug problems if there is not just one file that gets overwritten at each step. EVEN BETTER: Create additionally a complete logfile by appending all logs into one file, with some separation marker for clarity. STILL BETTER: Create also a logfile that lists in details all the commands that have been run (fsck, sfdisk or sgdisk or whatnot, partclone, ntfsclone,...
Thank you very much, Aleksey it works great now with the fix.
Thank you very much, Alexsey it works great now with the fix.
Infinite loop caused by nested symlinks
Hi Denis, I created the xoj on windows, and then copied both pdf and xoj to linux,...
Hi Denis, I created the xoj on windows, and then copied both pdf and xoj to linux,...
Hi Denis, I created the xoj on windows, and then copied both pdf and xoj to linux,...
Hi Denis, I created the xoj on windows, and then copied both pdf and xoj to linux,...
UPDATE: After re-reading Dennis' remarks it appears he knew the below already. The...
Hi Denis, I created the xoj on windows, and then copied both pdf and xoj to linux,...
Hi Denis, I created the xoj on windows, and then copied both pdf and xoj to linux,...
ADDENDUM: After re-reading Dennis' remarks it appears he knew the below already....
The problem is that the .pdf.xoj file contains a full path to the corresponding .pdf...
The problem is that the .pdf.xoj file contains a full path to the corresponding .pdf...
clock drift revisited
I got SleepyHead to compile after doing the following hack: cd /path/to/src/SleepyHead/code/sleepyhead...
I'm having linux compile problems, on fedora 19. Here is what I did, inspired by...