Re: FVWM: WindowList issue
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?
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?
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?
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()
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?
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.
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
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 ?
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
On Sun, Jun 19, 2022 at 11:35 PM Dov Grobgeld wrote: > > AddToFunc "Raise/Move/Shade" > + "M" Raise > + "M" Move > + "C" Raise > + "D" WindowShade > > > Apparently the "double" execution caused the behavior that I was seeing. > This is why it is common to DestroyFunc "Raise/Move/Shade" first. This way you start with a new function as opposed to adding to a previously defined one.
Re: FVWM: Button release does not stop window dragging
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
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
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
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
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?
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?
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
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
(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 icons
Re: FVWM: two questions about icons
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
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: Problems with special application mapppings
On Thu, Mar 21, 2019 at 2:40 PM Klaus Ethgen wrote: > - From the documentation, the following mapping: >Key Up A M Scroll +0 -10 >Key (mpv) Up A M - > > Should bind alt-Up to the Scroll except in mpv window. But it also > scrolls in mpv windown. > In the second command 'Key (mpv) Up A M -', the - removes the keybinding. Since there is no specific key binding for mpv it uses your global keybinding. From the documentation: Key [(window)] Keyname Context Modifiers Function Binds a keyboard key to a specified fvwm command, or removes the binding if Function is '-'. > When I do the scroll mapping as above but from command line I do > `FvwmCommand 'Key (mpv) Up A M -'`, it does not work. > It does work, just not as you expected. > So I tried `Key (mpv) Up A M Echo Up` which worked and echos the Up. Yes this will work, because now you have a window specific binding that fvwm uses. > - - Is that a known bug? No. > - - How to do a mapping for everything except in mpv window? > - - What is the difference between `-` and `--` in this context? >From the man page: A '--' action indicates that the event should be propagated to the specified window to handle. This is only a valid action for window-specific bindings. So in conclusion, when using window specific bindings and you want to propagate the press to the window you want to use '--', not '-' (which tells fvwm to remove the binding). Thus I think you should be able to get this to work if you change your bindings to Key Up A M Scroll +0 -10 Key (mpv) Up A M-- jaimos
Re: FVWM: how to escape F1?
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?
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
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
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
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
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
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
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?
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
Re: FVWM: Code Licence
On Sat, Feb 10, 2018 at 12:05 PM, Thomas Adam wrote: > On Sat, Feb 10, 2018 at 12:02:04PM -0500, Dan Espen wrote: >> Seems like a reasonable approach to me. > > I have collated a list of known authors of fvwm to date, and put it here: > > https://github.com/fvwmorg/fvwm/wiki/List-of-all-FVWM-Authors > There is also this list http://www.fvwm.org/authors/ jaimos
Re: FVWM: How to set the X & Y position of a newly created window using FvwmCommand in 2.6.5
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.
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?
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: FVWM: FVWM- fvwm-menu-desktop error
On Wed, Apr 12, 2017 at 7:09 PM, Dan Espen wrote: > Brian writes: > >> I'm running slackware 14.2-64bit fvwm-2.6.6 and have found that when I >> try to generate the fvwm-menu-desktop it is throwing an error >> Traceback (most recent call last): >> File "/usr/bin/fvwm-menu-desktop", line 59, in >> import xdg.Menu >> ImportError: No module named xdg.Menu >> >> I thought it was an issue of slackware not having slackware-xdg-menu >> support so added that package which had no effect. Still get the same >> error after installation. >> >> Where is he xdg.Menu module suppose to come from? > > On Fedora: > > /usr/lib/python2.7/site-packages/xdg/Menu.py > > I don't see it in my 3.5 packages. > You might want to make sure python 2 is being used. > The python script fvwm-menu-desktop requires the python-xdg module, seems it is called pyxdg in slackware. Note, this requires python2, the build process in fvwm doesn't always enforce this, you may have to edit the shebang on the top of the script to point at python2 (not python3) and install that module to work. If you don't have python2 installed, you will need to install it and the module for python2. jaimos
Re: FVWM: Telling fvwm to not use the top left 124x1152 even for maximized windows
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
Re: FVWM: The Future of fvwm Development
On Wed, Nov 16, 2016 at 4:43 PM, David Niklas wrote: > On Fri, 11 Nov 2016 23:13:49 + > > Not so much a question as a comment. > Many window managers and desktop environments have tried in vain to create > an automatic menu generator without success, I recommend that fvwm does > not attempt to do this, they break very easily over time. > Fvwm already provides such ability. The core of fvwm provides users with a configuration syntax to build menus and fvwm also provides a way for things to be scripted. So really an automatic menu generator is just a script that outputs the configuration syntax of fvwm. Within the core of fvwm is the method to build menus using the configuration syntax (which is one of the things that is planed to change in the future of fvwm) and create some sort of menu object that fvwm displays to the user. Independent of that is the ability to write scripts to generate menus. These can be from simple shell scripts, for i in wallpappers/*.jpg; do ... to build a wallpaper menu as mentioned in the manpage, to more complicated perl and now python scripts: fvwm-menu-desktop, fvwm-menu-directory, fvwm-menu-headlines and fvwm-menu-xlock are all scripts provided by fvwm. On top of that you can write you own scripts to automatically generate menus on your system. So this ability is already there and I think done in a nice way. In the core it is just the ability to configure menus (including dynamic ones that are generated when they are opened) and via fvwms ability to work with scripts, you can additionally use a script to generate menus. Yes the scripts sometimes break and need updated, but they are not internal to fvwm and are only optional for those who want to use them (and maybe fix them when standards evolve). > Also, please retain the win95 configuration script, in fact, they ability > to run a simple script to generate a few different common configurations > is a strong point of many WMs. > This is already gone. Fvwm now provides a default config as a starting point for users who don't want to write one from scratch. But Fvwm is more a wm that provides a user with the ability to configure their own setup. Examples are probably better given through some other means, such as the wiki. jaimos
FVWM: FvwmWiki
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
FVWM: Fvwm Default Configuration
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: FVWM: Website
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
On Tue, Jun 28, 2016 at 5:23 PM, Tim Johnson wrote: > * Jaimos Skriletz [160628 14:54]: > > On Tue, Jun 28, 2016 at 4:29 PM, Tim Johnson wrote: > Every system has it's own idiomatic syntax. The one I'm just > beginning to grok is 'swallow'. > > Do I understand that 'swallow' means to put one object inside of > another? > Yes, Swallow means to take a window and put it inside of FvwmButtons. For example here is my FvwmButtons (it doesn't contain FvwmIconMan which gives a list of running windows, but I just use WindowList for that). Here is the config I use --- Start Config --- # # SensorDock ### Style "SensorDock" !Title, Sticky, WindowListSkip, CirculateSkip, \ FixedSize, !Handles, BorderWidth 5 DestroyModuleConfig SensorDock: * *SensorDock: Geometry 120x205-5+5 *SensorDock: Colorset 6 *SensorDock: Rows 41 *SensorDock: Columns 24 *SensorDock: Frame 0 *SensorDock: (7x7, Icon "debian.svg:28x28", Frame 0) *SensorDock: (17x7, Swallow DateTime 'Module FvwmScript $[FVWM_USERDIR]/scripts/DateTime', Frame 0) *SensorDock: (2x12, Frame 0) *SensorDock: (20x12, Swallow FvwmPager 'Module FvwmPager', Frame 0) *SensorDock: (2x12, Frame 0) *SensorDock: (12x1, Frame 0) *SensorDock: (12x18, Swallow Sensors 'Module FvwmScript $[FVWM_USERDIR]/scripts/Sensors', Frame 2) *SensorDock: (1x16, Frame 0) *SensorDock: (10x10, Swallow(UseOld) "cpumon" `Exec exec xosview -title cpumon +cpu`, Frame 0) *SensorDock: (1x16, Frame 0) *SensorDock: (10x2, Swallow(UseOld) "memmon" `Exec exec xosview -title memmon +mem`, Frame 0) *SensorDock: (10x2, Swallow(UseOld) "netmon" `Exec exec xosview -title netmon +net`, Frame 0) *SensorDock: (10x2, Swallow(UseOld) "hdmon" `Exec exec xosview -title hdmon +disk`, Frame 0) *SensorDock: (2x4, Frame 0) *SensorDock: (20x4, Swallow(NoClose,UseOld) "stalonetray" 'Exec exec stalonetray', Frame 0) *SensorDock: (2x4, Frame 0) # # FvwmPager ### Style "FvwmPager" !Title, !Handles, Sticky, WindowListSkip, \ CirculateSkip, BorderWidth 5 DestroyModuleConfig FvwmPager: * *FvwmPager: Colorset 0 6 *FvwmPager: HilightColorset 0 7 *FvwmPager: BalloonColorset 0 8 *FvwmPager: WindowColorsets 8 9 *FvwmPager: Font none *FvwmPager: Balloons All *FvwmPager: BalloonFont "xft:Bitstream Vera Sans:Bold:size=8:antialias=True" *FvwmPager: BallonYOffset +2 *FvwmPager: Window3dBorders *FvwmPager: MiniIcons --- End Config --- I swallow FvwmPager inside of FvwmButtons along with many other apps include scripts, xosview (monintors), and the system tray. I launch this with Module FvwmButtons SensorDock I have attached a screenshot. jaimos
Re: FVWM: Fixing and Docking
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: FVWM: FVWM Wiki
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
On Sat, May 04, 2013 at 03:49:42PM -0400, Dan Espen wrote:
> Dominique Michel 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?
> > > 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
> > > > 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: Debian Unstable now has FVWM 2.6.5
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: how to? FakeClick for Middle button
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
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.
> 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...
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
On Thu, Feb 23, 2012 at 01:34:38PM -0700, msib...@crosswire.com wrote: > > Not trying to piss anyone off. IMHO, I'm just stating the obvious. There > is more holding FVWM back than what can be fixed with debugging. > Holding FVWM back from what? FVWM does its function really well. It is a configurable and stable wm that works on most systems. Sure there are a few things here and there that could be added or improved in fvwm and some bigger projects that would be nice, yet over all FVWM preforms its task well. I don't see FVWM being held back from anything. People use it for different reasons. I myself use FVWM because it is fun, light weight, and requires few dependencies. I have the ability to do most of what I want out of a WM (sure some things are lacking but they aren't a game breaker). If I didn't want to use a text based config file, or really wanted a different widget set there are plenty of other choices of WMs or even DEs to choose from. I don't think it was ever in FVWMs goals to be the all-in-one window manager. Over the 20 years of fvwm's existance there have been forks, derivatives, and even complete rewrites of these forks (spawning a new window manager) that take some ideas from FVWM, but these are no longer FVWM. It seems xfce even had its origins from FVWM but after a few complete rewrites is now a full desktop envorment. So this idea is not new, and many people really enjoy some of the rewrites of the derivatives, but FVWM is still around. jaimos
Re: FVWM: GSoC 2012: Project ideas
> > 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 > > And the link to that thread is? > http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg07167.html Seems like the idea was liked at the time, but mostly just died. Though as I said it would be possible to get everything done in the current menu syntax, I do like some of the ideas in the newer menu syntax suggestions in the thread. Also I'm sure we can imporve/change some of the ideas since that post was form 2002. jaimos
Re: FVWM: GSoC 2012: Project ideas
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" 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?
> > 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
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
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
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: Unofficial Tutorial once again
On Mon, Oct 24, 2011 at 06:37:24AM +0200, Michael Großer wrote: > Web page: > http://www.fvwm.org/doc/unstable/index.html > > Old link: > http://www.zensites.net/fvwm/guide/ > > Has to be updated into: > http://zensites.net/fvwm/guide/ > > I had removed the www subdomain along with many others from the domain and didn't realize that removing www would have side effects (I personally don't like the www subdomain). I have fixed this by adding www.zensites.net back to the nameserver and it should resolve just fine now. Though I would prefer any links just point to zensites.net, I will try to not remove the www.zensites.net in the future as to keep old links from breaking. jaimos p.s. this is my second response (Forgot to cc fvwm@fvwm.org)
Re: FVWM: Deprecating certain Fvwm* modules
On Mon, Oct 24, 2011 at 06:54:09PM +0100, Harry portobello wrote: > Hullo, > > On 24 October 2011 17:28, wrote: > > Harry portobello writes: > > > >> Hi, > >> > >> On 22 October 2011 11:23, Thomas Adam 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. > >> > >> Is this really the right thing to do? Really? How did you come up with > >> this list of depreciated modules to start with? What happens if > >> someone with a config theyve had for ages needs to use a module youve > >> depreciated? Will you personally have to provide the functions of that > >> module in some way? > >> > >> Can you not just leave these modules alone? > > > > Deprecating junk is a time honored Fvwm tradition. > > > > Reducing the size of the code base helps developers. > > As it is, Fvwm has grown so large that I can't keep up with > > the complexity. > > > > Anyway, Tom has done the right thing. He made a proposal and > > now he's getting feedback. > > Maybe. But time honored traditions are grating - when functionality > already exists and is removed for no good reason. I like FvwmTaskBar > but won't get to use it again - instead I have to use two modules I > don't know anything about. There's no thought gone in to this and > will force users to learn things they didn't need to before. I am also > amazed that mail checking is now left up to the user when it's built > in to FvwmTaskBar already! > > Can these modules not be archived and marked as unmaintained which > would still allow users to use them if they chose? > > Please! More thought needed =) > Functionality is not being removed. With FvwmButons + FvwmIconMan you have way more functionality than FvwmTaskBar. Since FvwmButtons + FvwmIconMan can do everything and more than FvwmTaskBar, there is no reason to keep and matain FvwmTaskBar. FVWM is a small project and mataining multiple tools that do the same thing just takes up the developers time they could spend adding new functionality. The goal is not to remove any functionality, but provide it though a smaller set of well tested modules. The point of Depericating is to give the users time to change their configs and learn the more accepted tool. Its not like this module is just going to disapear in the next release. Last this is an opensource project, You can grab the source code and matain your own unmatained, unoffical FvwmTaskBar module as you suggested. Though taking the time to learn the other options you may find that not only can you achive your current config, have more flexablity. jaimos
Re: FVWM: Deprecating certain Fvwm* modules
On Mon, Oct 24, 2011 at 07:18:20PM +0200, Bert Geens wrote: > On Sat, Oct 22, 2011 at 12:23 PM, Thomas Adam 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: Task Bar Disappearing
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: Task Bar Disappearing
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: Setting window title
On Tue, Dec 14, 2010 at 04:21:32PM -0800, Jason Timrod wrote: > hi Jaimos, > > --- On Wed, 12/15/10, Jaimos Skriletz 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: Setting window title
On Tue, Dec 14, 2010 at 04:06:01PM -0800, Jason Timrod wrote: > hi, > > --- On Mon, 12/13/10, Thomas Adam wrote: > > Or if you're not tracking that, the email I sent out to the > > mailing list: > > > > http://www.mail-archive.com/fvwm-workers@fvwm.org/msg02316.html > > this works really well! why wont it be applied? it solves my problem and i > know theres other people out there with the same issue! 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: "It's not really a bug fix per-se, hence why I've not committed it to CVS." After 2.6 comes out and new features start being added again this or a modified version of this does sound like a useful new feature add. jaimos
Re: FVWM: Paging behavior changed from fvwm version 2.5.26 to 2.5.28
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: question
On Sat, Jun 19, 2010 at 08:43:18PM +0100, Rui Silva wrote: > Hi! > > I've installed FVWM and FVWM-themes on my Ubuntu 10.04 but I'm > experiencing some difficulties: > > 1. How can I activate FVWM as my default WM? > > 2. How can I use the "cde" as the default theme? > > 3. How can I deactivate GNOME desktop manager and replace by the cde > look and feel? > The answer to these three questions are all related and depending on how you want thigns set up you have one of two basic models you can follow. Of the two I will briefly describe, the first is probabaly the one you don't want I'm just mentioning it incase you do and so you can see the difference in the philosphy of what is going on. The First Method: you will run fvwm/fvwm-themes as a window manager within gnome as your desktop. In this situation you replace just the window manager but the rest of the gnome destkop will still be running. To do this you will have to configure gnome (I haven't used this in a long time so I cannot answer on the paticulars here) to use fvwm/fvwm-themes as your window manager. In the first method your logon and everything will be the same, you will still have the gnome pannels, menus and configuring options, you will then just have fvwm/fvwm-themes to configure on top of it. The Second Method: you will run fvwm/fvwm-themes as your sole desktop window manager and not run it though gnome (i.e. you can scrape gnome completely). To do this you need the details of how you log into X. Most Ubuntu defaults will put you into gdm (gnome display manager) which will launch X and either give you a graphical logon or automatically log onto an account and into X. It is the job of gdm to know what desktop to run when you log into X, by default this will be gnome, but it is possible to configure gdm to run any other wm/desktop. So what you will want to do is configure gdm to launch fvwm-themes instead of gnome when you log on. Once you do that you will log into fvwm-themes. Once you have it setup how you want to use fvwm-themes (as a wm within gnome or as a stand along wm) you will then configure it via its graphical menus. For the most part I belive if you just select the 'cde' theme once it will set it up as the default and load that theam each time you log into fvwm-themes from that point on. Last if you don't like to use gdm as the display manager, xdm and wdm are two alternatives. > 4. How can I import the GNOME menus to my FVWM menu? > I know of no direct way to just import the menus, but you can get the program menu to work in fvwm. Ubuntu (i.e. Debian) has a package called 'menu' which is a script that creates a program menus for all the software you have installed on your Ubuntu machine. You should have by default if you are using the Debian fvwm package, you should have this menu and all you have to do is call it. The menus name is just "/Debian", so if you call Popup "/Debian" you should just get the debain menu that will have all the programs. You will not of course have all the system menus and gdm menus integrated since you won't be running gnome, but the software menu you can get just fine. If Popup "/Debian" doesn't give you a menu, then you may not have a default debian fvwm package and you may have to track down the script to generate the debian menu in fvwm. Hope this is of some help, jaimos
Re: FVWM: newbee
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 2>&1 > > 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
> 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: If I enable "Desktop Effects" fvwm2 crashes
On Thu, May 15, 2008 at 11:43:01PM +0100, Chris G wrote: > I'm running fvwm 2.5.24 on Fedora 8. > > If I go to System - Preferences - Look and Feel - Desktop Effects and > click the "Enable Desktop Effects" butoon it crashes my fvwm2 session. > What menu is this. By default fvwm does not have 'Desktop Effects' so you are using some custom configuration which probabally requires other softwear. Are you using fvwm-crystal? or some other set of fvwm configs? Is this system/preferences menu a part of a gnome/kde pannell you have running and so it is trying to set a preference for a special window manager which you are not running with its default window manager and so the desktop isn't able to set its preferences correctally? In either case this doesn't sound like an fvwm issue yet. To me it sounds like a gnome pannell you have running within fvwm, and in that case the system/preferences menu won't do much to changing fvwm. If it is fvwm-crystal or another set of configs I would ask the question there. If you can be a bit clearer about the above, it will be possible to help or point you in the right direction. jaimos
Re: FVWM: Widget fg color
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
> Font"shadow=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
Re: FVWM: fvwm patches and esperanza
On Mon, Feb 25, 2008 at 11:35:55AM +0100, Ingo Wardinski wrote: > Hi all, > I see some oddities in the behaviour of fvwm after I installed > fvwm-2.5.23 and applied various patches to obtain translucency, > roundcorners, etc. In fact when I start esperanza (xmms2 client) my X > crashes. I checked several logs, but I couldn't find what is causing > the problem. So my primary guess is that it might be related to the > applied patches, because everything was fine before the patches > applied. Does someone else have similar problems? You'll probabaly have to do some debugging to fix your issue. One method might be to use Style statments to ensure esperanza is not using any of the features provided by the patches. If this gives you the stability you can then start applying the styles you want one at a time until you find which one is causing the crash. another option is to figure out what patch(s) are causing the conflict by applying them one at a time and testing the results. Once you figure out what patch(s) are causing the problem then you can direct the bug to the patch matainer and hope he is helpful in solving the issue. these are just suggestions to try to get you up and running. jaimos
Re: FVWM: Swapping 2 window positions
On Sun, Feb 24, 2008 at 09:05:54PM +, Michael Treibton wrote: > On 24/02/2008, Jaimos Skriletz <[EMAIL PROTECTED]> wrote: > > I have not run across any built in way to do this. Bascailly all it does is > > move each > > window to the current location of the corresponding window. If the windows > > are the > > same size you get nice results (such as terminals), if windows are > > different size you > > could push them off the screen or get other strange behavior. > > i got that far, yes, it just seems to not work at all after a while. > > > Thomas enviormental pollution is more 'pointless' env vars are bad. As > > anything they > > just take up resorces and why waste resorces if there is no point. such as > > using > > $[fvwm_home] when $[FVWM_USERDIR] already exists and covers this. > > i don't follow you here - got an example? i only remember seeing > something in passing and am interested. > I did give you two examples of how 'pointless' enviorment variables are not needed, there are other reasons why you would want to use FVWM_USERDIR over fvwm_home (one is all systems know FVWM_USERDIR). please read thomas' writeup. http://fvwm.lair.be/viewtopic.php?t=1505 jaimos
Re: FVWM: Swapping 2 window positions
On Sun, Feb 24, 2008 at 07:33:46PM +, Michael Treibton wrote:
> On 24/02/2008, Michael Treibton <[EMAIL PROTECTED]> wrote:
> > Thank you for trying but i get odd results from this.
> >
> > is there no builtin way?
I have not run across any built in way to do this. Bascailly all it does is
move each window to the current location of the corresponding window. If the
windows are the same size you get nice results (such as terminals), if windows
are different size you could push them off the screen or get other strange
behavior.
The only way I can think of to make it work better is to have some shell script
hadel the variables and do some calculations to get everything to position
itself a bit smarter than just a force move on each of the windows. This would
require a lot more work.
>
> Also, didnt i read somewhere that to many env vars is bad?
Thomas enviormental pollution is more 'pointless' env vars are bad. As anything
they just take up resorces and why waste resorces if there is no point. such as
using $[fvwm_home] when $[FVWM_USERDIR] already exists and covers this.
The other example is to use an env var to store data that will never change, so
instead of having a SetEvn fvwm_icon $[FVWM_USERDIR]/icons
just write out the path relative to ${FVWM_USERDIR] everywhere you would of
written $[fvwm_icon] which in lots of configs was only in the ImagePath (hence
a waste of an env var)
and as you notice I just use them for tempory storage and unset them at the
end. Again if you would rather do this in a shell script, it is possible to
just have your functions call some shell script or even build a simple Module
to do the swaping.
jaimos
Re: FVWM: Swapping 2 window positions
On Sun, Feb 24, 2008 at 04:14:20PM +, Michael Treibton wrote: > Hi, > > Assume i have two windows, A and B. Is it possible to swap their > positions with each other? > I was able to get these functions to swap two window locations (under limited testing). One thing you may want to note is they have to be on the CurrentPage. If you wish to swap windows on different pages you will have to add some more detial and include MoveToPage options. You should be able to see the idea I am using extend this with MoveToPage options if you desire. DestroyFunc SwapWin AddToFunc SwapWin + I SwapWin2 1 + I Next (!Iconic, CurrentPage) SwapWin2 2 + I Test (EnvIsSet win1-id, EnvIsSet win2-id) WindowId $[win1-id] Move $[win2-x]p $[win2-y]p + I TestRc (Match) WindowId $[win2-id] Move $[win1-x]p $[win1-y]p + I UnsetEnv win1-x + I UnsetEnv win1-y + I UnsetEnv win1-id + I UnsetEnv win2-x + I UnsetEnv win2-y + I UnsetEnv win2-id DestroyFunc SwapWin2 AddToFunc SwapWin2 + I ThisWindow (AcceptsFocus, !Iconic) SetEnv win$0-x $[w.x] + I TestRc (Match) SetEnv win$0-y $[w.y] + I TestRc (Match) SetEnv win$0-id $[w.id] You will need both functions and in my limited test running the function as Pick SwapWin will swap the chosen window with the next window it finds that is not iconic and accepts focus. You could replace next with your directional options if you desire of course. jaimos
