Re: FVWM: GotoPage key binding works only on fvwm restart

[Thomas Adam]

Hi Brad,

Send me your config, please.

Kindly,
Thomas

On Mon, 30 Sep 2024 at 19:02, Brad Robertson 
wrote:

> I'm using fvwm3-1.1.0 on FreeBSD 14.1, with one virtual desktop of five
> pages defined so:
>
> DeskTopSize5x1
> DeskTopName0 Main
> EdgeScroll 10 10
> EdgeResistance 0
> EdgeThickness  2
> Style * EdgeMoveDelay 0
> Style * EdgeMoveResistance 0
> Key Right A C GotoPage wrapx +1p 0p
> Key Left  A C GotoPage wrapx -1p 0p
>
> For quite a while now, longer than I can remember, the GotoPage key
> bindings only work if I do an fvwm restart.  When I first launch X and
> start fvwm, those bindings do not work initially, but if I follow up
> with an fvwm restart, then the bindings do work.
>
> If it's relevant, X is xorg-server-21.1.13, and I'm using version
> 550.120 of the nVidia driver for my graphics card.
>
> Probably it's me being stupid or making some noob mistake, but I haven't
> been able to figure it out.
>
> I don't recall having this problem with fvwm2, and unfortunately I'm no
> longer sure if I've always had this problem with fvwm3 or if it started
> only sometime after I began using fvwm3.
>
> Any tips on how to figure out what I'm doing wrong?
>
> I can include my full fvwm config file, if anyone's willing to take a
> look.
>
> Thanks,
>
> --
> Brad Robertson
> 
>
>

Re: FVWM: fvwm3?

[Thomas Adam]

On Thu, Feb 08, 2024 at 05:50:44AM +0100, hw wrote:
> I still don't see why it shouldn't be possible.  I never expected a
> port, and I understand that the architectures of X11 and Wayland are
> very different.  Yet why shouldn't it be possible to create a
> compositor that provides the configurability fvwm has and which is so
> badly lacking in Gnome and KDE?

Absolutely it is possible.  But then it wouldn't be fvwm.

> Is it really impossible to create a wayland compositor that provides
> the required functionality?

I'm not entirely certain you've understood the points in my original email.

I also don't want to repeat myself, but...

To me, the things which make fvwm unique, are:

1.  Its architecture is tied to X11 -- it uses Xlib directly to render window
frames.  This is all using Xlib's graphics backend which has a large array of
2d drawing routines.  There's not a separate library which can be used to
abstract this out to be used elsewhere -- this is the entire point of the
client/server model in X11.

The only thing which comes close is libcairo (built on pixman) -- and you can
use that with a wlroots-based compositor to generate "SSDs" within a
compositor -- but this doesn't work well for fvwm because it doesn't allow for
shading when filling in rectangles, as well as various other things.

This is important because, for me, the entire point of fvwm is that it can be
made to look like MWM.  I'm serious here -- all of that blocky (even "ugly",
as some people have called it) looking borders is important to me, that's what
I like.

2.  Even if 1., were a solved problem, the second issue is a lack of
reparenting.  This is a core feature of xlib, and fvwm makes extensive use of
it to be able to function.  It makes things like resizing and moving windows
easier.  It's also very important for FvwmButtons; the "Swallow" command calls
XReparentWindow() directly.

I'm really dumbing-down the explanation here, but it's not possible on Wayland
at present.  I suspect it will never be.

Now, even if the graphics side of things from point 1 above were currently
possible under Wayland, the lack of reparenting means you're having to move
the window frame along with the window itself -- the two are not "connected",
which causes all manner of weird glitches.

3.  Lack of standards a la ICCCM/EWMH

Fvwm is the exemplar project for how implementing standards helps
interoperability rules for window governance.  Again, because of the X11
architecture, the XServer would make this easy.  Under Wayland, there's
"portals" but they're now selective about what's being implemented.  So things
like aspect-ratio resizing doesn't have a portal.   There's so much in the
EWMH which makes fvwm behave the way it does with applications, until that's
addressed -- or if it ever is -- you'll probably notice lots missing from a
potential fvwm-compositor under Wayland.

Let's not forget though that fvwm being a reparenting window manager was
always making it an outlier.  Widget libraries like GTK and QT have gone way
beyond just providing UI components -- they're now also responsible for CSDs
and a myriad of other crap -- and when you put that into context of what a
Wayland compositor needs to do -- it has fewer options.  Styling and theming
becomes the same across Wayland compositors.  So you're losing out on a lot
with the Wayland architecture being what it is, alas.

So Wayland is going to be dominated by Gnome and KDE.  Yes, they'll be smaller
tiling-only WMs on Wayland, but they'll all look the same.

So I hope this answers your question.  I shan't be replying to any more emails
in either this thread, or the other one which is talking about Wayland.  The
subject is becoming tiring and laboured, with most people just saying the same
thing, without the understanding behind it.

Kindly,
Thomas

Re: FVWM: fvwm3?

[Thomas Adam]

On Fri, Feb 02, 2024 at 10:42:37PM -0600, Jason Tibbitts wrote:
> Now, I don't know if you could use the really old-style remote display
> stuff where ssh is not involved.  Xwayland really is a proper X server
> so the ability to do it is probably down in there somewhere.

Yes-and-no -- in that, although XWayland is similar in architecture to Xephyr
and Xnest, it's not anywhere near a complete "stripped-down" XServer -- Xephyr
has better support for a lot of the XServer extensions than XWayland does, and
I suspect that will only ever support enough to run pure XLib/Xaw
applications, and nothing more. 

Certainly, running fvwm under XWayland is possible, but because of the RandR
support available, it doesn't recognise the host's screens, and hence doesn't
work how you'd expect it to at present.  Beyond that limitation, there's still
plenty of other extensions which would be needed to make fvwm run comfortably
under that.  You'll probably find plenty of rhetoric on Youtube and elsewhere
showing some $WM running under XWayland -- the point here is that such a $WM
is not a reparenting WM, and relies on just drawing window borders around
clients, which is very different.

Speaking of the Wayland architecture, and having read others' replies in this
thread, it's saddening to think of the shear lack of understanding there is
between Xorg and Wayland.

When people talk of a "port of FVWM to Wayland" they do so in the naive
understanding that it's already possible -- with there being an existing
framework or something which would make the possible.

There is not.

FVWM amongst the existing X11 WMs is already unique in that it has been built
against pure X11 -- that is, no existing higher-level widget toolkit to
provide window decorations, such as GTK or QT. Rather, FVWM is a *reparenting*
window manager, which means its window decorations are drawn via Xlib, and the
client window is embedded inside that frame, drawn via fvwm, via Xlib.  That's
what reparenting means.  When you go to resize, move, etc., a window managed
by fvwm, you do so by that parent frame telling the client about its new
size/geometry.

All of this is via the XServer.

With Wayland, and if there were to ever be a fvwm compositor, the *compositor*
is the "server", as well as everything else.  There is no longer a separation
of client/server under Wayland -- a compositor must do it all in one.

There are libraries which will assist with this -- such as wlroots.  This has
meant a lot of compositors function in the same way, such as river, dwl,
labwc, sway, etc.  But they all suffer the same problem in that they're only
as good as the functionality this library provides, which is not everything
which is part of the Wayland ecosystem -- albeit that is in itself in a state
of flux.

Although Wayland compositors have the separation to handle CSDs (client-side
decorations), and SSDs (server-side decorations), the SSD code in compositors
is nothing more than drawing a window frame around a client window, and moving
it relative to the client -- this is because of the lack of reparenting under
Wayland.

Perhaps one of the biggest drawbacks of Wayland which worries me is that there
is a notion of things called "portals" which are additional bolt-on bits of
functionality which Wayland compositors can choose to implement or not.  But
by themselves, they're not addressing anything near what they should -- and
when you compare them to what the ICCCM2 and the EWMH specification
standardised on, it's all very much a step-backward in terms of richness and
how windows should behave.

Indeed, these "portals" seems to popup sporadically, and are not being
addressed in a way which I would argue is cohesive.  I mentioned over on
Mastodon one such example of this [0] where a portal for specifying the
miniicon (to use fvwm's parlance) turned into an utter shit-show because of
the amount of bikeshedding involved.  If that is the level at which progress
is to be measured, Wayland is doomed.

But right now, if portals under Wayland are meant to selectively bring over
functionality found in the EWMH spec, it's a million miles away from being
complete.  Even if there were a cabal of compositors which were trying to do
this collectively -- even in the spirit of how this were being done on X11
originally -- it's still very much up to the individual compositor to
implement this, as there is no sever/client model to abstract some of that
away.  The best one might hope for is something like wlroots implementing
these portals.

Good luck with that.

So, a "port" of fvwm to Wayland?  No.  Impossible.  Because of the
architecture, the reliance on the server/client architecture, the fact that
there are no 2D graphics libraries which are standalone from Xlib which work
on Wayland to generate window frames, makes this difficult (XFillRectangle,
etc).  There is notion of reparenting under Wayland.

Wayland is not Xlib.

I have been, in my spare time, looking at the XServer code and all t

Re: FVWM: fvwm3: how to make qmmp2 sticky?

[Thomas Adam]

On Mon, 31 Jul 2023 at 19:31, Harald Dunkel  wrote:
>
> Hi folks,
>
> using fvwm3 and
>
> Style   "qmmp" NoTitle, WindowListSkip, Sticky, StaysOnBottom
>
> qmmp2 (https://sourceforge.net/projects/qmmp-dev/files/qmmp/2.1/) is not
> sticky. The other attributes from the list work as expected. Similar

I've not installed this application, but can you send me the output
from `xprop` on the window which should be sticky, but isn't?

Kindly,
Thomas

Re: FVWM: google meet presentation versus fvwm viewports

[Thomas Adam]

On Thu, May 25, 2023 at 10:44:10AM +0200, Martin Cermak wrote:
> This is annoying.  It forces me to keep my firefox presentation
> in an active viewport.  How can I work this around?

You would need to detect if the window changes state here to be either iconic,
or a smaller version of itself, etc.  You might be able to check this with
`xprop -spy`.

I'm sure I recall seeing this behaviour when using Zoom a few years ago.

-- Thomas Adam

Re: FVWM: emulating mouse button 2 on HP touchpad

[Thomas Adam]

On Sun, 14 May 2023 at 22:12, Lucio Chiappetti  wrote:
> So the problem is an incompatibility between xterm and fvwm syntethic
> events (or a syntax problem with PointerKey ?)
>
> Is there a solution ?

No.  By default generating synthetic events is considered a security
risk. which is why so many applications now no longer support them.

-- Thomas

Re: FVWM: Oddity with Mouse 2 using fvwm 2.6 & 2.7 on Suse Tumbleweed

[Thomas Adam]

On Tue, May 09, 2023 at 01:26:45PM -0700, mark_at_yahoo wrote:
> AddToFunc StartFunction
> + I   ImagePath 
> $[HOME]/.local/share/icons/hicolor/48x48:$[HOME]/.local/share/icons/hicolor/64x64:$[HOME]/.local/share/icons/hicolor/72x72:+

Setting ImagePath here is a little counter-intuitive.  It's a global command
that should be set at the top of your file.  See:

https://www.fvwm.org/Wiki/Tips/FvwmStartup/

> From reading the documentation I've always assumed that FVWM searches
> the ":"-separated paths (including the default indicated by "+") for an
> appropriate image file with some "NAME" plus a supported suffix such as
> ".xpm", ".svg", ".png", depending on how the fvwm binary was compiled. I
> recently discovered the following post, which clarified that the "NAME"
> is derived from the X11 window class property:

Hmm.  No.  Unless you set IconOverride, the preference is to the
application-provided icon.

> Q: Is my understanding of FVWM's ImagePath correct?

See above.

> Q: How can I list the compiled-in default "+" ImagePath, maybe
>with some command in an FvwmConsole?

You can't easily.

> Q: Where is the mystery small icon be coming from?

MiniIcon.  Same principle as above.

> #0  0x7f1e0696190c __pthread_kill_implementation (libc.so.6 + 0x8f90c)
> #1  0x7f1e06910196 raise (libc.so.6 + 0x3e196)
> #2  0x7f1e068f8897 abort (libc.so.6 + 0x26897)
> #3  0x7f1e068f87ab __assert_fail_base.cold (libc.so.6 + 0x267ab)
> #4  0x7f1e069084b6 __assert_fail (libc.so.6 + 0x364b6)
> #5  0x7f1e078b4c03 _XAllocID (libX11.so.6 + 0x42c03)

Try the fvwm2 version from git.

Kindly,
Thomas

Re: fvwm2 -> fvwm3 (War: FVWM: Resizing)

[Thomas Adam]

On Tue, May 09, 2023 at 08:51:00PM +0100, Klaus Ethgen wrote:
> Am Mo den  8. Mai 2023 um 19:24 schrieb Thomas Adam:
> > In fvwm3, randr support supports this without a restart, but it needs more
> > testing.
> 
> That brings me to the topic I did long postponed.
> 
> How to best move from fvwm2 to fvwm3?

Use:

fvwm-convert-2.6

Along with release notes:

https://github.com/fvwmorg/fvwm3/releases

I also recall cks writing a blog post about this:

https://utcc.utoronto.ca/~cks/space/blog/unix/Fvwm2ToFvwm3

> I just gave it a try and found several incompatibilities.

You will do -- this is now a feature, and not a bug.

> First I notice that fvwm3 does log nothing to .xsession-errors by
> itself. I have to start it with `-v -o -`.

It will log some things to stderr, but given how some display managers now
redirect this, it was becoming more and more inconsistent.  So yes, if you
want to see output from fvwm3, you can use:

  fvwm3 -v
  pkill -HUP fvwm3

The signal will toggle the logging.  BTW, the default log file location is
$FVWM_USERDIR/fvwm3-output.log

> The next is that there is somewhere default config that overwrite or
> replace parts of my config.

No -- no more than fvwm already has.

> I just put my current and growed config to [0].
> 
> - Xinerama (Line 8/9) does not work anymore, what is the correct
>   replacement?

There isn't.  You now need to use xrandr(1) or some other tool to represent
your monitors, and fvwm3 will automatically use that.

> - The Colorset styles seems to be broken that way
> - HilightBack and HilightFore style not supported
> - Color style not supported

Correct.  Use colorsets for everything now.

> - FvwmProxy gone

Correct.

> - The title line is completely different now. I use to have blue for
>   activated window and grey for inactive. Now it is the opposite (Have
>   to do with HilightFore and HilightBack)

Again, use colorsets.

> - How to have a config file for both versions with some
>   in-config-switches to choose between incompatible options?

You could use:

Test (Version ), but I would suggest converting your config file across.

fvwm2 isn't being maintained any more.  And fvwm3 was never guaranteed to be
backwards compatible with fvwm2 -- it tries to be in that those areas which
haven't changed will still work, but at some point things will diverge.

Kindly,
Thomas

Re: FVWM: fvwm: ../../src/xcb_io.c:626: _XAllocID: Assertion `ret != inval_id' failed.

[Thomas Adam]

On Tue, Apr 04, 2023 at 10:36:48AM +0200, Harald Dunkel wrote:
> Hi folks,
> 
> sometimes fvwm 2.70 (built by Debian) dies with

Please take a look at the last master commit in the fvwm2 repo.

AFAIK, this should fix the problem.

Kindly,
Thomas

Re: FVWM: Resizing

[Thomas Adam]

On Sun, 7 May 2023 at 09:08, Klaus Ethgen  wrote:

> Hi fvwm folks,
>
> what is the best method to react to resizing displays? Be it on beamer
> or in a virtualbox.
>
> Usually, fvwm does not apply to such an event and need to be restarted.
> But this is suboptimal and I would like to find a better solution (even
> automatic restart would be better).


In fvwm3, randr support supports this without a restart, but it needs more
testing.


>
> Related to that, how to best set the screen DPI in fvwm config?
>

You don't. Use xrandr itself along with xft.dpi in your .Xdefaults file.

Kindly,
Thomas

Re: FVWM: EdgeScroll breaks after restart

[Thomas Adam]

On Tue, 17 Jan 2023 at 10:05, Parragh, Szabolcs  wrote:
>
> Hi,
> I have a weird issue, where EdgeScroll breaks after I restart fwvm. The
> cursor even doesn't (as it does when it works) change as I move it to
> edge and I cannot go over to the next desktop with the mouse.
>
> I was able to replicate the issue with just this config:
>
> EdgeResistance 500
> Style "*"  EdgeMoveDelay 500
> Style "*"  EdgeMoveResistance 20
> EdgeScroll 100 100
> DeskTopSize3 3
>
> Am I missing something from my InitFuctions?

Do things work correctly if you also add the following to your config:

EdgeThickness 1

Kindly,
Thomas

Re: FVWM: mwmborder style in 1.0.6

[Thomas Adam]

On Fri, 4 Nov 2022 at 21:39, elliot s  wrote:
> What's the planned way of having minimal but existing relief in buttons?

No.  It was not.  I'll push a fix for this momentarily.

-- Thomas

Re: FVWM: controlling thunderbird

[Thomas Adam]

Hi,

On Sun, 18 Sept 2022 at 10:46, Klaus Ethgen  wrote:
>
> Hello,
>
> I have troubles with thunderbird (class thunderbird-default) always
> appearing in the middle of the screen, even if my placement policy would
> put it on the right side.

Style thunderbird StartsOnScreen 

Works fine for me, for example.

Send your fvwm config across to me, and I'll take a look.

Kindly,
Thomas

Re: FVWM: window swallowing

[Thomas Adam]

On Sun, Apr 17, 2022 at 02:06:49PM -0400, Paul Fox wrote:
> I've been using fvwm pretty much exclusively for so long, that I'm
> not sure anymore whether some features are unique to fvwm, or might
> be available elsewhere with different names.
> 
> In particular -- the notion of FvwmButtons "swallowing" a child window --
> is that a feature available in other window managers?  It's pretty
> powerful.

All FvwmButtons is doing is reparenting other windows.  Someone would have to
emulate that outside of fvwm (the reason it hasn't been done is because
there's a module <-> fvwm protocol which FvwmButtons uses).

The closest I know of is the program 'tabbed' from suckless.  However, this
doesn't have the same layout options as FvwmButtons does.

Kindly,
Thomas

Re: FVWM: fvwm focus change causes vim to leave insert mode

[Thomas Adam]

On Thu, Jul 22, 2021 at 03:34:56PM -0400, John Sellens wrote:
> When I have the vim editor open in an xterm window, in insert mode,
> and move my mouse (and focus) into another window, the vim in the
> original window receives some sort of escape sequence that causes
> it to leave insert mode and beep.

You presumably have some sort of vim plugin installed causing this.  There's
nothing that fvwm is going to be doing to make vim in xterm (or any other
terminal emulator) come out of insert mode.  The only way it could is if fvwm
was using FakeKeyPress, but this hasn't worked in years due to most
applications not allowing synthetic key events due to security considerations.

> I tried starting vim without customization, and fvwm 2.6.8 and fvwm 3 with
> stock configuration.  It seems to happen in xterm, x-terminal-emumator,
> terminator, uxterm, but not in rxvt.  I'm on ubuntu 21.04.

Can you share your fvwm configuration?  I know you've said it happend with
"stock configuration", but I can't reproduce the problem doing just that with
vim8.

Kindly,
Thomas

Re: FVWM: Thank you for your work and suggestions for new FVWM features

[Thomas Adam]

On Sun, Jul 11, 2021 at 12:13:49PM +1000, Wojciech Lipinski wrote:
> Perhaps I could help a little bit with the content cleaning and merging. I
> do not have much spare time either but I could do what I can in the time
> available. I am not sure how http://fvwm.sourceforge.net/ relates to
> fvwm.org and who is in charge of it. 

Me neither, and it's not something I'm bothered to find out.  In most
cases, it seems sourceforge sites have been taken over by squatters.  Although
that's perhaps not the case here, I don't have control of that site and don't
wish to.  As I said before, in most google searches, fvwm.org is usually the
place that's referenced.

> It says it is a mirror of fvwm.org and
> that it is an official FVWM page, but it does not look like a mirror of
> fvwm.org anymore. However, the following section of that "mirror" website is
> quite useful: http://fvwm.sourceforge.net/doc/unstable/allCommands.html

That's not something that's going to work for fvwm3, as the documentation is
now rendered via asciidoctor.  To maintain this list, we'd have to produce
this a different way.

> Furthermore, some websites, e.g. https://wiki.debian.org/Fvwm, refer to
> https://www.fvwm.org/contact/
> but it leads to 404.

If Jaimos is reading this, I'm sure he'll be able to fix this on the
Debian-side.

> I guess there is some legacy for the long history of
> FVWM. How is fvwm.org maintained?

It's no different to how it has always been.  It's just that now, Github is
being used for CI/CD and for people to submit patches.

> I can see that fvwm.org is now much
> refreshed and it has its Wiki section. Is it based on MediaWiki? If not,
> have you and/or your colleagues considered using MediaWiki?

It's using Markdown and Jekyll (which is what is used for Github Pages as
well).  See:  https://www.fvwm.org/Wiki/ -- this will tell where to find the
repository to checkout for the Wiki as well (it's a part of the fvwm.org
website code).

Kindly,
Thomas

Re: FVWM: Interview fvwm developers

[Thomas Adam]

On Mon, Jun 28, 2021 at 06:53:05PM +0200, Keywan Tonekaboni wrote:
> I'm looking for an interview with one of the developers of the early
> days. If you could help me, how to contact Robert Nation, Chuck Hines or
> somebody else, that would be great.

How far back is "early days"?  I am sure Dan Espen and Dominik Vogt would
qualify!  They're still lurking round these parts somewhere, I do hope!

As for Robert Nation, I contacted him a few years ago via LinkedIn.  Chuck
hasn't been seen on this list in several years, AFAIK.

I am sure those who qualify will see this email and reply in due course.

Kindly,
Thomas

Re: FVWM: Thank you for your work and suggestions for new FVWM features

[Thomas Adam]

> 1. Is it possible to add a feature similar to the visual window list switch
> in XFCE or other desktop environments, with window thumbnails / icons
> rotating horizontally? I have looked into the possibility of writing an FVWM
> script, similarly to the script that attempts to imitate this behaviour
> using a vertical menu:
> 
> https://zensites.net/fvwm/guide/advanced_functions.html

You could do this using FvwmButtons, but it might take a little bit of work to
do the right thing to your liking.

> 2. Is it possible to implement a solution using a detachable window title in
> a taskbar? Perhaps there is a way to configure fvwmiconman to serve this
> purpose. Any hint from you would be appreciated.

I'm not sure what you're referring to here.  Can you provide more detail, or a
screenshot showing what you mean?

> 3. There seem to be several websites dedicated to FVWM, each containing some
> partial information.
> 
> https://www.fvwm.org/
> https://github.com/fvwmorg

These two are linked from one another, and certainly if you google for "fvwm",
you'll be offered those links.

> http://fvwm.sourceforge.net/
> 
> May I suggest to include the fvwm.sourceforge.net content, in particular the
> documentation in www.fvwm.org, and redirects set to point to fvwm.org? The
> documentation at the sourceforge site has been very useful for ordinary
> users like me.

I don't think anyone here is responsible for that content.  Certainly it's low
on the search list and from other more recognised fvwm websites.

> I feel that consolidating the multiple websites under the complete fvwm.org
> site, with sub-pages dedicated to different FVWM versions, documentation,
> forums, etc, and possibly reformatted e.g. using a modern Wiki
> interface/style, with just one link to the github site would better serve
> the purpose of modernising, advancing and adopting FVWM by broader groups of
> do-it-your-way computer users.

Perhaps you're right.   But as with everything, someone's got to dedicate
their time to do the work and keep the work maintained.  For something like
this, I won't have the time to do so.

> 4. Are one-time donations possible to support FVWM development and
> maintenance?

I would instead give something to a charity of your choice.  Glad you're
enjoying Fvwm!

Kindly,
Thomas

FVWM: #fvwm IRC channel has moved to libera.chat

[Thomas Adam]

Hi all,

For anyone here who's used to stopping by the #fvwm IRC channel on freenode,
please be aware that I've officially moved this channel to irc.libera.chat.

Freenode have been having some internal issues and a number of channels are
moving to other IRC servers -- ours is irc.libera.chat

I'll be officially shutting down #fvwm on freenode at the end of May.

Any questions, do please let me know.

Kindly,
Thomas

Re: FVWM: Trouble with transient windows

[Thomas Adam]

On Sat, Feb 13, 2021 at 08:22:16PM +0530, Mandar Mitra wrote:
> I would like the transient windows to not affect focus at all. I looked at 
> the manual page for the FPGrabFocusTransient, FPGrabFocusTransient,  
> FPReleaseFocusTransient, and similar options, but I couldn't figure out what 
> I need to do to get the behaviour I want.
> 
> Is this something that I can take care of within fvwm? Or should I ask the 
> ipe developer about this?

I suppose you're referring to something like this:

Style * RaiseTransient
Style * LowerTransient
Style * StackTransientParent

-- Thomas

Re: FVWM: Positioning transient pager on screen

[Thomas Adam]

On Thu, Feb 04, 2021 at 08:54:50AM -0500, David J. Weller-Fahy wrote:
> Greetings,

Hello.

> I have tried a number of things to move the window, but figured I'd ask:
> what's the proper way to make a transient instance of FvwmPager move to
> an x position of 70 pixels, and a y position of 0 (+70+0 in geometry
> parlance)?

There isn't one.  The idea behind transient window is that they're dealt with
there-and-then, hence why they start by the mouse pointer in this case.  It's
a feature, not a bug.

Kindly,
Thomas

Re: FVWM: Identify window by PID?

[Thomas Adam]

On Wed, Sep 09, 2020 at 06:09:26PM +0200, Dr Rainer Woitok wrote:
> Greetings,
> 
> is there a way to identify a window by the PID of the process running in
> it?  So I could do something along the lines of
> 
>All (...  ...) WarpToWindow 50 50
> 
> I didn't yet find a solution at
> 
>https://www.fvwm.org/Archive/Manpages/fvwm.html
> 
> I know there is the "wmctrl", but I would prefer a solution within Fvwm.

Some applications might set _NET_WM_PID.  You can check using xprop.

-- Thomas

Re: FVWM: FVWM3-1.0.0 is released

[Thomas Adam]

On Sun, Sep 06, 2020 at 02:13:18PM -0700, elliot s wrote:
> Retrying from laptop since fvwm mail doesnt like my tablet gmail (html issue).
> 
> Is there a way to get a precompiled 64 bit version?
> Perhaps put one up on the site?
> I check pkgs.org but I assume it'll be a long time before it hits there.

You typically either compiler it yourself, or wait for your Linux distro/BSD
variant to provide one.

I personally won't support this outside of downstream packaging efforts.

Kindly,
Thomas

Re: FVWM: FVWM3-1.0.0 is released

[Thomas Adam]

On Thu, Sep 03, 2020 at 07:42:58AM -0400, Dan Espen wrote:
> Martin Cermak  writes:
> 
> > On  Thu  2020-09-03  09:49 , Dominik Vogt wrote:
> >> On Thu, Sep 03, 2020 at 02:06:10AM +0100, Thomas Adam wrote:
> >> > Well, we did it.  Version 1.0.0 of Fvwm3 is now live and ready to be
> >> > installed.
> >> 
> >> Um, can we call that fvwm-3.0.0 instead of fvwm3-1.0.0 please?
> >> Renaming the project because of a new major version was already a
> >> mistake for fvwm-2.0.0.  No reason to repeat it now.
> >
> > ( I was just thinking of creating a brand new package for fedora
> > providing /usr/bin/fvwm3 able to coexist with /usr/bin/fvwm2 from
> > the existing package.  Might this make sense from the user
> > perspective?  Not sure ... )
> 
> Not sure how Thomas feels.
> Fvwm3 was supposed to be largely incompatible with Fvwm2 hence the name
> change.  That hasn't occurred yet.

It's a tricky one.  Right now, things have not diverged because I haven't
implemented those changes.  I'd always viewed Fvwm3 as being a departure from
Fvwm2 -- and hence any association with it at the moment as being equivalent
is just because it's lacking any breaking changes.  It's also an easier
transition for any one wishing to try Fvwm3 who's previously used Fvwm2.

That's one of the reasons why I went with version 1.0.0 -- Fvwm3 is going to
be separate from Fvwm2 over time, in that I'm not expecting to maintain
compatibility, and I wouldn't therefore want to mislead users with a false
version number.

There may well be some overlap with Fvwm2 in terms of unchanged file names
(fvwm-config springs to mind), although I think for the most part Fvwm2 and
Fvwm3 can co-exist.  I'll try and make the distinction better in future
releases, so that it's easier for package maintainers to allow Fvwm2 and Fvwm3
to coexist.

Kindly,
Thomas

Re: FVWM: Calling Old Timers! Fvwm FTP mirrors, anyone?

[Thomas Adam]

On Wed, Sep 02, 2020 at 07:34:57PM -0600, Glenn Golden wrote:
> NOTE: This file.io file sharing site is download-once-then-auto-delete,
> so grab it before anyone else on the list does. :)  

Hey Glenn,

Alas, it's already a 404 -- so I guess something/one beat me to it.

Perhaps you could send me a link off-list instead?

Kindly,
Thomas

FVWM: FVWM3-1.0.0 is released

[Thomas Adam]

Hi all,

Well, we did it.  Version 1.0.0 of Fvwm3 is now live and ready to be
installed.  See:

https://github.com/fvwmorg/fvwm3/releases/tag/1.0.0

It's not without its rough edges, but that's true of any software.  Even
though I've called those out in the release notes, I consider Fvwm3 now good
enough for every day use.

Although I mostly have Coronavirus to thank for this release (working from
home means I got to get some of my time back), I do want to say that none of
what I've done has been groundbreaking.  I have merely built on top of what
was already there in the form of Fvwm2.  So I would really like to thank
people like:  Dan Espen, Dominik Vogt, Viktor Griph, etc., without whom this
wouldn't be in the shape it is now.  Thanks, fellas.

Special mention has to go to the folk on #fvwm on irc.freenode.net.  I've had
some great bug reports from regular users of fvwm come from there.  It's been
a very closed round of testing, but it's nonetheless helped a lot in fixing
silly bugs which have crept in over time.  Jaimos Skriletz in particular has
been invaluable in helping me with some of the more complicated mathematics in
wrangling windows with RandR.  Thanks, Jaimos!

Any questions, don't hesitate to shout.

Enjoy, and let the bug reports roll in...

Thomas

Re: FVWM: Calling Old Timers! Fvwm FTP mirrors, anyone?

[Thomas Adam]

On Wed, Sep 02, 2020 at 01:23:49PM -0600, Glenn Golden wrote:
> Hi Thomas,

Hello Glenn -- hope you're well.

> Let me know which (if any) files you'd like, I'll tar them up and dump them
> on a public file site somewhere. (Or, if there's wider historical interest
> than just the FVWM stuff, I can dump the full CDrom images.)

Wow.  Thank you indeed!  This is most definitely a good start.  I've gone
through the lists you've provided and although on the face of it, there's one
or two duplicates with what I have, I can't say for certain if that's the case
without really checking.

If it's not too much of a cheek to ask, would it possible for you to provide
all the Fvwm files across those CDs you've listed?  That would allow me to
pick apart anything of interest.  You never know, some downstream maintainer
may well have provided patches which never made it upstream.  Might be
something there...

Thanks again, Glenn!

Kindly,
Thomas

FVWM: Calling Old Timers! Fvwm FTP mirrors, anyone?

[Thomas Adam]

Hi all,

I'm planning on piecing together a richer timeline of how Fvwm started.  It
feels like a good time to do this now.  I know there's existing Fvwm history
page which is a really good start [1], but I was wondering if I could take
that a stage further to back it up with Fvwm releases.

I originally sent a variant of this email to Jason Tibbs, but he's possibly
busy and hasn't had time to reply yet, so I figured I'd try a wider audience.
Hopefully some of the old-time lurkers on these lists are reading this and can
pop their head above the FvwmParapet one last time?  :)  Here's to hoping!

Back in the day, Fvwm used to use ftp.hpc.uh.edu/pub/fvwm as an upload area
for fvwm releases, both what we'd now call RCs as well as official releases.
That FTP site along with its mirrors have long since ceased to be.  Even the
Wayback Machine (archive.org) is absent of these.

Back when Charles (Chuck) Hines was maintainer of Fvwm, he was uploading 2.0.x
patchlevel tarballs to ftp.hpc.uh.edu/pub/fvwm (as is referenced on the old
mailing list archives), which is where I'm hoping to be able to start
collecting changes from.  So if anyone has a mirror of ftp.hpc.uh.edu/pub/fvwm
around, do please let me know -- even if it's just a collection of old files.

What I'm planning on doing is trying to get these code releases into a git
repo, so I can better chart the progress of the changes to Fvwm over time.

So far, my collections of code tarballs is sketchy.  I have:

* fvwm-0.91b
* fvwm-1.21m
* fvwm-1.22f
* fvwm-1.23b
* fvwm-1.24r
* fvwm-2.0.40
* fvwm-2.0.41
* fvwm-2.0.43

It's likely the intermediary 2.0.X releases (including the different
patchlevels that were worked on) exist somewhere.  Those are the more
interesting to me.

The fvwm2 git repo goes back as far as version 2.1, so we're OK from that
point onward.

So, dust off your spinning rust disks, your DATs, and carrier pidgeons, and
let me know if there's anything out there worthy of salvaging.

Cheers everyone,
Thomas

[1] https://www.fvwm.org/Wiki/FvwmHistory/

Re: FVWM: Fvwm3-RC0 is released

[Thomas Adam]

On Tue, Sep 01, 2020 at 11:03:49AM -0500, Brian wrote:
> There is one comment.  On the Installation Instructinos page, under
> Manually, the first sentence ends akwardly.  Did you mean "core or
> optional" or "core and optional" ?  I believe you meant the latter that
> both core and optional should be installed.

Hmm, yes.  That's very confusing.  Not sure what I was thinking there.
Thanks!  Fixed now.

-- Thomas

Re: FVWM: Fvwm3-RC0 is released

[Thomas Adam]

On Tue, Sep 01, 2020 at 11:29:12AM -0400, gi1242+f...@gmail.com wrote:
> Very cool, thanks! Is there an upgrade guide/list of changes since
> Fvwm2? I couldn't find it on the website.

I've added some preliminary notes here:

https://github.com/fvwmorg/fvwm3/releases/tag/1.0.0-rc0

> (I see that my current configuration will still work with fvwm3,
> but I'm still slow to test it as it's critical for my daily work.)

Understood.  There shouldn't be any breaking changes.

-- Thomas

FVWM: Fvwm3-RC0 is released

[Thomas Adam]

Hi all,

I've just released RC0 of Fvwm3.  Doubtless there are a few bugs still to fix
(hence the first RC), and I'm going to be remain cautious on this one as it's
the first step towards an actual 1.0.0 release of Fvwm3.

Please do give this a try.  See:

https://github.com/fvwmorg/fvwm3/releases/tag/1.0.0-rc0

Please heed the release instructions.  Any questions/comments, please ask
here, or even better, on Github's issue tracker.

Enjoy!

Cheers,
Thomas

Re: FVWM: FvwmForm replaces FvwmPrompt (fvwm 2.0.41)

[Thomas Adam]

On Wed, Aug 26, 2020 at 03:03:10PM -0400, Dan Espen wrote:
> Wow, fvwm history that is before my time?  (I think.)

I managed to track down Drew Moseley (the original author of FvwmPrompt), and
he had this to say:

Hi Thomas,

Thanks for reaching out.  Yes, indeed that was me.

That's great to hear that fvwm is still under active maintainership.
What kind of systems is it used on?

I don't recall the specifics but I had switched to fvwm for my use on
the SunOS systems at the University of Florida and wanted to be able
to confirm logouts and such.  The default at the time was twm if I
recall correctly and it had that.  When the fvwm plugin architecture
was available it ended up being a simple thing to implement so I did.
I sent it over to the maintainer and he replied saying thanks and that
was the last I heard of it.

Drew

I think he appreciated the trip down memory lane.  I'm mindful to expand the
existing fvwm history page we have with these tidbits of information -- it's
nicely unique.  The maintainer at the time Drew submitted FvwmPrompt would
have been Chuck Hines, I imagine.

I did reply back to him -- he wishes us all well, and is delighted that fvwm
is still continuing.

As it happens, the module interface Drew refers to hasn't changed much since
1995.  Sure, more fields of data have been added, but the way data is
exchanged between fvwm and modules remains largely the same.  Not bad going
for 25 years of code!

Anyhow, I think this now wraps that mystery up.

Kindly,
Thomas

Re: FVWM: FvwmForm replaces FvwmPrompt (fvwm 2.0.41)

[Thomas Adam]

On Wed, Aug 26, 2020 at 09:19:40PM +0200, Dr. Nikolaus Klepp wrote:
> Some more history: 
> 
> sunsite.unc.edu-CD6/X11/window-managers/
> fvwm-2.0.43.tar.gz537 KB  12.07.9617:51:56 MESZ

Yes -- this is already catered for in what's in the git repositories.

> So 2.0.41 is somewhere between August 1995 and June 1996 - kind of a blind
> spot in my archive. Still it might be in the shrinkwaped box of 1998 which I
> dare not to open ...

What archive do you own?  Is this a private collection or something you've
found on Google?

-- Thomas Adam

Re: FVWM: FvwmForm replaces FvwmPrompt (fvwm 2.0.41)

[Thomas Adam]

On Wed, Aug 26, 2020 at 03:03:10PM -0400, Dan Espen wrote:
> Wow, fvwm history that is before my time?  (I think.)

I didn't think that was possible!  Damn.  :)

> All I can come up with is a config file with this:
> 
> AddToMenu Module-Popup"Modules"   Title   
> + "Prompt"Module  FvwmPrompt "hello" raise
> 
> Looks like it issued a prompt then executed an Fvwm command.

Indeed.  I can find compilation problems on the fvwm mailing list, but nothing
beyond that.

> I don't remember FvwmClean either.

See:  https://manpages.debian.org/jessie/fvwm1/FvwmClean1.1.en.html

I'm not sure what problem that solved, but it's interesting!

-- Thomas

Re: FVWM: FvwmForm replaces FvwmPrompt (fvwm 2.0.41)

[Thomas Adam]

On Wed, Aug 26, 2020 at 08:43:45PM +0200, Dr. Nikolaus Klepp wrote:
> Anno domini 2020 Wed, 26 Aug 19:37:03 +0100
> 1998 ... could it be that the SuSE Linux of 1995 has it? I remember I used
> fvwm95 around that time. I'll go to archive and check :)

That's not logical.  Fvwm95 was a fork.  See though:

https://www.fvwm.org/fvwm-ml/15306.html

Which takes us back to 1996...

-- Thomas

FVWM: FvwmForm replaces FvwmPrompt (fvwm 2.0.41)

[Thomas Adam]

Hi,

I'm curious about a piece of Fvwm history.  In the git log for fvwm2, the
initial revision (which is when Jason committed the Fvwm code to CVS), notes
the following for Fvwm 2.0.41:

Removed FvwmPrompt (use FvwmForm instead, since it's better anyways)

This was sometime in 1998, although I'm presuming 2.0.41 was before then.

Has anyone gpt any information about FvwmPrompt?  If it were a forerunner to
FvwmForm I've not heard of it before.  I note from the old mailing list
archives that it was a compiled module, but I can't find the code anywhere.

Dust off the cobwebs, folks!

I'm only asking as I have just committed a new binary to Fvwm3 called
"FvwmPrompt", and hadn't realised it had existed already.  I thought I was
being so clever with the choice of name as well... That'll teach me!  :)

-- Thomas

Re: FVWM: No module "FvwmTaskBar" in Fvwm 2.6.9?

[Thomas Adam]

On Mon, Aug 17, 2020 at 06:18:26PM +0200, Dr Rainer Woitok wrote:
> > > 2. After I upgraded  again from  Fvwm version 2.6.5-r3  to 2.6.9 I found
> > >that the  manpage  "/usr/share/man/man1/fvwm.1.bz2"  is missing.   Is
> > >this Gentoo specific or did I look in the wrong place?
> > 
> > Sounds like the '--enable-mandoc' option to ./configure wasn't passed?
> 
> Don't think so because other manual pages are there:

Pass.  Not a FVWM problem, but definitely a problem with Gentoo's ebuild.

[~]{7958}[0] % apropos fvwm[23] 
fvwm3 (1)- F? Virtual Window Manager for X11
FvwmMFL (1)  - the Fvwm3 front-loader module
fvwm2 (1)- F? Virtual Window Manager for X11

I'll get back to you about FvwmIconMan.

Kindly,
Thomas

Re: FVWM: No module "FvwmTaskBar" in Fvwm 2.6.9?

[Thomas Adam]

On Mon, Aug 17, 2020 at 04:59:42PM +0200, Dr Rainer Woitok wrote:
> Thomas,

Hello Rainer,

> On Saturday, 2020-08-15 12:36:24 +0100, you wrote:
> 
> > ...
> > Custom tooltips aren't possible in FvwmButtons yet.
> 
> Well, I think I'll survive with just the clock :-)

Cool!

> However, two other minor problems showed up:
> 
> 1. While the names  of the buttons  in FvwmButtons  are placed normally,
>the names of the FvwmIconMan buttons  are placed  (using format "%t")
>as if  all names started  with two  or three blanks,  which is just a
>minor waste of time.   That's probably just the space occupied by the
>square box shown for iconified windows.   But even whith "ShowNoIcons
>True" neither this box nor this space goes away.   What's the correct
>option to use?

Show me your config and I'll take a look.

> 2. After I upgraded  again from  Fvwm version 2.6.5-r3  to 2.6.9 I found
>that the  manpage  "/usr/share/man/man1/fvwm.1.bz2"  is missing.   Is
>this Gentoo specific or did I look in the wrong place?

Sounds like the '--enable-mandoc' option to ./configure wasn't passed?
Depends how you upgraded.  I'm afraid I know next to nothing about Gentoo and
would like to keep it that way.  :)

Kindly,
Thomas

Re: FVWM: FVWN on a high density System76 screen

[Thomas Adam]

On Wed, Aug 12, 2020 at 07:25:36PM -0400, Dan Espen wrote:
> A few years ago I spent a couple of days trying to make FvwmForm and
> FvwmScript use shared code to create their widgets.  Unfortunately,
> the French comments in FvwmScript defeated my attempts to understand
> what goes on in FvwmScript.

Well, thanks to Jean Eimer who deftly submitted a PR to Fvwm3, all the
comments in FvwmScript have now been translated from French to English.  See:

https://github.com/fvwmorg/fvwm3/commit/873f5c9af9cb05582fb13a44d5d3c49062ee0d35

I presume Jean is reading the list, so thanks again!

Kindly,
Thomas

Re: FVWM: No module "FvwmTaskBar" in Fvwm 2.6.9?

[Thomas Adam]

On Sat, Aug 15, 2020 at 01:31:23PM +0200, Dr Rainer Woitok wrote:
> Others have also pointed me to
> 
>https://www.fvwm.org/Wiki/Panels/FvwmTaskBar/
> 
> and that helped me re-implementing my taskbar, except for the clock dis-
> playing the current date as tooltip when hovering the mouse pointer over
> it.  Is this still doable?

Custom tooltips aren't possible in FvwmButtons yet.  I did have a patch for
that from years ago, but it needs a bit more work.  For now, you'll either
have to live without it, or find an external clock application which can be
swallowed by FvwmButtons and also has this tooltip functionality you're after.

> > ...
> > >FvwmForm
> > Killed.
> 
> I use FvwmForm to interactively ask questions  and to interpret the ans-
> wers received.  How to do this now?

I've just resurrected this module in Fvwm3.

> Erm ... what's the difference between "Killed" and "Dead"?   But more to
> the point: How do I achieve the same effect with current methods?

No difference.  You can use the WindowList command in Fvwm, or I quite happily
use an external command called 'rofi'.

Kindly,
Thomas

Re: FVWM: FVWM on a high density screen -> FvwmForm

[Thomas Adam]

On Thu, Aug 13, 2020 at 09:02:09PM -0400, Dan Espen wrote:
> First, DTL is crap, you really want to use ISPF as it was originally
> designed.  You create a text image of the screen using punctuation
> to mark input and output fields.

Hehe.  It's an interesting idea and one which probably still survives to this
day.  For instance, QT still uses XML to describe layout of widgets -- or it
did.  But the fact remains that the idea of using text to describe graphical
forms is cool.

It's a little bit like Perl's now deprecated format specifier, and Oracle DB
used to have ways of formatting output to look like forms as well.

> Second, he says you have to restart ISPF to be able to access your
> changes.  But that start command he was issuing does not restart ISPF
> and he showed himself going to option 7.

Hehe -- thankfully I wasn't using that video as anything instructional,
otherwise I'd have been up a creek without a paddle.  By the way, I made an
assumption that ISPF was somehow old and not used much.  But it turns out it's
still got a strong following and still maintained by IBM.

So where would this typically get used?  I can imagine its use for things like
help desks and bespoke processes where panels could be rolled out to people
for liaising with customers...

Mind you, with things like Zendesk and other HTML-based efforts, I can see
ISPF being less attractive unless it was already there.

> Third, there's zero reasons to write REXX for a menu, the panel itself
> can do the entire job.

Yeah.  I was wondering that.   I've used REXX once... I rather liked it, but I
wasn't sure it was applicable to what the chap in the video was attempting to
do.

> TBADD is just like creating an array in a unix shell.
> So you build up an array then in the panel your name for the array.
> The panel figures out how big the array is and displays as many
> occurances as it can fit on the screen.

I'm going to dig a bit deeper in to this, Dan as I find it all rather
interesting.  I'll probably chat to you off-list as I'm sure others reading
this are probably wondering if FvwmForms is going to become some sort of ISPF
emulator (no, it's not!  ;)).

Incidentally, I did find this (as someone's pet project):

https://github.com/daniel64/lspf

There's definitely a lot of folks around who are interested in this.  Cool.

> A lot of the tables you saw being displayed as he was working are the
> development panels from IBM.  They're totally uninspired, I had a lot
> of fun creating replacements.

Yes, I bet you did!

> I once ran a help desk for a large herd of UNIX C programmers forced
> into working with ISPF.  They pretty much hated the environment.
> I unleashed a bunch of panels I had written on them and they were
> converted on the spot.

Given the length of their beards, I can only presume that's proportional to
their hatred?  :)  I can understand how some dyed-in-the-wool C chaps being
forced to use ISPF wouldn't like it -- and that's just me surmising with ~10
minutes worth of video watching.  :)  But these panels are a God sent.

> I never used Rational Rose.

Neither did I in the end.  Think we both dodged a bullet there.

> I wish I could show you some of the stuff I did, but of course that
> belonged to my employers so I left it behind.

Well, even mockups might be useful further down the road.

> > Well, it's back:
> >
> > https://github.com/fvwmorg/fvwm3/commit/6e65b85d127de9b18022c8073974c2f3745b14a1
> 
> Good, I think you made the right choice and it should save you some work
> anyway even if the source code base is a bit larger.

Yeah, well, sometimes it's not just about the SLOC.

In digging around what FvwmScript offers, and what FvwmForm was doing, I can
perhaps understand why we have two similar modules.  But the more I look at
FvwmScript the more I can see just how similar it is to what FvwmForm does,
and that FvwmScript doesn't provide the flexibility that FvwmForm does in how
it approaches the text <-> layout point.   It's much more explicit/error prone
in FvwmScript.

I think I'll start in getting some sort of widget parity between FvwmScript
and FvwmForm.  I probably won't ever end up writing anything to convert
FvwmScript configs to FvwmForm -- that's much harder.  Not least of which
because FvwmScript's config parsing is wholly written in YACC.

Then I can look at tables.

> By the way, I think you've been doing some impressive work.

Cheers!

> I don't know if I'm slowing down due to age or what, but I'm finding it
> increasingly hard to do any coding.  I've been working out and doing
> lots of physical work on the house and in the yard.  Maybe I'm just
> reveling in not having to do coding any more.

I never wanted to be a computer programmer.  I had my heart set on
geochemistry.  Turning my hobby (programming) in to my career though hasn't
been so bad.  But since I do much more management day-to-day than programming
now, it does mean I've started to enjoy programming in my spare time now more
than I 

Re: FVWM: When will fvwm3 be ready to start trying out?

[Thomas Adam]

Hi,

On Thu, Aug 13, 2020 at 08:33:48PM -0500, Chris Bennett wrote:
> I've been using fvwm2 for a while, but I do find the syntax a bit hard
> to follow.

That hasn't changed in Fvwm3 (yet), and certainly won't any time soon.

> I've also had problems getting many example configs to work right.

Which configs have you been trying, what were you expecting, and what hasn't
worked for you?  Fvwm2's syntax for config files hasn't changed much at all
over the last twenty years, so failures are probably down to external tools
being used, or something else.

> Which means I'm pretty open to trying fvwm3 out.

Testing welcome.  Patches even more so.

> I've cloned the git, but I haven't had a chance to look at the code yet.

Well, it's ready for testing now even if there's no RC yet.  On that point,
see:

https://github.com/fvwmorg/fvwm3/projects/1?card_filter_query=milestone%3A1.0

For when I'll consider version 1.0 releasable.  This is still subject to
change depending on what bug reports I get.

Kindly,
Thomas

Re: FVWM: FVWM on a high density screen -> FvwmForm

[Thomas Adam]

On Thu, Aug 13, 2020 at 05:44:10PM -0400, Dan Espen wrote:
> I had a lot of experience with IBM ISPF panels.
> I wanted to model FvwmForm along those lines.
> That's were the data reading and saving came from.

That's amazing!  I really don't know anything about IBM's early software.  The
closest I ever got was Rational Rose, back when RUP was popular (early 2000s i
when I was exposed to that at University).  Needless to say I've not been
involved with any commercial companies which have used IBM.

I've just watched a Youtube video which highlighted ISPF Panels.  I can now
really appreciate why you were going down that route.  What a lot of fun!

> For tables, ISPF lets you say something like here is a line but the line is a 
> model
> for a table.  So, when you design an ISPF table it's a lot like
> FvwmForm's LINE.  You put a bunch of fields on a line with the
> understanding that the data determines how many times the line is
> repeated when displayed.

Right -- I think I understand this.  I'm basing a lot of this from this video:

https://www.youtube.com/watch?v=eA3rvZwU7e8

Is this what you're referring to, Dan?

> With FvwmForm, you'd say, here is a line that should be displayed in
> a box 10 lines high.  So, for example, with FvwmForm's implementation
> of FvwmTalk, where it shows the last error line, instead you'd say
> I want to show up to the last 10 error lines.

OK.

> ISPF itself handles things like scrolling the data if the data is
> bigger than the display area.
> 
> So, that's the table part.

It's really interesting.  Just on the mentioned video above, the style looks
similar to a lot of terminal libraries which golang has (one such example
would be:  https://github.com/gizak/termui).  I appreciate we're talking about
X11 here, but it's still not to see that in 2020, people are becoming more
invested in the terminal and CLIs than they perhaps used to.

> I had the idea that FvwmForm could display a table of lines,
> let you add or delete lines, or select a line.
> When you select a line you'd see another table of the fields
> on the line.

I really like this idea.  I wonder though how heavy this would be on window
resize?  It might flicker through redraws if we're not careful.

> Glad to hear it.
> Fvwm is still pretty far from being able to configure itself.
> I did some work along those lines with FvwmAnimate and FvwmForm-Form
> but didn't get far enough.

Well, it's back:

https://github.com/fvwmorg/fvwm3/commit/6e65b85d127de9b18022c8073974c2f3745b14a1

Kindly,
Thomas

Re: FVWM: detecting "continuous" keyboard modifier

[Thomas Adam]

On Tue, Jun 23, 2020 at 11:57:45AM -0400, Paul Fox wrote:
> Hi --
> 
> Is there a way in fvwm to distiguish these two sequences?
> alt  tab  alt  tab
>  ^tab and alt keys both released here
> and
> alt  tab  tab
>  ^ only tab key released here
> 
> I don't recall seeing anything about this in the docs -- but that
> doesn't mean it's not there!  :-)

This is not possible at the moment.

Kindly,
Thomas Adam

Re: FVWM: FVWN on a high density System76 screen

[Thomas Adam]

On Wed, Aug 12, 2020 at 07:58:59PM -0400, Dan Espen wrote:
> We had a French developer working with us for many years.
> Right now I can't recall his name, I used to fix up all the
> documentation he wrote.  He offered to fix up the comments but
> never got around to it.

Olivier Chapuis, most likely?  Really clever chap.   Ended up going on to form
Metisse, as I recall.

> I also had a plan to add boxes to FvwmForm.  The idea being
> you'd put fields in lines, lines in boxes, then boxes in the form.
> Relief lines around the boxes would be optional.
> Just an idea, I never started that.

I think that's a nice visual que, and the same could be applied to creating
tables as well.

> I wanted to do the widgets first.

This is definitely an area where FvwmScript has the upperhand, although I
admit I've never looked too deeply at how FvwmScript implements the widgets it
offers.

> Okay, at least you know something is missing.

One of many things.  :)

> > If you have a list of things which could be moved in to FvwmScript from
> > FvwmForm, I'd be interested in seeing that.  One of the things I liked about
> > FvwmForm (I did used to use it, BTW) was it could be told to grab the 
> > XServer.
> > So I wrote a FvwmForm instance to do just that in StartFunction to go in to
> > Work or Home mode, which would open certain applications, etc.  Although I
> > don't have a need for that now, the ability to grab the XServer would still 
> > be
> > useful.
> 
> Not sure I understand.

I was referring to FvwmForm's "GrabServer" option.  I used to make use of that
a lot in the FvwmForms I used to use.

> If you look at the comments I left in FvwmForm, I had some idea about
> it sitting around as a form display server to make it even faster.
> 
> I'm not sure about FvwmScript but I don't think it has the same capability
> to save and reuse what you last entered as FvwmForm does.

Oh, almost certainly not.

> Since we are blue skying here, I also had an idea that you could use
> FvwmForm to design new FvwmForms.  It would need the ability to display
> tables.

Could you expand on this a bit?

I'm happy to bring FvwmForm back (to Fvwm3) if the overlap with FvwmScript is
to minimal.  But I'd like to still explore in which direction an amalgamation
between FvwmScript <-> FvwmForm should go.  If I've overlooked this in the
wrong direction with how things are now, I'm happy to stand corrected!

Kindly,
Thomas

Re: FVWM: Microsoft Teams

[Thomas Adam]

On Thu, Aug 13, 2020 at 09:27:10PM +0200, Dr. Nikolaus Klepp wrote:
> If that's the case you can build a preloaded library that interceps the
> function call.

I mention it on that wiki page.  So...

Save this as ~/pl_xsetinputfocus.c

-
#include 
#include 

/* Compile with:
 *
 * gcc --shared -fPIC pl_xsetinputfocus.c -o disable_xsetinputfocus.so
 *
 * Then use:
 *
 * LD_PRELOAD=/path/to/disable_xsetinputfocus.so some_application
 */

int XSetInputFocus(Display *d, Window w, int i, Time t)
{
return 0;
}
-----

-- Thomas Adam

Re: FVWM: Microsoft Teams

[Thomas Adam]

On Thu, Aug 13, 2020 at 05:50:36PM +0100, Klaus Ethgen wrote:
> So I endet more than one time now, typing password into teams where it
> should never ever been.
> 
> I already have !FPFocusByFunction and !FPFocusByProgram set but it
> doesn't work.

Teams might be implicitly using XSetInputFocus() although it's an Electron
App, so it's unclear.  You could certainly use `xprop -spy` on the window.

Speaking of helping things, read this and double-check you're applying these
things to Teams:

https://www.fvwm.org/Wiki/Tips/FocusStealing/

-- Thomas

Re: FVWM: FVWM2: Test if windows has title bar

[Thomas Adam]

On Thu, Aug 13, 2020 at 08:41:10PM +0200, Carsten Kunze wrote:
> Hello,
> 
> how is it possible to test if a window has a title bar (i.e. an equivalent to 
> the test if a windows has resize handles with "ThisWindow (HasHandles)")?

No.  But I'm reminded of this:   https://xteddy.org/fvwm/patches.html#toc2

In lieu of that, you could write a function which used State to track this if
you know whether a window is going to have a title or not, as in:

Style foo, State 0
Style somethingElse, !State 0

DestroyFunc Foo
AddToFunc   Foo
+ I ThisWindow (State 0) DoSomethingForTitleOnWindow
+ I TestRc (NoMatch) DoSomethingForNoTitleOnWindow

-- Thomas

Re: FVWM: FVWN on a high density System76 screen

[Thomas Adam]

On Wed, Aug 12, 2020 at 07:25:36PM -0400, Dan Espen wrote:
> A few years ago I spent a couple of days trying to make FvwmForm and
> FvwmScript use shared code to create their widgets.  Unfortunately,
> the French comments in FvwmScript defeated my attempts to understand
> what goes on in FvwmScript.

That's interesting.  Do you still have your attempts anywhere?  I'm sure we
could find some someone to help translate the comments.  I agree -- it's
difficult to follow along.

This approach of unifying FvwmForm and FvwmScript would be interesting
beginnings to also merging in FvwmButtons to really create some sort of
ludicrous hybrid that could be really flexible.  That'll need thinking
through, but I appreciate that wasn't your intent.

> In my opinion, FvwmForm does all it's layout correctly, working off
> the fonts it's using.  Plus it has a GUI to configure the fonts it
> uses so you don't have to mess with a config file.
> 
> So, since you dropped FvwmForm in fvwm3 did you add an FvwmScript
> dialog to configure FvwmAnimate?

It was always going to be a tough call.  At the time, in conversation with
people the prevailing opinion was that FvwmScript was being used more heavily
because it had a lot of feature that FvwmForm did not.  I know the overlap
between the two isn't 100%.

I haven't yet moved the FvwmForm dialogue across to FvwmScript, but I'm aware
it needs to be done.

If you have a list of things which could be moved in to FvwmScript from
FvwmForm, I'd be interested in seeing that.  One of the things I liked about
FvwmForm (I did used to use it, BTW) was it could be told to grab the XServer.
So I wrote a FvwmForm instance to do just that in StartFunction to go in to
Work or Home mode, which would open certain applications, etc.  Although I
don't have a need for that now, the ability to grab the XServer would still be
useful.

Kindly,
Thomas

Re: FVWM: FVWN on a high density System76 screen

[Thomas Adam]

On Wed, Aug 12, 2020 at 06:54:53PM -0400, Dan Espen wrote:
> Recently I went from a 1600x1200 monitor to a 3840x2160 monitor.
> 
> Fvwm was the least of my problems.

Same here.  Mind you, even on laptops with 4K screens (so-called HiDPI), the
situation is diabolical.  X11 really doesn't work seamlessly in these
conditions.  I've resorted to all sorts of xrandr --dpi tricks without much
success.

Even if you do manage to get some scaling working, you're still left with the
various widget libraries playing nicely with different applications.  For
example, on this laptop which has:

% xdpyinfo | grep dimensions
  dimensions:3840x2160 pixels (1016x571 millimeters)

Firefox looks fine now that I've wrangled everything, but menus, buttons and
other widgets are so small I can't even see what I'm clicking on half the
time.  Messing with GDK_SCALE env var and others helps, but it's still not
great.

It's a shame that outside of larger DEs like GNOME where this is all
integrated, X11 and widget libraries just fall apart.  I'm not sure what the
best solution is to address this, but something needs to be done since it's
dire.

> An old config should work pretty well.
> Mine was born in 1996 and is pretty much the same as it was then,
> except that I changed to a more modern font syntax a pretty long time
> ago.

Hear hear!

-- Thomas

Re: FVWM: No module "FvwmTaskBar" in Fvwm 2.6.9?

[Thomas Adam]

On Wed, Aug 12, 2020 at 01:35:46PM +0200, Dr Rainer Woitok wrote:
> While I think I could also provide the buttons  via module "FvwmButtons"
> and could use  a separate digital clock application,  I did neither find
> an "AutoHide" specification for "FvwmIconMan" nor for "FvwmButtons".

Autohide is already in the FAQ and is independent of any module.  See:

https://www.fvwm.org/Archive/Faq/#autohiding-fvwmbuttons-or-other-windows

For everything else such as a Start button and a clock is achievable through
FvwmButtons.

> And while we're at it, here's a list of other Fvwm modules important for
> me:
> 
>FvwmAuto

Present.

>FvwmConsole

Present.

>FvwmForm

Killed.

>FvwmIdent

Present.

>FvwmPager

Present.

>FvwmWinlist

Dead.

> Are all of these still available in Fvwm 2.6.9 and not yet deprecated?

You'll hate Fvwm3.

-- Thomas

Re: FVWM: missing titlebar, decorations for one program (Microsoft Teams electron app)

[Thomas Adam]

On Wed, Apr 29, 2020 at 05:38:15PM +1000, Tim Connors wrote:
> https://webcache.googleusercontent.com/search?q=cache:0uXm_EuziOQJ:https://fvwmforums.org/forums/topic/opera-now-has-no-decorations-how-to-restore/+&cd=5&hl=en&ct=clnk&gl=au
> 
> Agreed?

Agreed.

-- Thomas Adam

FVWM: Fvwm Forums back online

[Thomas Adam]

Hi all,

Just a quick note to say that myself, Somiaj, and theBlackDragon have
resurrected the fvwm forums:

https://fvwmforums.org

All previous data from the old forums has been preserved, and those of you who
had existing accounts, and had posted before, will still find you have an
account.

The software for the forums is Discourse (https://www.discourse.org/)

Any questions, do let me know.

Hope everyone's safe and continues to remain so.

Kindly,
Thomas

Re: FVWM: Q: What is the config entry for selecting a theme?

[Thomas Adam]

On Sat, Apr 18, 2020 at 03:00:11PM -0500, Steven Lembark wrote:
> I've revewed doc's at the fvwm.org site, checking the FAQ (which 
> entirely lacks an answer to what should be a simple question)

Patches welcome on this, if you feel something should be improved.

> and the "themes" .

fvwm-themes hasn't been touched in years, so I couldn't tell you whether the
themes as-is still work, or how it's meant to be installed.  There is
documentation of for it somewhere, no doubt.

These days though I would suggest you look at:

http://fvwm-nightshade.github.io/Fvwm-Nightshade/
https://fvwm-crystal.sourceforge.io/
https://github.com/NsCDE/NsCDE

> Per the doc's I've moved my config to ~/.fvwm/config 
> (), which didn't seem to help.

That does look old in some parts of its syntax.  Have you ran
"fvwm-convert-2.6" over the file?

-- Thomas

Re: FVWM: Changing mouse cursor size

[Thomas Adam]

Hi Dominik,

On Sun, Feb 16, 2020 at 12:57:20AM +0100, Dominik Vogt wrote:
> Debian based distros seem to have some kind of scalable "cursor
> themes".  Has anybody (i) tried to use them with fvwm and (ii)
> managed to actually define a custom scaling factor without using
> some config dialog from the distro?

I'm not too sure what sort of themes you're referring to, however on my
laptop(s) which have 4K screens (which X11 hates until you mess about with all
manner of DPI settings, and even then the various X widget libraries have no
clue about scaling), I set the following in my ~/.Xdefaults file:

Xcursor.theme: cursor-theme
Xcursor.size: 90

Presumably, the 'Xcursor.size' is what you're after?

Kindly,
Thomas

Re: FVWM: FVWM3: RandR quirks and solutions?

[Thomas Adam]

On Fri, Jan 10, 2020 at 05:20:07PM -0600, Brian wrote:
> I know that Thomas is removing some redundant functions, I wonder if
> fvwmform is one of them?

That's correct.  FvwmForm was removed in commit
7b8684385826d71b38be96f3c1a4e82c39aa4b38

> Fvwm manpages can always be contributed to the list and the development
> team with review and determine if they belong in the repository.  Help
> with testing and writing are always appreciated.

fvwm3.1 exists, and can be built with the --enable-mandoc option to
./configure -- this is not done automatically so you'll have to manually
specofy it and ensure you've docbook and xslt, etc., installed.

I am updating the documentation as I go, but that doesn't mean it's obvious
where things are.  FVWM has a long history and a surprisingly good amount of
documentation which needs rationalising and made clearer.

Patches welcome!

Thomas

FVWM: FVWM3: RandR support ready for testing

[Thomas Adam]

Hi all,

Please can I ask any willing volunteers reading this to take a look at the
master branch of FVWM3 and try it out [0]?

Your current configs will be valid (FVWM3 will look in the same locations as
fvwm2), minus the deprecation of the Xinerama* commands.  Previous module
support for Xinerama is not available at the moment; to be added in later on.

You can compile and install FVWM3 alongside FVWM2; the namespaces/versioning
is different, so it won't clobber FVWM2.  The FVWM3 binary is called 'fvwm3'.

What I'm hoping for right now is the bare-bones functionality of:

* Correct screen detection (that is, correct number of physical screens) --
  this is currently printed to STDERR when FVWM3 starts up, so check there;
* Commands such as MoveToScreen with a valid RandR monitor name works;
* The 'Screen ' conditional works for All/Any/Current, etc
* Monitors can be added/removed/changed, and FVWM3 shouldn't need a restart to
  pick up on any changes;
* FvwmIdent should report which monitor a specific window is on correctly

What isn't working:

* Rotation isn't support yet, and there's only a stub for RRChangeNotify events,
  although FVWM3 will call "All Placeagain" by default.  It might look weird,
  but I'll change that for a dedicated function(s) later on;
* Modules don't know which monitor they're on, so FvwmIconMan for example is
  going to struggle with a resolution set to 'Screen'.

I'm aiming for everything mostly behaving the same way it used to with
Xinerama, but this time with RandR.

Any feedback is going to be greatly received, believe me.  I've given this
only the lightest of testing, and it seems to be working OK for me, but I'm
hoping those of you brave enough will start flooding me with bug reports [1].

Thanks!

Thomas

[0]:  https://github.com/fvwmorg/fvwm3
[1]:  https://github.com/fvwmorg/fvwm3/issues

Re: FVWM: Change window decoration mouse button mapping for just one app?

[Thomas Adam]

On Wed, Dec 11, 2019 at 08:01:14AM -0500, Tom Horsley wrote:
> I'm trying to train myself to leave one specific app
> running instead of clicking on the "close" button
> in the window decorations. (There is a bug that
> makes startup really slow).
> 
> Can I make the close button binding not do a close
> just for one app? (If I really want to close it, I can
> use File->Exit). Or even make the close button simply
> not be there at all just for one app?


Bind the appropriate button to a function which does this:

DestroyFunc X
AddToFunc   X
+ I ThisWindow ("ClassOfApplicationYouWantToKeep") Break
+ I Close

Other options such as using FvwmEvent also exist.

-- Thomas Adam

Re: FVWM: FvwmPerl not compatible with Perl 5.26 and later?

[Thomas Adam]

On Sun, Dec 08, 2019 at 03:55:50PM -0800, Lance wrote:
> Is this a known issue? I looked at the source code for fvwm 2.6.9 and it
> seems to have to same issue.

If you could check master, I can release a bug-fix version of FVWM for this.
Just let me know.

Kindly,
Thomas

Re: FVWM: FvwmPerl not compatible with Perl 5.26 and later?

[Thomas Adam]

On Sun, Dec 08, 2019 at 03:55:50PM -0800, Lance wrote:
> Is this a known issue? I looked at the source code for fvwm 2.6.9 and it
> seems to have to same issue.

Fixed in git, yes.

-- Thomas Adam

Re: FVWM: Style ... SkipMapping

[Thomas Adam]

On Mon, Nov 18, 2019 at 06:36:13PM +0100, Dr Rainer Woitok wrote:
> And it works?   Well, I have "FixedPPosition" rather than "NoPPosition".
> Could that matter?   Or is the  relevent difference  that you  start the
> browser from  within "fvwm"  while I'm  starting it  from within a shell
> script?

If it's not working for you, then I would suggest you do the following:

1.  Launch firefox.  When it's running, use FvwmIdent or xwininfo to ascertain
the *class* of the window.  It's either going to be Firefox or something else.
If it's not 'Firefox' then you'll understand why the Style isn't matching.

2.  Try adding:  EWMHIgnoreStateHints

Kindly,
Thomas

Re: FVWM: Two small oddities

[Thomas Adam]

On Fri, Jun 07, 2019 at 10:31:56PM -0700, Ronald F. Guilmette wrote:
> 1)
> 
> First, under fvwm, some certain applications, specifically evince and
> the chromium browser, display with any of the usual outer framing that
> fvwm seems to provide for all other X application programs, e.g. Xterm,
> xpdf, and the Firefox and Oprera browsers.

Chromium has an option to disable this.

As for evince and others, this is due to CSD (Client-side Decorations).
There's no proper way around this other than to use a patched gtk which uses
LD_PRELOAD to override this behaviour.

Have a look at gtk3-nocsd (https://github.com/PCMan/gtk3-nocsd).  I've just
checekd my FreeBSD machine -- it's not packaged.

-- Thomas Adam

Re: FVWM: two questions about icons

[Thomas Adam]

On Wed, Jun 05, 2019 at 02:12:07PM -0700, Ronald F. Guilmette wrote:
> The default theme for fvwm includes a big box that appears in the lower
> right hand corner of the screen.  Is there a name for that whole thing?
> If so, and if someone would be kind enough to tell me what it is, then
> I'll know what to call it in future.

Use FvwmIdent or xprop to find out.

> Anyway, that wide but not very tall box includes several different parts:
> 
> 1) A part where all of the current open windows are listed by name (and
>each name is clickable)

FvwmIconMan

> 2)  A square part consisting of a sort of map, divided into four quadrants
> that shows you whar part of your four-part virtual desktop you
> are currently actually looking at.

FvwmPager

> For me, 3c was in fact just a blank space.  I just now figured out why.  On
> FreeBSD, the xload command is in a separate package, all on its own, and that
> package is *not* currently listed as dependency of the fvwm package.  (I will
> be speakingt o the maintainer about this.)  As a result, my system was running

No sane maintainer is going to make xload a dependency of FVWM.  The point of
the default config here isn't to do that, but to provide some sane defaults
where possible.

> In any case, I would like to suggest to the fvwm maintainers that they do as
> I have done and substitute out the xload invocation in the default theme and
> replace it, as I have done, with a digital xclock display of the current date.

No.  I think what you've done is to prove the point -- that being that you're
expected to use this config as a starting to point to make your own
modifications, which you're doing.

> I would really appreciate it if the maintainers would fix this self-evident
> bug.  It is most annoying.  The minimization/iconization process should not
> be hiding minimized window icons underneath the boxes created by the default
> theme.  That's just wrong, and one would hope that there might be some simple
> way to get the window minimization/iconization process to avoid doing this
> annoying and clearly wrong thing.

This isn't a bug.

Thanks,
Thomas

Re: FVWM: FvwmForums: Change of engine and help with theming

[Thomas Adam]

On Wed, Jun 05, 2019 at 07:32:42AM -0600, Glenn Golden wrote:
> +1 for plain old nntp, with a digest option added too, as Lucio suggested.

The point of this email thread wasn't to ask the question:  "how can we
appease ourselves for those who want to use forums".  The point was to ask to
see if there was anyone who wishes to help theme the thing.

Like it or not, forums are not going to go away.  FVWM has had one for ~15
years now.  As a project, we should be recognising that there can be more than
one method for people to communicate and engage.  For some, forums are seen as
"better" in that there's an easier ride for people to attach images, and focus
in on topic they care about.  You can't easily do that with email.

I know this does increase burdens on contributors -- but in the last fifteen
years it hasn't been a problem.  Most people who use the forums are ultimately
pointed to this list for additional help that can't be solved elsewhere, and
that's OK, too.  I am not expecting contributors to this project to monitor
both emails and a forum if they don't want to.

-- Thomas Adam

Re: FVWM: _NET_WM_NAME

[Thomas Adam]

On Wed, Jun 05, 2019 at 04:30:07PM +0100, Klaus Ethgen wrote:
> Here the relevant props:
>WM_NAME(STRING) = "GNU Image Manipulation Program"
>_NET_WM_NAME(UTF8_STRING) = "[Verdon] (importiert)-1.0 (RGB-Farben 
> 8-Bit-Gamma-Ganzzahl, GIMP built-in sRGB, 1 Ebene) 1024x683 \342\200\223 GIMP"

Right... and?  You're still not telling me what the problem is.

FVWM will read this property and transliterate the UTF8 accordingly.

What is it that is causing a problem?

Kindly,
Thomas

Re: FVWM: _NET_WM_NAME

[Thomas Adam]

On Wed, Jun 05, 2019 at 03:46:49PM +0100, Klaus Ethgen wrote:
> However, the freedesktop guys are known to add often incompatible stuff
> that is not supported by other desktops than their own. And they are
> resistant to learn that what they do is stupid. So is there a way to get
> that property used by fvwm?

_NET_WM_NAME is already supported by FVWM.

What's the problem you're having?

-- Thomas Adam

Re: FVWM: FvwmForums: Change of engine and help with theming

[Thomas Adam]

On Tue, Jun 04, 2019 at 07:46:02PM -0400, Dan Espen wrote:
> Ever since Fvwm started using forums, I find I can't track everything
> going on.  Sorry, no inclination to follow a forum.  Wish we'd go back to
> exclusively email.

:)

I personally don't disagree -- but you know what the old maxim says:  "Give
the people what they want".  It seems the y00fh of today prefer forums.  God
knows why, but they do.

At least we're offering both forums and email, even though that does
potentially create a split.

> I realize there is a collection of documentation on the forums.
> Wish that was on the official web site instead.

We could shunt the wiki over to Github as well -- that would make it inclusive
of the website.

-- Thomas Adam

FVWM: FvwmForums: Change of engine and help with theming

[Thomas Adam]

Hello everyone,

I know things have been rather quiet on this list of late -- but behind the
scenes, there's still plenty of things happening with FVWM.

One of these is we're taking a look at moving the FvwmForums away from phpBB.
This was a great forum to use back in the early 2000s when there wasn't a lot
of choice.  But as of the past year or so, using phpBB and maintaining it has
become a burdensome nightmare for myself and Jaimos.

We've recently been looking at alternatives, and the one which seems to offer
equivalent functionality as phpBB (but without the perceived maintainence
nightmare), is bbPress (https://bbpress.org/).

We've imported the forum database to stand-up the core funtionality with the
same information.  This has worked fine.

What we now need is for someone to help us theme the main bbPress instance, to
make it look like a fvwm-type website (utilising the CSS/colours from
fvwm.org).  Originally, I thought I could do this, but that's not going to
happen, as I've too much other work to be getting on with.

Plus, this would be a good project for someone.

If anyone's interested (or you have any questions), do please let me know.

Thanks all,
Thomas

Re: FVWM: Full crash when using an invalid PNG for a mini-icon

[Thomas Adam]

On Tue, 28 May 2019 at 14:47,  wrote:
>
> Hi All,
>
> I'm using fvwm 2.6.7 from Debian/stretch.
>
> If I execute the command
>
> Pick WindowStyle MiniIcon password.png
>
> I get a full FVWM crash (and consequently an X server exit + lost work +
> tears).

Can you please ensure FVWM has been built with debug symbols, and get
a backtrace from gdb?

Thanks,
Thomas

Re: FVWM: focus stealing

[Thomas Adam]

On Fri, 24 May 2019 at 12:10, Harald Dunkel  wrote:
>
> Hi folks,
>
> the man page doesn't tell (AFAICS), so I wonder how I could prevent
> chrome, rocketchat-desktop and others from stealing input focus (using
> FocusFollowsMouse)?

See:  http://fvwmforums.org/wiki/Tips/FocusStealing/

-- Thomas Adam

Re: FVWM:

[Thomas Adam]

On Sat, Jan 05, 2019 at 01:27:38AM +0100, Peter Holm wrote:
> Is it possible to add an already started application (for example
> xterm) to fvwmbuttons.?

Yes -- how are you thinking of doing that?  Would it be by clicking a button
in FvwmButtons?

> Or is it better to use FvwmIconMan .? I don't get how to get
> FvwmIconMan to use numbered states.

FvwmIconMan has nothing to do with FvwmButtons.

> Reason to ask - I have managed to make some grouped windows which I
> want to add a buttonbar to, or on the fly or add and remove the
> windows  into FvwmButtons, and ther have a Button.Panel for the
> windows.
> Best would be if I could get the buttons to show up in the same order
> as the windows is layered.

Sounds as though you want to use FvwmIconMan then.

-- Thomas Adam

Re: FVWM: Escaping calls to State and Infosostore in piperead

[Thomas Adam]

On Wed, Dec 26, 2018 at 05:33:55PM +0100, Peter Holm wrote:
>   echo All '(State 31)' MovetoPage -1p 0p;\

Aside from avoiding asking the more obvious question of why you want to do it
this way, there's no code change required.  The above is wrong -- don't quote
'(State 31)' as this will throw the parser out.  Try:

All (State $[infostore.transi]) MoveToPage -1p -0p

-- Thomas Adam

Re: FVWM: FakeClick

[Thomas Adam]

On Mon, Jun 25, 2018 at 02:18:44PM +0100, Klaus Ethgen wrote:
> Hi Folks,
> 
> I try to get some automatic button press working but failed so far.
> 
> What I want to archive is to klick the middle mouse button in a xterm
> instance to paste some text. Alternative do shift-Insert.
> 
> What I tried so far:
> - `FvwmCommand 'FakeClick depth 3 press 2 release 2'` (alternative with
>   some waiting period in between)
> - `FvwmCommand 'ThisWindow FakeClick depth 3 press 2 release 2'`
> - `FvwmCommand 'ThisWindow FakeKeypress modifiers 6 press Insert'`
> - even `FvwmCommand 'ThisWindow FakeKeypress a'`
> 
> None worked.
> 
> Any idea how to archive the goal preferred with fvwm internal stuff?

You need to tell xterm to listen to sendevents (allowSendEvents) since
synthetic key events are an inherent security risk.

Even despite turning this on, there's no guarantee of this working, and
certainly not for any other application.

As far as your copy/paste situation goes, use xsel(1) or some such instead.
Then you wouldn't need to worry about this notion of keypresses at all.

-- Thomas Adam

FVWM: FVWM 2.6.8 released

[Thomas Adam]

Hi all,

Just a note to say that FVMM 2.6.8 has been released.  Nothing special in this
release in terms of features.  This is mostly a bug-fix release.  See the
following for further details and to download the release tarball:

https://github.com/fvwmorg/fvwm/releases/tag/2.6.8

Enjoy!

Thomas

Re: FVWM: Resizing BarButtons based on display size

[Thomas Adam]

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.

-- Thomas Adam

Re: FVWM: WinList replacement wit icons?

[Thomas Adam]

On Sat, Mar 03, 2018 at 08:58:42AM +0200, Michelle Konzack wrote:
> Good morning FVWM GEEKS,
> 
> while surfing the FVWM Internet for new ideas, I like to use  
> like under windows, mean with icons.  The left side if this
> 
> is how it should look like.
> 
> Does anyone have done this already and has a working example?

I'm sure someone did this using FvwmButtons; have a look on the FVWM Forums;
maybe a "ring menu" will be a good start.

Failing that, third-party programs might be an option, if they are EWMH
capable.

Kindly,
Thomas

Re: FVWM:

[Thomas Adam]

On Tue, Feb 27, 2018 at 10:04:52PM +0200, Michelle Konzack wrote:
> Hi *,
> 
> Am 2018-02-27 hackte Thomas Adam in die Tasten:
> > The other option here is to run:
> >
> >   fvwm-convert-2.6
> 
> This I had already done and it failed becasue I have MANY config files.

I'd be interested to know where.  The script is only as good as the
information fed to it.  Garbage in == garbage out.

-- Thomas Adam

Re: FVWM:

[Thomas Adam]

On Tue, Feb 27, 2018 at 07:45:50PM +0100, Dominik Vogt wrote:
> On Tue, Feb 27, 2018 at 05:51:52PM +0200, Michelle Konzack wrote:
> > Am 2018-02-27 hackte Dominik Vogt in die Tasten:
> > > Is the file that defines the root menu in this list?  Have you
> > > double checked the menu name and the binding?  Is there any
> > > problem with numlock or the other sticky modifier keys?
> > 
> > I have currently NO root menu, I just saw, that there is  a  non-visible
> > character in the filename which prevented my "tdfvwm-daemon" to read the
> > config file like
> > 
> > PipeRead `tdfvwm-daemon Menus.d`
> 
> Is the "no root menu" issue solved then?
> 
> That leaves the "comma" warning.  If you can't find it by looking
> at your files, try adding more "echo" commands to narrow it down
> to a specific place.  It's probably in a style or a window
> circulation command (Next, All, etc.).  Maybe this grep helps:
> 
>   grep "[[(].*," ~/.fvwm/*

The other option here is to run:

  fvwm-convert-2.6

over the main fvwm configuration file.  (See the manpage as this will follow
Read statements).  I suspect---given what we're seeing here---that stray
commas are the least of Michelle's concerns, which the conversion script ought
to address.

-- Thomas Adam

Re: FVWM: Jumping cursor

[Thomas Adam]

On Tue, Feb 27, 2018 at 10:13:50AM +0200, Michelle Konzack wrote:
> Good morning,
> 
> can someone tell me the option, which prevent a jumping  cursor  in  the
> middle of an application window?

http://fvwmforums.org/wiki/Tips/FocusStealing/

-- Thomas Adam

Re: FVWM: Several new behaviors by switching from 2.6 to 2.8

[Thomas Adam]

On Sat, Feb 24, 2018 at 04:47:18PM +0200, Michelle Konzack wrote:
> Hello FVWM community,
> 
> I have several problems and I do not find the reason, why it does not
> more work
> 
> 1) The FvwmPager does more show the icon names of the applications

Eh?  Are you referring the the labels of the windows in the pager?

> 2) A click on a application in the FvwmPager does not more give the
>focus

It does; this behaviour has not changed.

> 
> 3) Programs iconified can not more deiconified by clicking

They can.

> 4) Hidden windows do not more come in the foreground if I click
>on FvwmIconMan (is now togling), mean, even if the Window is
>maximized, I clich does not bring it in the foreground but
>instead iconify it and I have to click again, to get it.

There's nothing about FvwmIconMan which has changed to effect this.

> 5) IconBox does not more work...
>All Iconified windows are now clutering arround uncontrolled.

There is no more FvwmIconBox, but the IconBox style remains unchanged.

The long-and-short of this, Michelle is you need to send through your config
as that will be the thing which is causing this.

As for FVWM versions, there is no 2.8 version.  What are you looking at?

-- Thomas Adam

Re: FVWM: Why does the list have no mailiglist headers anymore?

[Thomas Adam]

On Sat, Feb 24, 2018 at 05:59:10PM +0200, Michelle Konzack wrote:
> Why does the list have no mailiglist headers anymore?

Which headers?  What do you think has changed?

-- Thomas Adam

Re: FVWM: Define menu-entry as disabled (greyed out)

[Thomas Adam]

On Thu, Feb 22, 2018 at 10:17:09PM +0100, Kalten wrote:
> But how would I use a Test-command to add the entry disabled and “greyed
> out”?

You can't.  The greyed out menu entries are as a result of FVWM honouring MWM
Hints.

-- Thomas Adam

Re: FVWM: Code Licence

[Thomas Adam]

On Sun, Feb 11, 2018 at 08:59:15AM +1030, Viktor Griph wrote:
> 2018-02-11 8:24 GMT+10:30 Thomas Adam :
> > Hence, the only known email address is:
> >
> > robert.j.nat...@baesystems.com
> >
> > I'd be amazed if he still worked for BAE.  Meh.  I could try phoning him 
> > based
> > on the information you've given, Viktor.  It's certainly a help, thanks!
> 
> I think he might actually do. I just searched Linked In, based on the
> information that he used to work on BAE, and found a profile[1] which
> matches with the background given in an interview in the Linux Journal
> 1997[2].

Mail sent.  Thanks for your efforts.

-- Thomas Adam

Re: FVWM: Code Licence

[Thomas Adam]

On Sun, Feb 11, 2018 at 08:10:15AM +1030, Viktor Griph wrote:
> I think he has moved from the above address. At least there is a
> Robert J Nation who has that address listed as a previous address:
> https://www.whitepages.com/name/Robert-J-Nation/Deerfield-NH/2i6uza7

I didn't know about the "J" as his middle name.

Thanks to my efforts on mail archiving[0] I used that to find this thread:

http://www.fvwm.org/fvwm-ml/8314.html

Hence, the only known email address is:

robert.j.nat...@baesystems.com 

I'd be amazed if he still worked for BAE.  Meh.  I could try phoning him based
on the information you've given, Viktor.  It's certainly a help, thanks!

Thomas

[0]  https://github.com/fvwmorg/fvwm-ml

Re: FVWM: Code Licence

[Thomas Adam]

On Sun, Feb 11, 2018 at 07:27:37AM +1030, Viktor Griph wrote:
> I think some of them are still subscribed to the fvwm-workers list. I
> know that Simon Griph has not changed his e-mail address since he
> submitted his patches.

Good to know, and nothing a mail-shot to fvwm-workers@ wouldn't cure --
something that would happen anyway.

Whether the relevant people read it or not is a different question.  ;)

-- Thomas Adam

Re: FVWM: Code Licence

[Thomas Adam]

On Sat, Feb 10, 2018 at 09:50:23PM +0100, Dominik Vogt wrote:
> Hi Thomas,

Hello, old friend.  How are you?  Keeping well, I trust?

> On Sat, Feb 10, 2018 at 04:32:51PM +, Thomas Adam wrote:
> >   Robert Nation
> >   8 Huckleberry Lane
> >   Merrimack, NH
> >   03054

Ths is interesting.  I even took a look on Google Maps, it seems like a nice
place.  I could always send a postcard to find out.  But 2003 was a while ago
now.

> I'm neither sure whether this information is still valid nor
> whether it's a good idea to call him if it is.  Maybe a letter
> would be better.  And I cannot remember him actually sending a
> message to fvwm-workers in 2003 (he said he would) - I definitely
> never sent an email to him personally.

That's a shame as it would have mase things easier.  Thank you for the
information though -- much appreciated!

Kindly,
Thomas

Re: FVWM: Code Licence

[Thomas Adam]

On Sat, Feb 10, 2018 at 01:23:28PM -0700, Jaimos Skriletz wrote:
> On Sat, Feb 10, 2018 at 12:05 PM, Thomas Adam  wrote:
> > On Sat, Feb 10, 2018 at 12:02:04PM -0500, Dan Espen wrote:
> >> Seems like a reasonable approach to me.
> >
> > I have collated a list of known authors of fvwm to date, and put it here:
> >
> > https://github.com/fvwmorg/fvwm/wiki/List-of-all-FVWM-Authors
> >
> 
> There is also this list
> 
> http://www.fvwm.org/authors/

Yes, but many of those names have no email addresses associated with them,
which is why I've largely ignored it.  Unfortunately, we need a pragmatic
approach to this.

-- Thomas Adam

Re: FVWM: Code Licence

[Thomas Adam]

On Sat, Feb 10, 2018 at 12:02:04PM -0500, Dan Espen wrote:
> Seems like a reasonable approach to me.
> Rob seems to have abandoned Fvwm or passed on.

That would be sad, if so.

I have collated a list of known authors of fvwm to date, and put it here:

https://github.com/fvwmorg/fvwm/wiki/List-of-all-FVWM-Authors

I'd like to suggest we send out an email explaining what we're thinking of
doing, and whether the response we get back is positive.

I'll leave this for a few days for feedback.

Thomas

FVWM: Code Licence

[Thomas Adam]

Hi all,

A while ago, I was trying to contact Robert Nation to determine whether he
would be willing to relicence his files to the GPL.  Unfortunately, I have
been unsuccessful in my attempts in finding an email address for him.

I appreciate this was done in order to be more compliant with Github's T&Cs,
however, I believe this is perhaps a worthwhile exercise, regardless of that
point.

I believe we should take an approach similar to that of OpenSSL[0] wherein
they made every effort to contact past authors[1].  It seems that even if did
not get a response, the licence change still went ahead.

IANAL, so I cannot comment on this in that regard.  However, it should be
noted that this approach did have lawyers behind it to begin with.

Any thoughts?

-- Thomas Adam

[0]  https://www.openssl.org/blog/blog/2017/03/22/license/
[1]  https://license.openssl.org/

Re: FVWM: Is there a way to find a window Id based on a window name

[Thomas Adam]

On Thu, Nov 23, 2017 at 09:38:27PM +0530, Bhupendra Kumar Jain wrote:
> Hi Thomas,
> 
> Sorry I missed adding the group in my last email. Resending.

That's OK.  You can also drop my email address from the Cc list, and just use
"fvwm@fvwm.org" -- I don't do private FVWM consultancy.

> I just know the window name and it is not necessary that the window is the
> same window which I am currently working on so I am not sure if ThisWindow
> would help.

It won't, but you've given me a piece of information you did not before.
Plus, my examples are just that.  I am expecting you to know enough of what I
tell you to apply it to your situation.  I can see now this is something
you're struggling with.

> 
> I tried the command which you gave for one of the windows(I tried being in
> the same as well as different window also), it ran with no output but I
> didn't get any result.
> 
> FvwmCommand 'ThisWindow "abc" Echo $[w.id]'

Aside from anything else, that's not the example I gave you, nor is it valid
FVWM syntax.  I'm fine with you asking for clarification on something, but I
do not like it when you don't put the effort in.

You have some options:


   Next (WindowName) Echo $[w.id]

This would take the next window in the ring and echo its window id.  I am
expecting you to replace "Echo" with something that uses "$[w.id]" -- the
point of the example is to show you that "$[w.id]" expands to the ID of the
specified window.

Incidentally, the output from FVWM's Echo command will go to stderr, so you
should check something like ~/.xsession-errors file to see it.

-- Thomas Adam

Re: FVWM: Is there a way to find a window Id based on a window name

[Thomas Adam]

On Thu, Nov 23, 2017 at 09:11:40PM +0530, Bhupendra Kumar Jain wrote:
> Hi,
> 
> One of the requirement for us to map window names with window id and then
> based on the window name, I should be able to get the window id.
> 
> Does Fvwm by default provide a way to find a window Id based on a window
> name?

ThisWindow (MyClass) Echo $[w.id]

-- Thomas Adam

Re: FVWM: How to set a window non-sticky from sticky

[Thomas Adam]

On Thu, Nov 23, 2017 at 08:55:43AM +0530, Bhupendra Kumar Jain wrote:
> The problem arises when I try the subsequent command to make that page
> Non-Sticky again e.g. When I try below command, *I get errors as - Sticky:
> Event not found.*
> 
> Next (FooBar, CurrentPage) WindowStyle !Sticky
> 
> So in a way, the moment I put *"!" or "No" or "Not" *before Sticky, I start
> getting errors when the commands are executed and the window which was
> sticky earlier doesn't get changed to Non-Sticky anytime.

This sounds as though you're using this:

FvwmCommand Next (...) WindowStyle !Sticky

Which, if I take this literally, along with your error message ("event not
found"), this is indicative of your shell trying to expand "!Sticky" as
history expansion.

> Has it got to do with Fvwm version that "!" is not being supported for me?

No.  You just need to use more quotes around what your shell is interpreting
and what FVWM receives.

At this point though, this has nothing to do with FVWM.

-- Thomas Adam

Re: FVWM: How to set a window non-sticky from sticky

[Thomas Adam]

On Wed, Nov 22, 2017 at 09:52:21PM +0530, Bhupendra Kumar Jain wrote:
> Hi,
> 
> A small correction to the last email in bold.
> 
> 
> *But if I try below command then it doesn't make them back sticky.*
> 
> *FvwmCommand 'Style "xterm" NoSticky'*

So as per usual, you're about as forthcoming as ever in terms of what it is
you're trying to achieve.  So I'll guess, by giving you as many examples as I
can, hoping that I hit on the right one, and this somehow applies to your
situation.  Here's a tip:  for the future, rather than sending out many
different emails with specific issues you're having, why not outline your
specific problems so that I (and others) have to spend time drip-feeding you
this information en masse.

Regardless of how FVWM receives your commands (whether it's via FvwmCommand or
a config file, or FvwmConsole, etc.), it will behave the same way.  In your
case, you have a few ways of ensuring a Sticky state:

1.  Style Foo Sticky

Will make "Foo" Sticky.  All "Foo"s will therefore be sticky, and it wouldn't
pertain to just one specific window.  For that, you've already found out
about the "WindowId" command.  However in the general case, you probably want
to use conditional commands to achieve the same thing, as a window's ID is
only valid for the lifetime of the window (and/or the window manager is
restarted -- in which case when the window is recaptured, it gets a new ID).
Examples of this include:

  Next (Foo, CurrentPage) WindowStyle Sticky
  Next (FooBar, CurrentPage) WindowStyle !Sticky

2.  Stick command versus Style condition

As with point 1., above, you'll note I'm using the Style command to change a
window's state.  There's nothing wrong in that, however, there is also the
"Stick" command which achieves the same thing:

  Next (MyWindow) Stick

This will toggle the state of the window between being sticky or not,
depending on the state of the window at that time.

Why is there a difference between a style state and a Stick command?  History,
and poor planning, and no one has yet removed one in favour of the other.
Personally speaking, I wouldn't say there's a compelling reason to use either
notion.  Pick one which makes sense to you.

When I was referring to "Pick" before is that this won't assume a window
context when executing a command if there isn't one already; making you choose
the window you wanted.  If you wanted to always be guaranteed a window to
select, you would use:

  NoWindow Pick (Foo) Stick

-- Thomas Adam

Re: FVWM: How to set a window non-sticky from sticky

[Thomas Adam]

On 22 November 2017 at 13:58, Bhupendra Kumar Jain
 wrote:
> FvwmCommand 'WindowId  Silent Stick False'
>
> But I don't want myself to be dependent on the WindowId so was asking the
> same.

Use the "Pick" command.

Kindly,
Thomas

FVWM: Re: What are the ways/commands to create a virtual desktop through fvwm

[Thomas Adam]

On Thu, Nov 16, 2017 at 07:04:00PM +0530, Bhupendra Kumar Jain wrote:
> Hi,
> 
> Is there a command already which will list the desktops which are created?

Not without using FvwmPerl/perllib, no.

-- Thomas Adam

Re: FVWM: What are the ways/commands to create a virtual desktop through fvwm

[Thomas Adam]

Hi,

[ Please stop emailing both lists -- I keep telling you this.  You
just need to use fvwm@fvwm.org ]

On 16 November 2017 at 00:56, Bhupendra Kumar Jain
 wrote:
> Hi,
>
> I was looking for ways/commands to create a virtual desktop through fvwm. I
> know that we can add it to the config files e.g. .fvwm/config and we can
> name the desktops.I don't want to do it via config options, instead I was
> looking for the commands to do the same e.g. if I just open a terminal and
> type in any of the fvwm or FVWMCommand and I should be able to create a
> virtual desktop. Please provide your inputs for the same. Thanks in advance.

You can use FvwmCommand or FvwmConsole for this.  The commands you want are:

DesktopName
DesktopSize

-- Thomas Adam

Re: FVWM: Question on "Maximize"

[Thomas Adam]

On Tue, Nov 07, 2017 at 10:09:48AM +0100, Dr. Nikolaus Klepp wrote:
> Hi!
> 
> Is there a differnce between a window, that was maximized using "Maximize
> 100 100" and a window that is maximized by "Move 0 0, Resize $[vp.width]
> $[vp.height]" ?

Yes.  If you use the Maximize command, then fvwm treats that window as such.

With your other example of using "Move", it does not.  See also
ResizeMoveMaximize.

> If there is a difference, how do I pass that "Maximised"-flag to a shell
> script? I assume that - while it is working - this is not the best way to do
> so:
> 
> + I ThisWindow (!Maximized) PipeRead ~/a/shell/script not_maximized   +
> I ThisWindow (Maximized)  PipeRead ~/a/shell/script maximized 

That'll work in your case, but you could limit it via State as well.

Depends what you're trying to do.

Kindly,
Thomas

Re: FVWM: Can we specify the size of a virtual desktop by myself

[Thomas Adam]

On Fri, Nov 03, 2017 at 11:36:08AM +0530, Bhupendra Kumar Jain wrote:
> Hi,

Please stop emailing fvwm@ and fvwm-workers@ -- you just need to use fvwm@.
You're asking a user question, not sending patches, which is what
fvwm-workers@ is for.

> I am looking for inputs from the community about if there is a way where in
> I can specify the size of a virtual desktop by myself when it gets created?
> This is needed by us because we don't want the entire area of the desktop
> to be virtual, instead a fixed size area of the desktop to be created
> through virtual desktops and remaining areas should be outside the control
> of FVWM and can be controlled by another utility(The idea here in is - We
> have a Single page HTML application which will cover the entire desktop
> area and part of it will be filled by the content of the virtual desktop).
> Please suggest any inputs from your end.

This sounds to me like an XY problem [0].  What is it you're trying to do?
You can't arbitrarily ask FVWM to create different virtual desktop sizes.
What you can do though is ask X11 to have a ViewPort size which would force
FVWM to pan around that, which might do what you want.

But why you wouldn't just use virtual desktops as-is and use the Scroll
command to pan around them, is beyond me.  I suspect you're over complicating
things.

-- Thomas Adam

[0] http://mywiki.wooledge.org/XyProblem

FVWM: Re: How to set the X & Y position of a newly created window using FvwmCommand in 2.6.5

[Thomas Adam]

On Tue, Oct 24, 2017 at 06:58:55PM +0530, Bhupendra Kumar Jain wrote:
> Hi Adam,

It's Thomas, actually.  Adam is my surname.

Oh, and don't drop the 'fvwm@fvwm.org' from replies.  I don't do private FVWM
consultancy.

> I didn't understand the solution you just mentioned. Can you please
> elaborate each step please as I have not used fvwm much and am failing to
> understand the use?

  Style * InitialMapCommand CheckMe

This defines a style line for all windows (indicated by '*') which will then
instruct FVWM to run a function (indicated by 'CheckMe') whenever a new window
is mapped (indicated by the 'InitialMapCommand' style option).  Mapped is just
a techical Xlib term for "initially visible on the screen".

The CheckMe function then, has to check the condition of all windows created.
Since this is a FVWM function, we have to define it like so:

  DestroyFunc CheckMe
  AddToFunc   CheckMe

The next line:

  + I ThisWindow (SomeClass) Move x y z

Is telling the function that as soon as it is called from a command (that's
what the 'I' means -- it stands for "Immediate"), the window is checked for a
condition.  "ThisWindow" is the window we've just mapped -- it's a way of
telling FVWM which window.  The condition of this test "SomeClass" is just
that -- a way of identifying which window we want to have the Move command
applied to.

Another way of doing this would be:

  Style SomeProgramOfMine InitialMapCommand Move x y z

HTH,
Thomas Adam

FVWM: Re: How to set the X & Y position of a newly created window using FvwmCommand in 2.6.5

[Thomas Adam]

On Tue, Oct 24, 2017 at 08:12:43AM +0530, Bhupendra Kumar Jain wrote:
> Hi Dan,
> 
> Thanks for sharing the information. Currently we are using FvwmCommand to
> whatever is needed for Window Management that was the reason I was looking
> for any argument which could be supplied to set the X & Y location of the
> window which is going the get launched. I do see that we had used the
> PositionPlacement argument earlier but somehow it is not working at this
> moment(May be because I am not specifying the window name). It would be
> great if you could share some of the sample commands which can be used for
> the MOVE option you just suggested or for PositionPlacement if you feel
> that works.

[ Dropping fvwm-workers@ as this should never have gone there. ]

You want something like this:

Style * InitialMapCommand CheckMe

DestroyFunc CheckMe
AddToFunc   CheckMe
+ I ThisWindow (SomeClass) Move x y z

-- Thomas Adam