Today I’ve created github page with my FVWM config, which I’ve started to create since my first post in this forum in 2016. May be useful for some users for sure.
It’s very usable and polished. Highly recommended. Just try to use it.
On github page there are complete instructions on how to use it, so I’ll not duplicate it here.
As this forum doesn’t seem to be alive… I won’t visit it too
Discussion/help for this configuration is available on official Devuan forum —
The forum is still alive, you have 30 views on this topic.
I just finished the test, you have done a lot of work. First, I was curious about the announcement…
It is modern and ready to use, so even gnome/kde users won't be missing something.
Gnome/KDE will miss the mouse bindings, menu bar and there is no icon bar but iconify tray, etc. The titlebar buttons on the left side will confuse them. I suggest, removing this statement and add what are the advantages of this config.
Secondly, this config is complex. Maybe this is why calling “Solid FVWM”. I did not check, but seems taking more memory than usual. Actually, after trying the different keybindings, the system froze… I tested it on USB drive, could be a drive problem.
I suggest testing it in parts, not as a whole config, to know that all things work.
it is very stable, tested on several machines for years.
so your “freezes” are part of your pen drive (or other) problems.
it’s tested “by parts”, as whole, with debuging and watching .xsession-errors file, etc.
Also there is nothing “extraordinary” in this config which may cause any problems/bugs
or an extra ram usage. ALL of its functionality is using native FVWM functions
and two native modules: FwmEvent and FvwmButtons. So extra RAM usage,
glitches or any other problems you’ve listed are excluded by design.
Also any extra scripts or some “secret code”, which may be force you
to try it on “pen drive”, is completely absent. Clean and native FVWM configuration.
If FVWM with its modules are working well on your machine, this config will work well too.
By “gnome/kde” I meant focus policy and automatic focus switch,
which is present in config with FvwmEvent module and modern look and feel -
“It’s containing functionality from modern window managers (including its focus policy) and some unique features”
Won’t be changed. because it may attract this part of audience to FVWM.
30 views for almost 4 days, and half of these viewers are bots and robots - not very big amount at all.
Where are users, moderators, anyone? just you and me, reminds me some kind
of schizophrenia. With such “support” this forum will never be very usable.
And I know what I’m talking about, because I was an administrator on one of popular forums for years. New users, like me, will see that “nobody home” and will leave it even if they’ve registered.
I tested it on my machine with Fvwm2 and 3. There are a few minor bugs and suggestions:
- autostart doesn’t have exe permission (add and upload in GitHub).
- Right-click menu…
Line 378 “&3 Identify” doesn’t work, and line 377 “&2 Destroy” works but good to change to Fvwm command.
+ "&2 Destroy" Destroy
+ "&3 Identify" FvwmIdent
- Add a button for Stalonetray… example
Test (x stalonetray) *<name button>: (94x1, Swallow(NoClose,UseOld) \
stalonetray 'Exec exec stalonetray --config \
- In README add how to change wallpaper in autostart.
fvwm-root -r ~/.fvwm/icons/rootbg.png
- The mild slowness is caused by the none-Fvwm apps in autostart (xrdb, xcompmgr, etc.)
- The keybindings are nice.
NONE of your bug reports and/or suggestions are useful and/or valid.
- Execute permissions for “autostart” file are NOT REQUIRED, as it is started by this command in config
+ I Exec exec sh $[FVWM_USERDIR]/autostart
+ I Exec exec $[FVWM_USERDIR]/autostart
“sh” command is present after “exec” in config.
Completely silly remark, “Destroy” — is already “FVWM” command. And “FvwmIdent” - “Identify” menu entry is working very well, you just need to select window interactively - using “target” cursor after pressing that menu entry, it is designed to work in this way — select an application with targer cursor and not an empty desktop, and you’ll see the effect.
No need to name buttons, as I don’t use any other FvwmButtons configurations, and it is started in this way in config:
+ I Module FvwmButtons
Stalonetray button already present and is working very well:
*FvwmButtons: (Swallow(UseOld,NoClose,Respawn) $[infostore.tray] 'Exec exec $[infostore.traycommand]', Action(Mouse1) ShowDesktop, ActionIgnoresClientWindow)
Stalonetray application and its command are set at the top of config via infostore environment variables:
InfoStoreAdd tray stalonetray
InfoStoreAdd traycommand 'stalonetray -bg "#333333" --geometry 2x2 --max-geometry 2x2 --scrollbars horizontal --scrollbars-size 3 --dockapp-mode simple --kludges force_icons_size'
This step is made to easyly replace it with another tray application when required, for example with wmsystemtray, this example is also given in the beginning of config file:
#InfoStoreAdd tray wmsystemtray
#InfoStoreAdd traycommand 'wmsystemtray --non-wmaker'
- It is enough that information about “autostart” file is mentioned twice in README, that it is used to autostart applications, and also that
Also line with “background” is also commented in ~/.fvwm/autostart file:
# Set background
fvwm-root -r ~/.fvwm/icons/rootbg.png
There is no “slowness” and it cannot be caused by such very lightweight applications like “xcompmgr” (and also “xrdb” cannot slowdown anything, as it is used to apply xterm/xft configuration once on start), if your PC is slow while using these applications, throw it away in the garbage, as such applications are pretty old-school, light and stable x11 classics.
Glad you’ve liked it.
Please, do not write to me such ignorant posts, as it is not my work to answer to such fake “issues”.
You jumped to a conclusion without checking what I wrote. Let’s go through a few points.
+ I Exec exec sh $[FVWM_USERDIR]/autostart
Thanks, this was new for me. Also, solves this “exe” question other users have been asking.
These are your config lines
Test (X xkill) + "&2 Destroy" Exec exec xkill
+ "&3 Identify" Exec exec FvwmCommand FvwmIdent
Exec exec xkill when Fvwm command “
Destroy” does the job???
+ "&2 Destroy" Destroy
Exec exec FvwmCommand FvwmIdent in Fvwm3, this doesn’t work. This code works fine, the same as what you also have in line 350.
+ "&3 Identify" FvwmIdent
- Just a suggestion. In MX Linux machine, your stalonetray script is not visible for users to change the network and have volume control.
same as it is in Fvwm default config.
This is made to force the interactive selection with cursor of a window to kill. Usable when
using hotkey Super+Escape when window is active. Simple FVWM “Destroy” will kill current
focused window. As all users have xorg installed - it is 99.9% that x11-apps are installed too,
xkill is available on every system (
xkill is used also with ctrl+alt+x hotkey).
This may be replaced with
FvwmCommand Destroy, to force interactive usage in FVWM,
but since FVWM 3 doesn’t support FvwmCommand, it should be completely removed.
This is partly not bad notice from your side, “FvwmCommand FvwmIdent” entry should be removed in future as it won’t work with FVWM3 (But is fully working with FVWM2).
What you’re showing on your screenshot has absolutely nothing to do with my config and with my stalonetray configuration, as my stalonetray instance is launched with FvwmButtons in
bottom left corner with command:
stalonetray -bg "#333333" --geometry 2x2 --max-geometry 2x2 --scrollbars horizontal --scrollbars-size 3 --dockapp-mode simple --kludges force_icons_size
So, you’re using some yours custom “blue” stalonetray code (not #333333 color from my config) in a completely random place of screen (not bottom left corner where FvwmButtons module should be starting it)
With my config (UNTOUCHED),
stalonetray by default will be started every time in such way like it is displayed on screenshot above. And this will happen with EVERY operating
fvwm may be installed, including even Open/Net/FreeBSD, Debian, RedHat, MX linux, PX linux, SMX linux, Madora linux, Minola linux, Momola linux and a fucken MOTOROLA linux too!
If you had salonetray instance running before restarting FVWM with my configuration — kill your instance of it and then restart FVWM again - stalonetray will be launched in bottom left corner.
On MX Linux and Arch Linux, with Fvwm2 and Fvwm3, the FvwmButton appears but no stalonetray.
That’s because you have no tray applications launched, so it is remaining empty.
It is as it should look like with no tray applications launched,
as no tray applications are started by default in config.
Stalonetray is launched automatically every time you start or restart FVWM using my config.
(If it is already runing on restart, it won’t be started or restarted again, existing instance of stalonetray will be used).
To make empty tray presence more obvious, it’s possible to replace
wmsystemtray package instead. To do this, replace stalonetray in “InfoStoreAdd tray”
and “InfoStoreAdd traycommand” lines with wmsystemtray in the top of config file:
InfoStoreAdd tray wmsystemtray
InfoStoreAdd traycommand 'wmsystemtray --non-wmaker'
- Kill stalonetray
$ pkill stalonetray
- Restart FVWM using root menu or Ctrl+Super+R hotkey
After this, you’ll see wmsystemtray with its buttons at the bottom left,
and when tray applications will be started, it will appear there.
P.S. Also, if you’re starting FVWM as a second (third, etc) X11 session, some tray applications will not be displayed in tray of a second session, like telegram-desktop, for example, or “nm-applet”, as it’s supporting only one instance running. To launch it in new Xorg session, it should be closed in older one.
Thanks for the info and instructions. With the
wmsystemtray it works fine.
I found an interesting feature of
wmsystemtray if not loaded at startup. The button becomes a desk cleaner with a mouse left click. It iconifies all running windows… that’s cool. Personally, I don’t like key bindings, being a mouse user when starting Linux in 1996.
Another feature that I didn’t notice because of the dark wallpaper, is the narrow transparent shadow under the windows. This is nice because Fvwm’s
RootTransparent does not work well.
This is a very nice config with interesting features.
This feature exist independed to running wmsystemtray/stalonetray or not,
you just need to press this button borders with running tray applications,
this is because ShowDesktop function is binded to FvwmButtons,
and info about this feature also was added to README:
will add this animation to README to attract more attention to this part.
Shadows are added with
xcompmgr composition manager.
Thanks, yes, it is polished even in details. Install also
dzen2 and watch how Desk notifications are nicely displaying with such shadows and colors. Also configure sound volume notifications, as written in README, it’ll be displayed in the same way as Desk change notifications.
First, thank you for the GitHub update.
I have tested the config by adding a few of my Fvwm Extensions (collection of individual modules, decors and styles). It is Solid and Xcompmgr makes it an elegant desk with the contrast and color sharpness that Desktop (Gnome/KDE) users want.
Just finished updating it, with adding more screenshots and more info.
Some ideas what should be added came with our conversation with you,
so there is also your part in this update too ;) Also, changed a little bit config
too, including that root menu fix too, with removing that stuff.
Good to hear that you’ve found it useful But, personally I prefer to use
all software in original, without any extensions or addons, that’s why I choose
such configurable software like zsh, vim, fvwm… etc, as its functionality
and configuration ability is very wide.
To whom this may be addressed, to all that few FVWM 3 users?
It should be used as fvwm3 slogan! As starting with 1.0.6a version,
titles from all menus are all in black color for some reason now
and with restart icons are disappearing… then deiconify/iconify
actions are required to see it again.
BTW, what really reminds me some schoolboy’s artwork is that green fvwm design,
which is used in default config, with all that bees and flowers… It is unusable for someone,
who have taste for well designed things.
This is a known bug. Details are in FVWM3 GH issues tab.
All are original Fvwm. Instead of running one large config, it is split into individual parts that can be added with
READ command and removed. This gives more choices and functionality to the users, the same as Gnome extensions give to Gnome.
With 1.0.5 there is no problem.
One of the differences with Fvwm3 is the naming of fvwm-root as fvwm3-root, you may have noticed.
fvwm3-root -r ~/.fvwm/icons/rootbg.png
Sorry for bugging you two more points… 1) buttons minimum size, and 2) limited wallpaper size.
- Line 40…
Style * MinWindowSize 64p 64p is limiting a user from adding smaller FvwmButtons. Below 64px is stretching the button.
For example, my Flux Taskbar module (
Removing this line doesn’t seem to affect your iconified buttons.
- I was wondering why your default wallpaper (rootbg.png) is 4x4 px. After checking,
Xcompmgr does not do well with large-size PNG wallpapers in Fvwm. On my machine (ASUS X509FL, 8GB) maximum 260x260px. Any larger size, for example, default Fvwm wallpaper (bg2.png) 480x480px, causes a screen lag… using the menu, shadow remains.
hsetroot works fine with full-size screen wallpaper. Though, it doesn’t duplicate a small size image but stretches it.
Your space wallpaper, what is the size and profile?