Re: FVWM: WindowList issue

[Jaimos Skriletz]

On Mon, Apr 1, 2024 at 9:47 AM Pavel Vávra  wrote:
>
>   I use fvwm 2.6.8 from Devuan oldstable distribution (I think its same 
> binary as from Debian oldstable). I am testing default fvwm config and I 
> found different results when I try to use WindowList from my old config and 
> when I want to use new config based on default config.
> 
> Has anybody idea why?

This is a known bug with the default-config in fvwm 2.x (which is no
longer a supported release). The issue is that the default-config
didn't define the ItemFormat correctly to account for additional
columns (which aren't used directly in the default-config). But menus
that add these additional columns will not be shown. This was fixed in
fvwm3, and the fixed ItemFormat from the fvwm3 default-config is:

MenuStyle * ItemFormat "%s%|%3.1i%5.3l%5l%5r%5.3>%|"

Add that to your config (replace the similar line in the
default-config) and things should work again.

As a side note, since fvwm2 is no longer supported, if you want to
build an fvwm3 package for any debian based systems, follow the
instructions here:

https://github.com/somiaj/fvwm3-debian/

The debian build tools automate most of the process, so outside of
having to install the build dependencies, it is fairly straight
forward. This should work on oldstable, though I personally use it on
stable.

jaimos

Re: FVWM: Is Move in fvwm3 supposed to be (current) RandR screen relative?

[Jaimos Skriletz]

On Thu, Mar 7, 2024 at 9:45 AM Chris Siebenmann  wrote:
>
> > On Wed, Mar 6, 2024 at 10:45 AM Chris Siebenmann
> >  wrote:
> > > Is this intended behavior? I can't spot a strong statement either way in
> > > the current documentation for Move, although some of the wording sounds
> > > a bit odd if explicit Move positions are supposed to be screen relative.
> >
> > Move honors EWMHBaseStruts, which even if they are zero, are now set
> > per monitor. Due to this some computations don't work as you would
> > expect, since fvwm will adjust the window location to be inside the
> > working area of the current monitor. Does telling Move to ignore the
> > base strust fix your issue. I.e. add ewmhiwa to the end of each of
> > your Move commands.
> >
> > Move 3370p -0p ewmhiwa
>
> This does indeed work in my testing.
>
> In general this seems like a surprising change, since historically fvwm
> has considered Move to be absolute, not per-monitor (well, current
> monitor). It may make sense for people who explicitly use an EWMH area,
> but for people who don't (and the area is implicitly the entire
> monitor), maybe something else should be done.
>

Fvwm has honored base struts with Move this way for a long time and
the ewmhiwa option is not new, so Move wasn't considered absolute. The
difference is with Xinemera these struts were in the bounding box of
all monitors, so it probably wasn't noticed unless you moved a window
partly outside of this bounding box, then fvwm would have ensured the
window was fully inside this bounding box unless ewmhiwa option was
added. The RandR change now gives per-monitor support and a lot more
control, and this default is still useful to ensure Move puts windows
inside a single monitor unless ewmhiwa is used.

The issue (which isn't an easy fix) is that fvwm cannot determine
which monitor to use in some cases, and will fallback to the current
monitor (the one with the mouse pointer) if no monitor is specified. I
do agree it would be nice if fvwm could better determine which monitor
to use when doing bounding box computations to ensure windows are
fully shown inside a single monitor, but I still think using the
bounding boxes with Move and other operations to ensure windows are
put inside a single monitor or working area is useful. Currently the
work arounds are to either tell move to ignore the bounding box or
specify which monitor you want it to use.

jaimos

Re: FVWM: Is Move in fvwm3 supposed to be (current) RandR screen relative?

[Jaimos Skriletz]

On Wed, Mar 6, 2024 at 10:51 AM Jaimos Skriletz
 wrote:
>
> On Wed, Mar 6, 2024 at 10:45 AM Chris Siebenmann
>  wrote:
> >
> >
> > Is this intended behavior? I can't spot a strong statement either way in
> > the current documentation for Move, although some of the wording sounds
> > a bit odd if explicit Move positions are supposed to be screen relative.
>
> Move honors EWMHBaseStruts, which even if they are zero, are now set
> per monitor. Due to this some computations don't work as you would
> expect, since fvwm will adjust the window location to be inside the
> working area of the current monitor. Does telling Move to ignore the
> base strust fix your issue. I.e. add ewmhiwa to the end of each of
> your Move commands.
>
> Move 3370p -0p ewmhiwa
>
> The other option is as you stated, make your move commands relative to
> a specific monitor (instead of the current one) for when base strut
> calculations are used.
>
> jaimos

I forgot to send my response to the list.

Re: FVWM: fvwm3?

[Jaimos Skriletz]

On Tue, Jan 30, 2024 at 1:25 PM hw  wrote:
>
> so is there finally a version that works for wayland?
>
No, fvwm only works with xorg and most likely won't be ported.

> What are the differences between fvwm2 and fvwm3?
>
See https://github.com/fvwmorg/fvwm3/discussions/878

jaimos

Re: FVWM: Abort from FRenderRender -> XRenderCreatePicture()

[Jaimos Skriletz]

On Tue, Jan 23, 2024 at 6:07 AM Mark Hills  wrote:
>
> I'm experiencing rare (but annoying) whole X session crashes, since
> mid-2023.
>

There was a change in libX11 that caused fvwm crashes due to event
handling. That has been fixed in fvwm3, and the fix isn't in fvwm2
yet, but you can find the patch here:

https://github.com/fvwmorg/fvwm/pull/102

Maybe test out that patch and see if that helps.

jaimos

Re: FVWM: FVWM3: 2 monitors with different geometries?

[Jaimos Skriletz]

On Fri, Dec 22, 2023 at 9:42 AM Mandar Mitra  wrote:
>
>
> Browsing around FVWM3's git repo, and looking at 
> https://github.com/fvwmorg/fvwm3/blob/main/dev-docs/NEW-COMMANDS.md#hierarchy-and-specification
>  in particular, it seems like fvwm3 will allow me to have independent 
> desktops with appropriate geometries on Screen1 and Screen2.
>

This is a bit better page to describe how to migrate from fvwm2 to fvwm3:

https://github.com/fvwmorg/fvwm3/discussions/878

Fvwm3 multi-monitor support is quite good and there are lots of
improvements in both how multiple monitors can be used and dealing
with monitors with different resolutions.

> I haven't been able to figure out how to do this with FVWM2, so if some kind 
> soul could please confirm that this is possible with FVWM3, I'll take the 
> plunge and migrate.
>
> Somewhat related questions:
>
> 1. The NEW-COMMANDS.md page states "Desktops are linear in their arrangement. 
> There is no concept of pages within a desktop (as there is with FVWM2)." Is 
> that information correct? Or is this something left over from early design 
> discussions?
>

This is about how the data structure stores monitors (though this has
changed recently), and not about the pages or setup for the user.
Pages and Desks work just the same in fvwm3 as fvwm2. Though you may
find that you want your pages to have a single column/row (depending
on how your monitors are setup) if you use EdgeScroll.

> 2. The picture on the NEW-COMMANDS.md page shows that the Desktops on Screen1 
> have different geometries. Is that really possible? Or shouldn't I take that 
> "literally"?
>

Yes, you can have different resolutions. I think you may run into
issues using DesktopConfiguration shared with different resolutions,
but DesktopConfiguration per-monitor will work just fine.

jaimos

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

[Jaimos Skriletz]

On Thu, May 11, 2023 at 3:21 PM Thomas Adam  wrote:
>
> 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.

This patch has also been applied to the debian package which migrated
to bookworm today. Debian version 1:2.7.0-2 has the fix.

jaimos

Re: FVWM: Desktop scaling

[Jaimos Skriletz]

On Mon, Dec 5, 2022 at 9:56 AM Stephen Dennison  wrote:
>
> On Sun, Dec 4, 2022 at 3:33 PM Klaus Ethgen  wrote:
> >
> > I have a new laptop with 3840x2400 graphic. Unfortunately, that is too
> > much to be visible so I use it with only 1920x1200. Unfortunately, the
> > controls are still very small.
>
> I have a similar issue with one of my systems.
>
> > Is there any way to scale all fvwm components by, say, factor 250%?
>
> I can't think of an *easy* way for FVWM to do this for you, but
> depending on the method you are using for scaling, there are some
> things you can try using xrandr.
>
> If you are only setting the output mode via`--mode`, you still have an
> issue with dpi.  You can adjust both to get the desired effect.  See
> the `--dpi` argument in the man page.
>

note the --dpi argument is only for old xfonts, which most apps don't
use. Instead you should be using xft fonts, in which case you can use
.Xdefaults to set a dpi scaling for xft fonts. I use 'Xft.dpi: 120' on
my 2k monitor setup.

jaimos

Re: FVWM: fvwm3 1.0.5 FvwmButtons issue ?

[Jaimos Skriletz]

On Thu, Oct 20, 2022 at 5:26 PM John McCue  wrote:
>
> Hi,
>
> I noticed an issue with fvwm3 1.0.5 vs 1.0.4.
>
> Please let me know if you need more information.
>

Could you check the known issues at github, and adding this issue
there will get more attention.

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

Also check the current master branch on github, see if the issue is
present there too.

jaimos

Re: FVWM: Button release does not stop window dragging

[Jaimos Skriletz]

On Mon, May 30, 2022 at 12:27 AM Dov Grobgeld  wrote:
>
> Hello,
>
> The problem is that when I drag a window and then release the mouse
> button, the dragging does not stop. It only stops after clicking the
> mouse button one more time.
>
> Thanks in advance for any ideas.

Two thoughts. First check (share) the mouse binding you use for
clicking on the title bar and moving your windows. If the mouse
binding calls Move directly, such as, 'Mouse 1 T A Move', that is the
behavior you get, first click moves, second click releases. In this
case you'll need to use a custom function (check the
default-configuration for what it does), and that custom function
needs to use '+ M Move' so the move is triggered by a mouse hold/move
and then released by a mouse release. (You could also just check the
default-configuration to see if this same behavior is there to inform
you it is due to your configuration).

My second thought is this could be hardware related. If the
default-configuration has this same behavior then check xev and make
sure you see both the ButtonPress followed by the ButtonRelease event.

jaimos

Re: FVWM: '--' key action has stopped working in the master

[Jaimos Skriletz]

On Sun, Aug 15, 2021 at 9:34 AM Klaus Ethgen  wrote:
>
> Hi,
>
> today i felt the need to use this Feature. I want to do the following:
>Key (oolite) LeftA   C   --
>Key (oolite) Right   A   C   --
>Key (oolite) Up  A   C   --
>Key (oolite) DownA   C   --
>Key LeftA   C   Scroll -100 0
>Key Right   A   C   Scroll +100 +0
>Key Up  A   C   Scroll +0   -100
>Key DownA   C   Scroll +0   +100
>
> To not scroll when in oolite. But it still scrolls instead of giving the
> keys to the application.
>
> Any idea what went wrong? Or did I stumble on a bug?
>
There was a bug where pass-through bindings were being ignored
(basically '--' is being treated as '-' which means to remove the
binding).

It was fixed in fvwm3, but is still present in fvwm.

https://github.com/fvwmorg/fvwm3/commit/954b689ee48c965c4c639bddd4a2fcc68f11217d

You can either upgrade to fvwm3 and see if that fixes your issue or
try to apply the patch to fvwm.

jaimos

Re: FVWM: browser used on input mail

[Jaimos Skriletz]

On Fri, Mar 26, 2021 at 11:36 AM Pierre Frenkiel
 wrote:
>
> hi,
> I have the following problem:
> when reading a mail from input, and clicking on a link, the browser used
> is not the one set in .alpinerc, but opera.
> I checked that "opera" in not present in any mailcap file.
> Once the mail saved in a folder, my mailcap is actually used.
>

This is not an Fvwm issue, and totally depends on your mail client.
Each client you use to read emails may use a different tool to open
the links and will be configured differently. I'm not quite sure what
client you mean by 'from input', and maybe it is some pager or other
tool that allows opening of links. It could be that this is using the
xdg default browser. You can look up how to set the default browser
xdg-settings. It could also be a mime type issue which you can
configure with xdg-mime. In either case, this is not an fvwm issue,
but an issue with whatever application you are using to read emails
and open links. So figure out what app is showing you the email and
then look up how to configure what browser it uses for links.

jaimos

Re: FVWM: FVWM3-1.0.0 is released

[Jaimos Skriletz]

On Thu, Sep 3, 2020 at 1:15 PM Dominik Vogt  wrote:
>
> On Thu, Sep 03, 2020 at 12:13:45PM -0600, Jaimos Skriletz wrote:
> > Creating two packages that live side by side is a far greater
> > challenge than initially anticipated. First there are a lot of other
> > binaries such as fvwm-root, fvwm-config, fvwm-menu-desktop, that would
> > conflict,
>
> Do these not get the --program-suffix?  If not, that should be
> fixed.
>

It does work for the binaries. Just not the module manpages, which
share a common location, $PREFIX/man/man1

> > and though the --program-{prefix,suffix,transform-name} can
> > rename the binaries, this isn't the only conflict. The manpages for
> > all the common modules conflict and so does the translations/locales.
> > And none of these are affected by the --program-foo options.
>
> All right, but if these problems had been *reported* and not just
> silently dealt with in the distribution, they would have been
> fixed immediately back when the change from fvwm2 to fvwm was
> done.
>

I just adopted the package as it was, so I was unaware of this issue
until now. And the package only renames a single binary fvwm -> fvwm2
(then creates a link for fvwm), so at the time it wasn't an issue, as
it appears these other binaires were not part of fvwm 1.x.

The rest is all done in the fvwm1 package to ensure no conflict, which
someone else maintains. I did a little more research, the fvwm1
package in debian just renames all the manpages FvwmFoo.1.gz ->
FvwmFoo1.1.gz. This was probably done by Debian since at the time fvwm
1.x was no longer supported.

> > and locales,
>
> I don't know much about locales, but are they not installed in
> /usr/share/fvwm?
>

Locales are placed in $PREFIX/share/locale//LC_MESSAGES/, fvwm
has both a fvwm.mo and FvwmScript.mo that get placed in multiple
languages. I only know that the files are there and conflict, unsure
of if they can be renamed or any issues that would arise from that.

> > but even this isn't doable since there is
> > already differences in the modules in fvwm2 and fvwm3, mostly it is
> > the modules that are available, but FvwmPager has already received
> > some changes in options for the RandR per monitor setup.
>
> Is is acceptable to have man pages named
> FvwmModule in addition to the default names?
> If all else fails, the manpages could be put in separate packages.
>

As mentioned above, that appears to be what Debian's fvwm1 package is
doing. So it would be acceptable (only issue I can see is confusion on
the user if man FvwmButtons either didn't give a man page or a version
they weren't expecting, but the docs can explain this convention).

> > Currently, I'm just gonna to go with fvwm3 conflicts with fvwm2 and
> > only one of those can be installed at a time.
>
> I don't like this naming scheme that suggest the version number is
> part of the project name.  Is naming them "fvwm", "fvwm-2",
> "fvwm-1" not an option?
>

It is an option, but it isn't how it is done now. Currently Debian has
two packages fvwm1 and fvwm. It seems to vary, some packages are
packagename-, and others are packagename to allow multiple
versions to be installed via multiple packages. I was just thinking of
being in line of what is currently in place.

jaimos



> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
>

Re: FVWM: FVWM3-1.0.0 is released

[Jaimos Skriletz]

On Thu, Sep 3, 2020 at 5:28 AM Martin Cermak  wrote:
>
> 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 ... )
>

I am trying to make a Debian package that lives side by side as well.
For many years, Debian's package renames the main binary from fvwm to
fvwm2 so fvwm1 and fvwm2 installable side by side, then uses their
alternative system to allow fvwm to point to either fvwm1 or fvwm2. It
would be nice to add fvwm3 to the list, and all three can be
installed.

I also see fvwm2 being used for quite a while even as fvwm3 matures.
It may not get updates, but I suspect (partly because it had one
recently) it will receive bug fixes to keep it buildable and usable
for the users who just want to stick to fvwm2, since as mentioned
there are still people maintaining (and I assume using) fvwm1. So
having it seperate may not be the issue it was at the last transition,
as after 20 years times have changed.

Creating two packages that live side by side is a far greater
challenge than initially anticipated. First there are a lot of other
binaries such as fvwm-root, fvwm-config, fvwm-menu-desktop, that would
conflict, and though the --program-{prefix,suffix,transform-name} can
rename the binaries, this isn't the only conflict. The manpages for
all the common modules conflict and so does the translations/locales.
And none of these are affected by the --program-foo options.

I was thinking of maybe some fvwm-common package that would host the
manpages and locales, but even this isn't doable since there is
already differences in the modules in fvwm2 and fvwm3, mostly it is
the modules that are available, but FvwmPager has already received
some changes in options for the RandR per monitor setup.

Currently, I'm just gonna to go with fvwm3 conflicts with fvwm2 and
only one of those can be installed at a time.

All in all it is nice to see something new, and hope that even after
quartiteen there is still enough time and effort to see where it
evolves.

jaimos

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

[Jaimos Skriletz]

On Tue, Aug 11, 2020 at 7:57 AM Dr Rainer Woitok
 wrote:
>
> Greetings,
>
> Question: What has become of "FvwmTaskBar"?
>

FvwmTaskBar was removed due it being buggy and having additional
options. Use FvwmButtons + FvwmIconMan instead. Here is an example:

https://www.fvwm.org/Wiki/Panels/FvwmTaskBar/

In general FvwmTaskBar is limiting compared to what you can do with
FvwmButtons + FvwmIconMan, you just now have to build your own panel
using other tools.

jaimos

Re: FVWM: Is Idle status communicated to SystemD?

[Jaimos Skriletz]

On Sun, May 3, 2020 at 1:37 PM  wrote:
>
> Hi All,
>
> it looks like it's the WM's responsibility to notify SystemD of the idle
> status. Does fvwm do this? (I start Fvwm from sddm, or directly via
> startx from the text console.)
>
> If anyone has it working and has any tips they can share that would be
> appreciated.
>

I am unsure about how to notify systemd, but on my system I use
xautolock to lock my screen with i3lock. I don't use suspend, but you
can configure xautolock to run any command after a set amount of time
of inactivity in xorg. So you could use xautolock to suspend your
system via systemctl suspend provided your user has permissions to do
this.

This doesn't directly answer your question of how to configure this in
logind.conf with systemd, but it will give you a way to suspend in
xorg after certain amount of inactivity.

jaimos

Re: FVWM: Two small oddities

[Jaimos Skriletz]

On Sat, Jun 8, 2019 at 5:59 AM Thomas Adam  wrote:
>
> 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.
>

You may need to restart chromium after you change this setting.

> 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.
>

You can tell fvwm to ignore the decor hints caused by the CSD to turn
off the decor. For me the following works to put borders/titlebar on
evince.

Style evince NoDecorHint

This may have other affects that all decor hints are ignored. For my
use it works in allowing fvwm to decorate my evince windows. Though I
personally just like the border, and not the titlebar on my evince
windows (since it dose provided maximum and minimum buttons on the
CSD), so I use

Style evince NoDecorHint, !Title

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

This option is also available if there are other decor hints you want
honored and ignoring them all with the above style isn't appropriate
for your use case.


jaimos

Fwd: FVWM: two questions about icons

[Jaimos Skriletz]

(forgot to cc the mailing list)

On Wed, Jun 5, 2019 at 4:30 PM Ronald F. Guilmette
 wrote:
>
>
> In message <20190605213540.hmud7pziqi64a6i5@laptop.local>,
> Thomas Adam  wrote:
>
> >> 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.
>
> The default configuration assumes the presence of xload.
>

The default configuration does not assume the presence of xload. In
general the default config assumes a very minimal set of tools,
because fvwm is just a window manager, not a full desktop. It does not
assume what sort of apps you want to use. The default config is merely
meant to be a starting point and to show some of the capabilities of
fvwm. It is not meant to service all users nor turn fvwm into a
desktop that links fvwm (a window manager) with lots of external apps.

If you want more info about the RightPanel (or Panels in general) the
wiki can help, along with other docs. Maybe start here and then read
up on how to include xload in your panel.

https://fvwmforums.org/wiki/Panels/RightPanel/

> I will let the FreeBSD port maintainer decide if that means that xload should
> be listed as a prerequsite for fvwm.  I have an opinion on this, and you have
> one, and he may have a third.
>

The FreeBSD maintainer can decide to provide their own default config
if they wish, but this is not a discussion for the fvwm mailing list.
I see no reason the default config should support xload.

> >> 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.
>
> As much as I admire all of the ornate and impressive complexity of fvwm, I
> never actually -wanted- to do any of this.  It has taken me a lot of hours,
> and none of what I have learned is applicable or useful to anything else
> that I am doing, or that I am at all likely to do in the future.
>
> No offense intended, but if there had been some other window manager that
> would give me multiple virutal desktops... a feature that I can no longer
> live without... and which didn't require a massive amount of unlearning
> and then re-learning (i.e. of basic usage conventions) then I would have
> used that instead.
>

Many window managers (and even desktops like gnome) provide support
for multiple virtual desktops. You may want to search around and find
one that more suits what you want. Fvwm will require one taking time
to learn how to configure it using the config file, because there are
just to many options to put into an GUI. Fvwm takes most a good
initial time investment, but once you have your config file, it will
keep working (I haven't had to update my config file in years except
for small tweaks).

There are also some desktops based off of fvwm, either fvwm-crytsal or
fvwm-nightshade. These both assume a bigger set of tools, provide some
gui configs and try to be more a full desktop. You may find they work
more to your liking as a lot more maybe configured for you. These are
not supported by the fvwm mailing list.

> I am not seeking to become an X wizard or a window manager wizard or anything
> else.  I just know enough to barely get by and that's all I have time for
> right now.  I have promises to keep, and many spammers to kill.
>
> >> 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.
>
> I gather that you would prefer not to elaborate further on that assertion,
> but I will ask you to do so anyway.
>
> How exactly is hiding icons underneath something else... where they can't
> even be clicked on... a Good Thing?  I mean, you know, for a perfectly
> ordinary end-luser.

The default config does not use Icons (it sets Style * !Icon), and
then uses FvwmIconManager to manage them instead. As such no effort
has been put into the default config to configure the IconBox and how
the 

Re: FVWM: two questions about icons

[Jaimos Skriletz]

On Wed, Jun 5, 2019 at 3:41 AM Lucio Chiappetti  wrote:
>
> On Tue, 4 Jun 2019, Ronald F. Guilmette wrote:
>
> > Grrr.  I can't imagine why this would be so hard.  I didn't think
> > what I wanted to do would be so complex.  Again, I just want a
> > digital xclock to appear in the blank space below the xbiff thingy
> > in the default theme.
>
> AFAIK there is no such thing as a "default theme" (valid for any fvwm
> installation anywhere). There could be a "system default" bundled in your
> OS distro (different for each distro).
>

A default theme was added to fvwm in 2.6.7 to provide users a starting
place in making their own theme. The default theme does contain a
script that will copy the config file to $HOME/.fvwm/config to allow a
user to start editing it.

jaimos

Re: FVWM: Problems with special application mapppings

[Jaimos Skriletz]

On Thu, Mar 21, 2019 at 3:21 PM Klaus Ethgen  wrote:
> But why dows it work when I do `Key (mpv) Up A M -` direct afterwards
> (but not in the config file)?
>

What do you mean by work? I am not able to get it to work as you want
with my tests.

> > Key Up  A   M   Scroll +0   -10
> > Key (mpv) Up A   M--
>
> I tried that too but it does not work.
>

My tests also shows this doesn't work as expected. I'm not quite sure
what is going on then. When I run

PrintInfo Bindings

I do not see a binding show up when I use the -- option (unsure why
this is not showing up). So unsure if the -- binding is not being
listed
correctly or not. It could be I'm overlooking something with the pass
through option

I do know that this really isn't the best way to do things, in general
most applications will not like this. From the man page

Note that Fvwm actually intercepts all events for a
window-specific binding and (if the focused window doesn't match
any of the bindings) sends a synthetic copy of the event to the
window.  This should be transparent to most applications,
however (for security reasons) some programs ignore these
synthetic events.

Really most programs ignore these synthetic events (see FakeKeyPress)
so I would think of another way to achieve your goal. Though if mpv
accepts synthetic events, you could try FakeKeyPress over a pass
through --, and see if that works for you.

My suggestion is find another way to achieve your goal. Some suggestions:

*) Use a modifier on Up/Down that isn't also used by MPV for your bindings.
*) Write a function and bind it to a binding that enables/disables
these scroll bindings. Not ideal, but this way you could disable the
bindings when you wanted to use Meta-Up inside of mpv. You could even
use Schedule to make it so the bindings will automatically enable them
selves after a set period of time.

jaimos

Re: FVWM: how to escape F1?

[Jaimos Skriletz]

On Fri, Mar 8, 2019 at 10:17 AM Stefan Klinger  wrote:
>
> Hi,
>
> this is an *untested* idea: There's `FakeKeypress` documented in
> fvwm(1), which seems to send a keypress event to an application.  I
> assume, that for each binding you have in yout setup, like
>

Many apps do not like FakeKeyPress, so it is probably not an
appropriate way to try to 'escape' a keybinding, since many apps will
just ignore fake events anyways. The options already listed in this
thread are most likely the better approaches.

1) Write a custom function that turns keybindings on/off, then you can
use that to escape the binding by turning it off, then you can run the
function again to turn it back on.

2) Use a modifier on the key bindings, so F1 isn't a key binding
anymore, this way F1 can pass to the applications just fine.

jaimos

Re: FVWM: collection of vector button definitions?

[Jaimos Skriletz]

On Tue, Feb 5, 2019 at 6:47 AM Paul Fox  wrote:
>
> Is there a library, or collection, of FVWM vector button definitions
> somewhere?  I want to add a new button to my window titlebars, and
> being a bit lazy, would rather not have to design something new
> myself.
>

The Wiki has a good list, including a java script applet you can play
with to make a custom one.

http://fvwmforums.org/wiki/Config/VectorButtons/

jaimos

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

[Jaimos Skriletz]

On Wed, Dec 26, 2018 at 9:35 AM Peter Holm  wrote:
>
> This is more or less a follow up from my earlier question.
> I have this
> ---
> Key Space   A   M   State 
> $[infostore.transi] True
> Key Space   A   C   State 
> $[infostore.transi] False
>
> ..
> AddToFunc StartFunction
> + I InfostoreAdd  transi 31
> 
>
>
> Then when I switch desk/workspace I  let the window(s) follow me

Why not just use Sticky for this. No need to define a custom state to
make it so windows move to a new workspace (pages/desktops) when you
do.

(sorry for the duplicate reply, forgot to CC the list)

jaimos

Re: FVWM: bookmark/unbookmark multiple windows

[Jaimos Skriletz]

On Wed, Dec 19, 2018 at 12:56 PM Peter Holm  wrote:
>
> To select a window for moving there is afaik two methods.
> Either you make the window sticky, and then unstick it - or you
> bookmark the window.
>

What do you mean by 'select a window for moving', Have you looked at Pick?

> I would like to do this :
> --
> 1), Select a windoiw
> 2), Add the window to a list, lets call it LIST_OF_BOOKMARKED_WINMDOWS
> 3), Add a new window to the list.
> 4), Search the list for select window - if window is found then do
> something with the windows.
> 5), remoive the window from the list.

You can use States (look up State) to give windows custom flags you
can then use for custom purposes, like making lists. Conditional
statements in Fvwm can identify windows based on their state.

jaimos

Re: FVWM: rare behavour with mouse buttons

[Jaimos Skriletz]

On Wed, Aug 29, 2018 at 2:35 PM bruce m beach  wrote:
>
> Hello
>
>
>   Mouse 1 2 NMaximize true 0  33
>   Mouse 3 2 NMaximize true 0  100
>
>   Mouse 1 4 NMaximize true 27  0
>   Mouse 3 4 NMaximize true 100 0
>
>   Mouse 0 6   A   Iconify
>
> Now what happens is that these mouse clicks totally stop working.
> No response whatever. A few minutes later everything is okay.
>

The N requires that no modifier is being pushed. If any modifier is
being pushed, the bindings won't work. Note that numlock is a
modifier. This might be relevant. This is one of the most asked
questions in the FAQ

http://www.fvwm.org/documentation/faq/#a-few-minutes-after-fvwm-is-started-my-keyboard-and-mouse-bindings-stop-working--what-can-i-do

Anyways, making N and A (for any modifiers) should make it work no
matter what modifier you are holding down.

jaimos

Re: FVWM: Using FVWM manager on RHEL 6 system

[Jaimos Skriletz]

On Tue, Jun 19, 2018 at 9:51 AM, William Muriithi
 wrote:
> Morning,
>
> I am interested in using fvwm on a Centos 6 and curious if this is a viable 
> idea.
>

Yes, fvwm should work just fine on Centos 6. You may want to compile
the 2.6.8 release instead of using the package available in CentOS for
the most current version.

> Couple of observation I have noticed that is a bit worrying:
>
> - There hasn't been any commit against this project for almost 2 years

There have been multiple commits in the last 2 years, and 2.6.8 was
released less than a month ago. You must not be looking in the correct
spot. Check github and fvwm.org.

Fvwm is mostly in maintenance mode, and commits are mostly bug fixes.
The project hasn't seen much new development in a while, but it is
still active and a stable window manager. It should run just fine on
CentOS.

> - Is the mailing list public?  Google searches are only bringing up very 
> dated information which lead to a feeling no one is using this manager 
> recently
>

Yes, the mailing list is public. The info to find the archives is on fvwm.org

http://www.fvwm.org/support/#lists

jaimos

Re: FVWM: Expand Stalonetray in Right Panel

[Jaimos Skriletz]

On Fri, May 18, 2018 at 4:08 PM, Brian  wrote:

> Thank you for the suggestion.  I'm trying to understand the "x" and
> "x!" commands.  I'm using the DEFAULT dynamic configuration.  My
> configuration is actually a 1280x720 screen on left with a 960x960
> screen on the right.  The RightPanel config is showing on the 1280x720
> screen, which is just where I want it desplayed.  But for some reason
> the the $[vp.height] is not properly calculating the height.  I'll try
> the hard static config with 720.  What I'm not understanding is that
> both the static and dynamic configs have both the -225 and -205
> lines. So I'm not clear which line you are suggesting should be
> modified? I do understand the static config can be calculated against
> the 720, but I believe the calculation is against the bottom right, so
> having two different size screens is confusing the calculation in the
> dynamic setup.
>

There is no 'x' command, there is a Test command that is testing for
things. Test (x stalonetray) tests to see if your system has an
executable called stalonetray, and then adjust the configuration.

The dynamic configuration in the default-config is a bit complicated
due to tests, and using variables like $[vp.height]. My suggestion
would be to follow the wiki link I gave you and rebuild the RightPanel
in such a way that you don't need all the additional Test and
computations done in your shell via PipeRead.

As for the lines to adjust, you need to adjust the two lines that have
Test (x stalonetray) at the start. First increase the size of the
button for stalonetray then reduce the size of the button for
FvwmIconMan as described.

jaimos

Re: FVWM: Expand Stalonetray in Right Panel

[Jaimos Skriletz]

On Thu, May 17, 2018 at 9:31 PM, Brian  wrote:
> I sometimes have more than seven items which want to place an icon
> image in the stalonetray.  However the tray will only show seven icons
> in the 120 column width of the right panel. Using the standard
> Right-panel how would one change the stalonetray to a second row of
> icons?  Is it simply a matter of changing
> $[FVWM_DATADIR]/default-config/.stalonetrayrc
> Max geometry to 6 x 2 or is it more complicated?
>

You would need to add space for stalonetray in FvwmButtons and take
away space from another piece, such as FvwmIconMan. So you would have
to change the geometry from 120x20 to 120x40 for the stalonetray
button. But then you'll have to take 20 pixels way from FvwmIconMan
button, so you would need to change the dynamic computation from
120x$(($[vp.height]-205)) to 120x$(($[vp.height]-225)).

Next I wouldn't edit the installed version of .stalonetrayrc, instead
copy the .stalonetrayrc to $HOME, update the RightPanel config to use
your custom configuration file.

Here is some more info that may help you if you want to edit the
RightPanel some more than just that.

http://fvwmforums.org/wiki/Panels/RightPanel/

jaimos

Re: FVWM: how to prevent involuntary page switching?

[Jaimos Skriletz]

On Wed, Apr 25, 2018 at 5:41 PM, hw  wrote:
> Hi,
>
> how can I prevent fvwm from automatically switching to the desktop page
> where an application like gajim receives a message and activates a
> window (or whatever it does to force this switch)?
>

It depends on what is causing the switch. This sounds like a window is
setting an UrgencyHint or something similar, and the default in fvwm
is to honor the windows hint and give it focus when it requests it.

Here is some tips on Focus Stealing and ways to deal with them. The
actual solution depends on what the app in question is actually doing.

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

jaimos

[fvwmorg/fvwm] e66b16: Add lighten/darken capability to colorset expansio...

[Jaimos Skriletz]

  Branch: refs/heads/js/lighten-darken-colors
  Home:   https://github.com/fvwmorg/fvwm
  Commit: e66b16aa1018458f2cb9f781b24bfda11807aaa7
  
https://github.com/fvwmorg/fvwm/commit/e66b16aa1018458f2cb9f781b24bfda11807aaa7
  Author: Jaimos Skriletz <jaimosskril...@gmail.com>
  Date:   2018-04-01 (Sun, 01 Apr 2018)

  Changed paths:
M NEWS
M doc/fvwm/expansion.xml
M fvwm/expand.c
M libs/ColorUtils.c
M libs/ColorUtils.h

  Log Message:
  ---
  Add lighten/darken capability to colorset expansion.

  * Added expansion for appending .lighten and .darken to
a color set expansion, such as $[fg.cs.lighten] or
$[shadow.cs.darken].
  * Added missing $[fgsh.cs] expansion to manpage.

[fvwmorg/fvwm] b46163: Add lighten/darken capability to colorset expansio...

[Jaimos Skriletz]

  Branch: refs/heads/js/lighten-darken-colors
  Home:   https://github.com/fvwmorg/fvwm
  Commit: b46163d5a60cf76875963ec9951db42e24367ca5
  
https://github.com/fvwmorg/fvwm/commit/b46163d5a60cf76875963ec9951db42e24367ca5
  Author: Jaimos Skriletz <jaimosskril...@gmail.com>
  Date:   2018-04-01 (Sun, 01 Apr 2018)

  Changed paths:
M NEWS
M doc/fvwm/expansion.xml
M fvwm/expand.c
M libs/ColorUtils.c
M libs/ColorUtils.h

  Log Message:
  ---
  Add lighten/darken capability to colorset expansion.

  * Added expansion for appending .lighten and .darken to
a color set expansion, such as $[fg.cs.lighten] or
$[shadow.cs.darken].
  * Added missing $[fgsh.cs] expansion to manpage.

Fvwm pauses in a wait state if a click is too fast

[Jaimos Skriletz]

Hello,

This was reported by a Debian user. Please retain the CC to
849354-forwar...@bugs.debian.org in your response, so that
the Debian BTS has a record.

The full bug report can be found at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849354

In summary I think the bug that the user experiences is due to the
time between a ButtonPress and ButtonRelease event being to quick. The
user has a binding that looks like this:

Mouse 1 A   SCM Raise

Sometimes when clicking on a window to raise it, fvwm will not
register the click fully and then be put into a wait state until the
mouse is clicked a second time, at which time the window is raised.
After some investigation the user discovered that it only happened
with their touchpad and further by looking at xev, only happened when
the time difference between the Press and Release events were less
than 10 units by xev (about 10+ times faster than the times registered
with a normal mouse button). Additionally the user discovered if they
wrapped the Raise call into a function or just held down the button a
little bit longer, the bug did not happen.

My theory is the time is so low there is a race condition. Fvwm gets
and maybe ignores the release event before fvwm fully processes the
press event. Then fvwm gets stuck waiting for a release event, which
happens the next time the mouse is clicked.

When using the function wrapper, this wouldn't happen because the function
wrapper might not necessarily we waiting for a release event like the
mouse binding might be.

So could there be some issue that causes fvwm to pause with such a
binding, as the push would put fvwm in a state that forces it to wait
for the release event to register the click as happening to trigger
the binding, and could a fix be have some timeout while fvwm is
waiting for the release button in this case?

In addition if I make such a binding and then click and hold my mouse
button, fvwm is put into a wait state and won't function until I
release my mouse button, so this seems to help support my theory that
the pause is due to fvwm waiting for the release event. So last
question, could a timeout be useful here to ensure fvwm won't pause
too long waiting for a release event, or is there some reason fvwm
needs to wait for the release event and this is just an issue with the
touchpard hardware sending to quick of press/release events?

Thanks for your time,

jaimos

fvwm-menu-desktop and Python 3

[Jaimos Skriletz]

Hello,

I am trying to update the fvwm-menu-desktop script to work in python 3
while being python 2 compatible, since python 2 is nearing end of
life.

I first ran 2to3 on the script and it fixed the majority the syntax
differences. But the script's output had some encoding issues due to
differences in python 2 and 3 in terms of utf-8. I was able to trace
down the issues and get them to work on my system, mostly by bypassing
the decoding/encoding function if using python 3 (I think this is
okay, because python 3 should support utf-8 in strings by default and
not need to encode/decode them).

Just seeing if anyone would want to test the script on their setup if
they use it to see if it works both with Python 3 and Python 2, and
especially with someone who has menus that uses lots of utf-8
characters with accents in them.

You can find the changes in the branch js/fvwm-menu-desktop

You may have to change the she-bang at the top of the script to
#!/usr/bin/python3 if it gets built with python 2.

Thanks,

jaimos

Re: fvwm.org domain name

[Jaimos Skriletz]

On Sat, Feb 10, 2018 at 8:38 AM, Dan Espen  wrote:
>
> Hi,
>
> I've renewed the fvwm.org domain name for the next 9 years.  (The max
> gandi allows for.)  The fvwm.org web site is back up from here.
>
> Hopefully, I'll still be alive in 9 years, but I've got no guarantees.
> I don't think there will be a problem, as I understand it anyone can
> renew.
>

If needed, and we want to go through the pain of transferring the
domain, I can put the domain with some domains I control, such as
fvwmforums.org, which is setup to auto renew.

jaimos

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

[Jaimos Skriletz]

On Mon, Oct 23, 2017 at 5:50 PM, Dan Espen  wrote:
> Bhupendra Kumar Jain  writes:
>
>> Hi,
>>
>> I am looking for a solution wherein I need to set the X & Y position of a 
>> newly created window using FvwmCommand in 2.6.5 version of
>> fvwm. Please suggest.
>
> Most apps accept an "-geometry" argument to control this.
> Why are you asking about FvwmCommand?
>
> If for some reason you can't use an argument, you could use a script
> that starts the application, then uses FvwmCommand to WAIT for the
> window to appear, then MOVE the window to the location you want.
>

The PositionPlacement Style may also work. With either using Wait,
InitialMapCommand or PositionPlacement, it will require you can
identify the window based on its name/class/resource. You may want to
describe in more detail what it is you are trying to achieve.

jaimos

Re: FVWM: Session management.

[Jaimos Skriletz]

On Sat, Sep 30, 2017 at 4:52 PM, Didier Spaier  wrote:
> Also, as a fallback are you aware of a an external window manager able
> to cooperate with FVWM and having very few dependencies?
>

Have you read this older article, http://linuxgazette.net/100/adam.html?

Maybe xsm will work for your needs, the info about the gnome session
manager is most likely out dated in that article though.

jaimos

Re: FVWM: Which setting to give focus to a window that just popped up?

[Jaimos Skriletz]

On Mon, Sep 25, 2017 at 5:04 PM, Didier Spaier  wrote:
> Hello,
>
> So, she would like that when she types a command that creates a window,
> or select an application menu entry (e.g. from the application menu
> plugged in lxpanel), this window be always given the focus. Some
> examples of applications associated to such windows:

The default focus policy is SloppyFocus which gives focus to the
window under the mouse (with some special rules about the root
window), so if a window is created and not under the mouse even with
GrabFocus it will loose focus based on where the mouse is located (or
if the mouse gets moved).

It might be you want to change the focus policy to ClickToFocus, this
is most like windows, where you have to click a window for it to gain
focus and thus focus is not tied to mouse location.

Style * ClickToFocus

jaimos

Re: Sometimes windows remain after the process has died.

[Jaimos Skriletz]

On Thu, Apr 27, 2017 at 5:09 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:

> On Thu, Apr 27, 2017 at 05:00:33PM -0600, Jaimos Skriletz wrote:
> > On Thu, Apr 27, 2017 at 4:21 PM, Dominik Vogt <dominik.v...@gmx.de>
> wrote:
> > > On Thu, Apr 27, 2017 at 11:04:14AM -0600, Jaimos Skriletz wrote:
> > >> Sometimes when a process stops the window will remain open until some
> > >> event is triggered in fvwm (in my test I use FvwmIdent) in which fvwm
> > >> will remove the window.
> > >
> > > That is not possible unless either
> > > ...
> >
> > The process do not appear in 'ps fax' and the script outputs [Done] on
> > all the jobs that were run in the background in the shell, so this is
> > not the case.
> >
> > >  2) the X server has a bug,
> >
> > This does seem to be the case. The user and myself both tested this
> > running an xsession with only an xterm. We could not reproduce it with
> > only running an xterm.
> >
> > I decided to test another window manager, openbox in this case, and
> > was able to reproduce the issue in openbox. So it seems to be some bug
> > with how the xserver but may require a window manager to trigger it.
>
> I wonder what that trigger could be.  If the window can be moved,
> fvwm is communicating with the X server in both directions, so if
> a destroy event was pending it should have been delivered to fvwm
> before any mouse motion events.  Maybe the X server itself has
> destroyed the window internally but not yet sent the event for
> some reason, and does so only when some request for that window is
> issued.  (Moving the fvwm window does not move the client window
> directly but the frame.)
>
> If you type "xsync" in FvwmConsole, does that kill the window?
> (This forces all pending requests and events to be delivered in
> both directions.)  My guess is that it doesn't, i.e. no event is
> pending.
>
>
​Typing xsync into FvwmConsole did not trigger the removal of the windows.
​

> > In all cases trying to get any info from the xserver closes the
> > windows. I have tried xprop, xwinfo and even just xdpyinfo and xvinfo
> > will close all the windows that were left open when running that
> > command.
>
> Does it also kill the window to request information from a
> different (non-zombie) window?
>
>
​It kills them before I even get a chance to pick the window to identify. I
am not able to find away to get any info on the zombie windows, as soon as
I query xorg with xprop or xwinfo, all zombie windows are removed, then it
gives me a pointer to pick a window. If I use FvwmIconMan (which still has
the windows) to Identify via FvwmIdent (using the window ops menu), the
windows disappear and I get no output from FvwmIdent. No errors in
.xsession-errors either.

jaimos

Re: Sometimes windows remain after the process has died.

[Jaimos Skriletz]

On Thu, Apr 27, 2017 at 4:21 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> On Thu, Apr 27, 2017 at 11:04:14AM -0600, Jaimos Skriletz wrote:
>> Sometimes when a process stops the window will remain open until some
>> event is triggered in fvwm (in my test I use FvwmIdent) in which fvwm
>> will remove the window.
>
> That is not possible unless either
>
>  1) the process is not really dead,

The process do not appear in 'ps fax' and the script outputs [Done] on
all the jobs that were run in the background in the shell, so this is
not the case.

>  2) the X server has a bug,

This does seem to be the case. The user and myself both tested this
running an xsession with only an xterm. We could not reproduce it with
only running an xterm.

I decided to test another window manager, openbox in this case, and
was able to reproduce the issue in openbox. So it seems to be some bug
with how the xserver but may require a window manager to trigger it.

In all cases trying to get any info from the xserver closes the
windows. I have tried xprop, xwinfo and even just xdpyinfo and xvinfo
will close all the windows that were left open when running that
command.

Thanks for the help, I will forward this bug on to xorg as it affects
more than just fvwm.

jaimos

Sometimes windows remain after the process has died.

[Jaimos Skriletz]

Hello,

This was reported by a Debian user. Please retain the CC to
855206-forwar...@bugs.debian.org in your response, so that
the Debian BTS has a record.

Sometimes when a process stops the window will remain open until some
event is triggered in fvwm (in my test I use FvwmIdent) in which fvwm
will remove the window.

The following script was provided by the user which launches and
closes a large number of xterms. When running this script some of the
xterm windows will remain even though the process is no longer
running.

On Wed, Apr 26, 2017 at 6:13 PM, Vincent Lefevre  wrote:
> Simpler test case:
>
> 
> #!/bin/sh
>
> n=${1:-200}
> n=$((n+0))
>
> for i in `seq $n`; do xterm -geometry 80x24+$((2*i))+$((2*i)) -e true & done
>
> wait
> 

After this script ends a few windows remain and can be moved,
iconified, shaded, resized. But if you run FvwmIdent something is
triggered which removes all the affected windows.

I was not able to reproduce this on my main machine (though rarely I
would have a window stick around for a second or two before it was
removed, most weren't even drawn), but I was able to reproduce this
with the default config on both the debian 2.6.7-3 package and the
master branch from git inside a virtual machine.

thanks for your time,

jaimos

Re: FvwmIconMan still sometimes triggers Hint Warnings

[Jaimos Skriletz]

On Wed, Mar 1, 2017 at 9:24 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> On Wed, Mar 01, 2017 at 07:18:11AM -0700, Jaimos Skriletz wrote:
>> On Wed, Mar 1, 2017 at 5:30 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
>> > On Tue, Feb 28, 2017 at 10:22:33PM -0700, Jaimos Skriletz wrote:
>> >> On Mon, Feb 27, 2017 at 11:10 PM, Jaimos Skriletz
>> >> <jaimosskril...@gmail.com> wrote:
>> >> > Hello,
>> >> >
>> >> > FvwmIconMan still reports Hint warnings even with the patchs applied.
>> >>
>> >> I wrote this small patch that has FvwmIconMan wait until the window
>> >> has resized to set the window hints. This is in the lines of Dominik
>> >> Vogt's patch, but waits until FvwmIconMan has fully resized to run
>> >> fix_manager_size() to set the window hints. My tests here no longer
>> >> seem to tiger the warnings like it still sometimes did.
>> >>
>> >> As an additional thought, talking to Thomas Adam about the patch in
>> >> #fvwm, he mentioned that the issue is more FVWM being overly cautious
>> >> and the fix should be in how fvwm handles size hint warnings over
>> >> working with FvwmIconMan to avoid triggering them.
>> >>
>> >
>> > So, if it's not possible to completely fix FvwmIconMan in a decent
>> > way, what do we do with the warning?  I'd rather not disable it,
>> > but the number of false positives is too high.  One could make a
>> > style that disables the warning for a certain class of windows,
>> > but that would probably be used as "style * ...", disabling the
>> > warning for everything.  :-/
>> >
>>
>> FvwmIconMan isn't the only application that triggers these warnings,
>> but using it in a situation where it grows/shrinks is a very regular
>> way to cause the warnings and it fills up .xsession-error with mostly
>> warnings. Other applications I use only trigger these warnings rarely,
>> and in each case the application appears to work fine so yet more
>> false positives. But FvwmIconMan is the only one that regularly
>> resizes itself triggering the warning a lot.
>
> Of course.  Flooding the log was not the intention of the patch.
>
>> I had two ideas on this, one is use a BugOpts option that can turn on
>> these warnings for a user who wants to debug things, but they are off
>> by default. This is basically your style idea and the affect will be
>> almost everywhere these warnings will not appear and thus may miss out
>> on programs that actually need to be reported.
>
> Yes, but defaulting to "off" makes the warning effectively useless.
>

Yea, hence the same line as a style and then turning it off. Though if
a window is misbehaving it could be turned on to see if it is
triggering these warnings. But one would have to know a window is
misbehaving and not able to just look in the logs to see that one is.

>> Another is maybe don't have fvwm jump to conclusions that there is a
>> warning.
>
> Let me rephrase that:  Fvwm informs the user about something that
> might not be possible to clean up.  In such a situation the user
> would see that the window did not get resized as intended and has
> no clue why.  At least, fvwm has told her that something strange
> was going on.
>
>> What if there was some timer that fvwm gave the application
>> to fix itself before reporting a warning, and then the warning is not
>> just that the window had this inconstant state which seems to give
>> false positives, but it has been inconsistent for a set amount of time
>> without fixing itself.
>
> Too complex stuff for such a simple situation.  Maybe one could
> peek the event queue for an event that fixes the windows's size
> and not complain if such an event is already pending?  Another
> option is to generate only a limited number of these warning for
> each window.
>
> Does the attached patch improve the situation?
>

I have applied the patch and it doesn't seem to change the situation,
FvwmIconMan is still triggering the hint size warnings every time a
window is added or removed.

jaimos

Re: FvwmIconMan still sometimes triggers Hint Warnings

[Jaimos Skriletz]

On Wed, Mar 1, 2017 at 5:30 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> On Tue, Feb 28, 2017 at 10:22:33PM -0700, Jaimos Skriletz wrote:
>> On Mon, Feb 27, 2017 at 11:10 PM, Jaimos Skriletz
>> <jaimosskril...@gmail.com> wrote:
>> > Hello,
>> >
>> > FvwmIconMan still reports Hint warnings even with the patchs applied.
>>
>> I wrote this small patch that has FvwmIconMan wait until the window
>> has resized to set the window hints. This is in the lines of Dominik
>> Vogt's patch, but waits until FvwmIconMan has fully resized to run
>> fix_manager_size() to set the window hints. My tests here no longer
>> seem to tiger the warnings like it still sometimes did.
>>
>> As an additional thought, talking to Thomas Adam about the patch in
>> #fvwm, he mentioned that the issue is more FVWM being overly cautious
>> and the fix should be in how fvwm handles size hint warnings over
>> working with FvwmIconMan to avoid triggering them.
>>
>
> So, if it's not possible to completely fix FvwmIconMan in a decent
> way, what do we do with the warning?  I'd rather not disable it,
> but the number of false positives is too high.  One could make a
> style that disables the warning for a certain class of windows,
> but that would probably be used as "style * ...", disabling the
> warning for everything.  :-/
>

FvwmIconMan isn't the only application that triggers these warnings,
but using it in a situation where it grows/shrinks is a very regular
way to cause the warnings and it fills up .xsession-error with mostly
warnings. Other applications I use only trigger these warnings rarely,
and in each case the application appears to work fine so yet more
false positives. But FvwmIconMan is the only one that regularly
resizes itself triggering the warning a lot.

I had two ideas on this, one is use a BugOpts option that can turn on
these warnings for a user who wants to debug things, but they are off
by default. This is basically your style idea and the affect will be
almost everywhere these warnings will not appear and thus may miss out
on programs that actually need to be reported.

Another is maybe don't have fvwm jump to conclusions that there is a
warning. What if there was some timer that fvwm gave the application
to fix itself before reporting a warning, and then the warning is not
just that the window had this inconstant state which seems to give
false positives, but it has been inconsistent for a set amount of time
without fixing itself.

Anyways, for those of us who use FvwmIconMan as a growing/shrinking
standalone module, this patch drastically reduces the amount of
warnings, but I agree it really doesn't seem like the way to deal with
this issue to make applications have to add these waits to deal with
resizing both the window and the size hints.

jaimos

Re: FvwmIconMan still sometimes triggers Hint Warnings

[Jaimos Skriletz]

On Mon, Feb 27, 2017 at 11:10 PM, Jaimos Skriletz
<jaimosskril...@gmail.com> wrote:
> Hello,
>
> FvwmIconMan still reports Hint warnings even with the patchs applied.
>

I wrote this small patch that has FvwmIconMan wait until the window
has resized to set the window hints. This is in the lines of Dominik
Vogt's patch, but waits until FvwmIconMan has fully resized to run
fix_manager_size() to set the window hints. My tests here no longer
seem to tiger the warnings like it still sometimes did.

As an additional thought, talking to Thomas Adam about the patch in
#fvwm, he mentioned that the issue is more FVWM being overly cautious
and the fix should be in how fvwm handles size hint warnings over
working with FvwmIconMan to avoid triggering them.

I don't know enough about the issue to say which is more appropriate,
but here is a patch that stops the warnings from being triggered in my
tests.

jaimos
From 227d7ea2597ec3fec304c53934fcc41773ab7e89 Mon Sep 17 00:00:00 2001
From: Jaimos Skriletz <jaimosskril...@gmail.com>
Date: Tue, 28 Feb 2017 17:43:12 -0700
Subject: [PATCH 1/1] Wait until FvwmIconMan is resized to set window HINTS

---
 modules/FvwmIconMan/xmanager.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/modules/FvwmIconMan/xmanager.c b/modules/FvwmIconMan/xmanager.c
index 58eaaedc..b4efe890 100644
--- a/modules/FvwmIconMan/xmanager.c
+++ b/modules/FvwmIconMan/xmanager.c
@@ -439,6 +439,16 @@ static void resize_window(WinManager *man)
 }
 MyXUngrabServer(theDisplay);
   }
+
+  // Wait until the window has resised to fix the HINTS.
+  // counter is used to break an infinte loop.
+  XWindowAttributes attribs;
+  int counter = 2;
+  while ( counter && (attribs.width != man->geometry.width ||
+  attribs.height != man->geometry.height)) {
+XGetWindowAttributes(theDisplay, man->theWindow, );
+counter--;
+  }
   fix_manager_size(man, man->geometry.width, man->geometry.height);
 }
 
-- 
2.11.0

FvwmIconMan still sometimes triggers Hint Warnings

[Jaimos Skriletz]

Hello,

FvwmIconMan still reports Hint warnings even with the patchs applied.

http://www.mail-archive.com/fvwm-workers@fvwm.org/msg04570.html

Using the current master branch I get the warnings from FvwmIconMan in
the situation it is set to grow/shrink. The easiest way to get this is
use the defaults, such as Module FvwmIconMan TestIconMan, then
adding/removing windows is triggering the following warning.

[fvwm][GetWindowSizeHints]: <> reason: 4: The hints have been
ignored because the window's current size would have become invalid.
The new hints willbecome active when the window generates the next
ConfigureRequest.

[fvwm][GetWindowSizeHints]: <> The application window (id 0x5a4)
  "FvwmIconMan" has broken size hints (inconsistent with current size).
fvwm is ignoring those hints.hint override = 0, flags = 371
  min_width = 120, min_height = 180, max_width = 120, max_height = 180
  width_inc = 1, height_inc = 1
  min_aspect = 0/0, max_aspect = 0/0
  base_width = 0, base_height = 0
  win_gravity = 3

If you are having a problem with the application, send a bug report
with this message included to the application owner.
There is no need to notify fvwm-workers@fvwm.org.

As before they are triggered whenever a window is added/removed from
the list. I looked at the patch and saw the functions that released
and then reset the hints, and if I comment out line 442 in
modules/FvwmIconMan/xmanager.c

 fix_manager_size(man, man->geometry.width, man->geometry.height);

The warnings are not triggered. So it seems to me there is some
race/timing issue where it may fix the size before
XMoveResizeWindow() has finished its task causing the warning to be
fired. At this point I'm unsure how to have fix_manager_size() wait
until the action is complete as to avoid triggering the warnings.

jaimos

Re: Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed

[Jaimos Skriletz]

On Sun, Jan 15, 2017 at 10:10 PM, Jaimos Skriletz
<jaimosskril...@gmail.com> wrote:
> On Sun, Jan 15, 2017 at 8:44 PM, Jaimos Skriletz
> <jaimosskril...@gmail.com> wrote:
>> On Wed, Dec 28, 2016 at 3:16 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
>>> On Tue, Dec 27, 2016 at 05:34:08PM -0700, Jaimos Skriletz wrote:
>>>> On Tue, Dec 27, 2016 at 5:28 PM, Jaimos Skriletz
>>>> <jaimosskril...@gmail.com> wrote:
>>>> > On Tue, Dec 27, 2016 at 5:15 PM, Dominik Vogt <dominik.v...@gmx.de> 
>>>> > wrote:
>>>> >> On Tue, Dec 27, 2016 at 05:04:40PM -0700, Jaimos Skriletz wrote:
>>>> >>> On Tue, Dec 27, 2016 at 4:52 PM, Jaimos Skriletz
>>>> >>> <jaimosskril...@gmail.com> wrote:
>>>> >>> > On Tue, Dec 27, 2016 at 3:44 PM, Dominik Vogt <dominik.v...@gmx.de> 
>>>> >>> > wrote:
>>>> >>> >> On Mon, Dec 26, 2016 at 01:17:05PM -0700, Jaimos Skriletz wrote:
>>>> >>> >>> Hello,
>>>> >>> >>>
>>>> >>> >>> This was reported by a Debian user. Please retain the CC to
>>>> >>> >>> 849355-forwar...@bugs.debian.org in your response, so that
>>>> >>> >>> the Debian BTS has a record.
>>>> >>> >>>
>>>> >>> >>> In short when running FvwmIconMan, fvwm prints warnings to stderr 
>>>> >>> >>> when
>>>> >>> >>> opening and closing windows. I too have had this issue in 2.6.7 
>>>> >>> >>> (and
>>>> >>> >>> previous versions) so I can also say it affects my Debian system.
>>>> >>> >>
>>> Fixed on the (new) fvwm2-stable branch; patch for the development
>>> branches will follow one I've figured out how to deal with the
>>> two repositories.
>>>
>>
>
> I'm also getting these errors from other applications. I will remove
> the patches and see if the behvior goes back to the way it was, or if
> there is something else in my system causing fvwm to output these
> warnings. Here is one from a vim window.
>

After further investigation these new warnings do not seem related to
the original bug as they occur with or without the patches in
question. If I remove the patches I get the old behavior back. And
without the patches I still get gvim and other windows giving
warnings. I wonder if there is something new going on on my system in
the other applications causing these warnings or if they were there
before, I just didn't notice in the spam of the ones from FvwmIconMan.

Anyways thanks again for your help on this.

jaimos

Re: Menu hot keys with accented characters

[Jaimos Skriletz]

On Sun, Jan 8, 2017 at 3:14 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> On Sun, Jan 01, 2017 at 02:10:03AM -0700, Jaimos Skriletz wrote:
>> Here is an old (minor) bug that is lurking in the Debian BTS.
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464363
>>
>> The bug is that when assigning non ASCII keys as hot keys in a Menu,
>> the underline underlines the non ASCII character and the one after it.
>
> Hotkeys must be printable 7 bit Ascii characters, which is
> probably not documented.  The reason for this is that the hotkey
> is specified as a substring from the item label (e.g. "á") instead
> of a key name ("aacute").  X has no real way to convert a string
> into a key name or vice versa, so hotkeys work only for keys where
> both representations are the same.
>

If keybindings for non 7 bit ASCII keys don't work, documentation
could be useful. Though this has been around for a long time and not
many seem to mention it so it probably isn't a big deal in the overall
picture.

>
>> Here is a simple test
>>
>> DestroyMenu TestMenu
>> AddToMenu TestMenu "Test" Title
>> + "T&êst" Echo Test
>> + "&ñice one" Echo Nice One
>> + "Th&ááát" Echo Thaaat
>> + " One" Echo This
>>
>> Then open the menu.
>
> I can reproduce the drawing bug.  Maybe we should simply disable
> hotkeys completely for anything not 7 bit ASCII.
>

Disabling the keys since they aren't working anyways and giving a
warning may be useful for those who try to use non ASCII characters.
Such a warning should only trigger when items are added to the menu,
not each time the menu pops up.

At least this way if anyone tries to use non-ASCII characters they are
correctly informed that they do not work and this can move to a
feature request to add support for these keys.

thanks for looking into this.

jaimos

Menu hot keys with accented characters

[Jaimos Skriletz]

Hello,

Here is an old (minor) bug that is lurking in the Debian BTS.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464363

The bug is that when assigning non ASCII keys as hot keys in a Menu,
the underline underlines the non ASCII character and the one after it.

Here is a simple test

DestroyMenu TestMenu
AddToMenu TestMenu "Test" Title
+ "T&êst" Echo Test
+ "&ñice one" Echo Nice One
+ "Th&ááát" Echo Thaaat
+ " One" Echo This

Then open the menu.

In addition to the visual bug, I was not able to correctly use these
non-ASCII characters as hot keys. Since I don't have a keyboard that
has accented keys on them it could be that I can't properly test if
they work as hot keys (since I have to hit alt-key to type them).

Seems there was once a patch trying to make these hot keys work better

http://www.mail-archive.com/fvwm-workers@fvwm.org/msg01916.html

Unsure if the bug is just an extra character is underlined in the Menu
or if using non ASCII characters for hot-keys doesn't work.

jaimos

Re: Improving the default config

[Jaimos Skriletz]

On Sat, Dec 31, 2016 at 8:31 AM, Dominik Vogt  wrote:
> On Sat, Dec 31, 2016 at 04:18:26PM +0100, Dominik Vogt wrote:
>> See branch dv/devel for various patches.
>
> (Feel free to use any of these patches to build a new patch.)
>

Thanks. I incorporated some of your suggestions.

I have hopefully made fvwm-menu-desktop error out nicer when either
python-xdg or a .menu file is not found.

In additions I have grouped some of your config changes (and some I
had in mind) into a single patch on js/default-config-changes.

Hopefully the commits explain enough, if you have any questions please ask.

happy new year.

jaimos

Re: Bug#802604: fvwm: focus is not given to the window when changing page with invisible mouse pointer

[Jaimos Skriletz]

On Sat, Dec 31, 2016 at 6:11 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> On Sat, Dec 31, 2016 at 05:37:45AM -0700, Jaimos Skriletz wrote:
>> On Sat, Dec 31, 2016 at 4:11 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
>> > On Fri, Dec 30, 2016 at 09:12:50PM -0700, Jaimos Skriletz wrote:
>> >> On Fri, Dec 30, 2016 at 8:49 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
>> >> > On Fri, Dec 30, 2016 at 08:24:07PM -0700, Jaimos Skriletz wrote:
>> >> >> Hello,
>> >> >>
>> >> >> This was reported by a Debian user. Please retain the CC to
>> >> >> 802604-forwar...@bugs.debian.org in your response, so that
>> >> >> the Debian BTS has a record.
>> >> >>
>> >> >> In short if the mouse cursor is over the root window and hidden with
>> >> >> unclutter, when switching pages (and maybe desks), focus is not given
>> >> >> to the window under the pointer.
>> >> >
>> >> > Works fine for me.  I'd need a precise description + config file
>> >> > to test this.
>> >> >
>> >>
>> >> Using SloppyFocus with a 2x2 grid of pages with the default config and
>> >> the following two key bindings
>> >>
>> >> Key Right A CM Scroll 100 0
>> >> Key Left A CM Scroll -100 0
>> >>
>> >> I then run unclutter to hide the mouse after being idle for a second:
>> >>
>> >> unclutter -idle 1 -root
>> >>
>> >> I move the mouse over the root window and wait for it to be hidden.
>> >> Once it is hidden
>> >> I use the key binding to switch to a new page. After I switch to the
>> >> page focus is kept
>> >> on the window in the old page and is not transferred.
>> >
>> > Still does not happen for me.  With unclutter 8-18 (Debian):
>> >
>> >  * Start fvwm with default config.
>> >  * Open two Xterms from the menu (left side of screen).
>> >  * Open FvwmConsole and move it to the bottom right corner.
>> >  * Type
>> >  style * sloppyfocus
>> >  Key Right A CM Scroll 100 0
>> >  Key Left A CM Scroll -100 0
>> >in FvwmConsole.
>> >  * Run "unclutter -idle 1 -root" from one of the Xterms.
>> >  * Press ctrl-alt-right to switch to page (1 0).
>> >  * (Optional: open an Xterm there and close it to take away the
>> >focus from any window on (0 0).)
>> >  * Move the pointer roughly to the middle of the FvwmConsole
>> >window.
>> >  * Press ctrl-alt-left to switch to page (0 0).
>> >  => The pointer ends up over FvwmConsole which gets the focus.
>> >
>>
>> These steps work for me.
>
> "Work" = "the window does not get focus"?
>

Yes work, as in reproduces the issue.

>> I tried with various versions of the optional
>> step, though in my tests I left the xterm around, but this did not
>> seem to matter, Leaving the xterm or not did not change the result.
>
> Neither for me.
>
>> Unsure how else to describe it as those steps cause this to happen,
>> just tested again in a VM and have attached screen shots to show how
>> the focus is right before and right after I switch pages. In the
>> before picture the mouse is in the bottom right corner over the root
>> window near the panel (but not over it) and unclutter has hidden the
>> mouse.
>>
>> Only other thing I note, as soon as I move the mouse, focus is then
>> given to the window under the mouse, but until then it remains on the
>> window on the previous page.
>
> You probably have a different version of unclutter.  In the past,
> there was some change of the method it uses to hide the pointer.
> his may well play a role here.  Can you find out which version you
> have?  I guess it's something that should be fixed in unclutter if
> it's still an issue with the latest version.
>

Using the version from Debian stretch, 8-20.

I downgraded to the wheezy version, 8-18 that you reported to use, and
no longer can reproduce this bug. So it is something with a change in
unclutter. I will reassign the bug to unclutter.

Thanks for the help.

jaimos

Re: FVWM: Telling fvwm to not use the top left 124x1152 even for maximized windows

[Jaimos Skriletz]

On Fri, Dec 30, 2016 at 1:29 AM, Thomas Glanzmann  wrote:
> Hello Jaimos,
>
>> This is a setting that doesn't need to be run in the function, as it
>> only needs to be set once. Once this is set, this changes the behavior
>> of Maximize and placement functions.
>
> I tried that first, but that didn't work for me. I put it in my .fvwm2rc
> config at the top:
>
> EWMHBaseStruts 144 0 0 0
>

That is all you need. You don not need to run this from the function
each time. You must have something overwriting this setting.

> I also tried:
>
> Style * EWMHBaseStruts 144 0 0 0
>

EWMHBaseSTruts is not a Style, read the man page if you are unsure how
to use it.

>
> Find my .fvwm2rc here: https://pbot.rmdir.de/HvZifRKhJuAx5HqVKScPEw

This is not complete, you have a Read ~./fvwm2rc-local (well you
should but you use PipeRead and cat, just use Read). You also have
some other things you don't need but that is beyond this thread.

If the line is not working it is because you override it somewhere in
your config file and putting it in the function sets it back. You
shouldn't need that. When fvwm loads, use FvwmConsole and enter in
that EWMHBaseStruts command into the console, it should work. This
shows that you have something in your local config that is overriding
the setting.

Running that command each time you maximize a window is not needed
unless your configuration is constantly resetting the EWMHBaseStruts

jaimos

Manpage patch + NEWS patch for 2.6.7

[Jaimos Skriletz]

Hello,

A Debian user pointed out that the manpages still mentioned some of
the removed modules. The attach patch either removes or updates the
manpages reference to the modules that were removed in 2.6.7.

Additionally it was also pointed out that FvwmDebug was not included
in the list of removed modules in the NEWS file.

Attached are patches to use as needed.

jaimos
--- a/doc/commands/Module.xml
+++ b/doc/commands/Module.xml
@@ -26,7 +26,6 @@ spawned. Currently several modules, incl
 ,
 ,
 ,
-,
 ,
 
 support aliases.  Aliases are useful if more than one instance of
@@ -53,12 +52,8 @@ Module FvwmForm MyForm
  (a command server to use with shell's FvwmCommand client),
  (to execute fvwm commands directly),
  (to preprocess your config with cpp),
- (to help debug fvwm),
- (the place to dragdrop to),
  (trigger various actions by events),
  (to bring up dialogs),
- (to bring up GTK menus and dialogs),
- (like the mwm IconBox),
  (a flexible icon manager),
  (to get window info),
  (to preprocess your config with m4),
@@ -66,16 +61,7 @@ Module FvwmForm MyForm
  (a Perl manipulator and preprocessor),
  (to locate and control obscured windows by using small proxy windows),
  (to rearrange windows),
- (saves the desktop state in .xinitrc style),
- (saves the desktop state in fvwm commands),
  (another powerful dialog toolkit),
- (puts scrollbars on any window),
- (a generic tabbing module),
- (a Windows like task bar),
- (managed colorsets, obsolete),
- (an AfterStep like button bar),
- (a configurable fvwm menu listing current windows),
- (a window list).
 These modules have their own man
 pages.  There may be other modules out on there as well.
 
--- a/doc/commands/Colorset.xml
+++ b/doc/commands/Colorset.xml
@@ -237,22 +237,15 @@ uses Colorset 10 as background. If you w
 the
 RootTransparent
 option.
-,
+
 ,
-,
-
 and
-
+,
 are relatively simple. There is one main colorset option which
 defines the background of the window and the other colorsets (if
 any) are drawn on the foreground. The case of
- and
-
-are simpler. With
-
-all the colorsets are drawn on the foreground and with
 
-the two colorsets refer to the window backgrounds.
+is simpler, the two colorsets refer to the window backgrounds.
 
 is more complicated as almost everything in the pager are windows
 with some parental relations (the mini windows are the child and
--- a/doc/fvwm/initialization.xml
+++ b/doc/fvwm/initialization.xml
@@ -136,14 +136,14 @@ is used instead of ExitFunction.
  InitFunction
  InitFunction
  + I  
- + I  
+ + I  
  + I  xsetroot -solid cyan
  + I  xterm
  + I  netscape
 
  RestartFunction
  RestartFunction
- + I  
+ + I  
 
  SessionInitFunction
  SessionInitFunction
--- a/doc/commands/LocalePath.xml
+++ b/doc/commands/LocalePath.xml
@@ -87,8 +87,6 @@ parameter:
 available.
 
 Note that the
-
-module has its own catalog and that the
 
 module has a set of special instructions for string
 translation. It is out of the scope of this discussion to explain
--- a/doc/commands/Style.xml
+++ b/doc/commands/Style.xml
@@ -1105,7 +1105,7 @@ window. This miniature icon can be drawn
 (see
 ),
 and can be used by various fvwm modules
-(,  and ).
+( and ).
 It takes the name of a pixmap as an argument.
 
  and 
@@ -2265,8 +2265,8 @@ Style rxvt !State 11
 
 styles do not appear in the menu that is created with the
 
-command or the lists shown in several modules like
- or .
+command or the lists shown in modules like
+.
 In the modules, the style can usually be ignored with an option.
 Please refer to the man page of the module in question for
 further information.  To disable this feature, use the default
--- a/doc/commands/Wait.xml
+++ b/doc/commands/Wait.xml
@@ -44,8 +44,8 @@ After the xmh window appears control mov
 Fvwm remains partially functional during a wait, but any input
 from the modules is queued up and processed only after the window
 appears or the command is aborted.  For example, windows can not
-be focused with  or 
- during a wait.
+be focused with  or
+ during a wait.
 
 You can escape from a
 Wait
--- a/doc/fvwm/colorsets.xml
+++ b/doc/fvwm/colorsets.xml
@@ -24,7 +24,8 @@ other color operations.
 
 was introduced to manage colorsets.  Starting with the 2.5.x beta
 version, the  functionality was moved to the core fvwm,
-so this module became obsolete.
+so this module became obsolete. In 2.6.7 the 
+module was removed.
 
 The old syntax:
 
--- a/doc/fvwm/virtualDesktop.xml
+++ b/doc/fvwm/virtualDesktop.xml
@@ -29,11 +29,11 @@ windows on a range of desktops can be vi
 ,
 a miniature view of the desktops.  The pager is an accessory
 program, called a module, which is not essential for the window
-manager to operate.  Windows may also be listed, along with their
-geometries, in a window list, accessible as a pop-up menu, or as a
-separate window, called the
-
-(another module).
+manager to operate.  Windows may also be listed using the
+
+command or the
+
+module.
 
 Fvwm keeps the windows on the desktop in a 

Spelling errors and manpage patchs

[Jaimos Skriletz]

Hello,

In making the Debian package lintian found some spelling errors in
both the man page and some binaries. Patch attached.

Additionally a Debian user noticed that the manpage under ClickTime
did not specify this also configures time for double clicks. The
second patch just adds a small note to this.

jaimos
Description: Add double click time info to ClickTime in manpage.
Author: Jaimos Skriletz <jaimosskril...@gmail.com>
Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567387
--- a/doc/commands/ClickTime.xml
+++ b/doc/commands/ClickTime.xml
@@ -26,4 +26,6 @@ is 150 milliseconds.  Omitting the delay
 ClickTime
 to the default.
 
+ClickTime also specifies the delay
+between two clicks to be interpreted as a double-click.
 
Description: Spelling Errors.
 Fixes spelling errors found by lintian.
Author: Jaimos Skriletz <jaimosskril...@gmail.com>
Last-Update: 2016-12-05
--- a/modules/FvwmCommand/FvwmCommand.c
+++ b/modules/FvwmCommand/FvwmCommand.c
@@ -532,7 +532,7 @@ void usage(void)
   fprintf (stderr,
 	   "  -v  print version number\n");
   fprintf (stderr,
-	   "  -w   waiting time for the reponse from fvwm\n");
+	   "  -w   waiting time for the response from fvwm\n");
   fprintf (stderr, "\nDefault fifo names are ~/.%sC and ~/.%sM\n",
 	   MYNAME, MYNAME);
   fprintf (stderr, "Default waiting time is 500,000 us\n");
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -4213,7 +4213,7 @@ void InitEventHandlerJumpTable(void)
 	{
 		/* should never happen */
 		fvwm_msg(ERR, "InitEventHandlerJumpTable",
-			 "Faild to initialize event handlers");
+			 "Failed to initialize event handlers");
 		exit(1);
 	}
 	if (FShapesSupported)
@@ -4231,7 +4231,7 @@ void InitEventHandlerJumpTable(void)
 shape_jump_table))
 		{
 			fvwm_msg(ERR, "InitEventHandlerJumpTable",
- "Faild to init Shape event handler");
+ "Failed to init Shape event handler");
 		}
 	}
 
--- a/fvwm/builtins.c
+++ b/fvwm/builtins.c
@@ -611,7 +611,7 @@ static char *ReadMultiPixmapDecor(char *
 			{
 fvwm_msg(
 	ERR, "ReadMultiPixmapDecor",
-	"Colorset shoule take one or two "
+	"Colorset should take one or two "
 	"positive integers as argument");
 			}
 			else
--- a/modules/FvwmScript/Instructions.c
+++ b/modules/FvwmScript/Instructions.c
@@ -794,7 +794,7 @@ static char *FuncSendMsgAndGet(int *NbAr
   FILE *f;
   struct timeval timeout;
 
-  /* comunication name */
+  /* communication name */
   (*NbArg)++;
   com_name=CalcArg(TabArg,NbArg);
   /* the command send to the receiver */
@@ -851,7 +851,7 @@ static char *FuncSendMsgAndGet(int *NbAr
   if (i > IN_FIFO_NBR_OF_TRY)
   {
 	fprintf(stderr,
-	 "[%s][GetMsgAndGet]: <> No in fifo %s for comunication %s\n",
+	 "[%s][GetMsgAndGet]: <> No in fifo %s for communication %s\n",
 	  ScriptName,in_fifo,com_name);
 	close(filedes);
 	err = 1;
@@ -908,7 +908,7 @@ static char *FuncSendMsgAndGet(int *NbAr
   if (i > OUT_FIFO_NBR_OF_TRY)
   {
 	fprintf(stderr,
-	 "[%s][GetMsgAndGet]: <>: No out fifo %s for comunication %s\n",
+	 "[%s][GetMsgAndGet]: <>: No out fifo %s for communication %s\n",
 	 ScriptName,out_fifo,com_name);
 	err = 1;
 	break;
--- a/modules/FvwmBacker/FvwmBacker.1.in
+++ b/modules/FvwmBacker/FvwmBacker.1.in
@@ -101,7 +101,7 @@ Cancels the effect of the previous optio
 It it possible to replace FvwmBacker's configuration at run-time,
 although it is not yet possible to remove existing configuration
 lines.  This is done by simply removing the old configuration from
-withing fvwm and then read a new one.  This can be done in many
+within fvwm and then read a new one.  This can be done in many
 ways, for example by using an fvwm function or one of the modules
 .BR FvwmCommand " or " FvwmConsole .
 
--- a/modules/FvwmButtons/FvwmButtons.1.in
+++ b/modules/FvwmButtons/FvwmButtons.1.in
@@ -988,7 +988,7 @@ inside the relief and padding.
 
 .SH DYNAMICAL ACTIONS
 A running FvwmButtons instance may receive some commands at run time.
-This is achived using the fvwm command
+This is achieved using the fvwm command
 .nf
 .sp
 SendToModule FvwmButtons-Alias  
--- a/modules/FvwmPerl/FvwmPerl.1
+++ b/modules/FvwmPerl/FvwmPerl.1
@@ -204,7 +204,7 @@ The following 5 options are only valid t
 If \fB\-\-nolock\fR is added here, \fBModuleSynchronous\fR returns immediately. Note that \fBModule\fR returns immediately regardless of this option.
 .SH "USING ALIAS"
 .IX Header "USING ALIAS"
-Aliases allow to have several module invocations and work separately with all invocations, here is an example:
+Aliases allow one to have several module invocations and work separately with all invocations, here is an example:
 .PP
 .Vb 4
 \&ModuleSynchronous FvwmPerl FvwmPerl\

Re: Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed

[Jaimos Skriletz]

On Tue, Dec 27, 2016 at 5:28 PM, Jaimos Skriletz
<jaimosskril...@gmail.com> wrote:
> On Tue, Dec 27, 2016 at 5:15 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
>> On Tue, Dec 27, 2016 at 05:04:40PM -0700, Jaimos Skriletz wrote:
>>> On Tue, Dec 27, 2016 at 4:52 PM, Jaimos Skriletz
>>> <jaimosskril...@gmail.com> wrote:
>>> > On Tue, Dec 27, 2016 at 3:44 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
>>> >> On Mon, Dec 26, 2016 at 01:17:05PM -0700, Jaimos Skriletz wrote:
>>> >>> Hello,
>>> >>>
>>> >>> This was reported by a Debian user. Please retain the CC to
>>> >>> 849355-forwar...@bugs.debian.org in your response, so that
>>> >>> the Debian BTS has a record.
>>> >>>
>>> >>> In short when running FvwmIconMan, fvwm prints warnings to stderr when
>>> >>> opening and closing windows. I too have had this issue in 2.6.7 (and
>>> >>> previous versions) so I can also say it affects my Debian system.
>>> >>
>>> >>
>>> >> I don't get any such messages with or without FvwmIconMan.  Can
>>> >> you give detailed instructions pelase?
>>> >>
>>> >
>>> > Using Fvwm 2.6.7 Debian package, doubt it is any of the debian
>>> > patches, but I will compile a version without patches and test.
>>> >
>>>
>>> Tested with a fresh compile of Fvwm 2.6.7 without any debian patches,
>>> same issue.
>>>
>>> >
>>> > I tested this with other windows and modules. FvwmScript modules
>>> > seemed to trigger it, FvwmIdentify did not, so I wonder if it has to
>>> > do with transient windows or not (just something I noticed).
>>> >
>>>
>>> Nevermind this, FvwmIdentify is not a traisnent window, the reason it
>>> was not producing the warning was it was configured so FvwmIconMan did
>>> not create a button for that window.
>>>
>>> After further testing the warning seems to be due to be caused by
>>> adding/removing the button for a window from FvwmIconMan. Windows that
>>> appear there trigger the warning but ones that don't appear don't.
>>
>> Still no luck to reproduce it.  After said message there should
>> always be this one which prints all the details of the window and
>> the faulty hints:
>>
>> fvwm_msg(
>> WARN, "GetWindowSizeHints",
>> "The application window (id %#lx)\n"
>> "  \"%s\" has broken size hints (%s).\n"
>> "fvwm is ignoring those hints.  "
>> "  hint override = %d, flags = %lx\n"
>> "  min_width = %d, min_height = %d, "
>> "max_width = %d, max_height = %d\n"
>> "  width_inc = %d, height_inc = %d\n"
>> "  min_aspect = %d/%d, max_aspect = %d/%d\n"
>> "  base_width = %d, base_height = %d\n"
>> "  win_gravity = %d\n",
>>
>
> I get no other output after the warning, so that message is never
> printed to stderr on my system.
>
> Unsure if this helps, but I did enable BugOpts DebugCRMotionMethod,
> and get the output
>
> _cdim: not moved 0x55927d4a8990 'FvwmIconMan'
>
> after each time the warning is produced.

Further testing, if I set the ManagerGeometry to something like 5x3 so
FvwmIconMan doesn't resize itself, I no longer get the warning. It is
only with the default like 0x1, causing the window to grow/shrink I
get the warning.

Wild guess, could it be some timing issue during the resizing of the
window when adding/removing a button cause the window's current size
to become invalid as per the warning?

jaimos

Re: Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed

[Jaimos Skriletz]

On Tue, Dec 27, 2016 at 5:15 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> On Tue, Dec 27, 2016 at 05:04:40PM -0700, Jaimos Skriletz wrote:
>> On Tue, Dec 27, 2016 at 4:52 PM, Jaimos Skriletz
>> <jaimosskril...@gmail.com> wrote:
>> > On Tue, Dec 27, 2016 at 3:44 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
>> >> On Mon, Dec 26, 2016 at 01:17:05PM -0700, Jaimos Skriletz wrote:
>> >>> Hello,
>> >>>
>> >>> This was reported by a Debian user. Please retain the CC to
>> >>> 849355-forwar...@bugs.debian.org in your response, so that
>> >>> the Debian BTS has a record.
>> >>>
>> >>> In short when running FvwmIconMan, fvwm prints warnings to stderr when
>> >>> opening and closing windows. I too have had this issue in 2.6.7 (and
>> >>> previous versions) so I can also say it affects my Debian system.
>> >>
>> >>
>> >> I don't get any such messages with or without FvwmIconMan.  Can
>> >> you give detailed instructions pelase?
>> >>
>> >
>> > Using Fvwm 2.6.7 Debian package, doubt it is any of the debian
>> > patches, but I will compile a version without patches and test.
>> >
>>
>> Tested with a fresh compile of Fvwm 2.6.7 without any debian patches,
>> same issue.
>>
>> >
>> > I tested this with other windows and modules. FvwmScript modules
>> > seemed to trigger it, FvwmIdentify did not, so I wonder if it has to
>> > do with transient windows or not (just something I noticed).
>> >
>>
>> Nevermind this, FvwmIdentify is not a traisnent window, the reason it
>> was not producing the warning was it was configured so FvwmIconMan did
>> not create a button for that window.
>>
>> After further testing the warning seems to be due to be caused by
>> adding/removing the button for a window from FvwmIconMan. Windows that
>> appear there trigger the warning but ones that don't appear don't.
>
> Still no luck to reproduce it.  After said message there should
> always be this one which prints all the details of the window and
> the faulty hints:
>
> fvwm_msg(
> WARN, "GetWindowSizeHints",
> "The application window (id %#lx)\n"
> "  \"%s\" has broken size hints (%s).\n"
> "fvwm is ignoring those hints.  "
> "  hint override = %d, flags = %lx\n"
> "  min_width = %d, min_height = %d, "
> "max_width = %d, max_height = %d\n"
> "  width_inc = %d, height_inc = %d\n"
> "  min_aspect = %d/%d, max_aspect = %d/%d\n"
> "  base_width = %d, base_height = %d\n"
> "  win_gravity = %d\n",
>

I get no other output after the warning, so that message is never
printed to stderr on my system.

Unsure if this helps, but I did enable BugOpts DebugCRMotionMethod,
and get the output

_cdim: not moved 0x55927d4a8990 'FvwmIconMan'

after each time the warning is produced.

Re: Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed

[Jaimos Skriletz]

On Tue, Dec 27, 2016 at 4:52 PM, Jaimos Skriletz
<jaimosskril...@gmail.com> wrote:
> On Tue, Dec 27, 2016 at 3:44 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
>> On Mon, Dec 26, 2016 at 01:17:05PM -0700, Jaimos Skriletz wrote:
>>> Hello,
>>>
>>> This was reported by a Debian user. Please retain the CC to
>>> 849355-forwar...@bugs.debian.org in your response, so that
>>> the Debian BTS has a record.
>>>
>>> In short when running FvwmIconMan, fvwm prints warnings to stderr when
>>> opening and closing windows. I too have had this issue in 2.6.7 (and
>>> previous versions) so I can also say it affects my Debian system.
>>
>>
>> I don't get any such messages with or without FvwmIconMan.  Can
>> you give detailed instructions pelase?
>>
>
> Using Fvwm 2.6.7 Debian package, doubt it is any of the debian
> patches, but I will compile a version without patches and test.
>

Tested with a fresh compile of Fvwm 2.6.7 without any debian patches,
same issue.

>
> I tested this with other windows and modules. FvwmScript modules
> seemed to trigger it, FvwmIdentify did not, so I wonder if it has to
> do with transient windows or not (just something I noticed).
>

Nevermind this, FvwmIdentify is not a traisnent window, the reason it
was not producing the warning was it was configured so FvwmIconMan did
not create a button for that window.

After further testing the warning seems to be due to be caused by
adding/removing the button for a window from FvwmIconMan. Windows that
appear there trigger the warning but ones that don't appear don't.

jaimos

Re: Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed

[Jaimos Skriletz]

On Tue, Dec 27, 2016 at 3:44 PM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> On Mon, Dec 26, 2016 at 01:17:05PM -0700, Jaimos Skriletz wrote:
>> Hello,
>>
>> This was reported by a Debian user. Please retain the CC to
>> 849355-forwar...@bugs.debian.org in your response, so that
>> the Debian BTS has a record.
>>
>> In short when running FvwmIconMan, fvwm prints warnings to stderr when
>> opening and closing windows. I too have had this issue in 2.6.7 (and
>> previous versions) so I can also say it affects my Debian system.
>
>
> I don't get any such messages with or without FvwmIconMan.  Can
> you give detailed instructions pelase?
>

Using Fvwm 2.6.7 Debian package, doubt it is any of the debian
patches, but I will compile a version without patches and test.

Run FvwnIconMan by itself with no configuration, so FvwmIconMan is in
its own window (if FvwmIconMan was swallowed in FvwmButtons I did not
notice this warning).

Once FvwmIconMan is running, run xterm, warning appears, close xterm,
warning appears again.

I tested this with other windows and modules. FvwmScript modules
seemed to trigger it, FvwmIdentify did not, so I wonder if it has to
do with transient windows or not (just something I noticed).

If you are not able to reproduce this wonder if it is something
specific with Debian's xserver, let me know what other output you
would want.

jaimos

Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed

[Jaimos Skriletz]

Hello,

This was reported by a Debian user. Please retain the CC to
849355-forwar...@bugs.debian.org in your response, so that
the Debian BTS has a record.

In short when running FvwmIconMan, fvwm prints warnings to stderr when
opening and closing windows. I too have had this issue in 2.6.7 (and
previous versions) so I can also say it affects my Debian system.

-- Forwarded message --
From: Vincent Lefevre 
Date: Sun, Dec 25, 2016 at 6:37 PM
Subject: Bug#849355: fvwm: GetWindowSizeHints warnings when windows
and opened and closed
To: Debian Bug Tracking System 


Package: fvwm
Version: 1:2.6.7-2
Severity: normal

I get the following warnings in my .xsession-errors file (where FVWM's
standard error is redirected):

[fvwm][GetWindowSizeHints]: <> reason: 2: The hints have been
ignored because the window's current size would have become invalid.
The new hints will become active when the window generates the next
ConfigureRequest.

when a window is opened.

[fvwm][GetWindowSizeHints]: <> reason: 4: The hints have been
ignored because the window's current size would have become invalid.
The new hints will become active when the window generates the next
ConfigureRequest.

when a window is closed.

I've tried with windows from the following applications: xterm, Emacs,
xev. This seems to be always reproducible.

This also occurs when I move to a different page with FvwmPager, with
lots of warnings (I assume one for each window of the old and new
pages).

After 23 hours, the size of my .xsession-errors file is 678 KB.
I don't think that the space taken is much a problem, but the major
consequence is that these warnings can easily hide more interesting
warning/error messages (from FVWM or applications started by it).

Edit (from a followup email):

This only occurs when I use the FvwmIconMan module (which I start
from RestartFunction, itself invoked from InitFunction).

If I remove my specific FvwmIconMan configuration, the problem still
occurs.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500,
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fvwm depends on:
ii  libc6   2.24-8
ii  libcairo2   1.14.8-1
ii  libfontconfig1  2.11.0-6.7
ii  libfreetype62.6.3-3+b1
ii  libfribidi0 0.19.7-1
ii  libgdk-pixbuf2.0-0  2.36.2-1
ii  libglib2.0-02.50.2-2
ii  libice6 2:1.0.9-1+b1
ii  libperl4-corelibs-perl  0.003-2
ii  libpng16-16 1.6.26-6
ii  libreadline77.0-1
ii  librplay3   3.3.2-16+b1
ii  librsvg2-2  2.40.16-1
ii  libsm6  2:1.2.2-1+b1
ii  libstroke0  0.5.1-8
ii  libtinfo5   6.0+20161126-1
ii  libx11-62:1.6.4-2
ii  libxcursor1 1:1.1.14-1+b1
ii  libxext62:1.3.3-1
ii  libxft2 2.3.2-1
ii  libxinerama12:1.1.3-1+b1
ii  libxpm4 1:3.5.12-1
ii  libxrender1 1:0.9.10-1
ii  perl5.24.1~rc4-1

Versions of packages fvwm recommends:
ii  lxmenu-data  0.1.5-1
ii  python   2.7.13-1
ii  python-xdg   0.25-4

Versions of packages fvwm suggests:
ii  cpp   4:6.2.1-1
ii  libx11-protocol-perl  0.56-7
ii  m41.4.17-5
ii  perl-tk   1:804.033-1+b3
pn  stalonetray   

-- no debconf information

fvwm-perllib patch

[Jaimos Skriletz]

Hello,

There was a bug reported in Debian about fvwm-perllib man's use of
pod2man via a pipe.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777471

Summary: Newer versions of pop2man will give an error if the --name
flag is not present and sets the title to STDIN if error handling is
set to proceed despite errors.

The attached patch adds the --name flag to the pod2man call to set the
manpage name.

In addition when testing this perl gave me deprecated warnings about
use of {} in regex without being escaped. The patch also adds escape
characters to {} inside of regex.

jaimos
Description: Adds --name '$topic' to pod2man and fixes deprecated warning.
 pod2man used in a pipe needs a --name to set manpage name.
 pod2man now errors out or defaults the title to STDIN if error handling
 is set to proceede despite errors.
 .
 Fixed a deprecated warning about unescaped braces {} in regex.
Author: Jaimos Skriletz <jaimosskril...@gmail.com>
Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777471
--- a/bin/fvwm-perllib.in
+++ b/bin/fvwm-perllib.in
@@ -390,7 +390,7 @@ if (exists $internal_pods->{$topic}) {
 	if ($topic eq 'index') {
 		my @class_names = sort @{list_filenames($perllibdir, 1)};
 		@class_names = map { s!\.pm$!!; s!/!::!g; $_ } @class_names;
-		$text =~ s/{{CLASS_NAMES}}/join("\n", @class_names)/seg;
+		$text =~ s/\{\{CLASS_NAMES\}\}/join("\n", @class_names)/seg;
 	}
 
 	if ($topic eq 'events') {
@@ -404,7 +404,7 @@ if (exists $internal_pods->{$topic}) {
 			/eg;
 			$result .= "\n";
 		}
-		$text =~ s!{{EVENT_NAMES}}!$result!se;
+		$text =~ s!\{\{EVENT_NAMES\}\}!$result!se;
 	}
 
 } else {
@@ -416,7 +416,7 @@ if (exists $internal_pods->{$topic}) {
 my $man_converter = $do_man ? " | nroff -man | $pager" : "";
 open(MANPIPE, $do_cat ? "| pod2text '$file' | $pager" :
 	"| pod2man --section 3 --release 'fvwm $version$version_info'" .
-		" --center 'Fvwm Perl library' '$file'" .
+		" --center 'Fvwm Perl library' --name '$topic' '$file'" .
 		" | @SED@ 's//perllib/ig'$man_converter")
 	or die "Can't open pipe to pod/man viewer\n";
 print MANPIPE $text

Re: FVWM: The Future of fvwm Development

[Jaimos Skriletz]

On Wed, Nov 16, 2016 at 4:43 PM, David Niklas  wrote:
> On Fri, 11 Nov 2016 23:13:49 +
>
> Not so much a question as a comment.
> Many window managers and desktop environments have tried in vain to create
> an automatic menu generator without success, I recommend that fvwm does
> not attempt to do this, they break very easily over time.
>

Fvwm already provides such ability. The core of fvwm provides users with a
configuration syntax to build menus and fvwm also provides a way for things
to be scripted. So really an automatic menu generator is just a script that
outputs the configuration syntax of fvwm.

Within the core of fvwm is the method to build menus using the configuration
syntax (which is one of the things that is planed to change in the future of
fvwm) and create some sort of menu object that fvwm displays to the user.

Independent of that is the ability to write scripts to generate menus. These
can be from simple shell scripts, for i in wallpappers/*.jpg; do ... to build a
wallpaper menu as mentioned in the manpage, to more complicated perl
and now python scripts: fvwm-menu-desktop, fvwm-menu-directory,
fvwm-menu-headlines and fvwm-menu-xlock are all scripts provided by fvwm.
On top of that you can write you own scripts to automatically generate menus
on your system.

So this ability is already there and I think done in a nice way. In the core it
is just the ability to configure menus (including dynamic ones that are
generated when they are opened) and via fvwms ability to work with scripts,
you can additionally use a script to generate menus.

Yes the scripts sometimes break and need updated, but they are not internal
to fvwm and are only optional for those who want to use them (and maybe fix them
when standards evolve).

> Also, please retain the win95 configuration script, in fact, they ability
> to run a simple script to generate a few different common configurations
> is a strong point of many WMs.
>

This is already gone. Fvwm now provides a default config as a starting point
for users who don't want to write one from scratch. But Fvwm is more a wm
that provides a user with the ability to configure their own setup. Examples
are probably better given through some other means, such as the wiki.

jaimos

FVWM: FvwmWiki

[Jaimos Skriletz]

Hello,

I have put together the various howtos, configuration examples, and so
forht I have compiled over the years and updated how the wiki is built
and lots of its content. You can find the wiki at

http://fvwmforums.org/wiki/

Hope it finds some use.

jaimos

Re: Changes in which regards dependency tree

[Jaimos Skriletz]

On Mon, Nov 7, 2016 at 3:33 PM, Jesús J. Guerrero Botella <
jesus.guerrero.bote...@gmail.com> wrote:

> I see, thanks for the pointers, they'll help.
>
>
​Please CC fvwm-workers@fvwm.org on replys. Glad I could help.
​


> On a related note, when I click the option to configure the xdg menu
> in the menu, fvwm says:
>
> Can't locate FVWM/Module.pm in @INC (you may need to install the
> FVWM::Module module) (@INC contains: /usr/share/fvwm/perllib /etc/perl
> /usr/local/lib64/perl5/5.22.2/x86_64-linux
> /usr/local/lib64/perl5/5.22.2
> /usr/lib64/perl5/vendor_perl/5.22.2/x86_64-linux
> /usr/lib64/perl5/vendor_perl/5.22.2 /usr/local/lib64/perl5
> /usr/lib64/perl5/vendor_perl /usr/lib64/perl5/5.22.2/x86_64-linux
> /usr/lib64/perl5/5.22.2 .) at /usr/lib/fvwm/2.6.7/FvwmPerl line 33.
> BEGIN failed--compilation aborted at /usr/lib/fvwm/2.6.7/FvwmPerl line 33.
>

​# ls /usr/share/fvwm/perllib/FVWM/Module.pm -- that is the file it is
looking for.

Do your build options not build with libperl (not sure on this) depends? I
don't know enough to think what option this can be. Check what build
options were detected.

The configure option uses FvwmPerl and FvwmForm to open a gui a user can
select options for building the menu. Including what .menu(s) to use,
include icons, menu titles, and some other options.

jaimos

​

Re: Changes in which regards dependency tree

[Jaimos Skriletz]

On Mon, Nov 7, 2016 at 2:57 PM, Jesús J. Guerrero Botella <
jesus.guerrero.bote...@gmail.com> wrote:

> Hi everyone!
>
> Regarding the dependency tree, I guess the latest changes added a
> dependency on pyxdg and stalonetray for the new configuration that
> fvwm ships by default.
>
> Is there something else that has been added or removed at lib level?
>
>
Those are the only ones that I can think of that have changed. In this case
I would considered them optional dependencies. The default-config will work
if stalonetray is not installed (in this case there is just no systemtray
in the panel). The python dependency is only for the fvwm-menu-desktop
script and xdg menus. Since this seems to be the standard menu system it
should be added if you want users to have menus work without having to
install extra packages. So without the python dependency and a .menu file,
system menus cannot be generated via the script.

Note that fvwm-menu-desktop also requires a .menu file, as fvwm does not
provide one. You may want to add a dependency to some gentoo package that
provides a .menu for the user to use as well. In the Debian package I have
put these as recommended packages (both python-xdg, stalonetray and a menu
(lxde menu is the one I like the best in Debian)), but not required depends.



jaimos

FVWM: Fvwm Default Configuration

[Jaimos Skriletz]

Hello,

I have put together a default configuration to go with Fvwm. The configuration 
could use some testing. To test this config, use the default-config branch on 
github.

The default config will load if fvwm doesn't find any config file when 
starting. There is a script in the built in menu to copy the config into 
$FVWM_USERDIR or copy the default config from $PREFIX/share/fvwm/default-config.

A screenshot of the config can be found here 
http://fvwmforums.org/scrot-fvwm-default.png

xterm is the default terminal. Edit the infostore variable at the top to change 
this.

If you have python-xdg and a .menu on your system, it should load a menu at 
start. The menu is not dynamic at this time.

If you have stalonetray installed the RightPanel will include a systemtray.

please share any comments you may have.

jaimos

Re: Default Configuration File

[Jaimos Skriletz]

On Sun, Oct 23, 2016 at 6:22 PM, Dan Espen  wrote:
>
>
> I have a few comments,
>
> 1) Wall paper changing isn't working.
>
> 2) The right panel goes all the way to the bottom of the screen
> but it's empty.  I don't like it wasting space.
>

​There was some issues modifying the config files to work from a system
location. This is hopefully fixed and you should be able to use the
wallpaper menu and that blank spot at the bottom is a clock.
​


> 3) "refresh" is in the menus.  Is that something users will use


​I have needed this through out the years and even on running inside a vnc
vm I found it was useful due to the low quality graphics. It doesn't need
to be in the menus, it is just something I find useful.
​


>
>
4) Olive Drab?
>
>
​I couldn't really figure out a good color and just went with the green. My
plan was to change it, never did. I am open for suggestions on replacing
the green. I thought about going with the blue from the website as a base
color.
​


> 5) I have windows without mini-icons and they are difficult
> to see in the pager


I'll modify the colorsets to make the windows stand out better. Also adding
a default mini icon for apps without them is a possibility.
​


>
>
6) There should be a menu to invoke the modules.
> Especially FvwmAnimate.
>
>
​I will look into adding such a menu and FvwmAnimate (I'm not that familiar
 with it)
​.

jaimos​

Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory

[Jaimos Skriletz]

On Sun, Oct 16, 2016 at 5:01 PM, Dominik Vogt  wrote:

> On Sun, Oct 16, 2016 at 05:09:57PM +0100, Thomas Adam wrote:
> > On Sun, Oct 16, 2016 at 04:48:34PM +0100, Dominik Vogt wrote:
> > > Maybe it's a silly question, but *why* does fvwm need mandatory
> > > image support at all?  Arent's images in a window manager just
> > > gimmicks?
> >
> > It's not a silly question, but I'd hoped the commit message said enough.
> > Gimmick is a matter of perspective.  I'm trying to stike a balance
> through
> > useability.  I don't think it's unreasonable to assume one image library
> as
> > the de facto; others are still available.  I'm trying to frame this in
> terms
> > of:
> >
> > * Making the default config useable and useful (which from what I'm
> seeing,
> >   does entail some form of image loading (for icons im menus and
> elsewhere)
> >
> > * Integrating with other third-party applications which generate menus
> (which
> >   use PNG).
>
> I completely understand that, and PNG seems to be a sensible
> choice.  The thing I'm unsure about is whether it should be
> possible to build fvwm without any libraries and expendable
> features to have a lean, minimalistic WM.  But I've honestly no
> idea whether anybody did that in the recent past or not.
> Perosnally, if I weren't too lazy to change the config, I could
> perfectly do without image support:  The menu logo is just
> decoration, icons work as well when done as text, and the
> FvwmButtons images could be replaced by thext or just menu
> entries.
>
>
What about having libpng be default but having a --disable-libpng
./configure option to disable? Have it set up to error out if libpng and
that option are not present with an error that says building without libpng
may affect the default config and other applications. If you want to build
without libpng use --disable-libpng.

This way if someone really wants to build without image support they can
without having to edit the configure script. Though the answer to having
such an option may be on what happens when fvwm hits the .png images in the
default config without support. I'm hoping it just throws a warning and
leaves a blank place where the image should be.

jaimos​

Re: FVWM: Website

[Jaimos Skriletz]

On Sat, Jul 9, 2016 at 6:15 PM, Dan Espen  wrote:

> Thomas Adam  writes:
>
> > On Sat, Jul 09, 2016 at 10:39:02PM +0100, Ethan Grammatikidis wrote:
> >> Just a quick note regarding the current website: The basic design is
> nice,
> >> but the white border gives me a headache when trying to read any of the
> >> actual text. Some desktop image (scaled or tiled) would likely be a big
> >> improvement, but so would a darker solid color.
> >
> > That's rather too vague; can you be a little more specific about your
> issue,
> > please?
>
> he's complaining that the web site looks like the user
> has set the root window to white.
>
> I didn't notice before, but I agree, it's not pleasant
> to look at.  I wonder what would make a better background,
> a gradient or an image.
>
>
​Easy enough to change,

you can also hit the maximize button and get rid of the border all together.

jaimos​

Re: FVWM: Fixing and Docking

[Jaimos Skriletz]

On Tue, Jun 28, 2016 at 4:29 PM, Tim Johnson  wrote:

> I would like to do the two following things with taskbar (as invoked
> by FvwmTaskbar) :
>
>
​FvwmTaskBar has been removed, use FvwmButtons + FvwmIconMan instead. This
gives you more flexibility to swallow different launchers, buttons, apps,
etc.
​


> 1)Render taskbar as fixed (no autohide) so that when windows are
> maximized, they do not overlap taskbar (or vice versa).
> Currently, there is overlapping and the windows have to be resized
> manually so that they "fit".
>
>
​You can use ​EwmhBaseStruts to reserve area of the screen that is used
when maximizing windows and placing windows. This can be used to keep
windows from covering the panel when maximizing.


> 2)"Dock" apps in the taskbar as per gnome or my fluxbox config.
>
>
​I'm unsure what you mean by Dock apps. If you want to make a launcher use
FvwmButtons and you can make your own custom launchers. If you mean
something like a system tray you'll have to use a third party app, such as
stalonetray (which I swallow inside of FvwmButtons).
​
jaimos

Re: Deprecation: Let's talk once more about removing $STUFF...Setup Form

[Jaimos Skriletz]

On Thu, Jun 9, 2016 at 4:45 AM, Thomas Adam  wrote:

> On Fri, Jun 03, 2016 at 02:21:51AM +0100, Thomas Adam wrote:
> Any lasting objections before this is merged and we can move onto the next
> phase with is introducing a default configuration?
>
>
​I have some ideas on a default configuration I was working on, but then
got side tracked with work.

I may have time in 2-3 weeks I could put into cleaning my configuration I
was working on, if some help is needed with creating a default
configuration.

​There will of course be some questions/discussion on what should be in the
default, but I'll save this for when I have time and another thread.

I was also curious if the document that was created many years ago (by
members of #fvwm) about what should be in the default config is still
around as that would be useful to look at.

jaimos



​

​

Re: Deprecation: Let's talk once more about removing $STUFF...

[Jaimos Skriletz]

On Tue, May 31, 2016 at 2:30 PM, Thomas Funk  wrote:

> On 05/31/2016 09:30 PM, Thomas Adam wrote:
>
>>
>> On 19 May 2016 4:18 p.m., "Thomas Adam"  tho...@fvwm.org>> wrote:
>>  >
>>  > Hey all,
>>  >
>>  > The last time this came up for conversation [0] things were far from
>> ideal.  I
>>  > want to have another conversation about this to see whether it's
>> possible to
>>  > state the case why some modules in FVWM should be removed.
>>
>> Anyone?
>>
>> Thomas Adam
>>
>> Perhaps you shouldn't remove FvwmTaskBar for the moment until someone
> creates a replacement
> with FvwmPager/FvwmIconman.
>
>
​Just remove FvwmTaskBar, there has been ample warning that this was going
to happen. There will be some fall back and it is my guess this is the one
that will get missed the most, but no need to keep it around and it isn't
like waiting is going to make it any less of an issue, I just expect to
hear various issues with it once fvwm 2.6.7 starts to get pushed into repos
of downstream oses.

jaimos​

Re: Deprecation: Let's talk once more about removing $STUFF...

[Jaimos Skriletz]

On Tue, May 31, 2016 at 2:46 PM, Jason Weber  wrote:

>
> I still have FvwmWinList on a button in case I get some rogue window
> that FvwmProxy doesn't represent, but, honestly, it isn't a big deal.
>
>
​You can also use WindowList and get a list of all the windows (under
certain conditions) in a menu which will serve as a replacement for
FvwmWinList if needed.​


​jaimos​

Re: Deprecation: Let's talk once more about removing $STUFF...

[Jaimos Skriletz]

On Thu, May 19, 2016 at 11:07 AM, Dan Espen  wrote:

> Just had an opportunity to look at Fvwm.Org, it looks pretty nice.
> I thought we were going to retain the themeing, but I don't see it.
> Not a real problem.
> ​
>

​Being a static site and only using html and javascript it makes being able
to switch themes not as practical as it was when the site was php (also
makes the site way easier to maintain and update).​ So the initial build of
the new site was just to remove the php and use a static site builder
(jekyll) to build the site with a single theme.

I still had in my mind that themes would be nice to change. I built the
site using mostly css, so a simple change to the theme is to just change
the css file, but this requires three things.

​1) Someone to build a new theme .css file.
2) Figuring out how to use javascript to load the correct .css file.
3) Deal with any issues that arise. Even though I tried to do everything
with .css, more than just the .css files
may need to be modified when trying to write a new theme to get it to work
correctly.

So as of now (and mostly likely for a while) there won't be themes. But
they could be added if someone wanted to invest the time.

jaimos​

Re: Deprecation: Let's talk once more about removing $STUFF...

[Jaimos Skriletz]

On Thu, May 19, 2016 at 9:18 AM, Thomas Adam  wrote:

>
> * FvwmTaskBar -- Use FvwmIconMan.
>
>
​I do agree that FvwmTaskBar should be deprecated and FvwmIconMan should be
used instead, but my experience is FvwmIconMan was not easy to create a
config that behaved like the simple FvwmTaskBar, and I still think many are
using this because it is so much easier to configure than FvwmIconMan for a
TaskBar (despite it is also buggy, I still see it used a lot).

I think removing this will cause some (or maybe more than some) discussion
on the main fvwm mailing list once people notice it is gone who have been
using it, including some not so happy fvwm users.

My suggestion is in order to remove FvwmTaskBar we should provide a config
that will provide something similar FvwmTaskBar using FvwmIconMan that
people can just take and slightly modify. This way when someone comes to
the list (or irc) and starts saying where did my FvwmTaskBar go, we can
just point them to a config and they can be on their way.


> I've also gone and removed these two directories:
>
> debian/
> rpm/
>
> AFAIAC, these shouldn't be part of a window manager, and it is
> unreasonable to
> expect maintainers of a window manager to understand package management to
> any
> degree.  All downstream do when they package FVWM is remove these
> directories
> and replace them with their own (newer) versions, since ours are just left
> to
> bitrot.  If you want to build packages of your own, do so.  But it's
> peripheral to FVWM.
>

​I can't speak for the rpm/ directory, but I know that in debian the
directory is removed by the debian maintainer and replaced by his own that
fits the modern debian standards, passes all the package auditing tools,
etc.​

​I also think that if someone wanted to build their own custom .deb, the
debian/ is outdated enough that it shouldn't be used.

If someone really wanted to build their own .deb over using the one
provided by debian I would suggest pointing them at debian_helper. This can
autogenerate a simple debian/ dir that is probably better than the one
provided by fvwm and is fairly automatic. I could look into writing up a
little doc on how to do this.​ The other option is to just use the debian/
from the debian source package, but then you have to deal with debian
patches.


Those are my two cents,

jaimos

Re: FVWM: REWRITE: Request for help -- parsing of command token

[Jaimos Skriletz]

On Sat, Sep 13, 2014 at 2:14 AM,
​​
Dominik Vogt dominik.v...@gmx.de wrote:

 For testing pusposes I need to get an overwiev of what types of
 commands people use in fvwm.  Could everybody please look through
 their configuration files and post any commands:

 1) That contain whitespace, quoting characters or variables
(e.g. $[foo] or $w) in  the first word of the line.  Expamples:


No occurrences in my config file.
​




 2) Such things in conditional commands or function or menu
definitions in place of the command name, menue name or
function name.  Examples:


I use variables in conditional commands to test for files before accessing
the file such as

​Test (f $[FVWM_USERDIR]/cfg/WallpaperMenu) Read
$[FVWM_USERDIR]/cfg/WallpaperMenu

Test (f $[FVWM_USERDIR]/cfg/DebianMenu) Read $[FVWM_USERDIR]/cfg/DebianMenu


 3) Fvwm allows to start modules without using the Module command,
e.g. with just FvwmButtons instead of Module FvwmButtons.
Do you use this?  Did you know that's possible?


​Nope, I did not know that was possible and have no occurrences of such a
thing.​

jaimos

Re: FVWM: FVWM Wiki

[Jaimos Skriletz]

On Wed, Apr 16, 2014 at 10:23:18PM +0200, Thomas Funk wrote:
 Am 16.04.2014 22:02, schrieb Jaimos F Skriletz:
  On 04/16/2014 01:40 PM, Thomas Funk wrote:
  Hi there!
 
  I am wondering what's happening with the FVWM wiki on 
  http://fvwmwiki.xteddy.org/ ?
 

http://fvwmforums.org/wiki

A copy of the wiki is now at that url, I tracked down most of the issues with 
rendering the html but there is still some clean up to do.

jaimos

Re: FVWM: FvwmScript and environment variables

[Jaimos Skriletz]

On Sat, May 04, 2013 at 03:49:42PM -0400, Dan Espen wrote:
 Dominique Michel dominique.mic...@vtxnet.ch writes:
 
  Hi,
 
  I am writing a font selector for fvwm-crystal with FvwmScript.
  Most of it work, but I didn't succeeded to use environment variables.
 
  Also thing like
  Set $PanelFont = (GetOutput {echo $[panel_font]} 1 -1)
 

I belive you could do something hackish like this if you don't want to patch 
for actual support. But you need to be a little more creative.

First I belive GetOutput is excuting a shell command, so you may just need 
(GetOutput {echo $PANEL_FONT} 1 -1)

this should work for the enviorment variables but not infostore (I'm hoping a 
new shell isn't spawned with a new enviorment). If this doesn't work my next 
thought is

Use FvwmCommand with Echo (from fvwm) which can echo a string to your stderr 
($HOME/.xsession-errors is common for this). Then parse the value from 
$HOME/.xsession-errors with grep/regex tools. This should work with either 
EnvVars or InfoStore since you can echo their values as well. The only issue I 
see with this portability as not everyone may have stderr of their Xserver 
redirected to $HOME/.xsession-errors

jaimos

Re: FVWM: ImageMagick display style option?

[Jaimos Skriletz]

   On Mon, Mar 25, 2013 at 08:45:36PM +0100, michael.gros...@gmx.de wrote:
Hello everybody,

I've noted that when I open with (ImageMagick) display command
an image larger than the screen the window geometry doesn't take
in care borders and title, then right and bottom window borders
are hidden outside the limit of the screen.  Somebody knows a
style option or another workaround for this?



Have you tried the using the -geometry option for display. Make the geometry 
just small enough that by the time fvwm adds the borders and title bar i it 
fits on teh full screen like you want?

When I tested I was able to set the geometry to make it work out correct. This 
isn't perfect but almost fits my screen.

Native geometry is 1920x1080, so to deal with borders/titlebar I ran

display -geometry 1910x1050 IMGP2657.jpg

And it almost worked like you want. The thumbnail image was slightly off, but 
since it is it's own window you can isolate it with a style command and put use 
position position or the likes to put it where you want it.

the nice thing about display is if the image is smaller than the geometry you 
request, it will resize and only make it as big as the image.

jaimos

Re: FVWM: Debian Unstable now has FVWM 2.6.5

[Jaimos Skriletz]

On Sun, Jan 27, 2013 at 08:49:14PM +0100, michael.gros...@gmx.de wrote:
 
  On Sun, Jan 27, 2013 at 10:53:15AM +0100, Michael Großer wrote:
   You will run into the problem that MenuFvwmRoot
   does not contain D. Debian Menu anymore like
   it used to be in Debian Lenny with FVWM 2.5.26.
   
  
  Just read /etc/X11/fvwm/menudefs.hook into your config.
  
  Claude
 
 I tried it. With no luck. It was one of my obvious ideas.
 Maybe, I did something wrong, but in my case, it didn't work.
 Perhaps, I should try to include /etc/X11/fvwm/menudefs.hook
 in FVWM 2.6.5, if it contains such a file. I tested both
 2.5.30 and 2.6.5 yesterday, bulldozing my two Debian
 partitions after each test with a fresh and chaste version
 of Squeeze, but I did different tests with 2.5.30 and
 2.6.5. I made more tests with 2.5.30, because it was
 more Debian affine than fvwm-2.6.5.tar.bz2.
 

the menu is created with a debian menu-methods and the output is the 
/etc/X11/fvwm/menudefs.hook by default on the debian package (I just checked 
this myself).

'Read /etc/X11/fvwm/menudefs.hook' will just read the debian menu but not add 
it to your root menu. So that file only contains the info generated by the 
debian 'menu' package.

you should less that file, but the menu name is /Debian and you can get the 
menu by doing 'popup /Debian' and there is the menu. You can add that to your 
root menu to get access to the menu from there.

Note you will have to 'Read /etc/X11/fvwm/menudefs.hook' each time you 
add/remove packages to change the menu you will need to reread that file to get 
the updated menu. But this method ensures that you only add the menu to your 
current config and not all fo the other stuff from the default debian config 
file.

jaimos

Re: FVWM: Debian Unstable now has FVWM 2.6.5

[Jaimos Skriletz]

  
  the menu is created with a debian menu-methods and the output is the 
  /etc/X11/fvwm/menudefs.hook by default on the debian package (I just 
  checked this myself).
  
  'Read /etc/X11/fvwm/menudefs.hook' will just read the debian menu but not 
  add it to your root menu. So that file only contains the info generated by 
  the debian 'menu' package.
  
  you should less that file, but the menu name is /Debian and you can get the 
  menu by doing 'popup /Debian' and there is the menu. You can add that to 
  your root menu to get access to the menu from there.
  
  Note you will have to 'Read /etc/X11/fvwm/menudefs.hook' each time you 
  add/remove packages to change the menu you will need to reread that file to 
  get the updated menu. But this method ensures that you only add the menu to 
  your current config and not all fo the other stuff from the default debian 
  config file.
  
 
 I can give it a try during the next 6 months. 'popup /Debian' could be
 an approach that I should indeed pursue. As usual, I will report
 about my progress when it is time. What do you mean with
 you should less that file? Using the less command to do
 something with that file? And if so, what?
 

I mean take a look at what is inside the file. You will see it is nothing more 
than Menu Definitions for fvwm and the main thing is it tells you the Menu 
Names so you can refence them in your own config.

As I said all you need to do to get the debian menu is

1) Read /etc/X11/fvwm/menudefs.hook

That will pull in all the menu defintions, then you need to configure your 
config to put the menu where you want it

once you decide where you want it (submenu, key binding, etc) you can then open 
the menu with 

2) 'Popup /Debian' or 'Menu /Debian'

That is all you need to do to get access to the debian menu. You can use 
FvwmConsole to play with things, but just add it as a submenu to your root menu 
in your config file and you have the menu.

jaimos

Re: FVWM: how to? FakeClick for Middle button

[Jaimos Skriletz]

On Fri, Jan 25, 2013 at 01:09:16PM -0500, Chris Siebenmann wrote:
 | Second it is not firefox that 'pastes' when you click the middle mouse
 | button. It is xorg that intercepts the middle mouse click and then
 | sends the resulting paste to the window. So sending the middle mouse
 | button click to the root window or the firefox window (or any other
 | window) will note generate the paste event. Firefox does not know to
 | paste when it receives a middle mouse click.
 
  This portion is not correct. Neither the X server nor the window
 manager intercept middle mouse clicks and turn them into magic paste
 events (or into streams of characters). Pasting is entirely handled
 by the program involved and Firefox really does receive a middle
 mouse button click event[*] and then invoke its own code to paste
 stuff. Programs can and do do entirely different things in response to
 middle mouse buttons (for example, I am writing this email in a program
 that does something different with it).

Thanks for the clarification. My experience was all xprograms accept middle 
click and with using gvim (or vim in a terminal) that it just accepts it as a 
string of data being sent directally to the program, so I thought this was an 
xorg mechnisim as opposed to implemented on a program per program basis. Then 
the issue for me then must be chromium didn't like synthetic mouse events (just 
ignores it) but would work with a FakeKeyPress.

Back to the question of creating a nice paste key binding I have found the 
following. Most likely a clipboard manager will do what you want and you should 
look into that (As I suggested earlier) but if you really want to do this with 
fvwm you could try the following.

First xorg has three buffers, primary, secondary and clipboard. The primary 
gets used in the select/middle mouse paste, while the clipboard gets used by 
some programs with ctrl-c/ctrl-v is the standard. So depending on which buffer 
you want to paste from adjust the following.

Second, there is a tool called xsel which will give you the output of any of 
the three buffers (with primary being the default). You can use this program in 
conjecution with xdotool or xvkdb (send typing events to a window) and could 
paste the output of say the primary buffer to a paticular window with the 
command

xdotool type $(xsel)

So set that up as your key binding and it will send the output the the 
currently focused program. I would add some logic (or do selective key 
bindings) so you don't send the output to a program that wouldn't know what to 
do with the stream of keypresses. This doesn't seem as nice as telling the 
program itself to get the data from the correct buffer, but is a hack if you 
just want to send the buffer to the program and hope for the best.


jaimos

Re: FVWM: Smart maximize

[Jaimos Skriletz]

On Sat, Nov 24, 2012 at 02:55:47PM +0100, Piotr Isajew wrote:
 On Sat, Nov 24, 2012 at 08:37:03AM -0500, Dan Espen wrote:
 
  I guess you are thinking of the largest free rectangular area.
 
 yes, that's right
 
  I'm not aware of any such feature.
 
 I'll try to look for a solution myself. If I find something I'll
 post it to the list.

The only thing similar I can think of is MinOverlapPlacement policy as it does 
what you want (sort of). I cannot think of a simple way to mix that placement 
policy (and replace your window) with trying to do this smart maximization. But 
if you know a bit of C that is something you can look up to see how it is done 
in terms of logic in determining the bigest open rectangle.

Just mentioning that placement policy because then you don't have to rebuild 
the logic from nothing and you can use it as a starting place to figuring out 
where the biggest rectangle is.

jaimos

Re: FVWM: A way to dump Fvwm config? Or more strictly mouse and key bindings.

[Jaimos Skriletz]

 which in some way say that it is not possible.
 

Correct it is not possible to dump the whole running config. I would suggest 
you find the config file on the machine if you want the whole config.

 I want to find what action take in effect when double clicking on window
 border. For application, like gmrun (which have no titles) double clicking
 hide that window in background and raise another window to foreground (sorry
 if I describe in non-technical terms).
 

There is a method to get some info about the current running config. Though the 
PrintInfo command (see the man page for more details) you can print all the 
keybindings.

PrintInfo Bindings

Will print all of the keybindings to stderr (this is $HOME/.xsession-errors in 
many cases).

jaimos

Re: FVWM: Book on fvwm...

[Jaimos Skriletz]

On Mon, Jul 09, 2012 at 09:07:17PM +0300, Oleksandr Gavenko wrote:
 On 2012-04-06, Michael Großer wrote:
 
  It seems like nobody is working on a book
  right now.
  [SKIP]
  The best thing you (and every other person who wants
  to learn FVWM) can do is to just read the man page,
  to read the Unofficial Tutorial at
  http://www.zensites.net/fvwm/guide/
 
 I just yesterday ask about using FvwmCpp and FvwmM4 modules. Because this
 page:
 
   http://www.zensites.net/fvwm/guide/global.html
 
 around 2008 introduce to me usage of:
 
   SetVar VAR VAL

That is my guide and I would like to update it to and make it more inline of my 
modern approach and good fvwm pratcies. Though if you read though the guide you 
do see I say don't abuse this and in my new version (its imcomplete and I can't 
seem to get the motivation to fine tune it) I removed the SetEnv completely and 
want to replace it with InfoStore. But from the guide

Note though that over-using environment variables leads to a lot of 
pollution within FVWM's evironment space, especially if they're only being 
used to hold settings which might only ever change once a year. You can see 
this thread on the fvwm forums for more detailed information.

though I guess I need to update the link there

If you want I don't mind sending a copy of the new version in its very raw 
incomplete form if you want to add to it. I am not really seeking help for it, 
but I don't mind accepting some if it follows the same format (I don't want it 
to be documentation but mearly a way to get people into the frameset of an fvwm 
config file so they can then start to read the fvwm man page to extract the 
info they need to do what they want)

jaimos

Re: FVWM: GSoC 2012: Project ideas

[Jaimos Skriletz]

On Fri, Feb 17, 2012 at 08:06:46PM +, Thomas Adam wrote:
 On Fri, Feb 17, 2012 at 08:38:06PM +0100, Thomas Funk wrote:
  Thomas Adam tho...@fvwm.org wrote:
   Comments welcome, or even ideas.

Another suggestion for possible projects (seems this list is getting big so any 
presepctive programer will have plenty to choose from) is a better Menu system. 
The main thing I am intersted in seeing is more control over what a single menu 
entry can do.

There are basically two basic ways to go about this, and I think the first is 
probabaly the better fit but the second could be nice if someone has the time 
desire.

1) Modify/extend the current menu system to offer more configurability, the 
main thing I am looking for here is say allow for multiple mouse bindings per 
menu entry (a right click and left click could do different things). I think 
FvwmButtons as an example is good for this, each menu item is given a list of 
options/commands. This would allow people to design menus to have say submenus 
on a right click while a default action on a left click which is a common 
feature in lots of wm/de.

2) Rewrite the menu syntax and redsign the object, there was some talk about 
this on the mailing list years ago now and some good ideas for improving menus. 
I don't think this is needed for adding just a few features to the current menu 
and it would break a lot of scripts (fvwm-menu-desktop, fvwm-menu-directory, 
and even distro specific menu generation scripts).

jaimos

Re: FVWM: Why is Debian behind schedule regarding recent FVWM versions so much?

[Jaimos Skriletz]

 
 Hm.
 I remember when I did it last time that it was a lg
 odyssey finding out which libraries were needed, finding
 the libraries, finding other libraries from which the libraries
 depend and so on. For newbies, this was definitely not an
 acceptable way. The reason why I write and publish my own howtos
 is exactly this: The experts throw one-liners like
 ./configure --prefix=/usr  make deb-inplace around and say
 how easy all is, and then you sit there and nothing works,
 because the experts forgot to say that there are concepts
 like dependencies.
 
 Thank you for your hint. I will test this line next time:
 ./configure --prefix=/usr  make deb-inplace
 
 But even if this one line will work, I will have to document
 it, because some kind of knowledge is not easy to find
 in the Internet.

I've been compiling my own fvwm debian packages for some time and here are some 
additional hints.

For dependencies the ones in Manjo's package are somewhat sane (as in they will 
work unless you care enough to limit some of them, you can install them all wth 
a single apt-get command) you can just type

apt-get build-dep fvwm

You may need/want to install build-essential as well.

as for using 'make deb-inplace', it makes a .deb file just fine and it should 
install on your system (Works here for me on debian sid). This is old and 
outdated and a newer debian/ dir should be used to be more in line with the 
newer debian specification and I belive thomas did some work on this and has a 
newer debian/ on his git server, though I never have gotten around to trying it 
to compile a debian package.

The last note is the debian package for some reason (I am still unsure why 
Manjo did this) has an epoch version and the package you made will not. Because 
of this epoch version the version in the debian repos 1:2.5.30 is considered 
greater than the version you compiled 2.6.3 for instance, and if you 
upgrade/dist-upgrade you system it will install the version from the debian 
repo effectivally downgrading your fvwm package. To prevent this you need to 
put the fvwm package on hold

echo fvwm hold | dpkg --set-selections

For those other fvwm debain users out there I hope this is of some help

jaimos

Re: FVWM: get dropbox status

[Jaimos Skriletz]

On Tue, Nov 29, 2011 at 10:25:05PM -0500, Vince Forgetta wrote:
 Hi,
 
 After a few years away from fvwm I am glad to say I am back. I forgot
 how wonderful this window manager is! Nice and quick, and easy to
 customize (at least to me).
 
 I am using dropbox and would like to know how to check the status of
 the synchronization (downloading, uploading, idle). Usually there is
 an icon in the taskbar of other WM/DE. Is there a command I can run or
 a way to get the icon in the button bar?

I'm assuming the other WM/DE display this in a system tray.

Stalonetray is a stand alone system tray which should work for you. You can 
either place it in its own window or swallow it into FvwmButtons. A quick 
search should find the info you need to swallow this. There are a few issues 
with swallowing the tray you'll have to look into if you go this route.

jaimos

Re: FVWM: a problem in windows focus

[Jaimos Skriletz]

On Thu, Nov 03, 2011 at 11:00:24AM +0800, source liu wrote:
 
 Hey, i cant tell exactly policies i'm using,  i configured my fvwm up
 following Knuth's way
 (http://www-cs-faculty.stanford.edu/~uno/programs.html ),  i though it
 might be Sloppy.


Searching through Knuth's fvwm2rc for the word 'Focus' I see the following.

He uses FocusFollowsMouse as his default focus policy.

For XTerm and Emacs he uses SloppyFocus and for XOsview he uses ClickToFocus.

So from his config the focus policy is dependent on the actual window (which 
can be useful in certain circumstances).

jaimos 

Re: FVWM: Deprecating certain Fvwm* modules

[Jaimos Skriletz]

On Mon, Oct 24, 2011 at 07:18:20PM +0200, Bert Geens wrote:
 On Sat, Oct 22, 2011 at 12:23 PM, Thomas Adam tho...@fvwm.org wrote:
  Hello all,
 
  This has been a while coming since 2.6.0 was released.  But I said at the
  time that since there was no longer ever going to be a split between
  stable/unstable, and that there was only ever rolling-stable releases, that
  there was now never any right time to make changes which have an impact.
 
  This is one of them.
 
  Currently, FVWM ships with a number of modules.  Some of them are used a lot
  in peoples' configs (such as FvwmButtons, FvwmEvent, etc.) and others are
  not so much used -- and indeed some of them have just bitrot.
  Unsurprisingly, that's due to confusion as to the need of the module, and in
  some cases the language the module is supporting, because it's no longer the
  coolest language to use, or has been pushed back because of another module
  giving functionality.
 
  So, here's a list of modules I wish to see deprecated, with reasons why:
 
  * FvwmCommand
  * FvwmConsole
 
  These three are on a list to be removed, but the functionality to replace
  them (notably getting FVWM to listen on a $DISPLAY socket, for instance)
  just isn't there yet.  So whilst I don't plan on deprecating them just yet,
  I'm aware I'll need to at some point.
 
 
 These two are the only ones on the list I really care about, I use
 FvwmCommand in my Emacs mode to just execute parts of my config
 without having to copy/paste to FvwmConsole. But a more direct means
 to access Fvwm without having to keep the terminal's shortcomings
 (thinking mainly about maximum command length here) in mind would be
 even more welcome.
 
 Either way, just a heads up to make sure FvwmCommand isn't brushed
 aside as being unused :)


They are just being flagged as future depricated. The goal is to allow FVWM to 
listen on a socket for commands in which can be sent from consoles, scripts, 
etc. Once this new behavior is added to FVWM, they will be depericated as their 
functionality will be done though the socket.

Both FvwmComand and FvwmConsole are used a lot, so the goal is to replace them 
with a more verstile tool. They won't be removed until this tool is functional, 
been tested in many situations and people have had plenty of time to change 
their configs.

jaimos

Re: FVWM: Deprecating certain Fvwm* modules

[Jaimos Skriletz]

On Mon, Oct 24, 2011 at 09:18:34PM +0100, John Latham wrote:
  Both FvwmComand and FvwmConsole are used a lot, so the goal is to replace=
   them with a more verstile tool. They won't be removed until this tool is=
   functional, been tested in many situations and people have had plenty of=
   time to change their configs.
 
 As I thought, thanks.
 
 One thing to point out though, for FvwmCommand it's not just configs that
 would be affected, but *software* built to run on fvwm. There may be an
 argument for providing a compat script, called FvwmCommand, to use the new
 module, when the old one is deleted. But I expect you would in any case have
 thought of that when the time comes! ;-)


Yes, ensuring FVWM doesn't break other software should be a consideration. But 
in this case it may only need to have FvwmCommand as a wrapper so it can be 
used in shellscipts (etc) in the same way. The difference is it won't be a 
Module running ontop of FVWM, it will just be a wrapper that sends the command 
to the socket.

jaimos 

Re: FVWM: Task Bar Disappearing

[Jaimos Skriletz]

On Fri, May 13, 2011 at 05:44:49PM +0100, Jamie Paul Griffin wrote:
 Hello
 
 I use the Task Bar and I have set it to check Maildirs in my home directory 
 for new mail. When the window manager starts the Task Bar disappears after a 
 few minutes, i'm assuming this is when the Maildir is first checked. 
 
 I wondered if anyone else has experienced this problem and if so, do you know 
 how I can fix it. I'm sorry but I do not know of any debugging technique to 
 provide more information.

You can check your $HOME/.xsession-errors (or stdout of your xserver) to see if 
any errors are spit out. Also if the process FvwmTaskBar isn't running when it 
disapeared its crashing. You are probabaly right about why its crashing, but 
will have to debug the paticulars.

For the most part FvwmTaskBar is no longer supported. If you want a task bar I 
would suggest mixing FvwmIconMan (for the task bar) + FvwmButtons as a 
container/pannel you can use to contain the start menu/clock/mail 
notification/system tray etc -- there are many examples of these floating 
around. Check the forums.

 
 The version of fvwm I am using is 2.7.0 built using the FreeBSD port process.
 

afiak fvwm is not going to continue using the stable/unstable branch split. 
Thus don't use 2.7.0 but use 2.6.1 instead (the offical branch is 2.6). Not 
sure about any paticulars on the FreeBSD port process but 2.7.0 is the same as 
the 2.6.0 release.

jaimos

Re: FVWM: Task Bar Disappearing

[Jaimos Skriletz]

On Fri, May 13, 2011 at 05:44:07PM -0700, elliot s wrote:
 
 Use FvwmIconMan and FvwmButtons.  I'll be deprecating FvwmTaskBar soon
  enough.  It's dead.
 
 
 Is there an example somewhere on converting fvwmtaskbar functionality
 to FvwmIconMan/FvwmButtons?

Have you checked the forums for examples, fvwmforums.org?

I would search there.

Basic idea, FvwmButtons is the container. You can use it to hold the various 
parts of the taskbar you want. FvwmIconMan is the part that keeps track of 
running programs. I would first configure that, to act like the major part of 
the taskbar. After that you can add the start button and other things like 
clock/notifications by swalowing it into FvwmButtons.

jaimos

Re: FVWM: Setting window title

[Jaimos Skriletz]

On Tue, Dec 14, 2010 at 04:21:32PM -0800, Jason Timrod wrote:
 hi Jaimos,
 
 --- On Wed, 12/15/10, Jaimos Skriletz jai...@diamond.boisestate.edu wrote:
 
  Thomas clearly explains why it won't be applied. FVWM is in
  a feature freeze until 2.6 comes out. This is a new feature
  (not a bug fix). From the link you read:
  
 
 what are the plans for the next release? is it near? i think ive read before 
 about 2.6.0 but that was ages ago - how long must us users wait before a new 
 release?
 
 whats left to be done, and why isnt the cvs version released as 2.6 already? 
 or am i missing something? :) who controls this process, and who can i talk 
 to about helping out?

The answer is as with many opensource software, when its ready. FVWM has very 
slow development (compared to other more main stream projects) but its still 
slowly moving forward.

If you are intersted in what is needed to be done check out the files docs/TODO 
and docs/todo-2.6 in the CVS tree. The second is a summary of the bugs/testing 
that plans to be done before the release of 2.6.

If your wanting 2.6 in the near future don't hold your breath, but it will 
eventally get released.

jaimos

Re: FVWM: Paging behavior changed from fvwm version 2.5.26 to 2.5.28

[Jaimos Skriletz]

On Mon, Jun 21, 2010 at 06:05:37PM +, halfdog wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hello List,
 
 Perhaps someone can give me a hint, how to restore the old (prior 2.5.28) 
 paging
 behavior in fvwm 2.5.28. At the moment, the simple configuration from below
 behaves differently on ubuntu jaunty (2.5.26) and lucid (2.5.28).
 

Just a debugging suggestion, have you tried to use Fvwm 2.5.26 from Jaunty on 
your Lucid install. It could be that the problem is not with fvwm, and if you 
get the same behaviour with 2.5.26 from Jaunty (or even if you download the 
current Fvwm from fvwm.org and make your own custom deb with 'make 
deb-inplace') then you know that there is something else running in Lucid that 
has caused this behavior.

jaimos

Re: FVWM: newbee

[Jaimos Skriletz]

On Tue, Sep 16, 2008 at 09:00:37PM -0400, Tamas Hegedus wrote:
 Hi,
 
 I just started to use fvwm. I like it very much.
 I have some problems/questions that I could not figure out.
 
 I am using fvwm-2.4.20 on Fedora 9.

 
I would strongly suggest using fvwm-2.5.x unless you have a real paticular 
reason to use fvwm-2.4.x. I do know that it is usually best to avoid 'unstable' 
software but in the case of fvwm there has been a lot of improvment and change 
that lots of functionality you may want will not be in fvwm-2.4 and most of the 
help you will find with google will also not apply to fvwm-2.4.


 
 1. Start X11
 
 I setup .xinit and .xsession:
 -rwxrwxr-x 1 hegedus hegedus 63 2008-09-10 10:04 .xinitrc
 lrwxrwxrwx 1 hegedus hegedus  8 2008-09-09 10:03 .xsession - .xinitrc
 
 content:
 #!/bin/sh
 exec /usr/local/bin/fvwm  $HOME/.fvwm/fvwm.log 21
 
 If I use startx, fvwm starts fine. No problem, only
 abs 0.9.0 appVersion=2.0.0.14 mTB3=0 in my log file.
 
 However, if I want to log from the graphical login screen (gdm, I suspect),
 there is a black screen for a few seconds then I get the login screen back.
 If I switch to a console to check out the login files then my characters
 starts to disappear: like a virus under windows.
 
 A few weeks ago I setup fvwm on a RedHat EL4 and I did not have any problem.
 Any idea?

Not really, I know gdm usually requires you to configure each session in its 
own fassion and sometimes has trouble with the .xsession / .xinitrc. I would 
check the gdm documation.

 
 
 2. Iconize Firefox
 I have the following definitions:
 Style Firefox Icon $[fvwm_icons]/mozicon50.xpm, MiniIcon 
 $[fvwm_icons]/mozicon16.xpm
 Style Thunderbird-bin Icon $[fvwm_icons]/thunderbird48.xpm, MiniIcon 
 $[fvwm_icons]/thunderbird16.xpm
 
 No problem with Thunderbird. But If I iconize Firefox to the desktop, 
 most of the time
 I get the 16pixel icon and not the 50pixel one. If I have the 16px icon 
 on the desktop
 and do an Fvwm Restart, most of the time the Firefox icon size changes 
 to the
 expected 50px.


Some notes, first I would suggest away from using $[fvwm_icons] and just use 
the ImagePath so you can just do Icon mozicon50.xpm as in it a waste of the 
envorment space. I do know my guide suggested this before I was explained the 
situation and have since started to avoid over use of env vars.

I cannot really see why it is getting the behivour you try, but I would double 
check with FvwmIdent that your matching the Firefox correctly (for I thought it 
too was now firefox-bin) and also that you do not have any other style 
definitions for firefox after this one that is changing the expected behaviour.

 
 3. Color definitions
 I use the 'simple' window style definition (downloaded from the fvwm 
 website).
 So the colouring seems to work. But if I define a new colorset and want 
 to apply
 it on something, like on the pager, it does not work. I do not get any 
 error
 message in the log file.
 
 # I created this color set to see notice change after FvwmRestart
 Colorset 41 fg blue, hi yellow, sh white, bg red
 
 # FvwmPager
 Style FvwmPager NoTitle, Sticky, WindowListSkip, CirculateSkip, 
 StaysOnTop, \
 FixedPosition
 DestroyModuleConfig FvwmPager: *
 *FvwmPager: Geometry 150x320-0+0
 *FvwmPager: Rows 2
 *FvwmPager: Colorset * 41
 *FvwmPager: HilightColorset * 41
 *FvwmPager: BalloonColorset * 41
 *FvwmPager: WindowColorsets 41 41
 
 
 Small question: I have the default mini-icon on the pager's icon in the 
 pager.
 How to set it 'none'?

Unforntally I am not able to see what is wrong with your config, it could be a 
conflict with things defined before or after this.

in fvwm-2.5 the miniicons are off by default and you have to use a FvwmPager 
option to turn them on. *FvwmPager: MiniIcons. One suggestion could be define 
the MiniIcon to be nothing for all windows using the Style * option, and also 
include the MiniIconOverride for the built in MiniIcons on some apps.

 
 Many thanks for your help and suggestion in advance,
 Tamas
 

I am unforntally not able to be of more help at this time as I'm not able to 
see why you have certain things acting as they do. My suggestion would be to 
first find an fvwm-2.5 package and use that instead of fvwm-2.4, and then visit 
the webpage fvwm.org for a faq and links to useful documation to help you 
figure things out.

Also realize that a lot of the time the part that is causing you trouble may 
not be in the code you are looking at but something else hiding in your config 
file causing a conflict and not the desired effect.

jaimos

Re: FVWM: If I enable Desktop Effects fvwm2 crashes

[Jaimos Skriletz]

 Yes, sorry, I should have said, the 'Desktop Effects' is accessed
 from gnome-panel.  However I don't really see why fvwm should stop
 it working.  Just about every other thing that I can access from
 gnome-panel works perfectly.  fvwm2 is supposed to be gnome friendly.
 


From your logs it apears that the conflict is with FvwmPager.

You could try to disable FvwmPager for the time you need to turn on the desktop 
effects.

jaimos

Re: FVWM: Widget fg color

[Jaimos Skriletz]

On Wed, Feb 27, 2008 at 02:40:44PM +0100, Ingo Wardinski wrote:
 Hi all,
 I try to set a widget foreground color to differ from the default, i.e. 
 
 WindowTitle {Weather_applet}
 WindowSize  210 210
 WindowPosition1038 634
 Colorset12
 Widget  1
 Property
 TypeItemDraw
 Size100 15
 Position71 82
 Fontshadow=0 se:xft:sans:size=7:antialias=True
 Flags   NoFocus NoReliefString Left
 ForeColor   { orange }
 Main
 Case message of
   SingleClic:
   Begin
   Quit
   End
 End
 where the default is defined by coloset 9 
 Colorset 9 fg #ff, bg #f1eee0, hi #f1eee0, sh #f1eee0, fgsh #f1eee0, Tint 
 black 35, RootTransparent
 
 However, fvwm(-2.5.23) is complaining: Cannot parse color  orange 
 What does that mean, and more generally, how can I set up a widget fg
 color differently from the default? 

notice that the script isn't striping out any spaces, the reason it can't find 
that color is because you have additional spaces. when it tries to find the 
color  orange  in the list it can't match it to anything.

What you want is ForeColor {orange}

jaimos