Re: FVWM: fvwm3? [on Wayland]
On Sun 2024-02-04 09:51 , Stuart Longland wrote: > So either some of us need to step up and get familiar with how X11 works > (unlikely, it seems like a monumental task)… or we need to "pack our bags", > so to speak It hurts, but my sense is that the above is right. IMHO the distributions effectively need a vibrant community around a project to pick it up. It can hardly be a one man show. The denial will start with security issues, as usual... IMHO for FVWM to survive, the FVWM community needs to focus on wayland. And start from scratch... I wish this happens. m.
FVWM: google meet presentation versus fvwm viewports
Hi folks, I need to use google meet with firefox on linux. I use fvwm 2.6 and I'm switching between viewports using GotoDesk 0 , where is a viewport number/id (hope I'm using the right terminology). A recent version of google meet started to behave such that when I'm presenting a firefox tab, google meet can somehow detect whether it's running in an active/visible viewport or not. In the latter case it will turn my presentation into a black rectangle until I bring my firefox back to the active viewport. Note that this surprisingly isn't about "focus". Or at least not *only* about focus. It is about whether my browser is or isn't withing an active viewport. This is annoying. It forces me to keep my firefox presentation in an active viewport. How can I work this around? Thanks, Martin
FVWM: sticky windows on given display
Hi folks, there's one manual step I'd like to automate with fvwm: I'd like to make all windows that are created or moved to given physical display - sticky. For now I've partially automated that based on the window name, but I'd love to base this on the display where the window is shown rather than on the window name. Is there a reasonable way of doing this? How? Thanks, Martin
Re: FVWM: FVWM3-1.0.0 is released
On Thu 2020-09-03 20:14 , Dominik Vogt wrote: > On Thu, Sep 03, 2020 at 12:13:45PM -0600, Jaimos Skriletz wrote: [ ... stuff deleted ... ] > > 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? Such a naming scheme provides the user with an option to have multiple versions installed at once. Which does imho have certain practical value per se. In Fedora world, there are various exmaples of such approach, such as e.g. samba4, xmms2, or softwarecollections.org. I'm wondering whether there is a good reason not to go this way. m.
Re: FVWM: FVWM3-1.0.0 is released
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 ... ) m.
Re: FVWM: Full crash when using an invalid PNG for a mini-icon
On Tue 2019-05-28 15:27 , Thomas Adam wrote: > On Tue, 28 May 2019 at 14:47, wrote: > > > > Hi All, > > > > I'm using fvwm 2.6.7 from Debian/stretch. > > > > If I execute the command > > > > Pick WindowStyle MiniIcon password.png > > > > I get a full FVWM crash (and consequently an X server exit + lost work + > > tears). > > Can you please ensure FVWM has been built with debug symbols, and get > a backtrace from gdb? Reproduced with fvwm-2.6.8-2.fc29.x86_64 (https://koji.fedoraproject.org/koji/buildinfo?buildID=1108778) : === (gdb) bt #0 0x7ff3879ff53f in raise () from /lib64/libc.so.6 #1 0x7ff3879e9895 in abort () from /lib64/libc.so.6 #2 0x7ff38851a235 in ?? () from /lib64/libpng16.so.16 #3 0x7ff38851f4eb in png_error () from /lib64/libpng16.so.16 #4 0x7ff38851f574 in png_chunk_error () from /lib64/libpng16.so.16 #5 0x7ff3885325ff in ?? () from /lib64/libpng16.so.16 #6 0x7ff388524b08 in png_read_row () from /lib64/libpng16.so.16 #7 0x7ff38852668a in png_read_image () from /lib64/libpng16.so.16 #8 0x559b77dc8df1 in PImageLoadPng (dpy=, path=, argb_data=0x7ffe4630b2b0, width=, height=) at PictureImageLoader.c:535 #9 0x559b77dc9941 in PImageLoadArgbDataFromFile (dpy=dpy@entry=0x559b78ff9290, path=path@entry=0x559b79020750 "/home/mcermak/password.png", argb_data=argb_data@entry=0x7ffe4630b2b0, width=width@entry=0x7ffe4630b354, height=height@entry=0x7ffe4630b358) at PictureImageLoader.c:114 #10 0x559b77dca14b in PImageLoadPixmapFromFile (dpy=dpy@entry=0x559b78ff9290, win=win@entry=6291788, path=path@entry=0x559b79020750 "/home/mcermak/password.png", pixmap=pixmap@entry=0x7ffe4630b368, mask=mask@entry=0x7ffe4630b370, alpha=alpha@entry=0x7ffe4630b378, width=0x7ffe4630b354, height=0x7ffe4630b358, depth=0x7ffe4630b35c, nalloc_pixels=0x7ffe4630b364, alloc_pixels=0x7ffe4630b380, no_limit=0x7ffe4630b360, fpa=...) at PictureImageLoader.c:830 #11 0x559b77dca36b in PImageLoadFvwmPictureFromFile (dpy=dpy@entry=0x559b78ff9290, win=win@entry=6291788, path=path@entry=0x559b79020750 "/home/mcermak/password.png", fpa=...) at PictureImageLoader.c:893 #12 0x559b77dd3fde in PCacheFvwmPicture (dpy=0x559b78ff9290, win=6291788, ImagePath=ImagePath@entry=0x0, name=, fpa=...) at Picture.c:138 #13 0x559b77d71c5d in setup_mini_icon (pstyle=pstyle@entry=0x7ffe4630bb00, fw=, fw=) at add_window.c:850 #14 0x559b77d7319e in change_mini_icon (fw=fw@entry=0x559b7902c460, pstyle=pstyle@entry=0x7ffe4630bb00) at add_window.c:2258 #15 0x559b77dac1af in apply_window_updates (t=t@entry=0x559b7902c460, flags=flags@entry=0x7ffe4630baf8, pstyle=pstyle@entry=0x7ffe4630bb00, focus_w=focus_w@entry=0x559b7902c460) at update.c:180 #16 0x559b77dad0c2 in flush_window_updates () at update.c:727 #17 0x559b77d5e755 in HandleEvents () at events.c:4199 #18 0x559b77d3b59a in main (argc=, argv=) at fvwm.c:2590 (gdb) === Martin
Re: FVWM: appearance
On Fri 2019-01-04 13:11 , Mandar Mitra wrote: > I haven't used Fedora in a very long time, but once upon a > time, rpm -qa --last would give you a list of packages in > most-recently-installed/updated-first order. That should give > you some hint about what might have changed. (To list the dnf (rpm) transactions, and possibly even undo some of them, one can use the dnf transaction history facility, as I've mentioned earlier in this thread.) m.
Re: FVWM: appearance
I don't think there is any difference in how fvwm looks in your screenshots. What differs is the appearance of your File Manager. One of the ways you can try to go is to look at your system as at a black box: Create a new account for testing with no user config files and play around with your dnf transation history [1]. Others might have smarter recommendations though. Martin. --- [1] https://docs.fedoraproject.org/en-US/Fedora/24/html/System_Administrators_Guide/sec-DNF-Transaction_History.html On Thu 2019-01-03 00:19 , Oleg Tyurin wrote: > Hi. Please help me understand how to configure application appearance > properly. > After fresh install of FVWM2 I had an appearance according to screenshot1. > Next, probably after install of something an appearance had > been changed according to screenshot2. > How can I configure this appearance back to screenshot1? > I use Fedora 25, FVWM2 without Gnome3. > I would appreciate any help. Thanks! > > Kind regards, Oleg.
Re: FVWM: Using FVWM manager on RHEL 6 system
Hello,
On Tue 2018-06-19 15:51 , William Muriithi wrote:
> Morning,
>
> I am interested in using fvwm on a Centos 6 and curious if this is a viable
> idea.
>
> Couple of observation I have noticed that is a bit worrying:
>
> - There hasn't been any commit against this project for almost 2 years
> - 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
>
> Any chance there is someone here using this manager on any recent Red Hat
> derived distribution and would like to share their experience please?
I didn't test on CentOS, but did on RHEL-{6,7}. Configuring EPEL [1]
and installing fvwm using yum might be all you need.
Martin
---
[1] https://fedoraproject.org/wiki/EPEL
Re: FVWM: FVWM Logo Competition
On Thu 2016-09-08 08:04 , Donald R Laster Jr wrote: > I use it on Slackware, where it is part of the distribution, > and RHEL where I have to install it. It's in EPEL, so it's kind of part of the RHEL/CENTOS distro too: https://fedoraproject.org/wiki/EPEL http://koji.fedoraproject.org/koji/packageinfo?packageID=1783 Martin
Re: FVWM: FVWM Logo Competition
Hi Thomas, On Mon 2016-08-29 21:50 , Thomas Adam wrote: > Hi all, > > I happened to be looking at the previous FVWM logo compeition [1] and wondered > if it's time to hold another one? The previous competition was held in the > early 2000s. Is it time for an update? > > If so, send some ideas through, it'd be great to see them! > > -- Thomas Adam > > [1] http://fvwm.org/fvwm-logos/competition/ I like the current logo. But as long as fvwm is here as such, I'm fine with pretty much any logo for it ;) m.
Re: FVWM: Survey: Are you affected by disappearing Firefox menus?
Hey guys, no such issue seen of Fedora 16, 20, 23, and CentOS 7. Using distribution packages exclusively. Martin On Wed 2016-03-30 06:12 , Michael Großer wrote: > Hi! > > I have a problem with newer versions of Firefox (and Thunderbird), so > after several months (probably years) of suffering, I finally filed a bug > last Thursday (after my patience snapped and I no longer could stall > this issue): > > https://bugzilla.mozilla.org/show_bug.cgi?id=1259520 > Bug 1259520 - Pull down menus close when I try to choose menu items > > Just now, it dawned on me that my FVWM config settings could be in > conflict with something that was not in Firefox until version 12 > but was newly introduced into Firefox 13 back in the year 2012. > > Because I need some time to adapt to newer software versions, > I notice such conflicts rather late. > > Some minutes ago, I did the test with a naked FVWM (entirely > without config) and I couldn't reproduce the Firefox bug, so > all I have to do is, systematically finding the difference between > a naked FVWM und my own FVWM config. > > But, I'm curious, and I want to ask you: > > +---+ > | Does anybody of you is confronted during day-to-day work with | > | issues that Firefox menues disappear when you are about to| > | open a sub menu or another menu? | > +---+ > > Just all I want from you is: I want to roughly estimate how > many FVWM users are affected or whether any FVWM user was > at all affected by the bug I'm currently tackling. > > Thanks in advance, > Michael Großer
Re: FVWM: window move issue
On Tue 2014-04-22 20:35 , Viktor Griph wrote: 2014-04-22 20:09 GMT+02:00 Martin Cermak marti...@gmail.com: [...] Any further ideas or thoughts? Does using the style OpaqueMoveSize 0 also leave artifacts on the screen when moving windows, or is it just opaque move that is affected? OpaqueMoveSize has no effect. BUT it turns out that what's not being redrawn is the root window. Nothing else. Using fvwm-root to set some background image kind of fixes the issue for me. Which is a good news I think :) However, there is some issue with the root window redrawing, which would be worth of fixing I guess. This happens with latest fedora 20 package fvwm-2.6.5-6.fc20 as well as with fvwm built from latest CVS sources. Martin
FVWM: window move issue
Hello there! Recently I noticed an issue moving windows using FVWM. The issue is described in [1] and seems to be HW dependent. However, successful usage of some other VMs on affected boxes makes me think that the issue might be on the FVWM side. Ideas? Thoughts? Regards, Martin [1] https://bugzilla.redhat.com/show_bug.cgi?id=1021782 https://bugzilla.redhat.com/show_bug.cgi?id=1086235
