Re: FVWM: The Future of fvwm Development
On Fri, 11 Nov 2016 23:13:49 + Thomas Adam wrote: > Hello all, > > For those of you who follow fvwm-workers@ may already know some of > this, but for those of you who don't, it's worth mentioning what the > state of fvwm development holds for the future. > > We have been discussing a lot about how we're able to make changes to > fvwm without breaking it for everyone. As many will know doubt know, > fvwm is well-over twenty years old and in some cases it shows, too! > Trying to bring fvwm up to date with newer technologies, and to even > make small improvements has a very high barrier to entry, especially > when trying to maintain backwards compatibility. Over the years, we've > had a loyal number of users who have come to rely on a lot of nuances > and behaviour which we don't necessarily want to take away. > > To that end, the latest stable release (2.6.7) marks the end of the > line for fvwm2. This release is unique because it was my opportunity > to remove all of the modules which I thought were no longer providing > anything useful (because the functionality no longer exists outside of > fvwm in certain applications, or because more widely-used modules in > fvwm provided equivalent/better funtionality). Indeed, this releases > also includes a new default configuration. I hope you find it useful. > > But I suppose it's fair to say that 2.6.7 won't necessarily appeal to > some of the dyed-in-the-wool types for whom changes is too much, and/or > cannot live with that really old module which works Just Fine (tm) as > it is. Well, that's OK as well, since we also have everything as it > was before on the 'fvwm2-stable' branch. So if you want to use things > like FvwmTaskBar, for example, that's the release you should use. This > branch may, occasionally, receive bug-fixes over time, but certainly > nothing else. > > In fact, I'm not envisaging any further work happening on fvwm2.X at > all. So what does this mean for fvwm? In order for us to continue to > make larger changes, we need to be able to break backwards > compatibility and to make a lot of structural changes. All of this > goes towards a lot of other changes we'd like to make. This therefore > means that we will look at fvwm3 to do this. This will be different to > fvwm2. > > We're in the process of setting up fvwm3, and there'll be additional > announcements when this is complete. > > For a reference on the releases, see the following: > > https://github.com/fvwmorg/fvwm#releases > > Any questions, do please ask. > > Kindly, > Thomas Adam > Not so much a question as a comment. Many window managers and desktop environments have tried in vain to create an automatic menu generator without success, I recommend that fvwm does not attempt to do this, they break very easily over time. Also, please retain the win95 configuration script, in fact, they ability to run a simple script to generate a few different common configurations is a strong point of many WMs. Thanks, David
Re: FVWM: The Future of fvwm Development
On Wed, Nov 16, 2016 at 4:43 PM, David Niklas wrote: > On Fri, 11 Nov 2016 23:13:49 + > > Not so much a question as a comment. > Many window managers and desktop environments have tried in vain to create > an automatic menu generator without success, I recommend that fvwm does > not attempt to do this, they break very easily over time. > Fvwm already provides such ability. The core of fvwm provides users with a configuration syntax to build menus and fvwm also provides a way for things to be scripted. So really an automatic menu generator is just a script that outputs the configuration syntax of fvwm. Within the core of fvwm is the method to build menus using the configuration syntax (which is one of the things that is planed to change in the future of fvwm) and create some sort of menu object that fvwm displays to the user. Independent of that is the ability to write scripts to generate menus. These can be from simple shell scripts, for i in wallpappers/*.jpg; do ... to build a wallpaper menu as mentioned in the manpage, to more complicated perl and now python scripts: fvwm-menu-desktop, fvwm-menu-directory, fvwm-menu-headlines and fvwm-menu-xlock are all scripts provided by fvwm. On top of that you can write you own scripts to automatically generate menus on your system. So this ability is already there and I think done in a nice way. In the core it is just the ability to configure menus (including dynamic ones that are generated when they are opened) and via fvwms ability to work with scripts, you can additionally use a script to generate menus. Yes the scripts sometimes break and need updated, but they are not internal to fvwm and are only optional for those who want to use them (and maybe fix them when standards evolve). > Also, please retain the win95 configuration script, in fact, they ability > to run a simple script to generate a few different common configurations > is a strong point of many WMs. > This is already gone. Fvwm now provides a default config as a starting point for users who don't want to write one from scratch. But Fvwm is more a wm that provides a user with the ability to configure their own setup. Examples are probably better given through some other means, such as the wiki. jaimos
Re: FVWM: The Future of fvwm Development
On Fri, Nov 18, 2016 at 12:18:15PM -0700, Jaimos Skriletz wrote: > On Wed, Nov 16, 2016 at 4:43 PM, David Niklas wrote: > > On Fri, 11 Nov 2016 23:13:49 + > > > > Not so much a question as a comment. > > Many window managers and desktop environments have tried in vain to create > > an automatic menu generator without success, I recommend that fvwm does > > not attempt to do this, they break very easily over time. > > > > Fvwm already provides such ability. The core of fvwm provides users with a > configuration syntax to build menus and fvwm also provides a way for things > to be scripted. So really an automatic menu generator is just a script that > outputs the configuration syntax of fvwm. > > Within the core of fvwm is the method to build menus using the configuration > syntax (which is one of the things that is planed to change in the future of > fvwm) and create some sort of menu object that fvwm displays to the user. > > Independent of that is the ability to write scripts to generate menus. These > can be from simple shell scripts, for i in wallpappers/*.jpg; do ... to build > a > wallpaper menu as mentioned in the manpage, to more complicated perl > and now python scripts: fvwm-menu-desktop, fvwm-menu-directory, > fvwm-menu-headlines and fvwm-menu-xlock are all scripts provided by fvwm. > On top of that you can write you own scripts to automatically generate menus > on your system. > > So this ability is already there and I think done in a nice way. Thanks, it's nice to see that people appreciate this work, and that MissingSubmenuFunction and DynamicPopupAction still work as they should as they always have. It war certainly fun to code. :-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
A short update: Version 6.0.6 requires an old kernel, version 12.5 is downloading now (which is a matter of several hours given the local internet speed). I'll have to find some 64-bit box to run it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: The Future of fvwm Development
On 19/11/16 06:22, Dominik Vogt wrote: > It war certainly fun to code. :-) ^ And a fight to debug? ;-) -- 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: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
> A short update: Version 6.0.6 requires an old kernel, version > 12.5 is downloading now (which is a matter of several hours given > the local internet speed). Sorry, I should have mentioned that this might be an issue. Each version of Vmware Workstation or Player supports only very few versions of the Linux kernel. (This has the very annoying consequence that one has to purchase a new license every few kernel updates.) For a rough orientation, Vmware offers the following compatibility map on their web page: http://kb.vmware.com/kb/2088579 It maps supported Linux distributions for each version of Vmware Workstation. (Unfortunately they don't list kernel versions, only versions of distributions.) To use that list for Vmware Player, one has to know that its version numbers differ from those of the corresponding Workstation counterpart. While I didn't find it documented in a closed form anywhere, I guessed the following correspondences from gossips in the web (they might be false): Player 4 <-> Workstation 8 supp. kernel 2.6.18 to 2.6.37 Player 5 <-> Workstation 9 supp. kernel 2.6.37 Player 6 <-> Workstation 10 supp. kernel 3.1.0 to 3.11.6 Player 7 <-> Workstation 11 supp. kernel 3.7.10 to 3.18 Player 12 <-> Workstation 12 supp. kernel 3.7.10 to 4.7 In addition, the compatibility to a given kernel strongly depends on the sub-version of the Vmware product. > I'll have to find some 64-bit box to run it. If I can assist you in some way, please let me know. Juergen
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
On Fri, Nov 18, 2016 at 10:33:20PM +, Jürgen Hartmann wrote: > > A short update: Version 6.0.6 requires an old kernel, version > > 12.5 is downloading now (which is a matter of several hours given > > the local internet speed). > > Player 6 <-> Workstation 10 supp. kernel 3.1.0 to 3.11.6 Ah, good, with 3.10, it runs now. So, runnig a virtual machine with no OS now, and it tries to get a config over DHCP. 1. Move cursor to menu bar of the vm window. 2. Press ctrl-alt-enter => goes to fullscreen mode. 3. Press ctrl-alt-enter => window vanishes, the keyboard is still grabbed, but the mouse os not. It's not possible to type commands. 4. Press ctrl-alt-enter => window comes back in window mode. The keyboard is still grabbed, but the mouse is not, so it can be used to interact with fvwm. 5. Move the pointer to the menu bar and press "X" => the keyboard grab is released. Is 3 what you mean? Is there a way to have this window vanish but not hold the keyboard grab? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
It turns out that the below patch from 2007 has broken it. Now if anybody knows where the mailing list archive has gone and how to find the thread related to this patch ... For the time being you can circumvent the problem by removing the whole if ( FCheckIfEvent( dpy, &dummy, test_withdraw_request, (XPointer)&args)) { ... } from HandleMapRequestKeepRaised. -- commit 31fcfe2130b9c3d10fd7618d4c65290b42f64f11 Author: griph AuthorDate: Mon Dec 3 20:22:23 2007 + Commit: griph CommitDate: Mon Dec 3 20:22:23 2007 + * don't map new windows that have a pending ICCCM2 request to go into WithdrawnState (synthetic UnmapNotify) --- fvwm/events.c | 43 +++ 1 file changed, 43 insertions(+) diff --git a/fvwm/events.c b/fvwm/events.c index 65e194f..e51421e 100644 --- a/fvwm/events.c +++ b/fvwm/events.c @@ -228,6 +228,33 @@ static Bool test_map_request( return rc; } +/* Test for ICCCM2 withdraw requests by syntetic events on the root window */ +static Bool test_withdraw_request( + Display *display, XEvent *event, XPointer arg) +{ + check_if_event_args *cie_args; + Bool rc; + + cie_args = (check_if_event_args *)arg; + cie_args->ret_does_match = False; + if (event->type == UnmapNotify && + event->xunmap.window == cie_args->w && + event->xany.send_event == True && +event->xunmap.event == FW_W(&Scr.FvwmRoot)) + { + cie_args->ret_type = UnmapNotify; + cie_args->ret_does_match = True; + rc = cie_args->do_return_true; + } + else + { + cie_args->ret_type = 0; + rc = False; + } + + return rc; +} + Bool test_button_event( Display *display, XEvent *event, XPointer arg) { @@ -2897,6 +2924,22 @@ void HandleMapRequestKeepRaised( /* If the window has never been mapped before ... */ if (!fw || (fw && DO_REUSE_DESTROYED(fw))) { + Bool is_unmap_request_pending; + check_if_event_args args; + XEvent dummy; + + args.w = ew; + args.do_return_true = True; + args.do_return_true_cr = False; + if ( + FCheckIfEvent( + dpy, &dummy, test_withdraw_request, + (XPointer)&args)) { + /* The window is moved back to the WitdrawnState +* immideately. Don't map it. */ + return; + } + /* Add decorations. */ fw = AddWindow(ea->exc, ReuseWin, win_opts); if (fw == AW_NO_WINDOW) Ciao Dominik ^_^ ^_^ -- Dominik Vogt