Announcement: NsCDE 2.0 released
Hi all, I just want to inform that I have finally released 2.0 which should be ok for packaging, and seamesly accepts FVWM 2 and 3. Here are release notes: https://github.com/NsCDE/NsCDE/blob/master/ReleaseNotes.txt ... and here a bit of pompous and shameless video propaganda. :-) https://www.youtube.com/playlist?list=PLpVwwj0aIJjcaTFrZ5FLokl-kAMwmBxux -- Hegel3DReloaded a.k.a. Miroslav
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Friday, December 17th, 2021 at 2:33 AM, Dominik Vogt wrote: > It uses the window's screen which has already been set by the time > the window is placed. Great. So this is the right fix. I have commented and closed https://github.com/fvwmorg/fvwm3/issues/648 -- Miroslav
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Friday, December 17th, 2021 at 1:38 AM, Dominik Vogt wrote: > Should be fixed now. > > However, I find it really annoying that screens now have to be > specified by name. Yes, now it works. So you replaced $[w.screen] with ... something as I see in git diff. Is it [c]urrent or is it aware if it should start on exact screen? > style xterm startsonscreen DVI-I-1 > is completely non-portable. Indeed it is. I can imagine after-pandemic situation where I go with notebook someware and connect it to monitor "DP-2" and this does not work because "DP-2" is not "DVI-I-1" nor HDMI1 ... I can imagine some translation table, where all non-primary monitors may be referred as left, top, right or bottom. StartsOnScreen p+1 for "right of primary" or p-1 for left and so on should be portable in a sense "ok FVWM, when there is setup where you have someting right of primary, do this with that window". -- Miroslav
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Friday, December 17th, 2021 at 1:18 AM, Dominik Vogt wrote: > When __pl_position_get_pos_simple() enconters a "center" argument > it replaces it with DEFAULT_PLACEMENT_POS_CENTER_STRING which is > defined to "screen $[w.screen] 50-50w 50-50w" as of commit id > 71c57858ffebdede86c2097464339b65b5742864: > > > PositionPlacement: include screen for Center > > When using "PositionPlacement Center", take into account the screen the > > window is on, so it's centered appropriately. > > Fixes #211 > This string is passed to GetMoveArguments() for interpretation. > However, $[w.screen] never gets expanded because that line is not > passed through the parser. FScreenGetScrRect() later looks for a > screen with the name "$[w.screen]", finds non and falls back to > the global monitor for placement (since a recent patch) but seems > to have used the "current" monitor before. > One way to fix this woud be to replace "$[w.screen]" with "c" for > the current screen, but that ignores the window's screen if > specified. Also, some places of the code expect screens specified > as "@g", " @c", "@p" while others use "g", "c" and "p". Are this latest examples for the "Move arguments"? G is global, c current, and p primary. I cannot find in docs what is the difference with or without '@'. Passing $[w.screen] to the parser is not an option in that part of the code? P. S. I'm too tired now. I will try to confirm tomorrow that it used 'c' before breaking explicit monitor placement in the current release. -- Miroslav
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Friday, December 17th, 2021 at 12:18 AM, Dominik Vogt wrote: > On Thu, Dec 16, 2021 at 07:18:23PM +0000, Hegel3DReloaded wrote: >> xrandr --output Virtual-1 --mode 1400x1050 --primary --output Virtual-2 >> --mode 1400x1050 --right-of Virtual-1 > And how do I get these virtual screens? Ok, I will describe my virtual environment in which I work and test. You need to have any Linux or *BSD system which supports Libvirt/KVM/qemu virtualization. I'm using Debian 11, and have whole virtual network of test virtual machines with various BSD, Linux and Solaris systems to test on. Additional virtual monitors are possible on virtual guests which have QXL kernel+Xorg driver, and spice protocol included into virtual machine definition. So nothing from BSD and OpenIndiana guests with multiple heads: they can only use legacy vesa driver. FreeBSD may have working QXL driver already, I don't know for sure. Your virtual guest needs to be recent Linux distro. Hardware host can be any system which can run Libvirt KVM Qemu. For a client, virt-manager's built in display is not capable of displaying mutliple monitors. You will need "remote-viewer" or similar spice protocol client. This is what I use. In virt-manager GUI, this are items "Display Spice", "Channel Spice" and "Video QXL" virtual hardware components. Configure "Display Spice" to have listen type "address", and choose some TCP port, like 5123/tcp. This is the point of remote-viewer connection (127.0.0.1:5123). Before starting virtual machine and connecting to it, there is one crucial thing virt-manager will NOT do for you: enable multiple monitor heads. You can do this by editing XML of VM guest before starting it. Edit with virsh(1), so you don't have to restart libvirtd(8). You will get "crontab -e" $VISUAL / $EDITOR like interface: virsh edit my-test-machine-1 Find section near the end of file, and change "heads" parameter from '1' to '4'. Increasing "vgamem" from 16386 to 32768 is also a good idea. This is from my testbox10 XML (also Debian 11 inside): virsh start my-test-machine-1 remote-viewer spice://localhost:5123 We are still not finished: When logged in, make sure you have spice-vdagentd daemon installed, up and running (spice-vdagent package), AND "spice-vdagent" client running as user from the X session. This will also allow you to move mouse in and out of guest window without Ctrl+Alt to release mouse. Now, you can choose from remote-viewer menu View -> Displays and enable display 2, display 3 ... Four is the maximum. Additional windows will appear empty, and when you run xrandr from the primary monitor, secondary will become alive. In that moment, you should make "Restart" of FVWM, because it still does not refresh and redraw everything in place. Your virtual RandR monitors will be called Virtual-0 and Virtual-1, or sometimes Virtual-1 and Virtual-2 ... depending on the virtual bus, slot, domain, function, kernel, moon at 7th house of Jupiter ... -- Miroslav
Re: [bug] Style PositionPlacement Center confused in multi monitor setup
On Thursday, December 16th, 2021 at 6:15 PM, Dominik Vogt wrote: > You forgot instructions to reproduce. I tought it was obvious, so in hurry I didn't described that. Here it is: Steps to reproduce with plain default FVWM setup: 1.Copy /share/fvwm3/default-config as ~/.fvwm 2.Edit ~/.fvwm/config, add Module FvwmMFL into StartFunction 3.Login to this session / start fvwm with this config 4.In one terminal window, enable the second screen and restart fvwm: xrandr --output Virtual-1 --mode 1400x1050 --primary --output Virtual-2 --mode 1400x1050 --right-of Virtual-1 FvwmCommand Restart Replace RandR names of the monitors above with you actual names. Then, configure xterm to have Style PositionPlacement Center and start it: FvwmCommand 'Style XTerm PositionPlacement Center' xterm & Xterm will appear between two monitors, in the real center instead of center of the current monitor. The same behaviour can be observer while calling Quit from the menu: Quit form will appear between two monitors. Latest release behaves well BTW.
[bug] Style PositionPlacement Center confused in multi monitor setup
Hi, I have opened an issue about PositionPlacement Center style: after the recent changes, in multi monitor mode, this centers window split between left and right monitor, while with latest fvwm3 release, this was not the case. Using dv/pager-noaspect where the current issues have been resolved couple days ago. It is repeatable on the current master. Here it is. together with the screenshot of the area between monitors. https://github.com/fvwmorg/fvwm3/issues/648 -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Monday, December 13th, 2021 at 12:17 PM, Dominik Vogt wrote: > On Mon, Dec 13, 2021 at 07:40:06AM +0000, Hegel3DReloaded wrote: > > > Yes, I fixed a leak at the cost of introducing a crash. > > > > I see. It is working now. May I close > > https://github.com/fvwmorg/fvwm3/issues/647 > > Ye, please. Closed. > > or you will do it with some description FTR? > Only if forced to. I'm not good with web tools. :-) Me niether, but to be honest, Github web is very responsive and without too much distractions if compared with some corporate shit I need to watch occasionally or equally bad so called "social networks". Thomas made really advanced automation system there. I will try to stick with this as much as I can; I have a feeling it can be fruitful and useful as project mgmt. -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Monday, December 13th, 2021 at 2:51 AM, Dominik Vogt wrote: > I've committed a patch to master that truncates out of range sizes > and positions to the max/min values instead of rejecting them. Yes, it is ok now. > Is there anything else in your config that's out of range? The X > protocol is limited to 16 bit values for positions (signed) and > window sizes (unsigned). I.e. -32768 to +32767 and 0 to 65535. It appears that on "Restart" Front Panel ends up in the +0 +0, upper left corner of the screen. It starts ok, it is placed at the bottom center part, but something relocates it in the last moment. I remember we had this problem often introduced and then fixed again. Now it seems that "All (FrontPanel,CirculateHit) PlaceAgain" is causing the problem. That is, it behaves differently that on fvwm3 1.0.4 and fvwm 2.6.9. It looks like PlaceAgain is ignoring Style for panel: PositionPlacement $[infostore.frontpanel.pos.placement] ... where infostore.frontpanel.pos.placement is "screen c 50-50w -0p ewmhiwa" hardcoding this in styles instead of infostore variable doesn't change this. A bit of more diagnostic: If I execute PlaceAgain with FvwmCommand from terminal in this branch, Front Panel (FvwmButtons) ends up on +0 +0. If I execute "Move screen c 50-50w -0p ewmhiwa" it ends up where it needs to be. > -32768 is probably the better choice for "out of view" windows. > Fvwm doesn't use negative coordinates. Thanks, I will make it like that. Now if I can only remember what I need to test, and what behaviour to expect from the FvwmPager. :-) I have set it up on two monitors now, and it looks consistent on the both screens with and without "Monitor" setting. When without "Monitor" setting, it shows both screens and it is horizontaly wide. I have tried with DeskTopScale too, it is ok. -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Monday, December 13th, 2021 at 2:14 AM, Dominik Vogt wrote: > On Mon, Dec 13, 2021 at 12:22:47AM +0000, Hegel3DReloaded wrote: > > Is this has something to do with intensive work you and Thomas did > > couple weeks ago with new parser? > > Yes, I fixed a leak at the cost of introducing a crash. I see. It is working now. May I close https://github.com/fvwmorg/fvwm3/issues/647 or you will do it with some description FTR? -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Monday, December 13th, 2021 at 1:12 AM, Dominik Vogt wrote: > On Sun, Dec 12, 2021 at 11:46:05PM +0000, Hegel3DReloaded wrote: > > Sorry to say, but I even didn't have a chance to start after trying to log > > in. > > It crashes badly. Something to do with malloc and pointers. > > Should be fixed. We need test cases for all this parsing code. > > :-/ Since I'm using FVWM as a framework, my heaveweight configuration often triggers things. I'm not trying to promote my work, but having one VM with NsCDE and trying to run new FVWM code with it's setup can be a good "stress test". See my second mail on FvwmPager issue. It seems also as parsing issue: looks like window context for "Move" is lost. > I'm not very happy with the "new" monitor handling code. It added > potentially broken new parsing code all over the place. That > should really be done in a single, well tested parser. At the > moment we have a myriad of places where parsing is done, and its > very tedious to even execute all code paths. Is this has something to do with intensive work you and Thomas did couple weeks ago with new parser? -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Monday, December 13th, 2021 at 12:46 AM, Hegel3DReloaded wrote: > On Sunday, December 12th, 2021 at 12:40 PM, Dominik Vogt dominik.v...@gmx.de > wrote: > > The dv/pager-noaspect should work now, but I've not tested it with > > multiple monitors. I have found temporary workaround to comment out definition of my complex function f_SetFvwm3NonGlobalBackground[1] which triggers this crash. Now I have iteresting behaviour with my "Local" pager even before I started to test: when Local pager does not posess pointer, it should disappear by the means of "Move +32768p +32768p", but instead of doing this, it changes my pointer into cross, GeometryWindow appears, and expects from me to move pager around! :-) It seems to me it looses the window X11 resource context of "LocalPager" [1] Schedule Periodic $[infostore.rootpagertimeout] 131313 All (LocalPager, CirculateHit, !HasPointer, !State 6) f_HideLocalPager For a reference, everything work fine with latest 1.0.4 release, and 2.6.9. [1] https://github.com/NsCDE/NsCDE/blob/master/data/fvwm/Functions.fvwmconf.in -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Sunday, December 12th, 2021 at 12:40 PM, Dominik Vogt wrote: > On Sat, Dec 04, 2021 at 02:04:48PM +0000, Hegel3DReloaded wrote: >> Sounds ok. Which branch should I checkout to test this? > The dv/pager-noaspect should work now, but I've not tested it with > multiple monitors. Hi Dominik, Sorry to say, but I even didn't have a chance to start after trying to log in. It crashes badly. Something to do with malloc and pointers. I have opened issue here: https://github.com/fvwmorg/fvwm3/issues/647 When we get pass this point, I will test the rest you wrote. BTW, I'm actually using one big monitor, but when testing multiple monitors setup, I'm helping myself with KVM/Qemu virtual machines with virtual monitors. The crash mentioned above was still in a single monitor setup. I didn't get very far. -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Sat, Dec 04, 2021 at 02:13:06PM +0100, Dominik Vogt wrote: >> On Sat, Dec 04, 2021 at 02:03:46PM +0100, Dominik Vogt wrote: >> Maybe the scaling argument can be set to "auto" or something to >> keep the desktopscale within reasonable limits? (The example with >> desktopsize 50x1 earlkier in the discussion showed that the pager >> currently does not have a reasonable scaling algorithm). >> Maybe something like this by default? >> desktopscale auto [max%] >> "auto" means to make the pager consume "max%" of the desktop width >> and height. The default would be "auto 10" or something, so (a) >> by default the pager autoscales and (b) it always consumes 10% of >> the screen size in one direction and no more than 10% in the other >> direction. > Experimental patch attached (only initial size calculation; no > live resizing yet). Sounds ok. Which branch should I checkout to test this? -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Saturday, December 4th, 2021 at 11:39 AM, Dominik Vogt wrote: > Okay, that is a real problem. The pager definitely needs to react > to changes of the desktop layout, be it by attaching or detaching > monitors at run time or by issuing the desktopsize command. > > The pager should fix that situation itself and not expect the fvwm > core to do it. There are two cases and multiple possible ways to deal > with it: > > 1) Pager is using a user specified geometry: > >a) Stick with the user specified size. >b) Resize the window proportionally. > > 2) Pager is using the calculated default size: > >a) Recalculate total size and use that. >b) Resize the window proportionally but try to keep it close > to the current one; at least don't make it much bigger or > smaller. > > The module interface provides the information necessary to > implement that. > > Would 1a + 2b be sensible default behaviour? By "calculated default size" do you mean DeskTopScale FvwmPager config paremater? If yes, then I think yes, 1a if user said so with Geometry parameter, no matter what we think of this. 2b is a bit of gray area. I can imagine some border cases where huge change of resolution or attaching notebook to the 3 monitors in a row docking station in mode where FvwmPager doesn't have "Monitor" config directive can give odd results. If 2b will have logic or more precisely heuristics similar to this: "if I need to grow more than twice my current size in X or Y direction, apply some divisor to make it a bit less space hungry (the result to be 1.5 instead of 2 for example), if size is more than 4 times, apply even bigger divisor, and the last safety which should never be hit unless you emit your screen on some open space expensive concert screen wall with insane resolution, stop growing if the resulting pager will be bigger then XY in proportion to $[vp.width] and/or $[vp.height]". This can be tested in KVM/qemu xrandr changing sharply from 1024x768 to 2560x1440 for example, and with configuring RandR to have 3-4 Virtual monitors in one row. -- Miroslav
Re: Rename back to fvwm.
On Saturday, December 4th, 2021 at 11:00 AM, Dominik Vogt wrote: > Fvwm is the only project I'm aware of that changes its name with > each major version. Let's _please_ go back to "fvwm" and replace > the 1.x versioning scheme with 3.x. Automake + autoconf can deal > with renaming executables if distros need that. Both versions use > the same config files anyway. You cannot have version 2 and 3 > installed at the same time using the default config file. > Some people still insist on calling fvwm-2.6.x "fvwm2". Why? The > name has been "fvwm" officially since April 2002. > The name split caused extra work and confusion back in ancient > times. The same thing will happen again. As much as I may agree with this opinion, I think this shouldn't be performed now when it is already fvwm3 for a longer time. It is already packaging that way, and by trying to fix this can cause counter effect, that is, introduce even more confusion. As of old confusion, it will be here forever. Some Linux distros are packaging FVWM 2.X as "fvwm2", and some BSD variants are even shipping with ancient fvwm1 in the base, and providing "fvwm2" from the ports. Weather main binary is called "fvwm" or "fvwm2", or having the same name, one beeing in /usr/bin, the other in /usr/local/bin or wherever is the current case. It is not really a horror, but having something that started as "fvwm3" as a name, going back to fvwm-3.X will be really another level of confusion on the top of this "mild" confusion mentioned above. As they were packing fvwm1 or fvwm, fvwm or fvwm2, let them pack fvwm3 I say. And last but not least, it is not som much the name IMHO, as about quality and the power this wonderful piece of software gives to those who know how to appreciate this. Just my 2 cents ... -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Wednesday, December 1st, 2021 at 2:13 AM, Dominik Vogt wrote: > On Tue, Nov 30, 2021 at 02:51:49PM +0000, Hegel3DReloaded wrote: >> Maybe having ctrl+mouse-resize as I proposed above? > Okay, I can imagine rare cases when one wants to re-enforce a > multiple of the original aspect ratio, and I'd be fine with > another key combination to force it. However, what are we > supposed to do with windows with a legitimate, fulltime aspect > ratio like mplayer? It would be very inconvenient to have the a. > r. ignored by default. Unfortunately I see no working heuristics > to tell a "hard" a. r. from a "hint". Sorry, I got confused here. I thought this is exclusively about FvwmPager's behaviour. Not other cases (video players), where you rightly say that aspect ratio does make a sense. Yes, there are some cases, or rather there will be them in FVWM3 when it will approach the point where resolution change, or new monitor addition will not mandate fvwm restart to get things in place. In this case, FvwmPager can end up smaller or bigger than wanted. I think shift+mouse-move, or configuration option for preserving aspect ratio makes a sense. >> the are made big enough by dinamically following screen resolution, > Isn't that what everybody does - give it a good default size and > that's it? Well, for me, it is ok, but having in mind how many people with their original ideas of behaviour of things use FVWM, that is, FVWM's native user base are really demanding users, I can imagine someone using this on daily basis, and wanting to have it preserve screen size, not trying to do it manually as much as they can visually. > What kind of use case is that; someone thinks the current size is > too small and wants to make it 50% bigger? Or the pager is in the > way, and instead of closing, lowering, shading, iconifying or > sending it to some container one makes the window smaller? What is > so special about the pager that it I don't know if you sent this mail prematurely, or the crappy mail service's web that I choose cutted it here, but "pager that it" is the last I see from your text. :-\ To answer: You are right for the other case when pager is on the way. All actions you enumerated have more sense than resizing it. But the first one can really be the issue. I remember once, a year ago, I had debugging session with Thomas and shared my screen. Pager was important during this problem, because state if windows on multiscreen was not the same as in pager. In one moment, Thomas asked me can I make my "Local" pager bigger, that it will be easier to work. So I resized it. -- Miroslav
Re: Removig the "Emulate" command
On Thursday, December 2nd, 2021 at 2:14 PM, Dominik Vogt wrote: > The command > > emulate mwm > > has almost no effect. I'd like to remove it. There are only > three things it controls: > > 1) The geometry window during move and resize is hard coded to the >center of the screen. > >=> Give the window it's coordinates explicitly. > > 2) During an interactive placement, to tell fvwm that you want to >resize the window after placement: > mwm mode: press shift + button 1 > fvwm mode: press button 2 > >=> Just allow both. > > 3) Some weirdness about initial drawing of the wire frame. > >=> Remove that special case. It makes zero sense. > > Opinions? Hi, As Jaimos said, geometry window is configurable via new GeometryWindow Position directive, the second one is really not something generally known, and making it both ways doesn't break anything. Weirdness about initial drawing of the wire frame ... I cannot see any difference here. I don't know how it differs. Looks like removal of "Emulate" it doesn't break anything. It can be even conditionally defined like GeometryWindow in configurations which have to support both FVWM2 and FVWM3. -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
Hi all, On Tuesday, November 30th, 2021 at 2:57 PM, Dominik Vogt wrote: > Still, what is the benefit of having an aspect ratio set? For a non-swallowed floating FvwmPager, I think it makes a sense that screen aspect ratio is preserved in it's smaller representation. Like: 16:10, 16:9, 4:3 etc ... For example, I like to use 4x4 matrix: 4 desks, 4 pages each. For removing constraint of minimal size, I agree that FvwmPager should not impose restrictions. 2-4 pixels maybe, but not 100x100. > The situation is: > 1. It's implementation is more or less broken everywhere. => > Nobody uses it. > 2. If the ratio is not close to 1, it's outright annoying or even > unusable. Try this: > > desktopsize 50x1 > FvwmPager > all (FvwmPager) move 0 50 > a) Grab the top border and resize it by moving the pointer. > => Maximum height stops around "WidthX412" because the width > automatically grows bacause af the aspect ratio, but can > not get bigger than 32767. > BAD Since the ways of using FvwmPager are so different between people's ideas how to set it up, I think that having the opportunity to configure keeping aspect ratio makes a sense. Those who are using 50x1 DesktopSize will of course not use that obviously, but people who use 2x2, 3x2, 2x3, 4x2 and similar and not having it swallowed inside FvwmButtons may prefer to keep aspect ratio. There can even be here a solution like in drawing programs: you press Ctrl or Shift while resizing the object to keep aspect ratio, otherwise, it is free form. [...] > Summary: There are a lot of quirks and bugs. Is there any gain > in usability to make up for this? Maybe having ctrl+mouse-resize as I proposed above? > > But in terms of configurability, I still think an option > > where the user can decide to preserve the aspect ratio when resizing > > the window or not allows the most freedom for users. > But why would anybody want that? Does anybody really use a > standalone pager, and if so, ever resizes it? I'm using 3 kinds of standalone FvwmPagers - "Local" Pager - showing only the current desk - "Desk" Pager - showing what is on the non-current desk I select on the Front Panel - "Global" Pager - all desks and pages They are floating semi-transient objects. That is, having them transient is not enough for me, so they quickly disappear by Schedule if they don't posess the pointer. I don't really resize them, the are made big enough by dinamically following screen resolution, but it will be nice if we can somehow keep aspect ratio in a sense: "this is my monitor in small". -- Miroslav
