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 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 lan
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-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
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: Resizing BarButtons based on display size
On 01/05/18 01:43, Thomas Adam wrote: > On Sun, Apr 29, 2018 at 12:04:49PM +1000, Stuart Longland wrote: >> This works, but I wonder if there's a more elegant way. Is it possible >> to grab the screen size in the .fvwmrc and do the required arithmetic >> for deriving Geometry? > > $[vp.width] > > Then use PipeRead to do whatever you need to do withit. Ahh brilliant, I take it there isn't a way to subtract a number off that without using PipeRead? -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
FVWM: Resizing BarButtons based on display size
Hi all,
This is a bit of a silly question. I have a FVWM config that's about 10
years old now that I set up to be largely keyboard oriented and maximise
screen real-estate.
For system status and a calendar, I have a BarButtons instance on the
right-hand side of the display which I can call up by hitting Logo, Z.
The problem is every time I've moved to a new machine, I have to edit
the config file to appropriately dimension the panel.
I want the panel to be the full height of the display, minus the height
of the task bar (now, fbpanel; since FVWM have dropped FVWMTaskBar).
Right now I have this:
> DestroyModuleConfig BarButtons: *
> *BarButtons: Fore Black
> *BarButtons: Back #cc
> *BarButtons: Font
> "xft:sans-serif:Bold:pixelsize=10;-*-helvetica-bold-r-*-*-10-*-*-*-*-*-*-*"
> # Geometry - really likes to pick its own size, but giving a position is OK
> # Warning: I've added a size geometry to avoid pbs if the fvwm_icons are
> # not in the image path ! Remove the size in this geometry especially if
> # you add buttons
> #*BarButtons: Geometry 250x568-0+24
> PipeRead "${HOME}/.fvwm/position-barbuttons.sh"
with the script containing this:
> #!/bin/sh
>
> printf '*BarButtons: Geometry 250x%d-0+24\n' $(( \
> $( xdpyinfo | sed -ne \
> '/dimensions/ { s/^.*: \+[0-9]\+x\([0-9]\+\) .*$/\1/; p }' ) -
> 24 ))
This works, but I wonder if there's a more elegant way. Is it possible
to grab the screen size in the .fvwmrc and do the required arithmetic
for deriving Geometry?
Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
signature.asc
Description: OpenPGP digital signature
Re: FVWM: garbled screen for big outputs
On 21/09/17 18:30, Pierre Frenkiel wrote: > On Sun, 18 Sep 2017, E Frank Ball wrote: >> Try xterm, or rxvt, or gnome-terminal > >thanks Frank, and also Dan , for your suggestions, but >the problem is actually with xterm. >I also tried with rxvt: it's worse. >Withe kde x-terminal-emulator, no problem. That would be Konsole, unless they've made a new one. >Here are the results of different tests > >==> xterm -geometry 100x40+0+70 -ls good >==> xterm -geometry 120x40+0+70 -ls garbled screen > >==> rxvt -geometry 80x40+0+70 -ls good >==> rxvt -geometry 100x40+0+70 -lsgarbled screen > > It looks like a bug, and I think I'll do a bug report, unless somebody > suggests something else. I'd be suspicious of the video drivers… perhaps Xlib (xterm, rxvt?) is triggering some bug in the video driver that Qt (Konsole) isn't. qterminal is another Qt-based terminal emulator that might confirm whether the widget set is having an effect. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: FVWM: pull requests
On 23/10/16 02:54, Thomas Adam wrote:
> On Sat, Oct 22, 2016 at 05:11:46PM +0100, Dominik Vogt wrote:
>> > Yes, but that's actually not the part I was asking about. How the
>> > "git pull-request" should look like is not in the docs.
> OK. For that, you'd have to use their web interface. See:
>
> https://help.github.com/articles/about-pull-requests/
`git merge --no-ff ${BRANCH}` seems to be more-or-less equivalent.
Is there going to be some sort of naming and usage convention around
branches, e.g. like Git flow¹? Or is 'master' where the action happens?
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
1. http://nvie.com/posts/a-successful-git-branching-model/
Re: FVWM: reading a split configuration file
On 05/12/13 20:45, bastian-fvwm-org-20121...@t6l.de wrote: If you need alphabetical order try: PipeRead 'for i in $(echo $HOME/.fvwm/*.fvwm | sort) ; do echo Read $i; done' Or even: PipeRead `ls -1 $HOME/.fvwm/*.fvwm | while read i; do echo Read $i; done` More than one way to skin this cat. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
