Re: FVWM: fvwm3?
On Thu, 2024-02-08 at 21:02 +1000, Stuart Longland wrote: > On 8/2/24 13:51, hw wrote: > > It has become a very limited option years ago and is basically > > obsolete. Just try to run, for example, firefox on a remote host via > > X11 forwarding. I suspect that anything that might use acceleration > > powers of a graphics card doesn't work, and that kinda leaves only > > xterm which would be pointless. It also has always been rather slow > > (slow on a 1 gigabit network and up to unusably slow over internet > > (VPN)) and was never a good option. > > Oddly enough, it *does* work, even via SSH over a WAN link, with a few > caveats. > > 1. you must start with `--new-instance` if you have Firefox running on > your local workstation as well; otherwise it'll "talk" to your local > Firefox instance and tell *it* to open a new window > 2. there'll be some noticeable lag, forget watching videos Last time I tried it didn't work at all. And what's the point when it's so slow that it's useless. I guess you can still try to do some web browsing with lynx as well :)
Re: FVWM: fvwm3?
On Thu, 2024-02-08 at 18:10 +, Thomas Adam wrote: > On Thu, Feb 08, 2024 at 05:50:44AM +0100, hw wrote: > > I still don't see why it shouldn't be possible. I never expected a > > port, and I understand that the architectures of X11 and Wayland are > > very different. Yet why shouldn't it be possible to create a > > compositor that provides the configurability fvwm has and which is so > > badly lacking in Gnome and KDE? > > Absolutely it is possible. But then it wouldn't be fvwm. > > > Is it really impossible to create a wayland compositor that provides > > the required functionality? > > I'm not entirely certain you've understood the points in my original email. Maybe --- I don't understand why it shouldn't be possible to make am fvwm that works with wayland. I can understand that wayland refuses to manage windows which might make it difficult to do that, yet it seems to work with gnome. > I also don't want to repeat myself, but... > > To me, the things which make fvwm unique, are: > > 1. Its architecture is tied to X11 -- it uses Xlib directly to render window > frames. This is all using Xlib's graphics backend which has a large array of > 2d drawing routines. There's not a separate library which can be used to > abstract this out to be used elsewhere -- this is the entire point of the > client/server model in X11. > > The only thing which comes close is libcairo (built on pixman) -- and you can > use that with a wlroots-based compositor to generate "SSDs" within a > compositor -- but this doesn't work well for fvwm because it doesn't allow for > shading when filling in rectangles, as well as various other things. > > This is important because, for me, the entire point of fvwm is that it can be > made to look like MWM. I'm serious here -- all of that blocky (even "ugly", > as some people have called it) looking borders is important to me, that's what > I like. Are you saying it's impossible with wayland to draw stuff like window decorations on a display and only X11 can do it? It seems to work just fine with gnome. > 2. Even if 1., were a solved problem, the second issue is a lack of > reparenting. This is a core feature of xlib, and fvwm makes extensive use of > it to be able to function. It makes things like resizing and moving windows > easier. It's also very important for FvwmButtons; the "Swallow" command calls > XReparentWindow() directly. > > I'm really dumbing-down the explanation here, but it's not possible on Wayland > at present. I suspect it will never be. > > Now, even if the graphics side of things from point 1 above were currently > possible under Wayland, the lack of reparenting means you're having to move > the window frame along with the window itself -- the two are not "connected", > which causes all manner of weird glitches. That doesn't seem to be an issue; I can move windows in gnome. > 3. Lack of standards a la ICCCM/EWMH > > Fvwm is the exemplar project for how implementing standards helps > interoperability rules for window governance. Again, because of the X11 > architecture, the XServer would make this easy. Under Wayland, there's > "portals" but they're now selective about what's being implemented. So things > like aspect-ratio resizing doesn't have a portal. There's so much in the > EWMH which makes fvwm behave the way it does with applications, until that's > addressed -- or if it ever is -- you'll probably notice lots missing from a > potential fvwm-compositor under Wayland. What I'm missing in gnome is configurability, and not only in regard to the window manager (and it doesn't really matter if it's called a compositor). So I don't see how ICCCM/EWMH would be relevant; I can only assume they aren't available with wayland, and yet things are working without. > Let's not forget though that fvwm being a reparenting window manager was > always making it an outlier. So does that mean that reparenting is a feature almost no window manager made use of except fvwm? Haven't they been able to do their job because they didn't use this feature? > Widget libraries like GTK and QT have gone way beyond just providing > UI components -- they're now also responsible for CSDs and a myriad > of other crap -- and when you put that into context of what a > Wayland compositor needs to do -- it has fewer options. Styling and > theming becomes the same across Wayland compositors. So you're > losing out on a lot with the Wayland architecture being what it is, > alas. Isn't it one of the purposes of such libraries that GTK looks like GTK and QT looks like QT? The software that doesn't use them also looks like it doesn't (i. e. like Xlib or xaw). And are you being forced to use these libraries? > So Wayland is going to be dominated by Gnome and KDE. I thought it's the other way round. > Yes, they'll be smaller tiling-only WMs on Wayland, but they'll all > look the same. > > So I hope this answers your question. I shan't be replying to any more
Re: FVWM: fvwm3?
On Thu, 2024-02-08 at 12:38 -0800, mark_at_yahoo wrote: > On 2/7/24 20:09, hw wrote: > > On Sat, 2024-02-03 at 13:53 +0100, Lucio Chiappetti wrote: > > > I hope to be able to go on with Xorg until I live. > > > > Or use wayland and start living now :) Living in the past seldwhen is > > a good idea. > Except when the past is better: More capable, complete, and highly > evolved architectural design. Read and understand Thomas' posts. Is it really better? It seemed to me that wayland scales better in that it leaves each program to work on its own and sending the results of its work to what they call a compositor that pieces it all together whereas Xorg requires a server process to do it all which could be a bottleneck. > Wayland improves performance over X11's client-server model? Does it? > Fine. If it wasn't possible to streamline X11 (I'm not convinced) > then do the full redesign ... but include all the capabilities of > the ICCCM and EWMH APIs. Even via an alternate, lower performance, > internal path if necessary. Who is gona do that? IIUC there are obsolete things that must be supported because the protocol requires them, and apparently the protocol is set in stone. That seems to prevent a redesign, and what would be the advantage of reinventing the wheel in exactly the same undesirable way? On of top that, it might be rather difficult to add new features for technical reasons and simply because nobody really wants to that anymore. > As I said before, Wayland sucks. If for no other reason that it will > force me to use bloated, crap window managers (excuse me: "Desktop > Environments"). You're being forced to use them anyway. The problem is not a particular window manger but other software as well since that software has made it impossible to do basic things like adjusting the font size, and it tends to depend on other software which is part of such so-called desktop environments. For example, try to use Evolution without gnome-keyring or kmail without akonadi, and try to get the fonts readable without gnome or kde. You can more or less do the things you do with software that doesn't depend on a so-called desktop environment, but not really, and what you can still do is more complicated and difficult than just using the software that works with the so-called desktop environment. Having to either hold a magnifying glass in front of the screen to be able to read the fonts or using software that isn't up to the task isn't the only problem, only a very annoying one. > Either that or primitive tiling ones (talk about living in the > past). So you're arguing that not using a so-called desktop environment, like instead of fvwm, means you're living in the past. Maybe try sway or i3 and you'll understand that they aren't primitive at all. > But I guess I'll be able to play live, alpha-blended video as the > background in a terminal window -- a nightmare, I mean utopian > dream, I never knew I had or needed. Maybe --- as long as you're not being forced to do such things, it's fine.
Re: FVWM: fvwm3?
On 2/7/24 20:09, hw wrote: On Sat, 2024-02-03 at 13:53 +0100, Lucio Chiappetti wrote: I hope to be able to go on with Xorg until I live. Or use wayland and start living now :) Living in the past seldwhen is a good idea. Except when the past is better: More capable, complete, and highly evolved architectural design. Read and understand Thomas' posts. Wayland improves performance over X11's client-server model? Fine. If it wasn't possible to streamline X11 (I'm not convinced) then do the full redesign ... but include all the capabilities of the ICCCM and EWMH APIs. Even via an alternate, lower performance, internal path if necessary. As I said before, Wayland sucks. If for no other reason that it will force me to use bloated, crap window managers (excuse me: "Desktop Environments"). Either that or primitive tiling ones (talk about living in the past). But I guess I'll be able to play live, alpha-blended video as the background in a terminal window -- a nightmare, I mean utopian dream, I never knew I had or needed.
Re: FVWM: fvwm3?
On Thu, Feb 08, 2024 at 05:50:44AM +0100, hw wrote: > I still don't see why it shouldn't be possible. I never expected a > port, and I understand that the architectures of X11 and Wayland are > very different. Yet why shouldn't it be possible to create a > compositor that provides the configurability fvwm has and which is so > badly lacking in Gnome and KDE? Absolutely it is possible. But then it wouldn't be fvwm. > Is it really impossible to create a wayland compositor that provides > the required functionality? I'm not entirely certain you've understood the points in my original email. I also don't want to repeat myself, but... To me, the things which make fvwm unique, are: 1. Its architecture is tied to X11 -- it uses Xlib directly to render window frames. This is all using Xlib's graphics backend which has a large array of 2d drawing routines. There's not a separate library which can be used to abstract this out to be used elsewhere -- this is the entire point of the client/server model in X11. The only thing which comes close is libcairo (built on pixman) -- and you can use that with a wlroots-based compositor to generate "SSDs" within a compositor -- but this doesn't work well for fvwm because it doesn't allow for shading when filling in rectangles, as well as various other things. This is important because, for me, the entire point of fvwm is that it can be made to look like MWM. I'm serious here -- all of that blocky (even "ugly", as some people have called it) looking borders is important to me, that's what I like. 2. Even if 1., were a solved problem, the second issue is a lack of reparenting. This is a core feature of xlib, and fvwm makes extensive use of it to be able to function. It makes things like resizing and moving windows easier. It's also very important for FvwmButtons; the "Swallow" command calls XReparentWindow() directly. I'm really dumbing-down the explanation here, but it's not possible on Wayland at present. I suspect it will never be. Now, even if the graphics side of things from point 1 above were currently possible under Wayland, the lack of reparenting means you're having to move the window frame along with the window itself -- the two are not "connected", which causes all manner of weird glitches. 3. Lack of standards a la ICCCM/EWMH Fvwm is the exemplar project for how implementing standards helps interoperability rules for window governance. Again, because of the X11 architecture, the XServer would make this easy. Under Wayland, there's "portals" but they're now selective about what's being implemented. So things like aspect-ratio resizing doesn't have a portal. There's so much in the EWMH which makes fvwm behave the way it does with applications, until that's addressed -- or if it ever is -- you'll probably notice lots missing from a potential fvwm-compositor under Wayland. Let's not forget though that fvwm being a reparenting window manager was always making it an outlier. Widget libraries like GTK and QT have gone way beyond just providing UI components -- they're now also responsible for CSDs and a myriad of other crap -- and when you put that into context of what a Wayland compositor needs to do -- it has fewer options. Styling and theming becomes the same across Wayland compositors. So you're losing out on a lot with the Wayland architecture being what it is, alas. So Wayland is going to be dominated by Gnome and KDE. Yes, they'll be smaller tiling-only WMs on Wayland, but they'll all look the same. So I hope this answers your question. I shan't be replying to any more emails in either this thread, or the other one which is talking about Wayland. The subject is becoming tiring and laboured, with most people just saying the same thing, without the understanding behind it. Kindly, Thomas
Re: FVWM: fvwm3?
On 8/2/24 13:51, hw wrote: It has become a very limited option years ago and is basically obsolete. Just try to run, for example, firefox on a remote host via X11 forwarding. I suspect that anything that might use acceleration powers of a graphics card doesn't work, and that kinda leaves only xterm which would be pointless. It also has always been rather slow (slow on a 1 gigabit network and up to unusably slow over internet (VPN)) and was never a good option. Oddly enough, it *does* work, even via SSH over a WAN link, with a few caveats. 1. you must start with `--new-instance` if you have Firefox running on your local workstation as well; otherwise it'll "talk" to your local Firefox instance and tell *it* to open a new window 2. there'll be some noticeable lag, forget watching videos -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: FVWM: fvwm3? [on Wayland]
On 8/2/24 11:55, Chris Bennett wrote: How many here have grey beards? I hope "somebody" (without grey beard but with a lot of time) makes a sane X11 emulation layer. On the other hand, OpenBSD is alive and has it's own heavily patched Xorg called Xenocara and they most likely won't let that go. So maybe porting Xenocara to linux is a better way to go. Nik I cannot imagine OpenBSD will give up it's special Xenocara. OpenBSD kept it's own specially patched Apache 1.39 for years to keep Apache within the base OS. The newer Apache 2 license was unacceptable for base OS requirements. I cannot confirm this, but rumor has it that Theo, the forker of OpenBSD from NetBSD uses FVWM, so I would bet that even though Wayland is being brought in, Xorg as Xenocara will be here to stay. That would not surprise me at all. OpenBSD's FVWM is the v1 release of FVWM for what it's worth (although fvwm2 was in ports, probably fvwm3 now). There's a (understandably) very strong preference for MIT/BSD licensed code in OpenBSD's base. I like FVWM because I can pretty much do whatever I want to take the time to think up and make it happen. I just can't do that with the other WM's I like. Also, it's lightweight, which is a must. Indeed. I don't mind some of the applications from the big desktop environments, but the major Wayland-enabled desktops themselves are inflexible and bloated. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: FVWM: fvwm3?
On Sat, 2024-02-03 at 22:05 +, Thomas Adam wrote: > [...] > GTK and QT dropping support for XLib, that's the time to worry -- as there > could, in theory, be a time when Firefox or Chromium no longer run under X > directly, without forcing a Wayland compositor. That's the real > nail-in-the-coffin. It's already there in that the gnome developers seem to be planning to drop all X11 support, and gnome won't run under X11 anymore. Once that happened, there may come up intentions to remove all the X11 cruft from GTK and QT: Who's gona maintain it when it's no longer used anyway? > So, I'll keep fvwm alive for as long as I can, but I really can't see how > there could ever be a Wayland compositor. I still don't see why it shouldn't be possible. I never expected a port, and I understand that the architectures of X11 and Wayland are very different. Yet why shouldn't it be possible to create a compositor that provides the configurability fvwm has and which is so badly lacking in Gnome and KDE? Gnome doesn't even allow you to configure a program to start with floating sticky windows so you have to set that manually every time the program starts, and that totally sucks. Last time I checked, KDE could do it --- and I like KDE better than gnome, but KDE has always been rather slow and too buggy. Fvwm can do tiling very well, using the tiling extension, and neither Gnome nor KDE come anywhere close. I had fvwm configured such that it managed the windows for me. Gnome and KDE will probably never be able to do that and will continue to force me to manage them myself. Is it really impossible to create a wayland compositor that provides the required functionality?
Re: FVWM: fvwm3?
On Fri, 2024-02-02 at 22:42 -0600, Jason Tibbitts wrote: > I'm running wayland right now (with the KDE desktop) and can fire up > a local xterm or ssh to a different machine and run xterm and it > works just fine. Does this have to be done from an X11 client (like xterm) so you're doing it from within an Xwayland client? Or does it just work with native wayland clients like gnome terminal with some magic done somehow with the Xwayland process that was started by gnome-shell (or kwin)?
Re: FVWM: fvwm3?
On Sat, 2024-02-03 at 13:53 +0100, Lucio Chiappetti wrote: > On Fri, 2 Feb 2024, Robert Heller wrote: > > > Afterall, no one needs more then one computer... > > I suppose there is a smiley missing after the sentence :-) > > My usual way of working (post-COVID, from home) involves usually one or > two ssh sessions on two different remote work machines. Quite occasionally > I also activate a VNC viewer with a remote session of a VNC server on one > of the work machines, and run X stuff there. Occasionally I also run a > point-to-point VPN work-home and NFS mount over it, I rsync stuff from > work to home, work on it at home, and rsync back when finished. Very > rarely I edit work files over remote X, and even more rarely over remote > NFS, but that's because I think my connection is low for that. > > At work I used regularly edit across machines over NFS, ssh and > occasionally remote X (but all machines are on a LAN ... some on different > VLANs and I have even expect gatewayed scripts to bypass that) Wireguard works wonders; if set up correctly, it makes no difference if you're at home or at work. NFS only needs a stable connection; if you have that, you can use cachefilesd to make it faster. If your connection isn't stable NFS will suck. For X stuff you can use xrdp. RDP is way faster then VNC. > Independently of all that, I've never considered switching to wayland, and > do not think any colleague does. Our recent standard installation at work > is Xubuntu (it used to be OpenSuse), and I had it mimicked on both the > home desktop (20.04) and home laptop (22.04) ... first thing I did was to > imstall also fvwm, and then run my good old .fvwmrc with the Minimum > Necessary Change. Ugh, Ubuntu ... Wayland is default in Fedora since a while, and I've been reading it's default in Debian as well (but is that true?). > I hope to be able to go on with Xorg until I live. Or use wayland and start living now :) Living in the past seldwhen is a good idea.
Re: FVWM: fvwm3?
On Fri, 2024-02-02 at 10:55 -0500, Paul Fox wrote: > I realize this discussion is drifting away from fvwm, but... > > ...a major part of my daily activity has always depended on X11's > ability to function on remote displays. Does that functionality > (i.e. "DISPLAY=remotehost:0" vs. "DISPLAY=:0") exist if either or > both of the hosts is based on Wayland? You'd have to try it out. I can't even try it since I can't tell if I have a configuration with which it could work. It has become a very limited option years ago and is basically obsolete. Just try to run, for example, firefox on a remote host via X11 forwarding. I suspect that anything that might use acceleration powers of a graphics card doesn't work, and that kinda leaves only xterm which would be pointless. It also has always been rather slow (slow on a 1 gigabit network and up to unusably slow over internet (VPN)) and was never a good option. You may be better off setting up xrdp for that, and you can use remmina (which works with wayland) to log in via rdp. It works fine over internet (VPN) as well. Gnome desktop sharing also works great, only you can't log in remotely (yet). You'd have to start a session and enable the sharing first for that. (I've waited over 20 years for a feature like that, and it finally works out of the box!)
Re: FVWM: fvwm3? [on Wayland]
On Sun, Feb 04, 2024 at 07:30:05PM +0100, Dr. Nikolaus Klepp wrote: > Anno domini 2024 Sun, 4 Feb 01:14:21 +0100 > Martin Cermak scripsit: > > On Sun 2024-02-04 09:51 , Stuart Longland wrote: > > [...] > > > > IMHO for FVWM to survive, the FVWM community needs to focus on > > wayland. And start from scratch... I wish this happens. > > How many here have grey beards? I hope "somebody" (without grey beard but > with a lot of time) makes a sane X11 emulation layer. On the other hand, > OpenBSD is alive and has it's own heavily patched Xorg called Xenocara and > they most likely won't let that go. So maybe porting Xenocara to linux is a > better way to go. > > Nik I cannot imagine OpenBSD will give up it's special Xenocara. OpenBSD kept it's own specially patched Apache 1.39 for years to keep Apache within the base OS. The newer Apache 2 license was unacceptable for base OS requirements. I cannot confirm this, but rumor has it that Theo, the forker of OpenBSD from NetBSD uses FVWM, so I would bet that even though Wayland is being brought in, Xorg as Xenocara will be here to stay. I like FVWM because I can pretty much do whatever I want to take the time to think up and make it happen. I just can't do that with the other WM's I like. Also, it's lightweight, which is a must. -- Regards, Chris Bennett "Who controls the past controls the future. Who controls the present controls the past." George Orwell - 1984
Re: FVWM: fvwm3? [on Wayland]
On Sun, Feb 04, 2024 at 07:30:05PM +0100, Dr. Nikolaus Klepp wrote: Anno domini 2024 Sun, 4 Feb 01:14:21 +0100 Martin Cermak scripsit: On Sun 2024-02-04 09:51 , Stuart Longland wrote: [...] IMHO for FVWM to survive, the FVWM community needs to focus on wayland. And start from scratch... I wish this happens. How many here have grey beards? I hope "somebody" (without grey beard but with a lot of time) makes a sane X11 emulation layer. On the other hand, OpenBSD is alive and has it's own heavily patched Xorg called Xenocara and they most likely won't let that go. So maybe porting Xenocara to linux is a better way to go. Nik Actually I am hoping all the BSDs get together and maintain Xenocara. IIRC, Xenocara is maintained by taking patches from Xorg and making adjustments. So once/if those Xorg patches stop, Xenocara will be on its own. If the BSDs do this, then it may be possible to port to Linux :) John
Re: FVWM: fvwm3? [on Wayland]
I'm going to document my own hatred for Wayland here, not that it will make any difference to its unstoppable adoption and the subsequent likely demise of FVWM. Note that I'm not an expert on the subject(s) nor do I have the time or inclination to become one as I'm 100% convinced that what I don't know, or any educated rebuttals to my arguments, won't change my overall conclusions. Wayland is the latest and greatest step in the destruction of the basic design concepts that are why UNIX, 50+ years after its inception, is the world's dominant operating system. It completely misses the point of separating functionality into independent and interchangeable software components. I have read the Wayland FAQ for years about why X11 needs to be replaced, and it boils down to exactly two points: 1. X11 is old. 2. It supports stippled line drawing which nobody uses any more. OK ... 1) what's wrong with that, and 2) update the API to deprecate un- and under-used functionality. Integrate the WM into the graphics server? What's next -- integrate the server into the kernel? Impossible you say, Linus would never accept that? Yeah, after years of him hating on C++ he accepted Rust because it's memory-safe. (Insist on smart pointers in C++. Problem solved.) I'll always venerate Linus for his contribution to computing -- the Herculean accomplishment of cracking Intel's insane X86 architecture to turn the toy Minix into a full-fledged virtual memory UNIX implementation -- but 30 years of being worshipped as a demigod might have gone to his head. (He recently demonstrated in one of his famous flamings, justified because the pull request in question broke the kernel, that he doesn't know how to read a stack trace.) I need FVWM, and therefor by extension X11 as has been documented here, because nothing else supports my customized desktop UI which allows me to be twice as productive as the alternatives. Not so much the visual look (an extension of MWM, perfect) but the bindings of the three mouse buttons, and most importantly the ability to iconify applications to specific positions on the desktop. All of the Gnomes/KDEs/M$Windows/Apples with their taskbars and iconboxes (in FVWM terms) require me to search by name or icon glyph through a constantly changing arrangement instead of my intuitive muscle memory moving the mouse to a known place on the screen and clicking there. I don't even have to look. Remote X11 rendering between two networked machines? I guess the Wayland designers didn't understand that concept. Either they don't care about high-end users in a professional environment, or they're only targeting the 99.9% demographic of casual users. "A GUI application? You mean a web browser connected to a cloud server, right?" I've long suspected that all of these visionaries leading us forward from the same boring old software technologies must have secret closets full of black turtleneck shirts, Levis blue jeans, and white running shoes in preparation for when they become the next Steve Jobs -- wealthy, famous, and beloved by all humanity. See GNOME 3 for a precedent. I'd like nothing more than to see a "Rebel Alliance" Linux distro that maintains X11, GTK and Qt, System V Init, config files without D-Bus, and everything else that already works (mostly) perfectly (plus any needed fixes/updates/improvements). But the huge amount of effort required (50+ highly capable and committed developers) probably means it won't ever happen. And I'm far too over-committed with my own open source projects to be able to contribute. "Retro" distributions already exist, but as Thomas astutely points out, the nail in the coffin will be when Firefox and Chromium stop working on them. You can have all the Konquerors, Vivaldis, Operas, GNOME Webs, etc. you want, but you'll eventually run into e-commerce, news, and governmental websites -- all required to function in current global society -- that fatally inform you your browser isn't supported and to come back when you're using something else. I suppose I'll hang on to FVWM/X11/etc as long as I can for my real work, probably having to add a separate/dedicated "modern" Linux box with Wayland and all the rest for online tasks. Maybe they'll keep `scp` running for the rest of my natural life so I'll at least be able to move important documents over to the "real" machine for inspection, analysis, and archiving. Sign me, Disgusted
Re: FVWM: fvwm3? [on Wayland]
Anno domini 2024 Sun, 4 Feb 01:14:21 +0100 Martin Cermak scripsit: > On Sun 2024-02-04 09:51 , Stuart Longland wrote: > [...] > > IMHO for FVWM to survive, the FVWM community needs to focus on > wayland. And start from scratch... I wish this happens. How many here have grey beards? I hope "somebody" (without grey beard but with a lot of time) makes a sane X11 emulation layer. On the other hand, OpenBSD is alive and has it's own heavily patched Xorg called Xenocara and they most likely won't let that go. So maybe porting Xenocara to linux is a better way to go. Nik > > m. > > > > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...
Re: FVWM: fvwm3? [on Wayland]
- Are people using FVWM for its looks? (Themability) Looks/functionallity: I want the MWM look/functionallity. Yes, I too like a simple mwm-like look, but even more I like the complete and easy customizability. I think there are proofs on the net of completely different looks. AND functionality ! It's not just a matter of changing a wallpaper. - Are people using FVWM for just being light-weight? YES! I want as lightweight a window manager as posible. I also do appreciate a lightweight wm (it usually runs at 1% CPU), or better I deprecate how heavy are some DE like KDE. - Are people using FVWM for its binding/scripting support? Yes, I added some of my own widgets, see reference below. And I would add a fourth reason ]] - I use FVWM because its customization (even if it has a steep learning curve) is all concentrated in a single text file, so with a minimum of self-documentation one will always know where to go (unless those DE with infinite branches of GUIs) These discussion instigated me to do sometyhing I lept pending for a couple of years, i.e. add some new screenshots to my FVWM doc page referring to my current fvwrc on Ubuntu, which adds to a pluridecennial experience http://sax.iasf-milano.inaf.it/~lucio/WWW/Opinions/window.html -- Cosi' per li gran savi si confessa / Che la Fenice muore e poi rinasce, / Quando al cinquecentesimo anno appressa. (Dante, Inferno, XXIV, 106-108) Thus the great wise testify / That the Phoenix dies and is born again, / When the five-hundredth year gets close.
Re: FVWM: fvwm3? [on Wayland]
On Sun 2024-02-04 09:51 , Stuart Longland wrote: > So either some of us need to step up and get familiar with how X11 works > (unlikely, it seems like a monumental task)… or we need to "pack our bags", > so to speak It hurts, but my sense is that the above is right. IMHO the distributions effectively need a vibrant community around a project to pick it up. It can hardly be a one man show. The denial will start with security issues, as usual... IMHO for FVWM to survive, the FVWM community needs to focus on wayland. And start from scratch... I wish this happens. m.
Re: FVWM: fvwm3? [on Wayland]
At Sun, 4 Feb 2024 09:51:45 +1000 Stuart Longland wrote: > > On 4/2/24 08:05, Thomas Adam wrote: > I think this is where we need to consider what the FVWM/Wayland re-write > would look like. What can be practically brought across under the > constraints of the `wlroots` back-end (or Wayland itself), and what do > we have to leave behind? Of the things we can bring across, what items > are of most important to people? > > - Are people using FVWM for its looks? (Themability) Looks/functionallity: I want the MWM look/functionallity. > - Are people using FVWM for its binding/scripting support? > - Are people using FVWM for just being light-weight? YES! I want as lightweight a window manager as posible. I don't want to have to a super powerful computer, just because of my GUI. Some of the GUI tools I use are more then "bloated" enough without having to add a "bloated" memory hog just to manage a few windows. > > I think this is what we need to be asking, what is important to us, the > FVWM community that we want to preserve? Then we can figure out how > best to bring across enough of the FVWM "essence" to build a new home in > the land of Wayland. -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services
Re: FVWM: fvwm3? [on Wayland]
On 4/2/24 08:05, Thomas Adam wrote: Wayland is not Xlib. I have been, in my spare time, looking at the XServer code and all the other libraries surrounding it, and looking at open MRs on Xorg's Gitlab instance -- which means I am going to help keep XServer alive -- which by extension means fvwm. For all the while that continues, when you hear about widget libraries such as GTK and QT dropping support for XLib, that's the time to worry -- as there could, in theory, be a time when Firefox or Chromium no longer run under X directly, without forcing a Wayland compositor. That's the real nail-in-the-coffin. So, I'll keep fvwm alive for as long as I can, but I really can't see how there could ever be a Wayland compositor. I appreciate your efforts in trying to keep FVWM alive. It has a long history… and so far, I've not found a more flexible window manager. FVWM was always my go-to when supporting Gentoo/MIPS, because I could get FVWM built very quickly due to its Xlib base. The others required me to build a GUI toolkit like Qt or GTK+, which meant no X11 environment for a lot longer. I've tried a couple of Wayland compositors, they seem to be at two extremes of the user experience space: either full-featured (and quite bloated) desktops such as Gnome or KDE Plasma… or extremely minimal tiling affairs. Nothing that is "in between" like FVWM, which works just as gracefully on my relatively new Ryzen 7 5800U laptop as it does the 14-year old Atom N450 netbook. I tried Plasma on the latter, I don't think I need to describe how it went. On the laptop I'm typing this on now (Panasonic CF-53; 10 years old now), Plasma worked okay, but it still "felt" slower, and a lot of things I was used to were missing. Window management is so much more than just drawing a box around a window and plonking it somewhere on a screen. My understanding for the Wayland push is that the X11 driver architecture was written around assumptions about video hardware that existed circa 1986~1996 which almost universally were built around CRT sync hardware. That assumption is starting to fall apart with some of the modern video hardware out there that outputs a digital packet-based stream via HDMI or DisplayPort. Apple Silicon hardware in particular, seems to bear little resemblance to what came before, and hence the Asahi Linux team decided they weren't going to support X11. While there are people still working on X11, many of them are starting to tire of the work because it's specialist code that requires a deep understanding of both X11 and graphic card hardware to be effective. So either some of us need to step up and get familiar with how X11 works (unlikely, it seems like a monumental task)… or we need to "pack our bags", so to speak, and move to a new world: FVWM on Wayland is basically going to be a re-write. Can we re-use certain modules to emulate what we had? I don't know. A big part of FVWM was its script-ability. It could hook various events, then you the user, could program it to automate what happened next using a domain-specific language. e.g. I have FVWM here set up so when I hit the "Super" key; a menu pops up. If it's on a window, the menu that pops up has window operations up the top (Close, Move/Resize, Maximise, Split…) followed by a "Quick Launch" (which lets me quickly access specific applications) and access to the root menu (to reach everything else). On a non-window, the menu that appears has just the latter parts (there's no window to operate on). So if I want to make the current window occupy the right-half of the screen, I hit Super, L (for Split), 2 (for Half), R (for Right). If I want it the lower-right quadrant, it'd be Super, L, 4, R (bottom right). A single keystroke brings up a menu tree, then keyboard mnemonics on menu items lets me navigate that menu to a specific item; which calls FVWM actions do the rest. I'm not sure how others use FVWM, but this is how I use it, and I find it is a huge productivity enhancement. I'm not bothered much about how it looks (I do insist on a title bar: my windows look like MWM), but a big part is being able to move things around. I think this is where we need to consider what the FVWM/Wayland re-write would look like. What can be practically brought across under the constraints of the `wlroots` back-end (or Wayland itself), and what do we have to leave behind? Of the things we can bring across, what items are of most important to people? - Are people using FVWM for its looks? (Themability) - Are people using FVWM for its binding/scripting support? - Are people using FVWM for just being light-weight? I think this is what we need to be asking, what is important to us, the FVWM community that we want to preserve? Then we can figure out how best to bring across enough of the FVWM "essence" to build a new home in the land of Wayland. -- Stuart Longland (aka Redhatter, VK4MSL) I
Re: FVWM: fvwm3?
On Fri, Feb 02, 2024 at 10:42:37PM -0600, Jason Tibbitts wrote: > Now, I don't know if you could use the really old-style remote display > stuff where ssh is not involved. Xwayland really is a proper X server > so the ability to do it is probably down in there somewhere. Yes-and-no -- in that, although XWayland is similar in architecture to Xephyr and Xnest, it's not anywhere near a complete "stripped-down" XServer -- Xephyr has better support for a lot of the XServer extensions than XWayland does, and I suspect that will only ever support enough to run pure XLib/Xaw applications, and nothing more. Certainly, running fvwm under XWayland is possible, but because of the RandR support available, it doesn't recognise the host's screens, and hence doesn't work how you'd expect it to at present. Beyond that limitation, there's still plenty of other extensions which would be needed to make fvwm run comfortably under that. You'll probably find plenty of rhetoric on Youtube and elsewhere showing some $WM running under XWayland -- the point here is that such a $WM is not a reparenting WM, and relies on just drawing window borders around clients, which is very different. Speaking of the Wayland architecture, and having read others' replies in this thread, it's saddening to think of the shear lack of understanding there is between Xorg and Wayland. When people talk of a "port of FVWM to Wayland" they do so in the naive understanding that it's already possible -- with there being an existing framework or something which would make the possible. There is not. FVWM amongst the existing X11 WMs is already unique in that it has been built against pure X11 -- that is, no existing higher-level widget toolkit to provide window decorations, such as GTK or QT. Rather, FVWM is a *reparenting* window manager, which means its window decorations are drawn via Xlib, and the client window is embedded inside that frame, drawn via fvwm, via Xlib. That's what reparenting means. When you go to resize, move, etc., a window managed by fvwm, you do so by that parent frame telling the client about its new size/geometry. All of this is via the XServer. With Wayland, and if there were to ever be a fvwm compositor, the *compositor* is the "server", as well as everything else. There is no longer a separation of client/server under Wayland -- a compositor must do it all in one. There are libraries which will assist with this -- such as wlroots. This has meant a lot of compositors function in the same way, such as river, dwl, labwc, sway, etc. But they all suffer the same problem in that they're only as good as the functionality this library provides, which is not everything which is part of the Wayland ecosystem -- albeit that is in itself in a state of flux. Although Wayland compositors have the separation to handle CSDs (client-side decorations), and SSDs (server-side decorations), the SSD code in compositors is nothing more than drawing a window frame around a client window, and moving it relative to the client -- this is because of the lack of reparenting under Wayland. Perhaps one of the biggest drawbacks of Wayland which worries me is that there is a notion of things called "portals" which are additional bolt-on bits of functionality which Wayland compositors can choose to implement or not. But by themselves, they're not addressing anything near what they should -- and when you compare them to what the ICCCM2 and the EWMH specification standardised on, it's all very much a step-backward in terms of richness and how windows should behave. Indeed, these "portals" seems to popup sporadically, and are not being addressed in a way which I would argue is cohesive. I mentioned over on Mastodon one such example of this [0] where a portal for specifying the miniicon (to use fvwm's parlance) turned into an utter shit-show because of the amount of bikeshedding involved. If that is the level at which progress is to be measured, Wayland is doomed. But right now, if portals under Wayland are meant to selectively bring over functionality found in the EWMH spec, it's a million miles away from being complete. Even if there were a cabal of compositors which were trying to do this collectively -- even in the spirit of how this were being done on X11 originally -- it's still very much up to the individual compositor to implement this, as there is no sever/client model to abstract some of that away. The best one might hope for is something like wlroots implementing these portals. Good luck with that. So, a "port" of fvwm to Wayland? No. Impossible. Because of the architecture, the reliance on the server/client architecture, the fact that there are no 2D graphics libraries which are standalone from Xlib which work on Wayland to generate window frames, makes this difficult (XFillRectangle, etc). There is notion of reparenting under Wayland. Wayland is not Xlib. I have been, in my spare time, looking at the XServer code and all
Re: FVWM: fvwm3?
Lucio Chiappetti wrote (Sat, Feb 03, 2024 at 01:53:29PM +0100): > I hope to be able to go on with Xorg until I live. Amen! :-)
Re: FVWM: fvwm3?
On Fri, 2 Feb 2024, Robert Heller wrote: Afterall, no one needs more then one computer... I suppose there is a smiley missing after the sentence :-) My usual way of working (post-COVID, from home) involves usually one or two ssh sessions on two different remote work machines. Quite occasionally I also activate a VNC viewer with a remote session of a VNC server on one of the work machines, and run X stuff there. Occasionally I also run a point-to-point VPN work-home and NFS mount over it, I rsync stuff from work to home, work on it at home, and rsync back when finished. Very rarely I edit work files over remote X, and even more rarely over remote NFS, but that's because I think my connection is low for that. At work I used regularly edit across machines over NFS, ssh and occasionally remote X (but all machines are on a LAN ... some on different VLANs and I have even expect gatewayed scripts to bypass that) Independently of all that, I've never considered switching to wayland, and do not think any colleague does. Our recent standard installation at work is Xubuntu (it used to be OpenSuse), and I had it mimicked on both the home desktop (20.04) and home laptop (22.04) ... first thing I did was to imstall also fvwm, and then run my good old .fvwmrc with the Minimum Necessary Change. I hope to be able to go on with Xorg until I live.
Re: FVWM: fvwm3?
On 3/2/24 01:55, Paul Fox wrote: I realize this discussion is drifting away from fvwm, but... ...a major part of my daily activity has always depended on X11's ability to function on remote displays. Does that functionality (i.e. "DISPLAY=remotehost:0" vs. "DISPLAY=:0") exist if either or both of the hosts is based on Wayland? There's `waypipe` for funnelling a Wayland application connection across a network link (via `ssh` in particular). Not sure if it supports mixed environments though. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: FVWM: fvwm3?
> John McCue writes: > I heard of waypipe, but from what I understand is for it to work, the > remote system needs to have wayland too. Well, it's for running a wayland application on a remote machine displaying on your local wayland-running machine. If you want to run an X11 application on a remote displaying on your local wayland-running machine, you just use ssh as usual. Basically any machine with wayland is going to have Xwayland (the X11 component) and will start it when needed, though I guess some distribution who really gets behind wayland could not compile that part if they really didn't want to. > So if for example you want to run a remote X application on a BSD (or > AIX), it will not work. Nope, works just fine (besides that usual caveat about endianness mismatches that you get with all X servers this decade). I'm running wayland right now (with the KDE desktop) and can fire up a local xterm or ssh to a different machine and run xterm and it works just fine. Interestingly, it appears that it's actually the window manager (kwin_wayland) that ends up starting Xwayland. None of it runs as root (just the display manager, which in my case is SDDM). > To me, this indicates it is Linux (or maybe Wayland) specific. Nothing there indicates Linux; I don't personally know if the code is portable but I doubt anyone is going out of their way to make it difficult. Somehow I don't think you'll see many AIX machines running wayland in any case. Of course waypipe is wayland specific; that is its function. For X11 forwarding, ssh handles things as it always has. Now, I don't know if you could use the really old-style remote display stuff where ssh is not involved. Xwayland really is a proper X server so the ability to do it is probably down in there somewhere. - J<
Re: FVWM: fvwm3?
On Fri, Feb 02, 2024 at 06:11:01PM -0600, Jason Tibbitts wrote: Robert Heller writes: I believe Wayland does not support that sort of thing. It does, actually, but not exactly the same way. Look up "waypipe". One does get the impression that it's all an afterthought, though. I heard of waypipe, but from what I understand is for it to work, the remote system needs to have wayland too. So if for example you want to run a remote X application on a BSD (or AIX), it will not work. From: https://wiki.archlinux.org/title/Wayland waypipeAUR (or waypipe-gitAUR) is a transparent proxy for Wayland applications, with a wrapper command to run over SSH To me, this indicates it is Linux (or maybe Wayland) specific.
Re: FVWM: fvwm3?
robert wrote: > > At Fri, 02 Feb 2024 18:11:01 -0600 Jason Tibbitts wrote: > > > > > > Robert Heller writes: > > > > > I believe Wayland does not support that sort of thing. > > > > It does, actually, but not exactly the same way. Look up "waypipe". > > One does get the impression that it's all an afterthought, though. > > Right. Wayland does not want to be a networked display environment and > would > like to be like the MS-Windows and MacOS display environments: purely a > local > machine only display environment. Afterall, no one needs more then one > computer... I confess I'm happy just to know that someone is considering the problem/feature at all. paul =-- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 37.8 degrees)
Re: FVWM: fvwm3?
At Fri, 02 Feb 2024 18:11:01 -0600 Jason Tibbitts wrote: > > > Robert Heller writes: > > > I believe Wayland does not support that sort of thing. > > It does, actually, but not exactly the same way. Look up "waypipe". > One does get the impression that it's all an afterthought, though. Right. Wayland does not want to be a networked display environment and would like to be like the MS-Windows and MacOS display environments: purely a local machine only display environment. Afterall, no one needs more then one computer... > > - J< > > > -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services
Re: FVWM: fvwm3?
> Robert Heller writes: > I believe Wayland does not support that sort of thing. It does, actually, but not exactly the same way. Look up "waypipe". One does get the impression that it's all an afterthought, though. - J<
Re: FVWM: fvwm3?
At Fri, 02 Feb 2024 10:55:46 -0500 Paul Fox wrote: > > I realize this discussion is drifting away from fvwm, but... > > ...a major part of my daily activity has always depended on X11's > ability to function on remote displays. Does that functionality > (i.e. "DISPLAY=remotehost:0" vs. "DISPLAY=:0") exist if either or > both of the hosts is based on Wayland? I believe Wayland does not support that sort of thing. > > paul > > ml-f...@srv.mx wrote: > > Also a bunch of new DE/WM and soon XFCE. There will still be diversity, > > but a new one. > > However I'm not sure Xorg will be out soon there are still missing > > features on Wayland, like screen recording (available only on Gnome), > > which means that softwares like OBS don't work on it. > > > > Le 02/02/2024 à04:28, hw a écrit : > > > On Tue, 2024-01-30 at 14:02 -0700, Jaimos Skriletz wrote: > > >> On Tue, Jan 30, 2024 at 1:25 PM hw wrote: > > >>> > > >>> so is there finally a version that works for wayland? > > >>> > > >> No, fvwm only works with xorg and most likely won't be ported. > > >> > > >>> What are the differences between fvwm2 and fvwm3? > > >>> > > >> See https://github.com/fvwmorg/fvwm3/discussions/878 > > > > > > Good pointer, thanks! > > > > > > It's a pity that there's no fvwm for wayland. Xorg doesn't seem to be > > > maintainted anymore and is on the way out. That only leaves us Gnome > > > and KDE. All the diversity we used to have is gone with that. > > > > > > > > > > > =-- > paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 38.9 degrees) > > > > > -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services
Re: FVWM: fvwm3?
> Does wayland have an X11 compatibility feature? Wayland has an 'XWayland' layer that allows regular X clients to talk to a Wayland server. However, this does not support special X clients like window managers or (as I understand it) automation tools like 'xdotool'. So you can run an X-based editor or xterm under Wayland, at least to some degree, but you can't run fvwm; the special X APIs that window managers use don't work. - cks
Re: FVWM: fvwm3?
I realize this discussion is drifting away from fvwm, but... ...a major part of my daily activity has always depended on X11's ability to function on remote displays. Does that functionality (i.e. "DISPLAY=remotehost:0" vs. "DISPLAY=:0") exist if either or both of the hosts is based on Wayland? paul ml-f...@srv.mx wrote: > Also a bunch of new DE/WM and soon XFCE. There will still be diversity, > but a new one. > However I'm not sure Xorg will be out soon there are still missing > features on Wayland, like screen recording (available only on Gnome), > which means that softwares like OBS don't work on it. > > Le 02/02/2024 à 04:28, hw a écrit : > > On Tue, 2024-01-30 at 14:02 -0700, Jaimos Skriletz wrote: > >> On Tue, Jan 30, 2024 at 1:25 PM hw wrote: > >>> > >>> so is there finally a version that works for wayland? > >>> > >> No, fvwm only works with xorg and most likely won't be ported. > >> > >>> What are the differences between fvwm2 and fvwm3? > >>> > >> See https://github.com/fvwmorg/fvwm3/discussions/878 > > > > Good pointer, thanks! > > > > It's a pity that there's no fvwm for wayland. Xorg doesn't seem to be > > maintainted anymore and is on the way out. That only leaves us Gnome > > and KDE. All the diversity we used to have is gone with that. > > > > > =-- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 38.9 degrees)
Re: FVWM: fvwm3?
Also a bunch of new DE/WM and soon XFCE. There will still be diversity, but a new one. However I'm not sure Xorg will be out soon there are still missing features on Wayland, like screen recording (available only on Gnome), which means that softwares like OBS don't work on it. Le 02/02/2024 à 04:28, hw a écrit : On Tue, 2024-01-30 at 14:02 -0700, Jaimos Skriletz wrote: On Tue, Jan 30, 2024 at 1:25 PM hw wrote: so is there finally a version that works for wayland? No, fvwm only works with xorg and most likely won't be ported. What are the differences between fvwm2 and fvwm3? See https://github.com/fvwmorg/fvwm3/discussions/878 Good pointer, thanks! It's a pity that there's no fvwm for wayland. Xorg doesn't seem to be maintainted anymore and is on the way out. That only leaves us Gnome and KDE. All the diversity we used to have is gone with that.
Re: FVWM: fvwm3?
At Fri, 02 Feb 2024 04:28:44 +0100 hw wrote: > > On Tue, 2024-01-30 at 14:02 -0700, Jaimos Skriletz wrote: > > On Tue, Jan 30, 2024 at 1:25â¯PM hw wrote: > > > > > > so is there finally a version that works for wayland? > > > > > No, fvwm only works with xorg and most likely won't be ported. > > > > > What are the differences between fvwm2 and fvwm3? > > > > > See https://github.com/fvwmorg/fvwm3/discussions/878 > > Good pointer, thanks! > > It's a pity that there's no fvwm for wayland. Xorg doesn't seem to be > maintainted anymore and is on the way out. That only leaves us Gnome > and KDE. All the diversity we used to have is gone with that. > Does wayland have an X11 compatibility feature? > > > -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services
Re: FVWM: fvwm3?
On Tue, 2024-01-30 at 14:02 -0700, Jaimos Skriletz wrote: > On Tue, Jan 30, 2024 at 1:25 PM hw wrote: > > > > so is there finally a version that works for wayland? > > > No, fvwm only works with xorg and most likely won't be ported. > > > What are the differences between fvwm2 and fvwm3? > > > See https://github.com/fvwmorg/fvwm3/discussions/878 Good pointer, thanks! It's a pity that there's no fvwm for wayland. Xorg doesn't seem to be maintainted anymore and is on the way out. That only leaves us Gnome and KDE. All the diversity we used to have is gone with that.
Re: FVWM: fvwm3?
> On Tue, Jan 30, 2024 at 1:25 PM hw wrote: > > so is there finally a version that works for wayland? > > > No, fvwm only works with xorg and most likely won't be ported. To add some information, a 'port' would be more difficult than it sounds. The architecture of Wayland does not have an equivalent of the separation between the X server and the window manager; the window manager is part of the 'Wayland compositor' that is effectively the equivalent of the X server. There are libraries that are intended to make writing a Wayland compositor easier, but it would still be a major addition to what fvwm does and a major change to how it works. Probably relatively little of the current fvwm code could be readily reused in such a 'Wayland fvwm'. (I do hope someone writes a Wayland compositor/window manager that works like fvwm does at some point, because some day I will probably have to switch to Wayland and at that point I'm going to miss any number of fvwm features, including great keybinding support and FvwmIconManager.) - cks
Re: FVWM: fvwm3?
On Tue, Jan 30, 2024 at 1:25 PM hw wrote: > > so is there finally a version that works for wayland? > No, fvwm only works with xorg and most likely won't be ported. > What are the differences between fvwm2 and fvwm3? > See https://github.com/fvwmorg/fvwm3/discussions/878 jaimos
Re: FVWM: FVWM3: 2 monitors with different geometries?
Jaimos Skriletz wrote (Fri, Dec 22, 2023 at 12:45:34PM -0700): > Yes, you can have different resolutions. I think you may run into > issues using DesktopConfiguration shared with different resolutions, > but DesktopConfiguration per-monitor will work just fine. FVWM3 installation went without a hitch (I'm on Manjaro and just installed the AUR package). My existing .fvwm2rc also works without any problems. The default config bundled in the package uses "DesktopConfiguration global". Could someone please point me to / share an example config file that uses "DesktopConfiguration per-monitor"? I couldn't find a starting point for this on the forums / wiki. I'd like to create a Desktop-default (laptop's own monitor, always available) and a Desktop-external-monitor, which can be used when the external monitor is plugged in. Afterwards, I think I can use move-to-desk, starts-on-desk and similar functions to complete the rest of my setup. Also, I'm sure there are more elegant ways to achieve this, but I suppose restarting fvwm after plugging in the external monitor will take care of detecting it, activating per-monitor DesktopConfiguration, and setting up the second Desktop on the external monitor? Thanks, Mandar.
Re: FVWM: FVWM3: 2 monitors with different geometries?
Jaimos Skriletz wrote (Fri, Dec 22, 2023 at 12:45:34PM -0700): > On Fri, Dec 22, 2023 at 9:42 AM Mandar Mitra wrote: > > > > > > Browsing around FVWM3's git repo, and looking at > > https://github.com/fvwmorg/fvwm3/blob/main/dev-docs/NEW-COMMANDS.md#hierarchy-and-specification > > in particular, it seems like fvwm3 will allow me to have independent > > desktops with appropriate geometries on Screen1 and Screen2. > > > > This is a bit better page to describe how to migrate from fvwm2 to fvwm3: > > https://github.com/fvwmorg/fvwm3/discussions/878 ... Thank you so much for all the detailed answers! I will try to install fvwm3 in the next few days. If I have anything to add to the above, I will definitely report. Thanks again, -mandar
Re: FVWM: FVWM3: 2 monitors with different geometries?
On Fri, Dec 22, 2023 at 9:42 AM Mandar Mitra wrote: > > > Browsing around FVWM3's git repo, and looking at > https://github.com/fvwmorg/fvwm3/blob/main/dev-docs/NEW-COMMANDS.md#hierarchy-and-specification > in particular, it seems like fvwm3 will allow me to have independent > desktops with appropriate geometries on Screen1 and Screen2. > This is a bit better page to describe how to migrate from fvwm2 to fvwm3: https://github.com/fvwmorg/fvwm3/discussions/878 Fvwm3 multi-monitor support is quite good and there are lots of improvements in both how multiple monitors can be used and dealing with monitors with different resolutions. > I haven't been able to figure out how to do this with FVWM2, so if some kind > soul could please confirm that this is possible with FVWM3, I'll take the > plunge and migrate. > > Somewhat related questions: > > 1. The NEW-COMMANDS.md page states "Desktops are linear in their arrangement. > There is no concept of pages within a desktop (as there is with FVWM2)." Is > that information correct? Or is this something left over from early design > discussions? > This is about how the data structure stores monitors (though this has changed recently), and not about the pages or setup for the user. Pages and Desks work just the same in fvwm3 as fvwm2. Though you may find that you want your pages to have a single column/row (depending on how your monitors are setup) if you use EdgeScroll. > 2. The picture on the NEW-COMMANDS.md page shows that the Desktops on Screen1 > have different geometries. Is that really possible? Or shouldn't I take that > "literally"? > Yes, you can have different resolutions. I think you may run into issues using DesktopConfiguration shared with different resolutions, but DesktopConfiguration per-monitor will work just fine. jaimos
Re: FVWM: fvwm3: how to make qmmp2 sticky?
On Mon, 31 Jul 2023 at 19:31, Harald Dunkel wrote: > > Hi folks, > > using fvwm3 and > > Style "qmmp" NoTitle, WindowListSkip, Sticky, StaysOnBottom > > qmmp2 (https://sourceforge.net/projects/qmmp-dev/files/qmmp/2.1/) is not > sticky. The other attributes from the list work as expected. Similar I've not installed this application, but can you send me the output from `xprop` on the window which should be sticky, but isn't? Kindly, Thomas
Re: FVWM: fvwm3 1.0.5 FvwmButtons issue ?
On Thu, Oct 20, 2022 at 5:26 PM John McCue wrote: > > Hi, > > I noticed an issue with fvwm3 1.0.5 vs 1.0.4. > > Please let me know if you need more information. > Could you check the known issues at github, and adding this issue there will get more attention. https://github.com/fvwmorg/fvwm3/issues Also check the current master branch on github, see if the issue is present there too. jaimos
Re: FVWM: FVWM3-1.0.0 is released
Stuart Longland writes: > On 7/9/20 9:40 am, Chris Bennett wrote: >> I'm running amd64 OpenBSD and there are libraries we don't have, such as >> libbson, which can be added. >> However, I'm a little unclear on what the -dev signifies on the required >> libraries. > > I'm guessing possibly a Debian or RedHat-ism? A lot of those > distributions ship packages that are "split": .so libraries and user > binaries in one package (libfoo) and the headers and .a libraries in a > "development" package (libfoo-dev). For Redhat, (well Fedora), the development packages are suffixed -devel. Typically you get headers and libraries you need to do compiles. -- Dan Espen
Re: FVWM: FVWM3-1.0.0 is released
On 7/9/20 9:40 am, Chris Bennett wrote: > I'm running amd64 OpenBSD and there are libraries we don't have, such as > libbson, which can be added. > However, I'm a little unclear on what the -dev signifies on the required > libraries. I'm guessing possibly a Debian or RedHat-ism? A lot of those distributions ship packages that are "split": .so libraries and user binaries in one package (libfoo) and the headers and .a libraries in a "development" package (libfoo-dev). -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: FVWM: FVWM3-1.0.0 is released
Hi, I'm running amd64 OpenBSD and there are libraries we don't have, such as libbson, which can be added. However, I'm a little unclear on what the -dev signifies on the required libraries. I'm a bit outside of what that means. My experience is mostly Perl and PostgreSQL. Thanks, Chris Bennett
Re: FVWM: FVWM3-1.0.0 is released
On 7/9/20 7:13 am, elliot s wrote: > Is there a way to get a precompiled 64 bit version? 64-bit? MIPS n64 binary compiled on OpenBSD 6.6 cool with you? To provide a binary that will actually work, we need to know more than the width of the address bus your CPU uses. There's AMD64, ARM64, MIPS64, UltraSPARC, PPC64, RISC-V, … and those are just the currently active platforms that are 64-bit… historically you can add to that MIPS3/MIPS4, DEC Alpha, HP PA-RISC, Intel IA64… and probably lots of others I've forgotten about. Then there's the kernel, Linux is a common choice, but you could also be running a BSD variant on a 64-bit processor. Solaris and IRIX both had 64-bit versions. Recent MacOS X is also 64-bit. Then there's userland libraries that FVWM might want to link to. I have an AMD64 Linux binary for fvwm2 here, but there's no guarantee that it'll work on your arbitrary AMD64 Linux computer as it was compiled against what I'm running here. This is the minefield that one walks into providing binaries. No different to any other OS. Firefox on Windows these days is compiled for Windows 7 (not sure about Vista): it won't work on Windows XP. Yes, you might download a 32-bit version of it, but it was linked against libraries that are newer than what is available on that OS. Lots of applications don't work on my Macbook running MacOS X 10.6 for this reason. Far and above the safest ways are: - compile it yourself - obtain a compiled package from your operating system's distributor Alternatively: if you could provide some detail on what 64-bit platform and OS you are running, someone here might be able to provide a binary package for that OS. Without that information, we are guessing. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: FVWM: FVWM3-1.0.0 is released
On Sun, Sep 06, 2020 at 02:13:18PM -0700, elliot s wrote: > Retrying from laptop since fvwm mail doesnt like my tablet gmail (html issue). > > Is there a way to get a precompiled 64 bit version? > Perhaps put one up on the site? > I check pkgs.org but I assume it'll be a long time before it hits there. You typically either compiler it yourself, or wait for your Linux distro/BSD variant to provide one. I personally won't support this outside of downstream packaging efforts. Kindly, Thomas
Re: FVWM: FVWM3-1.0.0 is released
Retrying from laptop since fvwm mail doesnt like my tablet gmail (html issue). Is there a way to get a precompiled 64 bit version? Perhaps put one up on the site? I check pkgs.org but I assume it'll be a long time before it hits there. Thanx
Re: FVWM: FVWM3-1.0.0 is released
On Thu, 3 Sep 2020 02:06:10 +0100 Thomas Adam wrote: > > It's not without its rough edges, but that's true of any software. > Even though I've called those out in the release notes, I consider > Fvwm3 now good enough for every day use. > I just want to report that virtual desktops still have the scrolling problem (at least on my system). Using the mouse, I can change VDs by scrolling right-to-left and up/down but moving left-to-right the scroll is broken. I can use the mouse to move an entire window left-to-right but simple scrolling left-to-right down not change the VD. For me at least, this is a show stopper since I switch VDs constantly. I am not using multiple monitors but only a single monitor and VDs. My config file is unaltered from fvwm-2.
Re: FVWM: FVWM3-1.0.0 is released
OpenBSD has an older fvwm installed in base. Licensing reasons. A newer fvwm2 is part of ports. So that's two different versions already available. Adding fvwm-3.X.X would really cause conflicts. I would much rather see fvwm2 and fvwm3. That avoids some tricky work making them both installable. As fvwm3 will diverge, I can easily see someone wanting a stable fvwm to use or go with a changing fvwm3. Multiple users are very likely to want two different versions. If you like your current setup, why require battling with configs? If you want changes, no problem with config changes. Everybody happy. There are already three flavors of fvwm available in ports right now, plus 1 installed with base system. Sure, the conflicts can be handled, but IMHO offering fvwm3 versus fvwm2 is easier for end users new to fvwm. Thanks for the hard work! Chris Bennett
Re: FVWM: FVWM3-1.0.0 is released
On Thu, Sep 3, 2020 at 1:15 PM Dominik Vogt wrote:
>
> On Thu, Sep 03, 2020 at 12:13:45PM -0600, Jaimos Skriletz wrote:
> > Creating two packages that live side by side is a far greater
> > challenge than initially anticipated. First there are a lot of other
> > binaries such as fvwm-root, fvwm-config, fvwm-menu-desktop, that would
> > conflict,
>
> Do these not get the --program-suffix? If not, that should be
> fixed.
>
It does work for the binaries. Just not the module manpages, which
share a common location, $PREFIX/man/man1
> > and though the --program-{prefix,suffix,transform-name} can
> > rename the binaries, this isn't the only conflict. The manpages for
> > all the common modules conflict and so does the translations/locales.
> > And none of these are affected by the --program-foo options.
>
> All right, but if these problems had been *reported* and not just
> silently dealt with in the distribution, they would have been
> fixed immediately back when the change from fvwm2 to fvwm was
> done.
>
I just adopted the package as it was, so I was unaware of this issue
until now. And the package only renames a single binary fvwm -> fvwm2
(then creates a link for fvwm), so at the time it wasn't an issue, as
it appears these other binaires were not part of fvwm 1.x.
The rest is all done in the fvwm1 package to ensure no conflict, which
someone else maintains. I did a little more research, the fvwm1
package in debian just renames all the manpages FvwmFoo.1.gz ->
FvwmFoo1.1.gz. This was probably done by Debian since at the time fvwm
1.x was no longer supported.
> > and locales,
>
> I don't know much about locales, but are they not installed in
> /usr/share/fvwm?
>
Locales are placed in $PREFIX/share/locale//LC_MESSAGES/, fvwm
has both a fvwm.mo and FvwmScript.mo that get placed in multiple
languages. I only know that the files are there and conflict, unsure
of if they can be renamed or any issues that would arise from that.
> > but even this isn't doable since there is
> > already differences in the modules in fvwm2 and fvwm3, mostly it is
> > the modules that are available, but FvwmPager has already received
> > some changes in options for the RandR per monitor setup.
>
> Is is acceptable to have man pages named
> FvwmModule in addition to the default names?
> If all else fails, the manpages could be put in separate packages.
>
As mentioned above, that appears to be what Debian's fvwm1 package is
doing. So it would be acceptable (only issue I can see is confusion on
the user if man FvwmButtons either didn't give a man page or a version
they weren't expecting, but the docs can explain this convention).
> > Currently, I'm just gonna to go with fvwm3 conflicts with fvwm2 and
> > only one of those can be installed at a time.
>
> I don't like this naming scheme that suggest the version number is
> part of the project name. Is naming them "fvwm", "fvwm-2",
> "fvwm-1" not an option?
>
It is an option, but it isn't how it is done now. Currently Debian has
two packages fvwm1 and fvwm. It seems to vary, some packages are
packagename-, and others are packagename to allow multiple
versions to be installed via multiple packages. I was just thinking of
being in line of what is currently in place.
jaimos
> Ciao
>
> Dominik ^_^ ^_^
>
> --
>
> Dominik Vogt
>
Re: FVWM: FVWM3-1.0.0 is released
On Thu 2020-09-03 20:14 , Dominik Vogt wrote: > On Thu, Sep 03, 2020 at 12:13:45PM -0600, Jaimos Skriletz wrote: [ ... stuff deleted ... ] > > Currently, I'm just gonna to go with fvwm3 conflicts with fvwm2 and > > only one of those can be installed at a time. > > I don't like this naming scheme that suggest the version number is > part of the project name. Is naming them "fvwm", "fvwm-2", > "fvwm-1" not an option? Such a naming scheme provides the user with an option to have multiple versions installed at once. Which does imho have certain practical value per se. In Fedora world, there are various exmaples of such approach, such as e.g. samba4, xmms2, or softwarecollections.org. I'm wondering whether there is a good reason not to go this way. m.
Re: FVWM: FVWM3-1.0.0 is released
On Thu, Sep 03, 2020 at 12:13:45PM -0600, Jaimos Skriletz wrote:
> I also see fvwm2 being used for quite a while even as fvwm3 matures.
Can we please stop calling the project "fvwm2" or "fvwm3". We've
renamed it to "fvwm" ages ago.
> Creating two packages that live side by side is a far greater
> challenge than initially anticipated. First there are a lot of other
> binaries such as fvwm-root, fvwm-config, fvwm-menu-desktop, that would
> conflict,
Do these not get the --program-suffix? If not, that should be
fixed.
> and though the --program-{prefix,suffix,transform-name} can
> rename the binaries, this isn't the only conflict. The manpages for
> all the common modules conflict and so does the translations/locales.
> And none of these are affected by the --program-foo options.
All right, but if these problems had been *reported* and not just
silently dealt with in the distribution, they would have been
fixed immediately back when the change from fvwm2 to fvwm was
done.
> I was thinking of maybe some fvwm-common package that would host the
> manpages
Applying the --program-suffix to the man page names should be
trivial to do in the Automakefiles.
> and locales,
I don't know much about locales, but are they not installed in
/usr/share/fvwm?
> but even this isn't doable since there is
> already differences in the modules in fvwm2 and fvwm3, mostly it is
> the modules that are available, but FvwmPager has already received
> some changes in options for the RandR per monitor setup.
Is is acceptable to have man pages named
FvwmModule in addition to the default names?
If all else fails, the manpages could be put in separate packages.
> Currently, I'm just gonna to go with fvwm3 conflicts with fvwm2 and
> only one of those can be installed at a time.
I don't like this naming scheme that suggest the version number is
part of the project name. Is naming them "fvwm", "fvwm-2",
"fvwm-1" not an option?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: FVWM: FVWM3-1.0.0 is released
On Thu, Sep 3, 2020 at 5:28 AM Martin Cermak wrote:
>
> On Thu 2020-09-03 09:49 , Dominik Vogt wrote:
> > On Thu, Sep 03, 2020 at 02:06:10AM +0100, Thomas Adam wrote:
> > > Well, we did it. Version 1.0.0 of Fvwm3 is now live and ready to be
> > > installed.
> >
> > Um, can we call that fvwm-3.0.0 instead of fvwm3-1.0.0 please?
> > Renaming the project because of a new major version was already a
> > mistake for fvwm-2.0.0. No reason to repeat it now.
>
> ( I was just thinking of creating a brand new package for fedora
> providing /usr/bin/fvwm3 able to coexist with /usr/bin/fvwm2 from
> the existing package. Might this make sense from the user
> perspective? Not sure ... )
>
I am trying to make a Debian package that lives side by side as well.
For many years, Debian's package renames the main binary from fvwm to
fvwm2 so fvwm1 and fvwm2 installable side by side, then uses their
alternative system to allow fvwm to point to either fvwm1 or fvwm2. It
would be nice to add fvwm3 to the list, and all three can be
installed.
I also see fvwm2 being used for quite a while even as fvwm3 matures.
It may not get updates, but I suspect (partly because it had one
recently) it will receive bug fixes to keep it buildable and usable
for the users who just want to stick to fvwm2, since as mentioned
there are still people maintaining (and I assume using) fvwm1. So
having it seperate may not be the issue it was at the last transition,
as after 20 years times have changed.
Creating two packages that live side by side is a far greater
challenge than initially anticipated. First there are a lot of other
binaries such as fvwm-root, fvwm-config, fvwm-menu-desktop, that would
conflict, and though the --program-{prefix,suffix,transform-name} can
rename the binaries, this isn't the only conflict. The manpages for
all the common modules conflict and so does the translations/locales.
And none of these are affected by the --program-foo options.
I was thinking of maybe some fvwm-common package that would host the
manpages and locales, but even this isn't doable since there is
already differences in the modules in fvwm2 and fvwm3, mostly it is
the modules that are available, but FvwmPager has already received
some changes in options for the RandR per monitor setup.
Currently, I'm just gonna to go with fvwm3 conflicts with fvwm2 and
only one of those can be installed at a time.
All in all it is nice to see something new, and hope that even after
quartiteen there is still enough time and effort to see where it
evolves.
jaimos
Re: FVWM: FVWM3-1.0.0 is released
On Thu, Sep 03, 2020 at 01:27:19PM +0100, Thomas Adam wrote: > It's a tricky one. Right now, things have not diverged because I haven't > implemented those changes. I'd always viewed Fvwm3 as being a departure from > Fvwm2 -- and hence any association with it at the moment as being equivalent > is just because it's lacking any breaking changes. It's also an easier > transition for any one wishing to try Fvwm3 who's previously used Fvwm2. > > That's one of the reasons why I went with version 1.0.0 -- Fvwm3 is going to > be separate from Fvwm2 over time, in that I'm not expecting to maintain > compatibility, and I wouldn't therefore want to mislead users with a false > version number. > > There may well be some overlap with Fvwm2 in terms of unchanged file names > (fvwm-config springs to mind), although I think for the most part Fvwm2 and > Fvwm3 can co-exist. I'll try and make the distinction better in future > releases, so that it's easier for package maintainers to allow Fvwm2 and Fvwm3 > to coexist. The exact same reasoning led to the "fvwm2" project, and it caused a whole lot of useless work to eventually clean up and rename it to fvwm again. The autotools can take care of having two versions installed in parallel (--program-suffix configure option). Distributors know how to use these options. And as far as I understand, nobody is going to maintain the 2.x version anyway. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: FVWM3-1.0.0 is released
On Thu, Sep 03, 2020 at 07:42:58AM -0400, Dan Espen wrote: > Martin Cermak writes: > > > On Thu 2020-09-03 09:49 , Dominik Vogt wrote: > >> On Thu, Sep 03, 2020 at 02:06:10AM +0100, Thomas Adam wrote: > >> > Well, we did it. Version 1.0.0 of Fvwm3 is now live and ready to be > >> > installed. > >> > >> Um, can we call that fvwm-3.0.0 instead of fvwm3-1.0.0 please? > >> Renaming the project because of a new major version was already a > >> mistake for fvwm-2.0.0. No reason to repeat it now. > > > > ( I was just thinking of creating a brand new package for fedora > > providing /usr/bin/fvwm3 able to coexist with /usr/bin/fvwm2 from > > the existing package. Might this make sense from the user > > perspective? Not sure ... ) > > Not sure how Thomas feels. > Fvwm3 was supposed to be largely incompatible with Fvwm2 hence the name > change. That hasn't occurred yet. It's a tricky one. Right now, things have not diverged because I haven't implemented those changes. I'd always viewed Fvwm3 as being a departure from Fvwm2 -- and hence any association with it at the moment as being equivalent is just because it's lacking any breaking changes. It's also an easier transition for any one wishing to try Fvwm3 who's previously used Fvwm2. That's one of the reasons why I went with version 1.0.0 -- Fvwm3 is going to be separate from Fvwm2 over time, in that I'm not expecting to maintain compatibility, and I wouldn't therefore want to mislead users with a false version number. There may well be some overlap with Fvwm2 in terms of unchanged file names (fvwm-config springs to mind), although I think for the most part Fvwm2 and Fvwm3 can co-exist. I'll try and make the distinction better in future releases, so that it's easier for package maintainers to allow Fvwm2 and Fvwm3 to coexist. Kindly, Thomas
Re: FVWM: FVWM3-1.0.0 is released
Martin Cermak writes: > On Thu 2020-09-03 09:49 , Dominik Vogt wrote: >> On Thu, Sep 03, 2020 at 02:06:10AM +0100, Thomas Adam wrote: >> > Well, we did it. Version 1.0.0 of Fvwm3 is now live and ready to be >> > installed. >> >> Um, can we call that fvwm-3.0.0 instead of fvwm3-1.0.0 please? >> Renaming the project because of a new major version was already a >> mistake for fvwm-2.0.0. No reason to repeat it now. > > ( I was just thinking of creating a brand new package for fedora > providing /usr/bin/fvwm3 able to coexist with /usr/bin/fvwm2 from > the existing package. Might this make sense from the user > perspective? Not sure ... ) Not sure how Thomas feels. Fvwm3 was supposed to be largely incompatible with Fvwm2 hence the name change. That hasn't occurred yet. -- Dan Espen
Re: FVWM: FVWM3-1.0.0 is released
On Thu 2020-09-03 09:49 , Dominik Vogt wrote: > On Thu, Sep 03, 2020 at 02:06:10AM +0100, Thomas Adam wrote: > > Well, we did it. Version 1.0.0 of Fvwm3 is now live and ready to be > > installed. > > Um, can we call that fvwm-3.0.0 instead of fvwm3-1.0.0 please? > Renaming the project because of a new major version was already a > mistake for fvwm-2.0.0. No reason to repeat it now. ( I was just thinking of creating a brand new package for fedora providing /usr/bin/fvwm3 able to coexist with /usr/bin/fvwm2 from the existing package. Might this make sense from the user perspective? Not sure ... ) m.
Re: FVWM: FVWM3-1.0.0 is released
On Thu, Sep 03, 2020 at 02:06:10AM +0100, Thomas Adam wrote: > Well, we did it. Version 1.0.0 of Fvwm3 is now live and ready to be > installed. Um, can we call that fvwm-3.0.0 instead of fvwm3-1.0.0 please? Renaming the project because of a new major version was already a mistake for fvwm-2.0.0. No reason to repeat it now. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Fvwm3-RC0 is released
On 9/1/20 2:20 AM, Thomas Adam wrote: Please do give this a try. See: https://github.com/fvwmorg/fvwm3/releases/tag/1.0.0-rc0 Cool, thanx very much. A slightly older version of fvwm can be found here, if you are interested: https://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/sources/usr.bin.X11/fvwm-0.91b.tar.gz The path in this URL is not correct; it is actually from 1993. See also this historic document: https://www.linux.co.cr/desktops/review/1993/0721.html. Regards Harri
Re: FVWM: Fvwm3-RC0 is released
On Tue, Sep 01, 2020 at 11:03:49AM -0500, Brian wrote: > There is one comment. On the Installation Instructinos page, under > Manually, the first sentence ends akwardly. Did you mean "core or > optional" or "core and optional" ? I believe you meant the latter that > both core and optional should be installed. Hmm, yes. That's very confusing. Not sure what I was thinking there. Thanks! Fixed now. -- Thomas
Re: FVWM: Fvwm3-RC0 is released
Thanks! I'll give it a shot this weekend. Been some 15 years of using fvwm now, so thanks for all your work! GI -- 'Smith & Wesson' -- The original point and click interface.
Re: FVWM: Fvwm3-RC0 is released
On Tue, Sep 01, 2020 at 11:29:12AM -0400, gi1242+f...@gmail.com wrote: > Very cool, thanks! Is there an upgrade guide/list of changes since > Fvwm2? I couldn't find it on the website. I've added some preliminary notes here: https://github.com/fvwmorg/fvwm3/releases/tag/1.0.0-rc0 > (I see that my current configuration will still work with fvwm3, > but I'm still slow to test it as it's critical for my daily work.) Understood. There shouldn't be any breaking changes. -- Thomas
Re: FVWM: Fvwm3-RC0 is released
Very cool, thanks! Is there an upgrade guide/list of changes since Fvwm2? I couldn't find it on the website. (I see that my current configuration will still work with fvwm3, but I'm still slow to test it as it's critical for my daily work.) GI -- When an actress saw her first strands of gray hair, she thought she'd dye.
Re: FVWM: FVWM3: RandR support ready for testing
On Saturday, 4. January 2020 16:29, Thomas Adam wrote: > What I'm hoping for right now is the bare-bones functionality of: > > - Correct screen detection (that is, correct number of physical screens) -- > this is currently printed to STDERR when FVWM3 starts up, so check there; Works. > - Commands such as MoveToScreen with a valid RandR monitor name works; Works. > - The 'Screen ' conditional works for All/Any/Current, etc I don't know how to test it. I have tried in FvwmConsole "All (Screen DP1) Iconify", but stderr says: [fvwm][CreateConditionMask]: <> Use comma instead of whitespace to separate conditions > - Monitors can be added/removed/changed, and FVWM3 shouldn't need a restart > to > pick up on any changes; If new monitor is added either before X login or with "xrandr --output eDP1 --mode 1920x1080 --primary --output DP1 --mode 2560x1440 --right-of eDP1 --noprimary" Half of the X apps windows opened on the new DP1 screen (okular, mate-terminal, xpdf, FvwmScripts) does not have focus (I'm using SloppyFocus policy). Gvim for example has the focus. Fvwm's "Restart" command solves this. Sometimes (before Restart), if I move mouse pointer outside unfocused window and then back in but only to the titlebar, it gets focus, but loses it when I proceed with mouse pointer from titlebar into the windows. Typing with keyboard on new nonprimary display is not posible in most of the X apps prior to Restart. Is this something known or should I open issue on github? > - FvwmIdent should report which monitor a specific window is on correctly Works. ... one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. -- Robert Firth
Re: FVWM: FVWM3: RandR quirks and solutions?
On Fri, Jan 10, 2020 at 05:20:07PM -0600, Brian wrote: > I know that Thomas is removing some redundant functions, I wonder if > fvwmform is one of them? That's correct. FvwmForm was removed in commit 7b8684385826d71b38be96f3c1a4e82c39aa4b38 > Fvwm manpages can always be contributed to the list and the development > team with review and determine if they belong in the repository. Help > with testing and writing are always appreciated. fvwm3.1 exists, and can be built with the --enable-mandoc option to ./configure -- this is not done automatically so you'll have to manually specofy it and ensure you've docbook and xslt, etc., installed. I am updating the documentation as I go, but that doesn't mean it's obvious where things are. FVWM has a long history and a surprisingly good amount of documentation which needs rationalising and made clearer. Patches welcome! Thomas
Re: FVWM: FVWM3: RandR support ready for testing
Can a (64 bit) compiled version be put in bin for those of use that don't have a compiler? I don't think theres much if any that are OS dependent. I just pull fvwm from whichever pkgs has the latest version and it works. I'm actually running puppy xenial. Thanx
