FVWM3: A call for testing

General News
1

Hi all,

FVWM3 is coming along nicely. My time has mostly been spent working on getting FVWM3 playing nicely with multi-monitor setups. This means:

  • Detecting when a monitor is plugged in;
  • Detecting when a monitor is unplugged;
  • Giving the option to allow for desks/pages to be independent of each monitor;

All of this assumes that libxrandr-dev is installed, and that the version of RandR is >=1.5 – this is because I make use of the XRRGetMonitors() function which isn’t present in versions of RandR < 1.5, but 1.5 has been out for over three years, so I’m not too worried about compatability.

Presently, all of the above is largely still a work-in-progress, but I’ve made some strides in this such that I consider this to be functional enough that I need as much testing and feedback as I can get.

All of this work is currently on a branch called ta/gh-22 – which originally was born out of Github issue #22 but I’ve now bundled way too much in there. Anyway, you can see that here.

This is the branch you should checkout and compile FVWM3 for.

The default behaviour for multiple monitors (if RandR is in use) is for them to all be treated as one global screen – the same behaviour as what Xinerama used to provide.

To change to having independent desktops per monitor, a command called DesktopConfiguration has been created and accepts two values:

  • DesktopConfiguration global – all screens/desktops work as one`
  • DesktopConfiguration per-monitor – desktops are independent per screen

This can be added to FVWM’s configuration file, as well as being a toggleable command via FvwmConsole.

As per the commentary in GitHub issue #22, there’s on-going discussions, but I could do with more people testing that branch, and trying out the multi-monitor aspect.

Please spread the word, and to open issues or ask questions here – I don’t mind. But the more eyeballs I have on this, the easier it will be to fix bugs, and to get us closer to a release of version 1.0

At this point, FVWM3 will honour your existing .fvwm2rc file, as there’s no breaking changes, save for the new commands in FVWM3 which you’d need to add.

On the subject of releasing FVWM3, I’ve set up a project board which shows the things I need to do before that can happen. If anyone wishes to help with that – get in touch!

Thanks all,
Thomas Adam

3

Hi all,

Just following up from the first post above…

Github issue #24 has now been closed and merged to master – so please give master a good test. The advice around DesktopConfiguration still stands; any/all testing anyone wants to do is still very much welcomed!

From my own day-to-day usage as well as some fantastic help from @NsCDE (I can’t thank him enough for the testing he’s done), we think the behaviour of per-monitor and global seems to work as intended.

But, keep testing please!

Thomas

4

Hi,

Further to this, I’ve put together an immediate list of things I’d like tested before any release-candidate can be considered.

Here’s the list: https://github.com/fvwmorg/fvwm3/issues/65

Any and all testing is appreciated, with feedback!

Thanks again,
Thomas

5

Hi all,

I’ve merged more things to master today:

  1. Made the EWMHBaseStruts command per-monitor aware. This means you can do things like:
    • EWMHBaseStruts 0 0 0 0 (global for all monitors);
    • EWMHBAseStruts screen Virtual-1 100 100 100 0 (just changes Virtual-1)
    • Note: this does not imply DesktopConfiguration per-monitor, it will work regardless.

This change was in response to some bugs reported, but now means that windows dragged between different monitor resolutions should maximize correctly to fill that space. I’m hoping this also works for higher DPI displays as well.

  1. Changed the behaviour of unmaximizing a window. Per my commit message:

When moving a maximized window between pages or screens, FVWM records the previous geometry of the unmaximized window, so it can restore correctly.

However, this doesn’t work well when the maximized window itself has moved between screens or different pages, since the unmaximized geometry from the point of view of the maximized window is now incorrect. Subsequently, unmaximizing a window will put that window in to the ether.

For now, the approach is to make unmaximizing a window imply MoveToScreen (relative to the window’s screen) such that it remains visible, and should largely do what the user expects.

So I’m hoping we won’t see any more unmaximized windows vanishing.

Thanks all for your continued testing and support!

Thomas

6

Hi all,

More updates on master

  • A few more bug-fixes.
  • FvwmEvent now understands and listens for RandR events:
    • monitor_enabled – when a new monitor is attached;
    • monitor_disabled – when a monitor is detached;
    • monitor_changed – when a monitor is already attached and changes resolution, etc.

Here’s an example taken from man FvwmEvent:

                  DestroyFunc MonitorExample
                   AddToFunc   MonitorExample
                   + I Echo "Monitor $0 changed ($[monitor.$0.width] x $[monitor.$0.height])

                   *FvwmEvent: monitor_changed MonitorExample

Test welcome. Any problems, please open issues on Github:

Thanks all,
Thomas

7

Hi,

I’ve just merged a PR to master which adds some additional changes to FvwmPager and multiple monitors.

To configure FvwmPager instances to limit them to a specific monitor, you must now issue the following configuration line:

*FvwmPager: Monitor RandRName

Where FvwmPager is the module configuration alias you’re using for FvwmPager, and RandRName denotes a specific monitor name.

This is mostly useful only where DesktopConfiguration per-monitor is in use.

The default behaviour of showing the global screen in FvwmPager is present when no Monitor configuration lines are used.

I’d be grateful for any testing you can give for this – especially in DesktopConfiguration per-monitor mode. Although I’ve given it some testing, it won’t be enough and so I am expecting some bugs.

8

Hi all,

I’ve just resurrected FvwmForm and pushed the result to the master branch.

I’ll be working on unifying this with FvwmScript at some point – but for now, it’s back and can be used again.

Any questions, let me know.

Kindly,
Thomas

9

Hi all,

I’ve merged FvwmPrompt to the master branch, ready for testing.

From the commit message:

This introduces a new command, FvwmPrompt, as a replacement for
FvwmConsole and FvwmCommand.

As a replacement for FvwmCommand, it can be run as:

    FvwmPrompt 'fvwm command here'

As a replacement for FvwmConsole, it can be run as:

    FvwmPrompt

Unlike FvwmConsole, FvwmPrompt is a standalone program communicating
with FvwmMFL, and is not therefore a Fvwm module.  As such, FvwmPrompt
does not accept the same command-line arguments as FvwmConsole to get it
to launch a specific terminal (-terminal), for example.  Instead, a
compat-friendly shell alias is recommended (but not provided):

   alias FvwmConsole='xterm -g 80x24 -e FvwmPrompt'

This also means that FvwmPrompt does not need to be started from FVWM
either, and will work as long as "Module FvwmMFL" is running.  This is
the case by default, and hence no configuration changes should be
required to make FvwmMFL load.

To enable FvwmPrompt, autotools will look for the Go runtime installed
on the system, and must be at a version >= 1.4.x.  It must also be told
to do this, via --enable-golang, as in:

    ./configure --enable-golang

It is expected in the future that more modules could be written in Go,
hence this option.  It is not currently mandatory that Go needs to be
installed, hence this configure flag.

If '--enable-golang' is used, and configure checks pass, then this
explicitly bypasses compiling and installing FvwmConsole.  This is a
compatibility feature only for now, until such time that confidence in
FvwmPrompt's use and surrounding tooling on different platforms (BSDs
mostly) is met without any large overhead for package maintainers.

Enjoy!

13

Hi!
I switched to fvwm3 and the construction for animation stopped working.

DestroyModuleConfig OmniTool:*
*OmniTool: Geometry 920x120+0+0
*OmniTool: Colorset 10
*OmniTool: Rows 120
*OmniTool: Columns 920
*OmniTool: Frame 0
*OmniTool: Font “xft:Sans:Bold:size=10:antialias=True”
*OmniTool: (120x45, Icon “fvwm-logo-small.png”, Frame 0)
*OmniTool: (Size 360x120, Frame 0, Colorset 0, Swallow “FvwmPager” ‘Module FvwmPager’ )
*OmniTool: (120x45, Swallow DateTime ‘Module FvwmScript FvwmScript-DateTime’,
Frame 0)
DestroyFunc ShowTheOmniTool
AddToFunc ShowTheOmniTool

  • I None (OmniTool) StartOmniTool
  • I Next (! OmniTool State 1) AnimatedMove 0p 0p
  • I TestRc (Match) All (OmniTool) Focus
  • I TestRc (Match) All (OmniTool) WarpToWindow 50 0
  • I TestRc (NoMatch) All (OmniTool) AnimatedMove 0p -$[vp.height]p
  • I Next (OmniTool) State 1 toggle
    Key escape A 4 ShowTheOmniTool

It should show the FvwmButton and hide it.
Now it shows and disappears, the re-call grabs a random window and hides it.

15

Upgraded 1.0.5 to 1.0.6a, nice improvements and fixes, such as fixed ChangeDesk function for pager and now also shows app icons. Command fvwm3-root changed to fvwm-root compatible for both fvwm2 and 3. Thanks.