Re: FVWM: The Future of fvwm Development

[David Niklas]

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

[Jaimos Skriletz]

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

[Dominik Vogt]

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

[Dominik Vogt]

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

[Stuart Longland]

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

[Jürgen Hartmann]

> 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

[Dominik Vogt]

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

[Dominik Vogt]

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