fvwm-crystal-3.7.1 released
Version 3.7.1 - Fvwm Crystal 3.7.1 is an important bug fix release. - Fix X failure at fvwm-crystal start when sh is dash (Debian and derivatives). I am sorry for that inconvenient which broke X startup on some distributions. I was very excited to release 3.7.0 which introduced fvwm3 support and didn't tested it on Debian. Being on a middle of a system update, virtualbox was not working. I learned the lesson and this lack of testing will not happen again. It also introduce some minor bug fixes and feature as well: - Use StartFunction with Test (Init) instead of the deprecated InitFunction in the Startup file of the preferences folder. - Add alsamixer launcher in the Startup file with support for the current Mixer preference setting. - Start FvwmMFL when running fvwm3. - Add support for FvwmPrompt (fvwm3 with golang support) and fvwm3 without golang into the FvwmMiniConsole. Fvwm2 and fvwm3 without golang are supported via FvwmConsole. As always, see ChangeLog for details. https://sourceforge.net/projects/fvwm-crystal/files/ Have fun! Dominique Michel
FVWM: fvwm-crystal-3.6.7 is out
Version 3.6.7 - Fvwm Crystal 3.6.7 is out! This version introduce a chinese zh_CN translation and a few bug fixes: - Fix the pmount menu (fvwm-crystal desktop icons). - timidity++: add user mode server into the application menu; it use jack-dbus and should be easy to change when needed. - Exec-Accelerator: remove superflous quoting. - Fix regression of trayer style which caused it to move around. - Custom button bar: fix multiple trayer instances when redrawing the magic button. https://sourceforge.net/projects/fvwm-crystal/files/ Cheers, Dominique
FVWM-Crystal 3.6.6 is out!
Version 3.6.6 - Fvwm Crystal 3.6.6 is out! This is a bug fix and new features release: - Fix libreofficce icons styles. - New addons/Xdefaults.no_transparency and Xresources.no_transparency files; they add support for non transparent terminals. - Fix the size of the desktop manager (Icons on dekstop). The widget was too big verticaly, which could be an issue when configured to display a lot of icons. - Add complete EWMH support for the size and the placement of the desktop manager. This fix collision with the magic button bar of the Custom recipe. I never constated such collision, but it was possible in theory. Anyway, this should be fixed now and this support, plus the geometry fix, make the visual to lock better. Enjoy! Dominique Michel https://sourceforge.net/projects/fvwm-crystal/files/3.6.6/
fvwm-crystal 3.6.3 is out
This is a bug fix release: - Fix the mpd FvwmScript applets. This fix add a dependency on python-mpd available on github as python-mpd2. It must be part of most GNU/linux distributions. As mpc does not provide what we need to get good working functions, it was both easier and better to use existing python bindings than to reinvent the wheel. It is a little bit slow at that time, but hopefully all the issues with these applets should be fixed. - Fix a warning into the Mixer-GUI function. - Add the Brave browser into the stay in full screen workaround. Enjoy! Dominique Michel https://sourceforge.net/projects/fvwm-crystal/files/
fvwm-crystal-3.6.2 is out
Every user is encouraged to update to 3.6.2: https://sourceforge.net/projects/fvwm-crystal/files/ Version 3.6.2 - Fvwm Crystal 3.6.2 is out! This is a bug fix release: - Fix the Show Custom Button Bar at top preferences to work on the same border with the mouse. - Fix outdated conditions syntax in Window-List, this remove the warning at start. See You in the streets! Dominique Michel Version 3.6.1 - Fvwm Crystal 3.6.1 is out! This is a bug fix release: - Fix media players styles after start and restart. - Use new exec name in the xmms2 audio player control. - Fullscreen function: fix nasty loops with the Schedule/Deschedule of the stay in fullscreen browser workaround. and a few minor fixes. See the ChangeLog file. Have fun! Dominique Michel
fvwm-crystal 3.6.0 is out
Version 3.6.0 - Code name "Magic Star" You can download it from https://sourceforge.net/projects/fvwm-crystal/files/ Fvwm Crystal 3.6.0 is a big step forward. - Dependencies updated to >=fvwm-2.6.9 and python3. - A configurable button bar along with the Custom new recipe are providing a contemporary look. It have its own preference menu and can be placed on any side of the desktop. - Left click: menu or application launcher - Middle cllick: remove the button and redraw the bar - Right click: preference menu, a new button will be placed at the right of the clicked button - New Italian translation - Support for FVWM_*DIR at fvwm-crystal invocation, see 'man fvwm-crystal'. - Support for Icon and MiniIcon fvwm Styles for each application found during the application menu generation. - Support of automatic restart of urxvtc when crashed. - Silent the application database. This make the login shell (and fvwm-crystal logfile if any), to be less poluted by external applications. - Improved the systemd Exit menu with hibernate/resume support. - Screenlid suspend-hibrid support with preference - Cadence support into the Music menu and Music GUI key binding - Mouse velocity preference (default: system value) - The python scripts are updated to python 3. They was tested with python 2 and should work, but that's not officially supported anymore. - Update of the Fullscreen fonction to the new fvwm builtin function with workaround about non ewmh compliant browsers That update simplify this function and make it to work better. - Improved support of different button sizes into the recipes with preferences. - The ACPI applets will be shown only when the required hardware is found. - New window decorations Buttons-amigaos-Fullscreen and Buttons-amigaos-MiniIcon-Fullscreen. A left click on the second button will bring the window in fullscreen. The existing amigaos button models will now maximize the window. As always, numerous fixes, bugfixes and new applications and icons for the application menu. Most important ones: - The EWMH working area was reverted to its original function and improved. It should work fine with all recipes and with both the desktop manager and the new button bar when activated. - Fix support of svg application icons. - Temporary fix for the Font preferences applet crashing at launch with some colorsets (due to a fvwm bug). It can look uggly but should work with all colorsets. - Fix the media players styles. This also fix their icons at top layer after a recipe change bug. See ChangeLog for the details. I tested fvwm-crystal with fvwm 3. It mostly work and is usable, but that's not supported at that time. Anyway, that's a very good news for the future of fvwm-crystal. A big thank you to the fwvm workers for their dedication to fvwm and for their support! A big thank you to Star the dog and to the translators! With the new Custom recipe and its magic button, fvwm-crystal get a modern look and a terrific customizable multiple launcher. This imply most effort into its development will be focused into making it fvwm3 fully compliant. Which in turn mostly imply to update the fvwm dialogs to fvwm scripts at that time of writing. Translations, fixes and bugfixes will continue to be applied. New functions and other improvements will be accepted, but for my part, they will be part of a general reflexion about what I want to do with fvwm-crystal. I know what I don't want: a full rewrite would be a time consuming catastrophe because we will loose all the history including numerous fixes. Also, as fvwm-crystal has been more and more extended with time, I think a tooltip system must be added. Beside that, I would appreciate very much any ideas or contributions. Enjoy! Dominique Michel
Possible bug with the locale system
I find a possible bug with how fvwm handle my French locale. The apostrophe is part of that language and fvwm is not consistant on how it handle that character. As example, if I have: msgid "Resume hybride with screen lid" msgstr "Veille puis hibernation lors de la fermeture de l'écran" into fvwm-crystal.po, the following will work fine: All (TestLocale-Dialog) Close DestroyModuleConfig TestLocale-Dialog: * *TestLocale-Dialog: Title "$[gt.Resume hybride with screen lid]" *TestLocale-Dialog: Text "$[gt.Resume hybride with screen lid]" *TestLocale-Dialog: Line Center *TestLocale-Dialog: Button quit "$[gt.Quit]" ^M *TestLocale-Dialog: Command Nop Module FvwmForm TestLocale-Dialog # but what follow will result into a screwed up menu: DestroyFunc TestScreenLidSuspend AddToFunc TestScreenLidSuspend + I Nop DestroyFunc TestNoScreenLidSuspend AddToFunc TestNoScreenLidSuspend + I Nop DestroyFunc TestScreenLidSuspend-generator AddToFunc TestScreenLidSuspend-generator + I DestroyMenu recreate /TestScreenLidSuspend + I Piperead "echo AddToMenu /TestScreenLidSuspend \\'$[gt.Resume hybride with screen lid]\\' TestScreenLidSuspend" DestroyMenu /TestScreenLidSuspend AddToMenu /TestScreenLidSuspend + DynamicPopupAction Function TestScreenLidSuspend-generator DestroyMenu /TestExit AddToMenu /TestExit + '%22x22/fvwm-crystal/gdm.png%$[gt.Resume hybride with screen lid]' Popup /TestScreenLidSuspend # Menu /TestExit show than the main menu is already screwed up. If I replace the "'" by a "_" into the translated string, it work fine in both cases. I try to escape the "'" into the po file, but in the best case it doesn't helped. Is it something I didn't figured out I can do? Best, Dominique -- If you have a problem and you are not doing anything to fix it, you are at the heart of the problem. fvwm-crystal.mo Description: application/gettext-translation # French translation for FVWM-Crystal # Copyright (C) 2005 FVWM-Crystal team # This file is distributed under the same license as the fvwm-crystal package. # Original by Nicolas Vilz 'niv' , 2005. # Modified by Dominique Michel , 2006 to 2014 # msgid "" msgstr "" "Project-Id-Version: fvwm-crystal 3.5.1\n" "POT-Creation-Date: 2019-08-28 12:14+0200\n" "PO-Revision-Date: 2019-08-28 12:32+0200\n" "Last-Translator: Dominique Michel \n" "Language-Team: French\n" "Language: fr\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: Poedit 2.2\n" msgid "Resume hybride with screen lid" msgstr "Veille puis hibernation lors de la fermeture de l'écran" TestLocale Description: Binary data
fvwm-menu-desktop, additional and extended categories
Hi all,
It is several xdg menus in my system:
fvwm-menu-desktop --get-menus desktop
/etc/xdg/menus/xfce-applications.menu /etc/xdg/menus/fvwm-applications.menu
/etc/xdg/menus/xfce-settings-manager.menu /etc/xdg/menus/e-applications.menu
The fvwm-applications menu provide full support for the additional
categories as defined here:
https://specifications.freedesktop.org/menu-spec/latest/apas02.html
With
fvwm-menu-desktop \
--menu-type applications \
--all-menus \
--enable-mini-icons \
--theme FVWM_Xdg \
--size 32 \
--title FvwmMenu \
--mini-icon-dir ${FVWM_USERDIR}/icons/fvwm-desktop >
${FVWM_USERDIR}/${MENU_FILE}
The --all-menus is mandatory to get the wanted additional xdg
categories. Without it, the additional categories of the
fvwm-applications menu are missing because several menus provide the
same submenus with identical names but without the additional
categories. But even with that option, the resulting menu is a little
bit messy because if the fvwm and xfce menus are OK, the 2 others are
duplicated (get 2 times all the main categories in each of them).
If I run
fvwm-menu-desktop \
--menu-type applications \
--desktop fvwm \
--enable-mini-icons \
--theme FVWM_Xdg \
--size 32 \
--title FvwmMenu \
--mini-icon-dir ${FVWM_USERDIR}/icons/fvwm-desktop >
${FVWM_USERDIR}/${MENU_FILE}
fvwm-menu-desktop work as expected: I only get the fvwm applications
menu and get all the needed additional categories, as provided by this
xdg menu (can be found here: https://github.com/domichel/fvwm-xdg-menu)
But in both cases, I get no support of the extended categories as
defined here:
https://specifications.freedesktop.org/menu-spec/latest/ar01s03.html
"Appendix A, Registered Categories enumerates the standard categories.
Categories not in this document must be prefixed by the string "X-"
indicating that they are extensions."
I don't know if that issue comes from fvwm-desktop-menu or from PyXdg
on which it depend.
As example, I have several application desktop files like:
#
cat /usr/share/applications/lsp-plugins-spectrum-analyzer-x1-lsp.desktop
[Desktop Entry]
Name=spectrum-analyzer-x1
Type=Application
Comment=Linux Studio Plugins Project
Exec=lsp-plugins-spectrum-analyzer-x1
TryExec=lsp-plugins-spectrum-analyzer-x1
Icon=lsp-plugins-spectrum-analyzer-x1
Categories=AudioVideo;Audio;X-LSP_Plugins;
and
# cat /usr/share/desktop-directories/LSP-Plugins.directory
[Desktop Entry]
Type=Directory
Verson=1.0
Name=LSP-Plugins
Icon=lsp
# cat /etc/xdg/menus/applications-merged/LSP-Plugins.menu
http://www.freedesktop.org/standards/menu-spec/menu-1.0.dtd;>
Applications
LSP Plugins
LSP-Plugins.directory
X-LSP_Plugins
In /etc/xdg/menus/applications-merged, I have an electronics menu very
similar to the LSP-Plugins menu, and it appear correctly. The only
difference I can see that can trigger X-LSP_Plugins to be ignored is
than Electronics is an additional category when X-LSP_Plugins is an
extension.
Also, from my experience with fvwm-crystal, I know than the
applications desktop files contains all the needed informations in
order to generate a xdg menu which will support all the categories
(main, additional and extensions), that as long these desktop files are
valid ones.
Best,
Dominique
--
If you have a problem and you are not doing anything to fix it, you are
at the heart of the problem.
Re: fvwm-menu-desktop and mini icons
Le Fri, 25 Apr 2014 01:47:23 +0200,
Dominique Michel dominique.mic...@vtxnet.ch a écrit :
To be able to test it with the complete menu and the little and still
incomplete icon theme I use, you can download the whole thing here:
https://github.com/domichel/fvwm-xdg-menu
It is even a Makefile that will let you easily install and de-install
it.
Hi,
Using the following command, I get unexpected results:
fvwm-menu-desktop --desktop fvwm --menu-type applications \
--enable-mini-icons --theme FVWM_Xdg --size 24 --mini-icon-dir \
${FVWM_USERDIR}/icons/fvwm-desktop applications.menu
give:
DestroyMenu FvwmMenu
AddToMenu FvwmMenu
+
Accessoires%/home/dom/.fvwm-crystal/icons/fvwm-desktop/24x24-applications-accessories.png%
Popup Accessoires
+
Autres%/home/dom/.fvwm-crystal/icons/fvwm-desktop/24x24-applications-other.png%
Popup Autres
+
Bureau%/home/dom/.fvwm-crystal/icons/fvwm-desktop/24x24-applications-office.png%
Popup Bureau +
Développement%/home/dom/.fvwm-crystal/icons/fvwm-desktop/24x24-applications-development.png%
Popup Développement
with a index.theme file with:
# Directory list
Directories=24x24/categories,16x16/categories,32x32/categories
But when I have the following:
Directories=24x24/categories
the same command than above give:
DestroyMenu FvwmMenu
AddToMenu FvwmMenu
+
Accessoires%/usr/share/icons/FVWM_Xdg/24x24/categories/applications-accessories.png%
Popup Accessoires
+
Autres%/usr/share/icons/FVWM_Xdg/24x24/categories/applications-other.png%
Popup Autres
+
Bureau%/usr/share/icons/FVWM_Xdg/24x24/categories/applications-office.png%
Popup Bureau
+
Développement%/usr/share/icons/FVWM_Xdg/24x24/categories/applications-development.png%
Popup Développement +
Infographie%/usr/share/icons/FVWM_Xdg/24x24/categories/applications-graphics.png%
Popup Infographie
The fist time, the icons are converted and put in ~/.fvwm-crystal/...
the second time the icons are taken directly from the theme
in /usr/share/icons
According to
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
this is the order of the directories into the Directories key that
should determine how they are used.
Visually, the icons in the menu look much better when they are taken
directly from the theme. So I don't know if it is a bug in
fvwm-menu-desktop or if I am doing something wrong.
Dominique
Re: fvwm-menu-desktop and mini icons
Le Fri, 25 Apr 2014 12:32:09 +0200, Dominique Michel dominique.mic...@vtxnet.ch a écrit : The fist time, the icons are converted and put in ~/.fvwm-crystal/... the second time the icons are taken directly from the theme in /usr/share/icons According to http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html this is the order of the directories into the Directories key that should determine how they are used. Visually, the icons in the menu look much better when they are taken directly from the theme. So I don't know if it is a bug in fvwm-menu-desktop or if I am doing something wrong. I think this is a bug. To correct it, if that imply to slow down fvwm-menu-desktop, I can make a simple work-around to my icon theme: split in into 3 different themes, one for each icon size. Dominique
fvwm-menu-desktop and mini icons
Hi,
Using the following command, I get unexpected results:
fvwm-menu-desktop --desktop fvwm --menu-type applications \
--enable-mini-icons --theme FVWM_Xdg --size 24 --mini-icon-dir \
${FVWM_USERDIR}/icons/fvwm-desktop applications.menu
give:
DestroyMenu FvwmMenu
AddToMenu FvwmMenu
+
Accessoires%/home/dom/.fvwm-crystal/icons/fvwm-desktop/24x24-applications-accessories.png%
Popup Accessoires
+
Autres%/home/dom/.fvwm-crystal/icons/fvwm-desktop/24x24-applications-other.png%
Popup Autres
+
Bureau%/home/dom/.fvwm-crystal/icons/fvwm-desktop/24x24-applications-office.png%
Popup Bureau +
Développement%/home/dom/.fvwm-crystal/icons/fvwm-desktop/24x24-applications-development.png%
Popup Développement
with a index.theme file with:
# Directory list
Directories=24x24/categories,16x16/categories,32x32/categories
But when I have the following:
Directories=24x24/categories
the same command than above give:
DestroyMenu FvwmMenu
AddToMenu FvwmMenu
+
Accessoires%/usr/share/icons/FVWM_Xdg/24x24/categories/applications-accessories.png%
Popup Accessoires
+
Autres%/usr/share/icons/FVWM_Xdg/24x24/categories/applications-other.png%
Popup Autres
+
Bureau%/usr/share/icons/FVWM_Xdg/24x24/categories/applications-office.png%
Popup Bureau
+
Développement%/usr/share/icons/FVWM_Xdg/24x24/categories/applications-development.png%
Popup Développement +
Infographie%/usr/share/icons/FVWM_Xdg/24x24/categories/applications-graphics.png%
Popup Infographie
The fist time, the icons are converted and put in ~/.fvwm-crystal/...
the second time the icons are taken directly from the theme
in /usr/share/icons
According to
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
this is the order of the directories into the Directories key that
should determine how they are used.
Visually, the icons in the menu look much better when they are taken
directly from the theme. So I don't know if it is a bug in
fvwm-menu-desktop or if I am doing something wrong.
Dominique
Re: fvwm-menu-desktop locale strangeness
Le Thu, 17 Apr 2014 19:21:49 +0200, Thomas Funk t.f...@web.de a écrit : Am 17.04.2014 09:55, schrieb Dominique Michel: Le Sun, 13 Apr 2014 20:13:45 +0200, Thomas Funk t.f...@web.de a écrit : Am 13.04.2014 17:31, schrieb Dominique Michel: Hi, with fvwm-crystal, I get an issue with a localized xdg menu. If I launch fvwm as a Xephyr session and use its default configuration (no config file), I get a very simple menu where it is a Desktop Menu. If I click on it, I get an applications menu with several menus in it: Fvwm Applications Suse Applications Xfce Applications Xfce Settings Manager which correspond to what I have in /etc/xdg/menus. The Fvwm Applications menu is my localized menu. If I browse it, only parts of it are localized, and other parts are not when the localization exist in /usr/share/directories. I made the following function: DestroyMenu FvwmMenu AddToMenu FvwmMenu + DynamicPopupAction PipeRead 'fvwm-menu-desktop \ --desktop fvwm-applications \ --enable-mini-icons \ --mini-icon-dir $[FVWM_USERDIR]/icons/fvwm-desktop' Try this: DestroyMenu FvwmMenu AddToMenu FvwmMenu + DynamicPopupAction PipeRead 'fvwm-menu-desktop \ --desktop fvwm \ --type applications \ --enable-mini-icons \ --mini-icon-dir $[FVWM_USERDIR]/icons/fvwm-desktop' I get: Warning: Arg --type is obsolete and ignored, but the menu work fine. I only get the fvwm menu and the localization is coKey A A $[Mod1] Menu FvwmMenurrect. Uuups, my fault - not --type but --menu-type That work without warning and I only get the fvwm menu with the correct translations. fvwm-menu-desktop version 2.3.1 and $ fvwm-menu-desktop --get-menus all --verbose That look OK to me. All is here: Parameters for creating menu list: XDG_MENU_PREFIX: '' --install-prefix: '' --desktop:'' --menu-type: '' Start search ... found in /home/dom/.config/menus: [] found in /etc/xdg/menus: ['fvwm-applications.menu', 'yast-settings.menu', 'lxde-applications.menu', 'xfce-applications.menu', 'ggz.menu', 'kde-4-applications.menu', 'gnome-applications.menu', 'suse-applications.menu', 'xfce-settings-manager.menu'] Menu list: ['/etc/xdg/menus/fvwm-applications.menu', '/etc/xdg/menus/yast-settings.menu', '/etc/xdg/menus/lxde-applications.menu', '/etc/xdg/menus/xfce-applications.menu', '/etc/xdg/menus/ggz.menu', '/etc/xdg/menus/kde-4-applications.menu', '/etc/xdg/menus/gnome-applications.menu', '/etc/xdg/menus/suse-applications.menu', '/etc/xdg/menus/xfce-settings-manager.menu'] Previous used theme: gnome Current used theme: gnome Create submenu 'FvwmFvwm Applications' from '/etc/xdg/menus/fvwm-applications.menu' Create submenu 'FvwmYast Settings' from '/etc/xdg/menus/yast-settings.menu' Menu is empty - won't be used! Create submenu 'FvwmLxde Applications' from '/etc/xdg/menus/lxde-applications.menu' Create submenu 'FvwmXfce Applications' from '/etc/xdg/menus/xfce-applications.menu' Create submenu 'FvwmGgz' from '/etc/xdg/menus/ggz.menu' Menu is empty - won't be used! Create submenu 'FvwmKde 4 Applications' from '/etc/xdg/menus/kde-4-applications.menu' Create submenu 'FvwmGnome Applications' from '/etc/xdg/menus/gnome-applications.menu' Create submenu 'FvwmSuse Applications' from '/etc/xdg/menus/suse-applications.menu' Create submenu 'FvwmXfce Settings Manager' from '/etc/xdg/menus/xfce-settings-manager.menu' /etc/xdg/menus/fvwm-applications.menu /etc/xdg/menus/lxde-applications.menu /etc/xdg/menus/xfce-applications.menu /etc/xdg/menus/kde-4-applications.menu /etc/xdg/menus/gnome-applications.menu /etc/xdg/menus/suse-applications.menu /etc/xdg/menus/xfce-settings-manager.menu Process took 36.1115701199 seconds Looks good. Would it be possible to repeat that test with removed menus? With only the fvwm menu: fvwm-menu-desktop --get-menus all --verbose Parameters for creating menu list: XDG_MENU_PREFIX: '' --install-prefix: '' --desktop:'' --menu-type: '' Start search ... found in /home/dom/.config/menus: [] found in /etc/xdg/menus: ['fvwm-applications.menu'] Menu list: ['/etc/xdg/menus/fvwm-applications.menu'] Previous used theme: gnome Current used theme: gnome /etc/xdg/menus/fvwm-applications.menu Process took 31.5769798756 seconds Without any menu: fvwm-menu-desktop --get-menus all --verbose Parameters for creating menu list: XDG_MENU_PREFIX: '' --install-prefix: '' --desktop:'' --menu-type: '' Start search ... found in /home/dom/.config/menus: [] found in /etc/xdg/menus: [] Menu list: [] .menu not available on this system. Exiting... whether all menus on place? Yes, that just that locale issue. It may come from the suse menu that collide with my fvwm menu. The fvwm menu is using the localisation from the files in /usr/share/desktop
[Announce] fvwm-xdg-menu
Hi all, I am working on a xdg application menu for use with fvwm and fvwm-menu-desktop. Currently, about 90 % of the menu structure is implemented, which means it is already very usable and better than the default xdg application menu that come with any wm/desktop (at the exception of fvwm-crystal). You can find it here: https://github.com/domichel/fvwm-xdg-menu Any comment, bug report, etc. are welcome. Dominique
Re: [Announce] fvwm-xdg-menu
Le Wed, 23 Apr 2014 22:10:45 +0200, Dominique Michel dominique.mic...@vtxnet.ch a écrit : Hi all, I am working on a xdg application menu for use with fvwm and fvwm-menu-desktop. The menu structure is 100% done, which give 135 category files!: Currently, about 90 % of the menu structure is implemented, which means it is already very usable and better than the default xdg application menu that come with any wm/desktop (at the exception of fvwm-crystal). You can find it here: https://github.com/domichel/fvwm-xdg-menu Any comment, bug report, etc. are welcome. What is left now is to find some nice icon theme. But I doubt any existing theme will have icons for all these categories. Dominique
Re: fvwm-menu-desktop locale strangeness
Le Sun, 13 Apr 2014 20:13:45 +0200, Thomas Funk t.f...@web.de a écrit : Am 13.04.2014 17:31, schrieb Dominique Michel: Hi, with fvwm-crystal, I get an issue with a localized xdg menu. If I launch fvwm as a Xephyr session and use its default configuration (no config file), I get a very simple menu where it is a Desktop Menu. If I click on it, I get an applications menu with several menus in it: Fvwm Applications Suse Applications Xfce Applications Xfce Settings Manager which correspond to what I have in /etc/xdg/menus. The Fvwm Applications menu is my localized menu. If I browse it, only parts of it are localized, and other parts are not when the localization exist in /usr/share/directories. I made the following function: DestroyMenu FvwmMenu AddToMenu FvwmMenu + DynamicPopupAction PipeRead 'fvwm-menu-desktop \ --desktop fvwm-applications \ --enable-mini-icons \ --mini-icon-dir $[FVWM_USERDIR]/icons/fvwm-desktop' Try this: DestroyMenu FvwmMenu AddToMenu FvwmMenu + DynamicPopupAction PipeRead 'fvwm-menu-desktop \ --desktop fvwm \ --type applications \ --enable-mini-icons \ --mini-icon-dir $[FVWM_USERDIR]/icons/fvwm-desktop' I get: Warning: Arg --type is obsolete and ignored, but the menu work fine. I only get the fvwm menu and the localization is coKey A A $[Mod1] Menu FvwmMenurrect. Do you know if it is possible to get ride of the Regenerate the XDG menu? I find nothing in the doc, so I don't think it is possible without a awk or sed function. because --desktop defines not the menu name. fvwm-menu-desktop assemble the menu name from the desktop type and the menu type. Key A A $[Mod1] Menu FvwmMenu With it, I get only the fvwm-applications menu, and it is entirely localized (the part which are already done, it's a work in progress). After that, I removed all the files in /etc/xdg/menus but fvwm-applications.menu, and after launching fvwm, I get an error instead of the menu: # fvwm-menu-desktop Traceback (most recent call last): File /usr/bin/fvwm-menu-desktop, line 634, in module main() File /usr/bin/fvwm-menu-desktop, line 232, in main menulist, desktop_temp = getmenulist(desktop, menu_type) File /usr/bin/fvwm-menu-desktop, line 400, in getmenulist desktop_dict[de_highest].add(menu) KeyError: 'xfce' What is strange is I don't have any xfce key into the menu. I try with Would you please post the output of $ fvwm-menu-desktop --version fvwm-menu-desktop version 2.3.1 and $ fvwm-menu-desktop --get-menus all --verbose That look OK to me. All is here: Parameters for creating menu list: XDG_MENU_PREFIX: '' --install-prefix: '' --desktop:'' --menu-type: '' Start search ... found in /home/dom/.config/menus: [] found in /etc/xdg/menus: ['fvwm-applications.menu', 'yast-settings.menu', 'lxde-applications.menu', 'xfce-applications.menu', 'ggz.menu', 'kde-4-applications.menu', 'gnome-applications.menu', 'suse-applications.menu', 'xfce-settings-manager.menu'] Menu list: ['/etc/xdg/menus/fvwm-applications.menu', '/etc/xdg/menus/yast-settings.menu', '/etc/xdg/menus/lxde-applications.menu', '/etc/xdg/menus/xfce-applications.menu', '/etc/xdg/menus/ggz.menu', '/etc/xdg/menus/kde-4-applications.menu', '/etc/xdg/menus/gnome-applications.menu', '/etc/xdg/menus/suse-applications.menu', '/etc/xdg/menus/xfce-settings-manager.menu'] Previous used theme: gnome Current used theme: gnome Create submenu 'FvwmFvwm Applications' from '/etc/xdg/menus/fvwm-applications.menu' Create submenu 'FvwmYast Settings' from '/etc/xdg/menus/yast-settings.menu' Menu is empty - won't be used! Create submenu 'FvwmLxde Applications' from '/etc/xdg/menus/lxde-applications.menu' Create submenu 'FvwmXfce Applications' from '/etc/xdg/menus/xfce-applications.menu' Create submenu 'FvwmGgz' from '/etc/xdg/menus/ggz.menu' Menu is empty - won't be used! Create submenu 'FvwmKde 4 Applications' from '/etc/xdg/menus/kde-4-applications.menu' Create submenu 'FvwmGnome Applications' from '/etc/xdg/menus/gnome-applications.menu' Create submenu 'FvwmSuse Applications' from '/etc/xdg/menus/suse-applications.menu' Create submenu 'FvwmXfce Settings Manager' from '/etc/xdg/menus/xfce-settings-manager.menu' /etc/xdg/menus/fvwm-applications.menu /etc/xdg/menus/lxde-applications.menu /etc/xdg/menus/xfce-applications.menu /etc/xdg/menus/kde-4-applications.menu /etc/xdg/menus/gnome-applications.menu /etc/xdg/menus/suse-applications.menu /etc/xdg/menus/xfce-settings-manager.menu Process took 36.1115701199 seconds whether all menus on place? Yes, that just that locale issue. It may come from the suse menu that collide with my fvwm menu. The fvwm menu is using the localisation from the files in /usr/share/desktop-directories, when the suse menu was using files in /usr/share/locale. The suse menu with that localization system just hang fvwm-menu-desktop
Re: fvwm-menu-desktop locale strangeness
Le Thu, 17 Apr 2014 09:06:52 -0400, des...@verizon.net (Dan.Espen) a écrit : Am 13.04.2014 17:31, schrieb Dominique Michel: Do you know if it is possible to get ride of the Regenerate the XDG menu? I find nothing in the doc, so I don't think it is possible without a awk or sed function. The menu does not update when applications are added, so there is no option for removing the entry. It is the same into fvwm-crystal, but the option to recreate it is into the preferences. I just automatized it, it compare the date of some files at startup/restart and update the menu when needed. For now my first concern is to finish my fvwm-applications xdg menu. About 2/3 is done. Maybe later I will include it in fvwm-crystal in parallel with its existing menu system, but with another key binding. Dominique
fvwm-menu-desktop locale strangeness
Hi, with fvwm-crystal, I get an issue with a localized xdg menu. If I launch fvwm as a Xephyr session and use its default configuration (no config file), I get a very simple menu where it is a Desktop Menu. If I click on it, I get an applications menu with several menus in it: Fvwm Applications Suse Applications Xfce Applications Xfce Settings Manager which correspond to what I have in /etc/xdg/menus. The Fvwm Applications menu is my localized menu. If I browse it, only parts of it are localized, and other parts are not when the localization exist in /usr/share/directories. I made the following function: DestroyMenu FvwmMenu AddToMenu FvwmMenu + DynamicPopupAction PipeRead 'fvwm-menu-desktop \ --desktop fvwm-applications \ --enable-mini-icons \ --mini-icon-dir $[FVWM_USERDIR]/icons/fvwm-desktop' Key A A $[Mod1] Menu FvwmMenu With it, I get only the fvwm-applications menu, and it is entirely localized (the part which are already done, it's a work in progress). After that, I removed all the files in /etc/xdg/menus but fvwm-applications.menu, and after launching fvwm, I get an error instead of the menu: # fvwm-menu-desktop Traceback (most recent call last): File /usr/bin/fvwm-menu-desktop, line 634, in module main() File /usr/bin/fvwm-menu-desktop, line 232, in main menulist, desktop_temp = getmenulist(desktop, menu_type) File /usr/bin/fvwm-menu-desktop, line 400, in getmenulist desktop_dict[de_highest].add(menu) KeyError: 'xfce' What is strange is I don't have any xfce key into the menu. I try with # XDG_MENU_PREFIX=fvwm fvwm-menu-desktop and it work fine. It should be nice fvwm if fvwm-menu-desktop would be able to use by default a fvwm-applications.menu if it exist and is the only one in /etc/xdg/menus. I made another try, to issue 'SetEnv XDG_MENU_PREFIX fvwm' into the fvwm console in crystal, and with it, it work when I launch fvwm with Xephyr, that even if I move back the other menu files. So, to summarize, it should be nice fvwm if fvwm-menu-desktop would be able to use by default a fvwm-applications.menu if it exist and is the only one in /etc/xdg/menus. And without XDG_MENU_PREFIX defined and its default fvwm configuration (no fvwm config file at all), fvwm-menu-desktop localization seam to be confused when it is several menus in /etc/xdg/menus with different localizations or non localizations. Best, Dominique
New French translation
Here is a new French translation. fvwm.po is an almost full rewrite, many strings was wrong. As pooedit was insisting to use utf-8, I edited the other po files as well. Other translations are already in utf-8. At the same time, I added the missing strings into FvwmScript.po. Dominique fvwm-tmp.tar.bz2 Description: application/bzip
Re: A few issues with fvwm-desktop-config.fpl and fvwm-menu-desktop
Le Tue, 25 Feb 2014 22:24:51 +0100, Thomas Funk t.f...@web.de a écrit : On 02/25/2014 07:35 PM, Thomas Funk wrote: On 02/25/2014 05:16 PM, Dominique Michel wrote: Hi, I get a few issues with fvwm-desktop-config.fpl. [... snip ...] The file formats that cause these warnings are .bmp, .gif, .ico, .jpg, .pcx, .ppm and .tga so far. It should be better to convert all of them into a format that is know to fvwm. Something like convert other options name.ext name.png can be used. Yes, only svg icons will be changed to png. All others as is. Will fix it. Fixed. I still have a problem with the cannonsmash icon. It is a .ico file, with 4 images into it, and convert convert one file by image and name them cannonsmash-[0-3].png. It is the same issue with fvwm-crystal, which also use convert. I didn't get the time to look if it is possible to tell convert to output only one file with the wanted name, so I made a quick workaround for now. It check if it is a file with name some_name-0.png after the conversion, and if yes rename it to some_name.png. It add a little overhead, but not much. The conversion time is much bigger. Linux have a very poor support for animated files. Only the gif with a very limited number of picture viewers, apng only with firefox, and no multiple images ico, maybe with firefox, I didn't try. And with fvwm, we can made nice 2 or 3 pictures icons with buttons. Dominique - Thomas -
names in auto generated menus
Hi all and happy new year!
In FVWM-Crystal, the media menu use auto generated menus for the
playlist and to play individual files.
1) it is a preference dialog where the users can tell Crystal where
their audio and video files are, and write them into a file.
2) from that file, a script generate the menu call into another file.
It use fvwm-directory.
At that time, mine look like this:
DestroyFunc FuncFvwmMenuMovieDirectory
AddToFunc FuncFvwmMenuMovieDirectory
+ I PipeRead 'case \'$0\' in \
/home/alian/Vídeos*) myexec=fvwm-crystal.mplayer-wrapper file
dom;;
/media/Toshiba_External_USB_3.0_20130324040598-1/Backup/Vidéos*)
myexec=fvwm-crystal.mplayer-wrapper file dom;; /home/dom/Vídeos*)
myexec=fvwm-crystal.mplayer-wrapper file dom;;
/home/dom/Descargas*) myexec=fvwm-crystal.mplayer-wrapper file
dom;;/media/cdrom*) myexec=fvwm-crystal.mplayer-wrapper file
dom;; \ esac; \ fvwm-menu-directory --icon-title
22x22/categories/directory.png \ --func=FuncFvwmMenuMovieDirectory
\ --exec-file ^${myexec} --dir \'$0\''
DestroyMenu /Music/LoadMovie
AddToMenu /Music/LoadMovie
+ MissingSubmenuFunction FuncFvwmMenuMovieDirectory
+ '%22x22/categories/video_movies_view.png%$[gt.Browse Medias]'
Popup /home/alian/Vídeos
+ '%22x22/categories/video_movies_view.png%$[gt.Browse Medias]'
Popup /media/Toshiba_External_USB_3.0_20130324040598-1/Backup/Vidéos
+ '%22x22/categories/video_movies_view.png%$[gt.Browse Medias]'
Popup /home/dom/Vídeos
+ '%22x22/categories/video_movies_view.png%$[gt.Browse Medias]'
Popup /home/dom/Descargas
+ '%22x22/categories/video_movies_view.png%$[gt.Browse DVD]'
Popup /media/cdrom
4) that file is read by fvwm
As it is here, it work fine. As soon I add things like
--exec-title ^fvwm-crystal.play-movies or icons into the Piperead
like in Taviso function, fvwm get confused and it fail to open some of
the directories in the Descargas folder and to show the files into them.
It seam like file and directory names with characters like {} or ()
into their names confuse very easily fvwm. At the beginning, I was
thinking it was fvwm-menu-directory that get confused by them, but
after running the same command into a console, it appear the menu
generated by it is correct in any cases. So the issue is in fvwm itself.
I know such characters must be avoided into file names, but they are
broadly used on the internet.
Dominique
Re: names in auto generated menus
Le Fri, 3 Jan 2014 15:07:52 +0100,
Dominique Michel dominique.mic...@vtxnet.ch a écrit :
Hi all and happy new year!
In FVWM-Crystal, the media menu use auto generated menus for the
playlist and to play individual files.
1) it is a preference dialog where the users can tell Crystal where
their audio and video files are, and write them into a file.
2) from that file, a script generate the menu call into another file.
It use fvwm-directory.
At that time, mine look like this:
DestroyFunc FuncFvwmMenuMovieDirectory
AddToFunc FuncFvwmMenuMovieDirectory
+ I PipeRead 'case \'$0\' in \
/home/alian/Vídeos*) myexec=fvwm-crystal.mplayer-wrapper file
dom;;
/media/Toshiba_External_USB_3.0_20130324040598-1/Backup/Vidéos*)
myexec=fvwm-crystal.mplayer-wrapper file dom;; /home/dom/Vídeos*)
myexec=fvwm-crystal.mplayer-wrapper file dom;;
/home/dom/Descargas*) myexec=fvwm-crystal.mplayer-wrapper file
dom;;/media/cdrom*) myexec=fvwm-crystal.mplayer-wrapper file
dom;; \ esac; \ fvwm-menu-directory --icon-title
22x22/categories/directory.png \
--func=FuncFvwmMenuMovieDirectory \ --exec-file ^${myexec} --dir
\'$0\''
DestroyMenu /Music/LoadMovie
AddToMenu /Music/LoadMovie
+ MissingSubmenuFunction FuncFvwmMenuMovieDirectory
+ '%22x22/categories/video_movies_view.png%$[gt.Browse Medias]'
Popup /home/alian/Vídeos
+ '%22x22/categories/video_movies_view.png%$[gt.Browse Medias]'
Popup /media/Toshiba_External_USB_3.0_20130324040598-1/Backup/Vidéos
+ '%22x22/categories/video_movies_view.png%$[gt.Browse Medias]'
Popup /home/dom/Vídeos
+ '%22x22/categories/video_movies_view.png%$[gt.Browse Medias]'
Popup /home/dom/Descargas
+ '%22x22/categories/video_movies_view.png%$[gt.Browse DVD]'
Popup /media/cdrom
4) that file is read by fvwm
As it is here, it work fine. As soon I add things like
--exec-title ^fvwm-crystal.play-movies or icons into the Piperead
like in Taviso function, fvwm get confused and it fail to open some of
the directories in the Descargas folder and to show the files into
them.
It seam like file and directory names with characters like {} or ()
into their names confuse very easily fvwm. At the beginning, I was
thinking it was fvwm-menu-directory that get confused by them, but
after running the same command into a console, it appear the menu
generated by it is correct in any cases. So the issue is in fvwm
itself.
Here is a version that file with some directory names:
DestroyFunc FuncFvwmMenuMovieDirectory
AddToFunc FuncFvwmMenuMovieDirectory
+ I PipeRead 'case \'$0\' in \
/home/alian/Vídeos*) myexec=fvwm-crystal.mplayer-wrapper file
dom;;
/media/Toshiba_External_USB_3.0_20130324040598-1/Backup/Vidéos*)
myexec=fvwm-crystal.mplayer-wrapper file dom;;
/home/dom/Vídeos*) myexec=fvwm-crystal.mplayer-wrapper file dom;;
/home/dom/Descargas*) myexec=fvwm-crystal.mplayer-wrapper
file dom;;
/media/cdrom*) myexec=fvwm-crystal.mplayer-wrapper file dom;; \
esac; \
fvwm-menu-directory --icon-title 22x22/categories/directory.png \
--icon-file 22x22/categories/Audio-Video.png \
--icon-dir 22x22/categories/video_movies_view.png \
--func=FuncFvwmMenuMovieDirectory \
--exec-file ^${myexec} --dir \'$0\' --exec-title
^fvwm-crystal.play-movies'
DestroyMenu /Music/LoadMovie
AddToMenu /Music/LoadMovie
+ MissingSubmenuFunction FuncFvwmMenuMovieDirectory
+ '%22x22/categories/video_movies_view.png%$[gt.Browse Medias]'
Popup /home/alian/Vídeos
+ '%22x22/categories/video_movies_view.png%$[gt.Browse Medias]'
Popup /media/Toshiba_External_USB_3.0_20130324040598-1/Backup/Vidéos
+ '%22x22/categories/video_movies_view.png%$[gt.Browse Medias]'
Popup /home/dom/Vídeos
+ '%22x22/categories/video_movies_view.png%$[gt.Browse Medias]'
Popup /home/dom/Descargas
+ '%22x22/categories/video_movies_view.png%$[gt.Browse DVD]'
Popup /media/cdrom
I know such characters must be avoided into file names, but they are
broadly used on the internet.
Dominique
Re: names in auto generated menus
Le Fri, 03 Jan 2014 10:34:24 -0500,
Dan Espen des...@verizon.net a écrit :
Dominique Michel dominique.mic...@vtxnet.ch writes:
Le Fri, 3 Jan 2014 15:07:52 +0100,
Dominique Michel dominique.mic...@vtxnet.ch a écrit :
It seam like file and directory names with characters like {} or ()
into their names confuse very easily fvwm. At the beginning, I was
thinking it was fvwm-menu-directory that get confused by them, but
after running the same command into a console, it appear the menu
generated by it is correct in any cases. So the issue is in fvwm
itself.
Sorry, I've read your post twice and still don't understand.
Please send a single fvwm command that doesn't work as you expect.
A resumed fvwm code that fail is:
DestroyFunc FuncFvwmMenuMovieDirectory
AddToFunc FuncFvwmMenuMovieDirectory
+ I PipeRead 'case \$0\ in \
/home/alian/Vídeos*) myexec=fvwm-crystal.mplayer-wrapper file dom;;
\
esac; \
test -f \$0\/.icontitle.png mytitle=\$0\/.icontitle.png; \
test -f \$0\/.media.png mypng=\$0\/.media.png; \
fvwm-menu-directory --icon-title
${mytitle:-22x22/categories/directory.png} \
--icon-file ${mypng:-22x22/categories/Audio-Video.png} \
--func=FuncFvwmMenuMovieDirectory \
--exec-file ^${myexec} --dir \$0\
--exec-title=^fvwm-crystal.play-movies \$0\'
This generate:
DestroyMenu recreate /home/alian/Vídeos
AddToMenu /home/alian/Vídeos
+ DynamicPopDownAction DestroyMenu /home/alian/Vídeos
+ MissingSubmenuFunction FuncFvwmMenuMovieDirectory
+ %22x22/categories/directory.png%/home/alian/Vídeos Exec cd
/home/alian/Vídeos; fvwm-crystal.play-movies /home/alian/Vídeos
+ Nop
+ Musiques Popup /home/alian/Vídeos/Musiques item +100 c
This is called by:
DestroyMenu /Music/LoadMovie
AddToMenu /Music/LoadMovie
+ MissingSubmenuFunction FuncFvwmMenuMovieDirectory
+ '%22x22/categories/video_movies_view.png%$[gt.Browse Medias]'
Popup /home/alian/Vídeos
Popup /Music/LoadMovie
The menu pop up, the 4 subdirs are here, but for the
Paco de Lucia directory, I see only its title and cannot navigate
further into it:
# ls -R /home/alian/Vídeos/Musiques
/home/alian/Vídeos/Musiques:
Français Madonna Paco de Lucia Santana
/home/alian/Vídeos/Musiques/Français:
Plume Latraverse _ Belle et Bum.avi
/home/alian/Vídeos/Musiques/Madonna:
05 _ Madonna _ Re_Invention Tour _ June 16 2004 _ American Life.avi
Madonna _ American Life _Version 1 _ withdrawn__HQ no logo_.vob
Madonna._.American.Life.vob
Madonna._._American.Life_.MV._Uncensured_.vob
/home/alian/Vídeos/Musiques/Paco de Lucia:
Paco De Lucia _ Concierto De Aranjuez _Spanish Kvcd_ By Waydansar.mpg
Video _ Paco de Lucia _ Rumba.mpg
/home/alian/Vídeos/Musiques/Santana:
Carlos Santana _ Live In Mexico _Concerto Video Sacred Fire.mpg Carlos
Santana _ Soul Sacrifice _Live in Woodstock_.mpg
Jeff Beck_ Carlos Santana_ Steve Lukather et Jan Hammer _ Karuizawa
Live.mpg
--
Note the spanish í in Vídeos, and the spaces into Paco de Lucia.
For my own music, I run a script that fixes the file names.
I do the same, but only for the special characters. It is no point to
have utf-8 file systems and not use them. That's funny, because fvwm
can handle Chinese characters inside this menu, but not a well
known Spanish name like Paco de Lucia.
Also, with the 2 precedent versions (second mail), one work better but
is not perfect, the only one that work fine is the one without icons and
without exec-title command.
For me this is a bug into fvwm. It took me a very long time, trying
different sorts of quoting, to figure that fvwm-menu-directory seam to
work fine in all cases, and that by removing all the icons and the
exec-title command, it work fine. So, this is not an issue with the
file or directory names.
As a workaround, I done a preference in fvwm-crystal that let the user
to choose if they want or not the icons and the exec-title command.
Dominique
container in FvwmScript
Is it possible to have a container in a FvwmScript. By it I mean a script with a lot of widgets and a scroll bar at the right of the script that will scroll the widgets? If yes, is it an example of such a script somewhere? Regards, Dominique
Re: Another key binding issue
Le Sat, 21 Dec 2013 03:11:06 +0100, Dominik Vogt dominik.v...@gmx.de a écrit : On Sat, Dec 21, 2013 at 01:20:16AM +0100, Dominique Michel wrote: [snip] But if I want to remove it only when a window of class Ardour have the focus and I run Key B A M Music-Next Key (Ardour) B W M - it do nothing and Alt+B call Music-Next in any case, even when Ardour have the focus. That's not the way removing bindings works. You can only remove a binding completely or not at all. It's not possible to partially remove a binding just for selected windows. I try the same thing with the name, class and resource of an urxvt term with the same result: the binding is not removed when the window have the focus. That does not work and was never intended to work. There is some obscure feature in the binding code that instructs fvwm to pass a keystroke to the underlying window if there is a binding with the action -- (without the quotes), but on one hand the code has a bug (i.e. it does not work), and even if the bug is fixed, I see no way how it could work. It doesn't work. So, I must think about some kind of bindings editor. Maybe next year. -- Thanks for the in-deep explanation: Fvwm intercepts the defined key bindings on _all_ windows because otherwise key bindings on unfocused windows might not work (PointerKey command). Now, there _is_ code that detects that fvwm got a key press event on a window for which it has no binding, but then the damage is already done. events.c:__handle_key() makes a feeble attempt to pass the intercepted key event to the window that may or may not work. The normal sequence of events a window gets is KeyPress (non-synthetic) KeyRelease (non-synthetic) With the undone interception it gets FocusOut (NotifyAncestor) KeyPress (synthetic) FocusOut (NotifyPointer) FocusIn (NotifyAncestor) KeymapNotify (non-synthetic) KeyRelease (synthetic) So, on one hand the window gets synthetic events which some or maybe even many applications refure to handle, and on the other hand the KeyPress arrives during the grab, while the window has lost the focus. There's nothing we can do about the synthetic events, and I cannot think of a way to terminate a passiv grab early, i.e. before the grabbed key is released. If there was such a way, then the window would get the FocusIn evens _before_ the synthetic KeyPress which should improve the chance that the application actually uses the KeyPress. I can think only of one way to really fix this. We'd have to re-grab all bindings on all windows (1) whenever the focus changes (Focus... events or fvwm sets focus) and (2) whenever the pointer crosses any window borders (including unmanaged windows) (i.e. EnterNotify and LeaveNotify events). However, for remote servers on slow connections this would be _slow_ (including dead modifiers a complex fvwm configuration may have hundreds or thousands of grabs per window). To sum it up: At the moment I've no idea how this can be fixed. Ciao Dominik ^_^ ^_^
Another key binding issue
Now I have another key binding issue. If I have an assigned binding with: Key B A M Music-Next It call the function Music-Next when I press Alt+B. That work fine. If I remove it with Key B A M - That work fine too, Alt+B is doing nothing, and when in Ardour I can use Alt+B to fire and close its big clock. But if I want to remove it only when a window of class Ardour have the focus and I run Key B A M Music-Next Key (Ardour) B W M - it do nothing and Alt+B call Music-Next in any case, even when Ardour have the focus. I try the same thing with the name, class and resource of an urxvt term with the same result: the binding is not removed when the window have the focus. Same result with Key (Ardour) B A M - Also, I try with fvwm-2.6.5, and the problem is different, I must use function , the binding is removed when in Ardour, but Ardour's own function is not restored. This was working in 2007: https://mail.gna.org/public/fvwm-crystal-users/2007-03/msg6.html Dominique
To remove a key binding fail with -
Hi, In fvwm man page: 31.6.5. Key Key [(window)] Keyname Context Modifiers Function Binds a keyboard key to a specified fvwm command, or removes the binding if Function is '-'. If I have ardour running, its class is Ardour, I get the following into the fvwm console: Key (Ardour) B W M ToggleFail [fvwm][__execute_function]: ERROR No such command 'ToggleFail' # The ToggleFail function doesn't exist Key (Ardour) B W M - [fvwm][__execute_function]: ERROR No such command 'ToggleFail' # To remove the binding fail, but the following work: Key (Ardour) B W M More strange is the following sequence: Key (Ardour) B W M ToggleFail [fvwm][__execute_function]: ERROR No such command 'ToggleFail' Key (Ardour) B W M ToggleWork [fvwm][__execute_function]: ERROR No such command 'ToggleWork' Key (Ardour) B W M - [fvwm][__execute_function]: ERROR No such command 'ToggleFail' Key (Ardour) B W M - [fvwm][__execute_function]: ERROR No such command 'ToggleFail' Key (Ardour) B W M # work Cheers, Dominique
Re: To remove a key binding fail with -
Le Wed, 18 Dec 2013 12:52:59 +0100, Dominique Michel dominique.mic...@vtxnet.ch a écrit : Hi, In fvwm man page: 31.6.5. Key Key [(window)] Keyname Context Modifiers Function Binds a keyboard key to a specified fvwm command, or removes the binding if Function is '-'. If I have ardour running, its class is Ardour, I get the following into the fvwm console: Key (Ardour) B W M ToggleFail Maybe I was not clear enough. When ardour have the focus and I press Alt+B, I get the following: [fvwm][__execute_function]: ERROR No such command 'ToggleFail' That imply the binding work fine. # The ToggleFail function doesn't exist Key (Ardour) B W M - Idem, that imply the binding was not removed: [fvwm][__execute_function]: ERROR No such command 'ToggleFail' # To remove the binding fail, but the following work: Key (Ardour) B W M More strange is the following sequence: Key (Ardour) B W M ToggleFail The binding work: [fvwm][__execute_function]: ERROR No such command 'ToggleFail' Key (Ardour) B W M ToggleWork The new binding work: [fvwm][__execute_function]: ERROR No such command 'ToggleWork' Key (Ardour) B W M - The binding was not removed, but put back to its preceding state: [fvwm][__execute_function]: ERROR No such command 'ToggleFail' The way to remove a binding as stated into the man page doesn't work: Key (Ardour) B W M - [fvwm][__execute_function]: ERROR No such command 'ToggleFail' The only way to remove a binding: Key (Ardour) B W M # work Cheers, Dominique
Re: To remove a key binding fail with -
Le Wed, 18 Dec 2013 23:05:23 +0100, Dominik Vogt dominik.v...@gmx.de a écrit : On Wed, Dec 18, 2013 at 10:47:59PM +0100, Dominique Michel wrote: Le Wed, 18 Dec 2013 12:52:59 +0100, Dominique Michel dominique.mic...@vtxnet.ch a écrit : 31.6.5. Key Key [(window)] Keyname Context Modifiers Function Binds a keyboard key to a specified fvwm command, or removes the binding if Function is '-'. If I have ardour running, its class is Ardour, I get the following into the fvwm console: Key (Ardour) B W M ToggleFail Maybe I was not clear enough. When ardour have the focus and I press Alt+B, I get the following: [fvwm][__execute_function]: ERROR No such command 'ToggleFail' ... I can see that soething is amiss with the binding removal code, but I cannot reproduce your specific problem. Could you please make a minimal config file that shows this behaviour? That will be hard, my minimal config is fvwm-crystal. I will think about what I can do to simplify it. Binding removal was working it was a few years ago inside fvwm-crystal, so maybe I can find a clue about which commit changed it. But it will take a lot of time, and I don't have much time these days. Ciao, Dominique Ciao Dominik ^_^ ^_^
Re: FvwmScript - WriteToFile seems not working
Le Sat, 14 Dec 2013 00:34:38 +0100,
Thomas Funk t.f...@web.de a écrit :
Dan Espen wrote:
Thomas Funk t.f...@web.de writes:
Hi!
I'm working on a composite configurator with FvwmScript and
getting an issue with WriteToFile command. It only writes '#end'
into the file.
First I thought I've done something wrong but I do the same as in
FvwmScript-BaseConfig. So I started a test with
FvwmScript-BaseConfig and the same happens. Used FVWM is 2.6.5.
This happens under Fedora 19, too.
My next thought was something has changed in WriteToFile source
since creation of FvwmScript-BaseConfig - 2007-08-07. So I
compared the code from 2.5.22 and CVS but nothing has changed.
So, what could be the problem?
We'd probably have to see the script but you could always resort to
adding printfs in Instructions.c.
Start with determining if it gets NbArg right.
Just seeing #end is an indication that it doesn't
see the args after the filename.
I have checked different VMs with different FVWM versions with
FvwmScript-BaseConfig:
Debian 4.x (2007) with FVWM 2.5.22 - ok, creates full config
Debian 6.x (2011) with FVWM 2.6.0 - ok, creates full config
Debian 7.1 (2013) with FVWM 2.6.6 - ok, creates full config
Debian 7.1 (2013) with FVWM 2.6.5 - ok, creates full config
Debian 8 (testing, 2013) with FVWM 2.6.5 - nok, creates '#end'
Fedora 19 (2013) with FVWM 2.6.5 - nok, creates '#end'
Dominique Michel wrote:
I get the same issue yesterday.
This is with fvwm-2.6.6 from cvs and gentoo.
So, it seems it's not a script problem.
Therefore I've starting your suggestion with 'printfs' in
instructions.c under my Fedora VM. I used this FvwmScript with one
WriteToFile:
#WindowTitle {Test WriteToFile}
#WindowSize 470 415# Taille
#
#Init
#Begin
#Set $userDir = (GetOutput {echo $FVWM_USERDIR} 1 -1)
#Set $configPath = $userDir{/bla}
#
#WriteToFile $configPath {This is a test}
#Quit
#End
As I didn't knew what you meant with 'printfs' I used printf first
and hoped that output went into .xsession-errors. No output appeared
but WriteToFile worked. So I removed printf and compiled code
suddenly worked!
Same code, different behaviors...
Therefore I did the same on my Debian 8 system and the compiled
version of FvwmScript works also.
Under Debian 8 and Fedora 19 I have distribution packages installed.
All others are self compiled.
Could it be a problem of code optimization? Because the FvwmScript
executables has huge different sizes:
package: 380K
compiled: 1,5M
The only thing that not fit in this to theory is Dominiques issue
because his code is self compiled, too ...
My ebuild is the same than the one in gentoo. I modified it to use the
cvs and to be able some patches, but I don't apply them, so the code is
the one from the cvs.
The cflags are a little bit extensive, that was to be able to cross
compile in my tower and be sure to get a consistent result, but the
tower is dead now. The only ones that doesn't are for the processor are
-O2 -pipe and they should be sure:
CFLAGS=-march=amdfam10 -mcx16 -msahf -mpopcnt -mabm --param
l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=512 -mtune=amdfam10 -O2 -pipe
CFLAGS_amd64=-m64
CXXFLAGS=-march=amdfam10 -mcx16 -msahf -mpopcnt -mabm --param
l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=512 -mtune=amdfam10 -O2 -pipe
LDFLAGS=-Wl,-O1 -Wl,--as-needed
LDFLAGS_amd64=-m elf_x86_64
The ebuild append -fno-strict-aliasing to the cflags.
The result with my configure USE flags is:
fvwm --version
fvwm 2.6.6 (from cvs) compiled on Oct 27 2013 at 16:48:42
with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm,
SM, Bidi text, XRender, XCursor, XFT, NLS
The size of FvwmScript executable is around 400.6k here.
Dominque
- Thomas -
Re: FvwmScript - WriteToFile seems not working
Le Wed, 11 Dec 2013 20:29:22 +0100, Thomas Funk t.f...@web.de a écrit : Hi! I'm working on a composite configurator with FvwmScript and getting an issue with WriteToFile command. It only writes '#end' into the file. I get the same issue yesterday. I use a Piperead for now. The script is here: http://sourceforge.net/p/fvwm-crystal/code/HEAD/tree/fvwm/scripts/PrefVars/PrefVars The commented out WriteToFile is into Widget 23. This is with fvwm-2.6.6 from cvs and gentoo. Dominique First I thought I've done something wrong but I do the same as in FvwmScript-BaseConfig. So I started a test with FvwmScript-BaseConfig and the same happens. Used FVWM is 2.6.5. This happens under Fedora 19, too. My next thought was something has changed in WriteToFile source since creation of FvwmScript-BaseConfig - 2007-08-07. So I compared the code from 2.5.22 and CVS but nothing has changed. So, what could be the problem? - Thomas -
Re: Language patch?
Le Wed, 07 Aug 2013 21:00:40 -0400, Dan Espen des...@verizon.net a écrit : If I remember right, there was an fvwm language patch posted for French? that I never applied. Please repost or provide a link. I'll try to apply it this time. I replied to the original thread, I thing this is why the last version was lost. No matter, here it is. Cheers, Dominique -- We have the heroes we deserve. --- fvwm/po/fvwm.fr.po.orig 2012-08-24 03:17:43.0 +0200 +++ fvwm/po/fvwm.fr.po 2013-07-23 00:15:49.0 +0200 @@ -8,14 +8,14 @@ msgstr Project-Id-Version: fvwm\n POT-Creation-Date: 2002-11-28 14:23+0100\n -PO-Revision-Date: 2002-11-23 06:00+0100\n -Last-Translator: Olivier Chapuis olivier.chap...@free.fr\n +PO-Revision-Date: 2013-07-23 00:15+0100\n +Last-Translator: Dominique Michel dominique.mic...@users.sourceforge.net\n Language-Team: French\n -Language: \n MIME-Version: 1.0\n Content-Type: text/plain; charset=ISO-8859-15\n Content-Transfer-Encoding: 8bit\n Plural-Forms: nplurals=2; plural=(n 1);\n +X-Generator: Poedit 1.5.5\n #: ../fvwm/fvwm.c:1362 msgid Builtin Menu @@ -319,3 +319,168 @@ #. ./modules/FvwmForm/FvwmForm-Setup.in: line 55 msgid Copy Config File(s) msgstr Copier les Fichiers + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 51 +msgid Fvwm Menu Desktop Config +msgstr Configuration de Fvwm Menu Desktop + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 58 +msgid Multiple Menu +msgstr Menu multiple + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 66 +msgid Menus in +msgstr Menus dans + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 95 +msgid No menus found! Check why from within a terminal with +msgstr Pas de menu trouvé ! Depuis un terminal, contrôlez pourquoi avec + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 107 +msgid General Options +msgstr Options générales + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 110 +msgid Use Icons in Menus? +msgstr Avec icônes dans les menus? + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 112 +msgid Yes +msgstr Oui + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 113 +msgid No +msgstr Non + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 116 +msgid Icon size: +msgstr Taille d'icône : + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 118 +msgid (in pixels. Default is 24) +msgstr (en pixels. Valeur par défaut 24) + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 121 +msgid Converted Icon directory: +msgstr Dossier des icônes: + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 123 +msgid (Directory for converted icons) +msgstr (Répertoire pour les icônes converties) + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 126 +msgid Use Titles in Menus? +msgstr Avec titres dans les menus? + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 132 +msgid Insert Menu(s) in a Menu? +msgstr Menu(s) dans un menu? + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 136 +msgid Top title name: +msgstr Nom du titre principal: + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 140 +msgid Used Icon theme: +msgstr Thème d'icônes à utiliser: + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 142 +msgid (Theme name for icon selection) +msgstr (Nom du thème pour le choix des icônes) + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 149 +msgid Single Menu +msgstr Menu simple + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 152 +msgid If you want a single menu only deselect all menus above and fill out +msgstr +Si vous voulez un menu unique, désélectionner tous les menus ci-dessus et +remplissez + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 154 +msgid +the fields below. But remember, if the menu doesn't exist, nothing happens. +msgstr +les champs ci-dessous. Mais rappelez-vous, si le menu n'existe pas, rien ne +se passe. + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 158 +msgid Menu Top Title: +msgstr Titre principal du menu : + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 147 +msgid (Eg. FvwmTestMenu) +msgstr (Ex. FvwmTestMenu) + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 160 +msgid Install-Prefix: +msgstr Préfixe d'installation : + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 165 +msgid (Eg. /etc/xdg/menus/) +msgstr (Ex. /etc/xdg/menus/) + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 168 +msgid Desktop: +msgstr Bureau : + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 170 +msgid (Eg. gnome, kde, xfce, lxde) +msgstr (Ex. gnome, kde, xfce, lxde) + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 173 +msgid Menutype: +msgstr Type de menu : + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 175 +msgid (Eg. applications, settings) +msgstr (Ex. applications, réglages) + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 178 +msgid Output path: +msgstr Chemin de sortie : + +#. ./bin/fvwm-menu-desktop-config.fpl.in: line 180 +msgid (Full path to store output) +msgstr (Chemin complêt du fichier de
Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization
Le Mon, 17 Jun 2013 00:55:55 +0200, Thomas Funk t.f...@web.de a écrit : Dominique Michel wrote: @Dominique: Would you update the french translation file, please? It is join. As it works now can you change your translation to fit the french text in fvwm-menu-desktop-config.fpl so that is all in the correct places? Because the spaces behind the text moves the elements like check boxes and text fields in the correct positions. Perhaps you have to reduce some text parts a little bit. A new version is joined. Dominique -- We have the heroes we deserve. # French translations for fvwm package # Traduction anglaise du package fvwm. # Copyright (C) 2002 fvwm workers # This file is distributed under the same license as the fvwm package. # Olivier Chapuis olivier.chap...@free.fr, 2002. # msgid msgstr Project-Id-Version: fvwm\n POT-Creation-Date: 2002-11-28 14:23+0100\n PO-Revision-Date: 2013-07-23 00:15+0100\n Last-Translator: Dominique Michel dominique.mic...@users.sourceforge.net\n Language-Team: French\n MIME-Version: 1.0\n Content-Type: text/plain; charset=ISO-8859-15\n Content-Transfer-Encoding: 8bit\n Plural-Forms: nplurals=2; plural=(n 1);\n X-Generator: Poedit 1.5.5\n #: ../fvwm/fvwm.c:1362 msgid Builtin Menu msgstr Menu Interne #: ../fvwm/fvwm.c:1365 msgid Setup Form msgstr Configuration avec Form #: ../fvwm/fvwm.c:1368 msgid Setup 95 Script msgstr Configuration avec Script95 #: ../fvwm/fvwm.c:1371 msgid Issue fvwm commands msgstr Executer des commandes fvwm #: ../fvwm/fvwm.c:1374 ../modules/FvwmForm/FvwmForm-Setup.in: line 66 msgid Restart fvwm msgstr Redémarrer fvwm #: ../fvwm/fvwm.c:1375 msgid Exit fvwm msgstr Quitter fvwm #: ../fvwm/expand.c:255 ../fvwm/virtual.c:2042 msgid Desk msgstr Bureau #: ../fvwm/windowlist.c:94 ../fvwm/windowlist.c:100 ../fvwm/windowlist.c:107 msgid \tGeometry msgstr \tGéometrie #: ../fvwm/windowlist.c:105 #, c-format msgid Desk: %d%s msgstr Bureau: %d%s #: ../fvwm/menus.c:1674 msgid More... msgstr Plus... #. ./fvwm/ConfigFvwmSetup: line 91 msgid Root Menu msgstr Menu Principal #. ./fvwm/ConfigFvwmSetup: line 95 msgid Remote Logins msgstr Login à distance #. #-#-#-#-# duplicate #-#-#-#-# #. ./fvwm/ConfigFvwmSetup: line 97 #. #-#-#-#-# duplicate #-#-#-#-# #. ./fvwm/ConfigFvwmSetup: line 109 msgid Utilities msgstr Utilitaires #. #-#-#-#-# duplicate #-#-#-#-# #. ./fvwm/ConfigFvwmSetup: line 99 #. #-#-#-#-# duplicate #-#-#-#-# #. ./fvwm/ConfigFvwmSetup: line 194 msgid Fvwm Modules msgstr Modules de Fvwm #. ./fvwm/ConfigFvwmSetup: line 100 msgid Fvwm Window Ops msgstr Opérations sur les fenêtres #. #-#-#-#-# duplicate #-#-#-#-# #. ./fvwm/ConfigFvwmSetup: line 101 #. #-#-#-#-# duplicate #-#-#-#-# #. ./fvwm/ConfigFvwmSetup: line 124 msgid Fvwm Config Ops msgstr Opérations de config #. ./fvwm/ConfigFvwmSetup: line 103 msgid Refresh Screen msgstr Raffraîchir l'écran #. ./fvwm/ConfigFvwmSetup: line 104 msgid Recapture Screen msgstr Recapturer l'écran #. ./fvwm/ConfigFvwmSetup: line 106 msgid Exit Fvwm msgstr Quitter fvwm #. ./fvwm/ConfigFvwmSetup: line 121 msgid Reset X defaults msgstr Rétablir les défauts de X #. ./fvwm/ConfigFvwmSetup: line 125 msgid Sloppy Focus msgstr Focus fluide #. ./fvwm/ConfigFvwmSetup: line 126 msgid Click To Focus msgstr Cliquer pour le Focus #. ./fvwm/ConfigFvwmSetup: line 127 msgid Focus Follows Mouse msgstr Le Focus suit la souris #. ./fvwm/ConfigFvwmSetup: line 129 msgid Colormap Follows Mouse msgstr La Colormap suit la souris #. ./fvwm/ConfigFvwmSetup: line 130 msgid Colormap Follows Focus msgstr La Colormap suit le Focus #. ./fvwm/ConfigFvwmSetup: line 132 msgid Full Paging ON msgstr Pagination complète activée #. ./fvwm/ConfigFvwmSetup: line 133 msgid All Paging OFF msgstr Toute Pagination désactivée #. ./fvwm/ConfigFvwmSetup: line 134 msgid Horizontal Paging Only msgstr Pagination horizontale seulement #. ./fvwm/ConfigFvwmSetup: line 135 msgid Vertical Paging Only msgstr Pagination verticale seulement #. ./fvwm/ConfigFvwmSetup: line 136 msgid Partial Paging msgstr Pagination partielle #. ./fvwm/ConfigFvwmSetup: line 137 msgid Full Paging Edge Wrap msgstr Pagination complète Bord électrique #. ./fvwm/ConfigFvwmSetup: line 144 msgid Move msgstr Déplacer #. ./fvwm/ConfigFvwmSetup: line 145 msgid Resize msgstr Redimensionner #. ./fvwm/ConfigFvwmSetup: line 146 msgid Raise msgstr En avant #. ./fvwm/ConfigFvwmSetup: line 147 msgid Lower msgstr En arrière #. ./fvwm/ConfigFvwmSetup: line 148 msgid (De)Iconify msgstr (De)Minimiser #. ./fvwm/ConfigFvwmSetup: line 149 msgid (Un)Stick msgstr (De)Fixer #. ./fvwm/ConfigFvwmSetup: line 150 msgid (Un)Maximize msgstr (De)Maximiser #. ./fvwm/ConfigFvwmSetup: line 152 msgid Delete msgstr Quitter #. ./fvwm/ConfigFvwmSetup: line 153 msgid Close msgstr Fermer #. ./fvwm/ConfigFvwmSetup: line 154 msgid Destroy msgstr Bruler #. ./fvwm/ConfigFvwmSetup: line 161 msgid Window Ops msgstr Opérations sur les fenêtres #. ./fvwm/ConfigFvwmSetup: line 163
Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization
Le Tue, 18 Jun 2013 14:41:31 +0200, Thomas Funk t.funk...@googlemail.com a écrit : 2013/6/18 Dominique Michel dominique.mic...@vtxnet.ch Le Mon, 17 Jun 2013 21:24:28 +0200, Thomas Funk t.f...@web.de a écrit : Dominique Michel wrote: Portage doesn't give rej file. I used patch -p0 fvwm-menu-desktop-config.fpl.gettext.patch to get it. Perhaps Portage isn't up-to-date with CVS? No, its my own live ebuild which download or update the last CVS code, and do the compilation and installation from this code. It is several month ago I made it and never get in trouble with it. Ah, that's the point: ' ... several months ago ...'. The fpl file I used to diff was several months old. Therefore no rejection. Gentoo is a source based distribution. That imply portage doesn't need tarballs and can also install directly from a code repository. I made the ebuild it was several months ago, but the ebuild download the code from the CVS at its first call, and update it with the last code from the CVS with each subsequent call. This is the point of a live ebuild: - to install a program from its source code repository with the last version of the code. It is scripts in portage for that, called eclass. They can be used used by the ebuilds for cvs, git, svn, ..., any kind of repository. In an overlay like the pro-audio one (the equivalent of multiple repositories with the binary based distributions - in gentoo this is just an ebuild (scripts) collection), it is a lot of such live ebuilds, and the only issue we get with them is, sometime we must update them when upstream change their build system or the dependencies. I am sure I have the last code. Last time I ran it for fwvm, I see that portage downloaded the last files committed to the CVS. They was your last patches from this thread. BTW, I took a lock at the files in /etc/xdg/menus. They doesn't support the freedesktop additional categories. The freedesktop guys are amazing, they write a norm and don't respect it. Or I missed something, but the result is the generated menus in Fvwm-NightShade only use the main categories, which is a mess when you have a lot of apps in one category. Hmmm, sounds strange to me. I will test it on my Xubuntu VM whether this happens there also. On my Mint I have sub categories in the menus, so ... I think some distributions can provide their own files in /etc/xdg/menus, when gentoo policy is generally to not interfere with what upstream provide. A notable exception to that is gentoo eudev fork of udev, which is mature now, but that's another subject... The easiest way is to log in into KDE/Gnome/Xfce session and have a look in their menus. They build them from /etc/xdg/menus/, too. I get the same menus than in NightShade. That confirm this is an upstream issue and that some distributions improve these menus, and others not. And it is more, a lot of applications are missing. I guess this is why kde provide an utility to find and add them into its menu. As example, I didn't get alsaplayer in any of these menus, when alsaplayer do provide, and install, a compliant alsaplayer.desktop file. In consequence, the whole xdg menu thing is completely broken from the root, it have always been, and this have nothing to do with fvwm-menu-desktop. Cheers, Dominique Ciao, Thomas -- We have the heroes we deserve.
Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization
Le Tue, 18 Jun 2013 16:06:50 +0200, Dominique Michel dominique.mic...@vtxnet.ch a écrit : Le Tue, 18 Jun 2013 14:41:31 +0200, Thomas Funk t.funk...@googlemail.com a écrit : 2013/6/18 Dominique Michel dominique.mic...@vtxnet.ch Le Mon, 17 Jun 2013 21:24:28 +0200, Thomas Funk t.f...@web.de a écrit : Dominique Michel wrote: Portage doesn't give rej file. I used patch -p0 fvwm-menu-desktop-config.fpl.gettext.patch to get it. Perhaps Portage isn't up-to-date with CVS? No, its my own live ebuild which download or update the last CVS code, and do the compilation and installation from this code. It is several month ago I made it and never get in trouble with it. Ah, that's the point: ' ... several months ago ...'. The fpl file I used to diff was several months old. Therefore no rejection. Gentoo is a source based distribution. That imply portage doesn't need tarballs and can also install directly from a code repository. I made the ebuild it was several months ago, but the ebuild download the code from the CVS at its first call, and update it with the last code from the CVS with each subsequent call. This is the point of a live ebuild: - to install a program from its source code repository with the last version of the code. It is scripts in portage for that, called eclass. They can be used used by the ebuilds for cvs, git, svn, ..., any kind of repository. In an overlay like the pro-audio one (the equivalent of multiple repositories with the binary based distributions - in gentoo this is just an ebuild (scripts) collection), it is a lot of such live ebuilds, and the only issue we get with them is, sometime we must update them when upstream change their build system or the dependencies. I am sure I have the last code. Last time I ran it for fwvm, I see that portage downloaded the last files committed to the CVS. They was your last patches from this thread. BTW, I took a lock at the files in /etc/xdg/menus. They doesn't support the freedesktop additional categories. The freedesktop guys are amazing, they write a norm and don't respect it. Or I missed something, but the result is the generated menus in Fvwm-NightShade only use the main categories, which is a mess when you have a lot of apps in one category. Hmmm, sounds strange to me. I will test it on my Xubuntu VM whether this happens there also. On my Mint I have sub categories in the menus, so ... I think some distributions can provide their own files in /etc/xdg/menus, when gentoo policy is generally to not interfere with what upstream provide. A notable exception to that is gentoo eudev fork of udev, which is mature now, but that's another subject... The easiest way is to log in into KDE/Gnome/Xfce session and have a look in their menus. They build them from /etc/xdg/menus/, too. I get the same menus than in NightShade. That confirm this is an upstream issue and that some distributions improve these menus, and others not. And it is more, a lot of applications are missing. I guess this is why kde provide an utility to find and add them into its menu. As example, I didn't get alsaplayer in any of these menus, when alsaplayer do provide, and install, a compliant alsaplayer.desktop file. I just see it is not installed. I must search why. In consequence, the whole xdg menu thing is completely broken from the root, it have always been, and this have nothing to do with fvwm-menu-desktop. Well, the additional categories are broken. And this is mess. Cheers, Dominique Ciao, Thomas -- We have the heroes we deserve.
Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization
Le Tue, 18 Jun 2013 16:46:21 +0200, Thomas Funk t.funk...@googlemail.com a écrit : 2013/6/18 Dominique Michel dominique.mic...@vtxnet.ch Gentoo is a source based distribution. That imply portage doesn't need tarballs and can also install directly from a code repository. I made the ebuild it was several months ago, but the ebuild download the code from the CVS at its first call, and update it with the last code from the CVS with each subsequent call. This is the point of a live ebuild: - to install a program from its source code repository with the last version of the code. It is scripts in portage for that, called eclass. They can be used used by the ebuilds for cvs, git, svn, ..., any kind of repository. In an overlay like the pro-audio one (the equivalent of multiple repositories with the binary based distributions - in gentoo this is just an ebuild (scripts) collection), it is a lot of such live ebuilds, and the only issue we get with them is, sometime we must update them when upstream change their build system or the dependencies. I am sure I have the last code. Last time I ran it for fwvm, I see that portage downloaded the last files committed to the CVS. They was your last patches from this thread. Ah, ok I understand. I haven't used Gentoo anytime. I think this portage feature is one of the reasons why many gentoo users are developers. The first time install is very time consuming, but after, you get a continuous update process, and will never need to reinstall the whole distribution, that even with a many years old installation. BTW, I took a lock at the files in /etc/xdg/menus. They doesn't support the freedesktop additional categories. The freedesktop guys are amazing, they write a norm and don't respect it. Or I missed something, but the result is the generated menus in Fvwm-NightShade only use the main categories, which is a mess when you have a lot of apps in one category. Hmmm, sounds strange to me. I will test it on my Xubuntu VM whether this happens there also. On my Mint I have sub categories in the menus, so ... I think some distributions can provide their own files in /etc/xdg/menus, when gentoo policy is generally to not interfere with what upstream provide. A notable exception to that is gentoo eudev fork of udev, which is mature now, but that's another subject... The easiest way is to log in into KDE/Gnome/Xfce session and have a look in their menus. They build them from /etc/xdg/menus/, too. I get the same menus than in NightShade. That confirm this is an upstream issue and that some distributions improve these menus, and others not. And it is more, a lot of applications are missing. I guess this is why kde provide an utility to find and add them into its menu. As example, I didn't get alsaplayer in any of these menus, when alsaplayer do provide, and install, a compliant alsaplayer.desktop file. I just see it is not installed. I must search why. In consequence, the whole xdg menu thing is completely broken from the root, it have always been, and this have nothing to do with fvwm-menu-desktop. Well, the additional categories are broken. And this is mess. Yes, if it so, then it is a big mess :( It is the main reason why I begun to use Fvwm-Crystal it was a few years ago. To made its menu system to be FreeDesktop compliant, inclusive the additional categories, was one of the first things I made. It doesn't care about the files into /etc/xdg/menus, but use directly the desktop files, that to add only the missing menu entries and icons into Fvwm-Crystal applications database. Which can be tailored independently by the user. Btw. you have listed in a last mail your menu files: $ ls -R /etc/xdg/menus /etc/xdg/menus: applications-merged kde-information.menu xfce-applications.menu gnome-applications.menu lxde-applications.menuxfce-settings-manager.menu kde-4-applications.menu lxlauncher-applications.menu Did you have activated all checkboxes in fvwm-menu-desktop-config.fpl? Sometimes you find sub menus in menus where you haven't think about. Yes, but I don't get the additional categories in any of them. I can send you these files, or to the list, if someone want to look at the differences. Ciao, Dominique Cheers, Thomas -- We have the heroes we deserve.
Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization
Le Sat, 15 Jun 2013 21:08:25 +0200,
Thomas Funk t.f...@web.de a écrit :
Hi Dan!
attached are some patches to fix the following:
fvwm-menu-desktop:
- fix problem with python-xdg versions 0.19 (Dominique reported this
some days ago)
- localization support for gettext - 'Regenerate XDG menu(s)'
fvwm-menu-desktop-config.fpl:
- localization support for gettext
- add query to check if no menus found - message occur
PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch
'/var/lib/layman/test/x11-wm/fvwm/files/fvwm-menu-desktop-config.fpl.gettext.patch'
==
checking file bin/fvwm-menu-desktop-config.fpl
Hunk #2 FAILED at 48.
Hunk #3 succeeded at 205 (offset 16 lines).
Hunk #4 FAILED at 225.
2 out of 4 hunks FAILED
I included the rej file. It is against the svn of today.
fvwm.pot:
- update to support translations for fvwm-menu-desktop and
fvwm-menu-desktop-config.fpl
fvwm.de.po:
- update of the German translation
The other patches are working fine. But I still doesn't get anything
into Fvwm-Nightshade menu configurator:
cut: champs et positions sont numérotés à partir de 1
which mean
cut: fields and positions are numbered from 1
@Dominique:
Would you update the french translation file, please?
It is join.
Best,
Dominique
--
We have the heroes we deserve.
--- fvwm-menu-desktop-config.fpl.in 2012-07-28 20:20:30.0 +0200
+++ fvwm-menu-desktop-config.fpl 2013-06-15 17:41:33.654376217 +0200
@@ -48,130 +48,159 @@
my $fvwmform_commands =
DestroyModuleConfig ${modname}: *
-*${modname}: Title \Fvwm Menu Desktop Config\
+*${modname}: Title \\$[gt.Fvwm Menu Desktop Config]\
*${modname}: WarpPointer
*${modname}: Line center
-*${modname}: Text \Fvwm Menu Desktop Config\
+*${modname}: Text \\$[gt.Fvwm Menu Desktop Config]\
+*${modname}: Line
+*${modname}: Separator
*${modname}: Line center
-*${modname}: Text \-- Multiple Menu --\
+*${modname}: Text \\$[gt.Multiple Menu]\
*${modname}: Line
;
-foreach my $key (sort( keys %all_menus)) {
-$fvwmform_commands .=
-*${modname}: Line left
-*${modname}: Text \Menus in $key\
-*${modname}: Line left
-*${modname}: Selection meth multiple
-;
-my $m_count = 0;
-foreach my $count (sort(keys %{$all_menus{$key}})) {
-my @menu = @{$all_menus{$key}{$count}};
-my $newstring = $menu[0] . ' ' x eval($max_length-length($menu[0]));
-$fvwmform_commands .= *${modname}: Choice $menu[1] $menu[1] $menu[2] \$newstring\
- ;
- $m_count++;
- if ($m_count == 3) {
- $fvwmform_commands .=
- *${modname}: Line left
- *${modname}: Selection meth multiple
- ;
- $m_count = 0;
+if (scalar keys %all_menus != 0) {
+ foreach my $key (sort( keys %all_menus)) {
+ $fvwmform_commands .=
+ *${modname}: Line left
+ *${modname}: Text \\$[gt.Menus in]\
+ *${modname}: Text \ $key\
+ *${modname}: Line left
+ *${modname}: Selection meth multiple
+ ;
+ my $m_count = 0;
+ foreach my $count (sort(keys %{$all_menus{$key}})) {
+ my @menu = @{$all_menus{$key}{$count}};
+ my $newstring = $menu[0] . ' ' x eval($max_length-length($menu[0]));
+ $fvwmform_commands .= *${modname}: Choice $menu[1] $menu[1] $menu[2] \$newstring\
+ ;
+ $m_count++;
+ if ($m_count == 3) {
+$fvwmform_commands .=
+ *${modname}: Line left
+ *${modname}: Selection meth multiple
+;
+$m_count = 0;
+ }
+ }
+ $fvwmform_commands .=
+ *${modname}: Line left
+ *${modname}: Text \ \
+ ;
}
-}
-$fvwmform_commands .=
-*${modname}: Line left
-*${modname}: Text \ \
-;
+}
+else {
+ $fvwmform_commands .=
+ *${modname}: Line center
+ *${modname}: Text\\$[gt.No menus found! Check why from within a terminal with]\
+ *${modname}: Line center
+ *${modname}: Text\'fvwm-menu-desktop -v'\
+ *${modname}: Line left
+ *${modname}: Text \ \
+ ;
}
$fvwmform_commands .=
+*${modname}: Line
+*${modname}: Separator
*${modname}: Line center
-*${modname}: Text \-- General Options --\
+*${modname}: Text \\$[gt.General Options]\
*${modname}: Line
*${modname}: Line Left
-*${modname}: Text \Use Icons in Menus? \
+*${modname}: Text \\$[gt.Use Icons in Menus? ]\
*${modname}: SelectionSelItype single
-*${modname}: Choice IconsOn IconsOnon \Yes\
-*${modname}: Choice IconsOff IconsOff off \No\
+*${modname}: Choice IconsOn IconsOnon \\$[gt.Yes]\
+*${modname}: Choice IconsOff IconsOff off \\$[gt.No]\
*${modname}: Line left
-*${modname}: Text \Icon size:\
+*${modname}: Text \\$[gt.Icon size:]\
*${modname}: Input Size 2 \\
-*${modname}: Text \ (in pixels. Default is 24)
+*${modname}: Text \\$[gt. (in pixels. Default is 24)]\
+
+*${modname}: Line left
+*${modname}: Text \\$[gt.Converted Icon
Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization
Le Sun, 16 Jun 2013 23:10:04 +0200, Dominique Michel dominique.mic...@vtxnet.ch a écrit : Le Sat, 15 Jun 2013 21:08:25 +0200, Thomas Funk t.f...@web.de a écrit : Hi Dan! attached are some patches to fix the following: fvwm-menu-desktop: - fix problem with python-xdg versions 0.19 (Dominique reported this some days ago) - localization support for gettext - 'Regenerate XDG menu(s)' fvwm-menu-desktop-config.fpl: - localization support for gettext - add query to check if no menus found - message occur PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch '/var/lib/layman/test/x11-wm/fvwm/files/fvwm-menu-desktop-config.fpl.gettext.patch' == checking file bin/fvwm-menu-desktop-config.fpl Hunk #2 FAILED at 48. Hunk #3 succeeded at 205 (offset 16 lines). Hunk #4 FAILED at 225. 2 out of 4 hunks FAILED I included the rej file. It is against the svn of today. fvwm.pot: - update to support translations for fvwm-menu-desktop and fvwm-menu-desktop-config.fpl fvwm.de.po: - update of the German translation The other patches are working fine. But I still doesn't get anything into Fvwm-Nightshade menu configurator: cut: champs et positions sont numérotés à partir de 1 which mean cut: fields and positions are numbered from 1 Forget it. After removing ~/.fvwm-nightshade, it work. @Dominique: Would you update the french translation file, please? It is join. Best, Dominique -- We have the heroes we deserve.
Re: Patches for fvwm-menu-desktop to support py-xdg 0.19 and localization
Le Mon, 17 Jun 2013 00:23:41 +0200, Thomas Funk t.f...@web.de a écrit : Dominique Michel wrote: PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch '/var/lib/layman/test/x11-wm/fvwm/files/fvwm-menu-desktop-config.fpl.gettext.patch' == checking file bin/fvwm-menu-desktop-config.fpl Hunk #2 FAILED at 48. Hunk #3 succeeded at 205 (offset 16 lines). Hunk #4 FAILED at 225. 2 out of 4 hunks FAILED I included the rej file. It is against the svn of today. Portage doesn't give rej file. I used patch -p0 fvwm-menu-desktop-config.fpl.gettext.patch to get it. I used your patch command and it worked on my machine with the latest CVS update. But I copied fvwm-menu-desktop-config.fpl.in together with the patch into a temp directory: tf@t61:/media/daten/shared/sourcen/Fvwm/temp$ patch -p1 -g0 -E --no-backup-if-mismatch fvwm-menu-desktop-config.fpl.gettext.patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |--- ../cvs/fvwm/bin/fvwm-menu-desktop-config.fpl.in2012-07-28 20:20:30.0 +0200 |+++ fvwm-menu-desktop-config.fpl 2013-06-15 17:41:33.654376217 +0200 -- File to patch: ./fvwm-menu-desktop-config.fpl.in patching file ./fvwm-menu-desktop-config.fpl.in Also with the simpler command patch -p0: tf@t61:/media/daten/shared/sourcen/Fvwm/temp$ patch -p0 fvwm-menu-desktop-config.fpl.in fvwm-menu-desktop-config.fpl.gettext.patch patching file fvwm-menu-desktop-config.fpl.in I get the same result with your command. That's strange. I know portage want patch generated with diff -u Maybe this have to do not with portage, but with the patch version in gentoo. Akso, to get portage to work with the other patches, it was needed to edit them and remove the ../cvs in the path. It don't want relative path. If I diffing my version with the patched one no differences occur on both patch tries. fvwm.pot: - update to support translations for fvwm-menu-desktop and fvwm-menu-desktop-config.fpl fvwm.de.po: - update of the German translation The other patches are working fine. But I still doesn't get anything into Fvwm-Nightshade menu configurator: cut: champs et positions sont numérotés à partir de 1 which mean cut: fields and positions are numbered from 1 What does fvwm-menu-desktop -v prints out? Also --version? I tested the changed fvwm-menu-desktop on Xubuntu 13.04 which use python-xdg 0.25 and on my Mint LMDE which uses 0.19. What is your default Python version? Type 'python' in a terminal to start the interactive python console. It is important that it is 2.x because fvwm-menu-desktop isn't usable with Python 3.x. It work know. I removed ~/.fbwm-nightshade. Maybe something get screwed when it was not working. The .menu file was existing but was empty. Also, the default python version doesn't matter much on gentoo, because portage adjust the shebangs of all python files in its sandbox, that for them to use the correct version. It also install wrapper scripts sometime. It is a big mess when writing ebuilds, and a mess that change all the time, but the result work fine. BTW, I took a lock at the files in /etc/xdg/menus. They doesn't support the freedesktop additional categories. The freedesktop guys are amazing, they write a norm and don't respect it. Or I missed something, but the result is the generated menus in Fvwm-NightShade only use the main categories, which is a mess when you have a lot of apps in one category. Cheers, Dominique @Dominique: Would you update the french translation file, please? It is join. Thanks :) Thomas -- We have the heroes we deserve.
Re: Something fishy with State in 2.6.5
Le Tue, 28 May 2013 17:18:48 -0400, gau...@math.cmu.edu a écrit : Dear All, I'm having trouble testing State in Fvwm 2.6.5. Here is code that was working in Fvwm 2.5.30: SetEnv FVWM_WS_DECOR 2 DestroyFunc DecorateToggle AddToFunc DecorateToggle + I ThisWindow (State $[FVWM_WS_DECOR]) UnDecorate + I TestRc (NoMatch) ThisWindow Decorate DestroyFunc Decorate AddToFunc Decorate + I State $[FVWM_WS_DECOR] True + I WindowStyle State $[...] + I WindowStyle !NoTitle DestroyFunc UnDecorate AddToFunc UnDecorate + I State $[FVWM_WS_DECOR] False + I WindowStyle !State $[...] This is what I use in such cases. Dominique + I WindowStyle NoTitle Now Current DecorateToggle would happily toggle decorations of the Current window. This worked perfectly in 2.5.30 and prior versions. However, when I upgraded my Debian box recently, it stopped working in 2.6.5. (I also interject many Current or ThisWindow commands into the above with no success.) Any ideas? I Googled Fvwm State 2.6.5 etc. without posting, but didn't have much luck. Thanks, GI -- We have the heroes we deserve.
Re: Strange charset issue
Le Sun, 19 May 2013 01:01:14 +0200, Dominique Michel dominique.mic...@vtxnet.ch a écrit : With the following DestroyModuleConfig Téléchargements: * *Téléchargements: Font xft:Verdana:pixelsize=18:Regular *Téléchargements: (1x1+0+0) Module FvwmButtons Téléchargements I get: [Téléchargements][FlocaleGetFontSet]: (fixed) Missing font charsets: ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7, ISO8859-9, ISO8859-13, ISO8859-14, ISO8859-15, JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0, ISO10646-1 With DestroyModuleConfig Telechargements: * *Telechargements: Font xft:Verdana:pixelsize=18:Regular *Telechargements: (1x1+0+0) Module FvwmButtons Telechargements I didn't get any error messages. To use Telechargement instead of Téléchargement is not an option because it is, as Vidéos that create the same error, localized strings from xdg-user-dirs-update in (file ~/.config/user-dirs.dirs Is it something I can do, or is it a bug in FvwmButtons? It is another and very annoying issue with that. I use it into a function that check /proc/mounts and the different XDG_USERDIRS, and create corresponding icons on the desktop. Those icons serve to launch Thunar. I begun to create a function that check for changes in /proc/mounts and will update those icons accordingly when needed. The easiest way would have to kill all those buttons and recreate them. If I issue something like KillModule FvwmButtons /* they don't get all killed because those with non ascii characters did survive. They even survive when killing them with their full name: KillModule FvwmButtons /home/dom/Vidéos KillModule /* or KillModule /home/dom/Vidéos fail to kill them too. I didn't find another way to kill them than a restart. Dominique Dominique -- We have the heroes we deserve.
Strange charset issue
With the following DestroyModuleConfig Téléchargements: * *Téléchargements: Font xft:Verdana:pixelsize=18:Regular *Téléchargements: (1x1+0+0) Module FvwmButtons Téléchargements I get: [Téléchargements][FlocaleGetFontSet]: (fixed) Missing font charsets: ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7, ISO8859-9, ISO8859-13, ISO8859-14, ISO8859-15, JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0, ISO10646-1 With DestroyModuleConfig Telechargements: * *Telechargements: Font xft:Verdana:pixelsize=18:Regular *Telechargements: (1x1+0+0) Module FvwmButtons Telechargements I didn't get any error messages. To use Telechargement instead of Téléchargement is not an option because it is, as Vidéos that create the same error, localized strings from xdg-user-dirs-update in (file ~/.config/user-dirs.dirs Is it something I can do, or is it a bug in FvwmButtons? Dominique -- We have the heroes we deserve.
Re: FvwmScript, UseGettext and LocalePath
Le Sun, 5 May 2013 18:24:39 +0200, Dominique Michel dominique.mic...@vtxnet.ch a écrit : Le Sun, 05 May 2013 14:56:53 +0200, Thomas Funk t.f...@web.de a écrit : Dominique Michel wrote: https://sourceforge.net/p/fvwm-crystal/code/HEAD/tree/fvwm/scripts/FontSelector/FontSelector A little remark to your script to reduce code you can use for loops to assign your font to the widgets: For $Widget=1 To 6 Do It look like my script have another and much bigger problem. It was working fine yesterday, but it just crash at startup today. It I move the ChangeTitle and ShowWidget stuffs from Init to the Periodic section, I cannot reproduce this bug, even after restarting the machine. That also seam to imply that Fvwm must have some kind of internal cache that keep stuff from a previous run of this script. How can I be sure this cache is cleaned without to restart the machine? Dominique -- We have the heroes we deserve.
Re: FvwmScript, UseGettext and LocalePath
Le Mon, 06 May 2013 09:43:07 -0400, Dan Espen des...@verizon.net a écrit : Dominique Michel dominique.mic...@vtxnet.ch writes: Le Sun, 5 May 2013 18:24:39 +0200, Dominique Michel dominique.mic...@vtxnet.ch a écrit : Le Sun, 05 May 2013 14:56:53 +0200, Thomas Funk t.f...@web.de a écrit : Dominique Michel wrote: https://sourceforge.net/p/fvwm-crystal/code/HEAD/tree/fvwm/scripts/FontSelector/FontSelector A little remark to your script to reduce code you can use for loops to assign your font to the widgets: For $Widget=1 To 6 Do It look like my script have another and much bigger problem. It was working fine yesterday, but it just crash at startup today. It I move the ChangeTitle and ShowWidget stuffs from Init to the Periodic section, I cannot reproduce this bug, even after restarting the machine. That also seam to imply that Fvwm must have some kind of internal cache that keep stuff from a previous run of this script. How can I be sure this cache is cleaned without to restart the machine? I don't think there is any cache. If you have a crash, you need to examine the core file. That's very strange because I cannot reproduce it any more. And I don't find any core file. I must set ulimit -c to something else than 0. Also, I was doing a system update yesterday, and I did purged the old files only now. This should not be a problem, but who knows exactly what can append into such complex systems... Another pointer is I didn't get any report of such a crash, and the last time it was a problem with Fvwm-Crystal, a few peoples was very fast to report it. I think I will wait and see. Dominique -- We have the heroes we deserve.
Re: FvwmScript, UseGettext and LocalePath
Le Sun, 05 May 2013 01:35:32 +0200,
Thomas Funk t.f...@web.de a écrit :
It does, but the string in FvwmScript have to be quoted in FvwmScript
quotes:
UseGettext
{$FVWM_USERDIR/locale;fvwm-crystal:$FVWM_SYSTEMDIR/locale;fvwm-crystal:+}
Great, that work fine.
My Font statement was confusing me:
Fontxft:$[panel_font]:size=16:$[panel_font_style]
It is instead of {}. With that, widgets like ItemDraw or CheckBox
are OK. With all other statements I try, they get shortened and the
text cam get cut in those widgets.
Another strange font issue is, whatever I try, only the font size is
applied correctly with that statement, as well with the Font in the
Init section. But Font changes are applied integrally into in further
sections.
https://sourceforge.net/p/fvwm-crystal/code/HEAD/tree/fvwm/scripts/FontSelector/FontSelector
Dominique
--
We have the heroes we deserve.
Re: FvwmScript, UseGettext and LocalePath
Le Sun, 05 May 2013 14:56:53 +0200,
Thomas Funk t.f...@web.de a écrit :
Dominique Michel wrote:
Le Sun, 05 May 2013 01:35:32 +0200,
Thomas Funk t.f...@web.de a écrit :
It does, but the string in FvwmScript have to be quoted in
FvwmScript quotes:
UseGettext
{$FVWM_USERDIR/locale;fvwm-crystal:$FVWM_SYSTEMDIR/locale;fvwm-crystal:+}
Great, that work fine.
You're welcome ^^
My Font statement was confusing me:
Fontxft:$[panel_font]:size=16:$[panel_font_style]
It is instead of {}. With that, widgets like ItemDraw or
CheckBox are OK. With all other statements I try, they get
shortened and the text cam get cut in those widgets.
It is interesting that this works in the header :)
Another strange font issue is, whatever I try, only the font size
is applied correctly with that statement, as well with the Font in
the Init section. But Font changes are applied integrally into in
further sections.
I accustom oneself to use a temporarily variable for each command I
assigned to GetOutup because then I can see whether the command is
correct. For checking your problem do this:
Set $Cmd = {echo \$[panel_font]}
Do {echo Cmd panel_font: }$Cmd
Set $PanelFont = (GetOutput $Cmd 1 -1)
Set $Cmd = {echo \$[panel_font_size]}
Do {echo Cmd panel_font_size: }$Cmd
Set $PanelFontSize = (GetOutput $Cmd 1 -1)
Set $Cmd = {echo \$[panel_font_style]}
Do {echo Cmd panel_font_style: }$Cmd
Set $PanelFontStyle = (GetOutput $Cmd 1 -1)
Set $SelectorFont = {xft:}$PanelFont{:pixelsize=16:}$PanelFontStyle
Do {echo SelectorFont: }$SelectorFont
So you can see in .xsession-errors if your command looks fine.
It is what I have done. I removed them for the repository.
https://sourceforge.net/p/fvwm-crystal/code/HEAD/tree/fvwm/scripts/FontSelector/FontSelector
A little remark to your script
to reduce code you can use for loops to assign your font to the
widgets: For $Widget=1 To 6 Do
ChangeFont $Widget $SelectorFont
For $Widget=12 To 16 Do
ChangeFont $Widget $SelectorFont
Set $step = 10
Set $Widget = 20
While $step 80 Do
Begin
ChangeFont $Widget $SelectorFont
Set $Widget = (Add $Widget $step)
End
ChangeFont 71 $SelectorFont
ChangeFont 100 $SelectorFont
ChangeFont 101 $SelectorFont
ChangeFont 102 $SelectorFont
ChangeFont 121 $SelectorFont
ChangeFont 122 $SelectorFont
Thanks for the tip. It will be for the next release.
Best,
Dominique
--
We have the heroes we deserve.
FvwmScript, UseGettext and LocalePath
I try to get UseGettext to work with FvwmScript and Fvwm-Crystal.
From FvwmScript man page:
UseGettext [locale_path]
You can reset this catalog or add some catalogs exactly in the same
way than with the LocalePath fvwm command (see the fvwm manual
page).
In Fvwm-Crystal config, one of the first instruction is:
LocalePath
$[FVWM_USERDIR]/locale;fvwm-crystal:$[FVWM_SYSTEMDIR]/locale;fvwm-crystal:+
If I put exactly the same path in my FvwmScript
UseGettext
$[FVWM_USERDIR]/locale;fvwm-crystal:$[FVWM_SYSTEMDIR]/locale;fvwm-crystal:+
the script crash with a syntax error at that line:
UseGettext!
[/home/dom/.fvwm-crystal/scripts/FontSelector/FontSelector] Line 7:
syntax error
The beginning of the script:
# FvwmScript Font Selector
# A Font Selector for Fvwm-Crystal
# Copyright Dominique Michel dominique_li...@users.sourceforge.net
2013
# Released under the GNU GPL license v2 or later
# Header ̣{{{1
UseGettext
$[FVWM_USERDIR]/locale;fvwm-crystal:$[FVWM_SYSTEMDIR]/locale;fvwm-crystal:+
WindowLocaleTitle {FVWM-Crystal Font Selector}
Is it something I can do, or is it a bug?
This append with both 2.6.5 and the cvs.
Best,
Dominique
--
We have the heroes we deserve.
Re: Reproductible crash
Le Tue, 23 Apr 2013 12:57:38 +0100, Thomas Adam tho...@fvwm.org a écrit : On 23 April 2013 12:21, Dominique Michel dominique.mic...@vtxnet.ch wrote: It is the %i in TitleFormat that caused the crash. With other parameters, fvwm doesn't crash. I know, it is no icon defined for FvwmStalonePanel. But I don't know if you already know that fvwm can crash in such a situation. I'll be the judge of that. I can't reproduce this. I need a stacktrace from a corefile, or some other minimal means of reproducing your problem. I don't think you want it. gdb show me: Core was generated by `stalonetray --decorations none --parent-bg true --window-type dock --no-shrink'. Program terminated with signal 11, Segmentation fault. #0 0x7f2db920caeb in ?? () In fvwm log, it is: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server :1 after 5 requests (5 known processed) with 0 events remaining. XIO: fatal IO error 2 (No such file or directory) on X server :1 after 22 requests (22 known processed) with 0 events remaining. I think this is stalonetray that made fvwm to crash. I will report this to Roman Dubtsov. A single style entry of: Style * !Icon, TitleFormat %i Does not make FVWM crash. -- Thomas Adam -- We have the heroes we deserve.
Re: Reproductible crash
Le Tue, 23 Apr 2013 14:16:56 +0100,
Thomas Adam tho...@fvwm.org a écrit :
On 23 April 2013 14:13, Dominique Michel dominique.mic...@vtxnet.ch
wrote:
Le Tue, 23 Apr 2013 12:57:38 +0100,
Thomas Adam tho...@fvwm.org a écrit :
On 23 April 2013 12:21, Dominique Michel
dominique.mic...@vtxnet.ch wrote:
So how is FVWM taken out by this? FVWM isn't crashing from the
corefile you're showing here.
The whole backtrace for fvwm is as follow:
Thread 1 (LWP 32646):
#0 0x7f2db920caeb in ?? ()
No symbol table info available.
#1 0x in ?? ()
No symbol table info available
Doing the same for stalonetray show:
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need set solib-search-path or set sysroot?
Core was generated by `stalonetray --decorations none --parent-bg true
--window-type dock --no-shrink'. Program terminated with signal 11,
Segmentation fault. #0 XSync (dpy=0x0, discard=0)
at /var/tmp/portage/x11-libs/libX11-1.5.0-r2/work/libX11-1.5.0/src/Sync.c:42
42 /var/tmp/portage/x11-libs/libX11-1.5.0-r2/work/libX11-1.5.0/src/Sync.c:
Aucun fichier ou dossier de ce type.
Thread 1 (LWP 32646):
#0 XSync (dpy=0x0, discard=0)
at /var/tmp/portage/x11-libs/libX11-1.5.0-r2/work/libX11-1.5.0/src/Sync.c:42
rep = {type = 0 '\000', revertTo = 0 '\000', sequenceNumber = 0, length
= 0, focus = 0, pad1 = 0, pad2 = 0, pad3 = 0, pad4 = 3111012096, pad5 =
32557} #1 0x0040298a in ?? () No symbol table info available.
#2 0x7f2db8c45509 in __run_exit_handlers (status=-1,
listp=0x7f2db8fb45c8 __exit_funcs,
run_list_atexit=run_list_atexit@entry=true) at exit.c:77 atfct =
optimized out onfct = optimized out cxafct = optimized out f =
optimized out #3 0x7f2db8c45595 in __GI_exit (status=optimized
out) at exit.c:99 No locals.
#4 0x00403dec in ?? ()
No symbol table info available.
#5 0x7f2db8c2ec15 in __libc_start_main (main=0x403ce0, argc=17,
ubp_av=0x7fffbde7d918, init=optimized out, fini=optimized out,
rtld_fini=optimized out, stack_end=0x7fffbde7d908) at
libc-start.c:258 result = optimized out unwind_buf = {cancel_jmp_buf
= {{jmp_buf = {0, 754501913821412383, 4204480, 140736379476240, 0, 0,
-754356573086843873, -854567942409978849}, mask_was_saved = 0}}, priv =
{pad = {0x0, 0x0, 0x40cb20, 0x7fffbde7d918}, data = {prev = 0x0,
cleanup = 0x0, canceltype = 4246304}}} not_first_call = optimized out
#6 0x004027e9 in ?? () No symbol table info available. #7
0x7fffbde7d908 in ?? () No symbol table info available. #8
0x in ?? () No symbol table info available.
What look strange to me is Xsync that doesn't find a file at
/var/tmp/portage/x11-libs/libX11-1.5.0-r2/work/libX11-1.5.0/src/Sync.c
/var/tmp/portage/x11-libs/libX11-1.5.0-r2/work/libX11-1.5.0/ is the
location of the source when portage build libX11 before to install it.
So, maybe a gentoo specific bug.
-- Thomas Adam
--
We have the heroes we deserve.
Fvwm FAQ Q 5.5
This is about the FAQ Q 5.5 Why do NumLock, CapsLock and ScrollLock interfere with ClickToFocus and/or my mouse bindings? A new answer can be added. Fvwm-Crystal implement the 4 basic focus policies: Click to Focus or Enter to Focus combined with Raise or !Raise. To add FPFocusClickModifiers NA at the end of the focus related styles fixed the problems with NumLock. Without it, Numlock interfere not only on the Click to Focus styles (Amiga and MSWindow), but also on the Enter to Focus with Raise style (FVWM-Crystal with raise). Best, Dominique -- We have the heroes we deserve.
InfoStoreAdd return error when the variable is empty
I use imfostore for a variable that can have 2 values: 2/dev/null or . When I try to initialize it to , I get the following: InfoStoreAdd TestVariable [fvwm][CMD_InfoStore]: ERROR Bad arguments given. I don't know if it is a wanted behaviour. But or '' are not the same than a missing value. This it is not a problem for my use case, if I do the same with a space , it work fine. I use it as an extra parameter to functions that launch external software from the menus or buttons. That way, I can choose if I want or not the messages from those software mixed with the ones from fvwm into the log file, Very useful to silent the kde or gtk+ programs :) Dominique -- We have the heroes we deserve.
Echo only issue %s
After updating from fvwm-2.6.5 to 2.6.6 (from cvs), the Echo command stopped to work. I have a few of them. As example Echo Amiga recipe loading from $. return [fvwm][]: Echo %s Any Echo statement always return 'Echo %s' now. And the output at stderr is on 2 lines when it is one 1 line with 2.6.5 Dominique -- We have the heroes we deserve.
Re: CVS tadam: Fix Echo command displaying messages
Le Tue, 16 Apr 2013 09:53:26 -0500, c...@math.uh.edu a écrit : CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: tadam 13/04/16 09:53:26 Modified files: fvwm : Tag: branch-2_6 builtins.c misc.c Log message: Fix Echo command displaying messages This fixes Echo when using fvwm_msg() I didn't see that before, sorry, but now it is another issue. The Echo statements are working fine, but when I have a button with some binding on a non existing function, it is no error message any more. Before, it was something like: [fvwm][menu_func]: ERROR No such menu /Speed [fvwm][__execute_function]: ERROR No such command 'Music-Seek' Now, fvwm is completely silent.. Dominique -- We have the heroes we deserve.
Re: X does not support es_CU.UTF-8 message
Le Sun, 14 Apr 2013 21:36:00 +0200, Dominique Michel dominique.mic...@vtxnet.ch a écrit : Is it because my patch is wrong or miss something? Or is it because it is no spanish translation files in fvwm at that time (I begun to make some today, but it will take some time)? When I try to open po/fvwm.pot with poedit, it fail with 09:35:38 AM: /tmp/poeditgUBFPw/0ref.pot:321: duplicate message definition... 09:35:38 AM: /tmp/poeditgUBFPw/0ref.pot:36: ...this is the location of the first definition 09:35:38 AM: msgmerge: found 1 fatal error gtranslator warm me about this too, but is able to open the file: In consequence, I am not sure if the resulting translation file is fully usable. And also: # make fvwm.pot-update rm -f fvwmrc.pot; \ rcpotfiles='../fvwm/ConfigFvwmSetup ../modules/FvwmForm/FvwmForm-Setup.in'; \ rm -f duplicate; \ for file in $rcpotfiles; do \ perl -ne 's/\[gt\.((\\.|.)+?)\]/ print \ \#$ARGV: line $.\n.msgid \$1\\n.msgstr \\\n\n/ge' \ $file duplicate; \ done; \ msguniq duplicate fvwmrc.pot; duplicate:1: keyword SCALAR unknown duplicate:1:7: syntax error duplicate:1: keyword x250c430 unknown duplicate:4: keyword SCALAR unknown duplicate:4:7: syntax error duplicate:4: keyword x250c460 unknown duplicate:7: keyword SCALAR unknown duplicate:7:7: syntax error duplicate:7: keyword x250c430 unknown duplicate:10: keyword SCALAR unknown duplicate:10:7: syntax error duplicate:10: keyword x250c460 unknown duplicate:13: keyword SCALAR unknown duplicate:13:7: syntax error duplicate:13: keyword x250c430 unknown duplicate:16: keyword SCALAR unknown duplicate:16:7: syntax error duplicate:16: keyword x250c460 unknown duplicate:19: keyword SCALAR unknown duplicate:19:7: syntax error msguniq: too many errors, aborting make: *** [fvwm.pot-update] Error 1 Dominique -- We have the heroes we deserve.
Re: X does not support es_CU.UTF-8 message
Le Mon, 15 Apr 2013 10:05:10 +0200, Thomas Funk t.f...@web.de a écrit : Dominique Michel wrote: When I try to open po/fvwm.pot with poedit, it fail with 09:35:38 AM: /tmp/poeditgUBFPw/0ref.pot:321: duplicate message definition... 09:35:38 AM: /tmp/poeditgUBFPw/0ref.pot:36: ...this is the location of the first definition 09:35:38 AM: msgmerge: found 1 fatal error gtranslator warm me about this too, but is able to open the file: In consequence, I am not sure if the resulting translation file is fully usable. If I open po/fvwm.pot from CVS with poedit directly or via 'New catalog from Template' no errors occur. My poedit version: 1.4.6 Thomas You are right, I was working with the wrong cvs branch. The web site is a little bit confusing: http://www.fvwm.org/documentation/dev_cvs.php quote: You use the CVS checkout (or co) command to retrieve an initial copy of the code. The simplest form of this command, for retrieving the latest code, doesn't require any label: cvs -d :pserver:anonym...@cvs.fvwm.org:/home/cvs/fvwm checkout fvwm endquote With that command, the downloaded code is outdated, as well than with the 2.7 branch. Someone should update that page with the actual situation: cvs -d :pserver:anonym...@cvs.fvwm.org:/home/cvs/fvwm co -r branch-2_6 fvwm Dominique -- We have the heroes we deserve.
Re: CVS dane: InfoStore supported in EnvMatch
Le Sat, 13 Apr 2013 19:40:27 -0500, c...@math.uh.edu a écrit : Log message: InfoStore supported in EnvMatch Thank you, I will try it later. Dominique -- We have the heroes we deserve.
X does not support es_CU.UTF-8 message
I am preparing a laptop. It is several locales into the system: # locale -a C en_US.utf8 es_CU es_CU.utf8 fr_CH.utf8 POSIX sv_SE.utf8 Root have en_US.utf8. This make easier to paste its message in the internet. The user start fvwm-crystal with startx. With the fr_CH.utf8 locale, I get no message, but with the , I get massages like [FvwmButtons][FlocaleSetlocaleForX]: WARNING -- X does not support locale es_CU.UTF-8 I investigated it a little bit. The Xlib doesn't support es_CU.utf8 So, I made a little patch: https://bugs.freedesktop.org/show_bug.cgi?id=63493 but I still get those warnings. Is it because my patch is wrong or miss something? Or is it because it is no spanish translation files in fvwm at that time (I begun to make some today, but it will take some time)? Dominique -- We have the heroes we deserve.
Re: FVWM: fvwm development
Le Fri, 30 Nov 2012 09:33:00 -0500, Tom Horsley horsley1...@gmail.com a écrit : On Fri, 30 Nov 2012 14:06:36 +0100 Adam Sjøgren wrote: I think it would be much more accurate to call FVWM mature. An even better word is useful (unlike many linux products under frenetic active development by folks who believe change is always good no matter how stupid it is :-). I agree, GNU/linux is following a dangerous path those days, I never understood the need for pulseaudio when we can do the same with alsa + jack + the snd-aloop module, and that with a constant sound latency, which is a must for any serious audio work. I will not even talk about a completely idiotic take_my_freedom_ware.tm and break_my_good_working_system.tm like policykit. That was the drop that made me to begun to look for alternatives. Dominique -- We have the heroes we deserve.
Re: War on SetEnv -- hello, InfoStore.
Le Tue, 13 Dec 2011 07:24:05 +, Thomas Adam tho...@fvwm.org a écrit : I said there's no documentation for it yet. If you check, you'll note that the FVWM binary *is* built, since compiling the documentation happens *after* that point. -- Thomas Adam I added this file in doc/commands It is far from perfect, but it is the easiest way I can get portage to manage the installation. I prefer to have all the files in the system area to be managed by portage. It is far from perfect, but maybe you can use it as outline. Thank you again, Dominique Michel -- We have the heroes we deserve. InfoStore.xml Description: XML document
Re: War on SetEnv -- hello, InfoStore.
Le Mon, 12 Dec 2011 11:02:00 +, Thomas Adam tho...@fvwm.org a écrit : But people are forever asking me *why*, and it's because shoving information in the environment is global to processes created from FVWM within the same process group. Hence, that information is both publicly viewable and potentially modifiable, which in some cases might be what's wanted, but more than likely it isn't, and in that case, what you're after then is some other means which can do the same thing as SetEnv, but which is internal to FVWM, but still accessible from things like functions [1]. This is why I wrote the InfoStore command. See: https://github.com/ThomasAdam/fvwm/tree/ta/metainfo Hi Thomas, That's a great news. Thanks a lot for that. I've not added anything to the docs yet, I've yet to psych myself up enough to attempt that without injuring myself. But needless to say it's a very simple linked-list implementation with two single entries -- a key, and its value. Here's some examples: InfoStore key1 value1 InfoStore key2 value2 To get the value for a given key, you must go through the FVWM expand mechanism, as in: Echo $[infostore.key1] I can list the current values of all environment variables with the command env. Will it be possible to do something similar? I am not asking for a new feature because it will always be possible to debug a config using environment variables, and to shift using InfoStore when the debugging is done. Dominique Michel -- We have the heroes we deserve.
Re: War on SetEnv -- hello, InfoStore.
Le Mon, 12 Dec 2011 18:19:55 +, Thomas Adam tho...@fvwm.org a écrit : On Mon, Dec 12, 2011 at 05:39:38PM +, Thomas Adam wrote: On Mon, Dec 12, 2011 at 06:32:03PM +0100, Dominique Michel wrote: I can list the current values of all environment variables with the command env. Will it be possible to do something similar? No, but I can easily add it. Done. Please do a git pull and see: PrintInfo Infostore ... which will print its contents to stderr. -- Thomas Adam Thank you. I cannot get it to compile. Tried both by hand and with portage. Same result: xsltproc --path ../../doc --xinclude \ --stringparam profile.attribute output \ --stringparam profile.value html \ -o ImagePath.xml.p \ ./../docbook-xsl/profiling/profile.xsl ImagePath.xml make[3]: *** No rule to make target `InfoStore.xml', needed by `InfoStore.html'. Stop. make[3]: *** Waiting for unfinished jobs xsltproc --path ../../doc --xinclude \ --stringparam html.stylesheet ./../style.css \ --stringparam header.file ./../header.html \ -o IgnoreModifiers.html ./../fvwm.xsl IgnoreModifiers.xml.p rm IgnoreModifiers.xml.p xsltproc --path ../../doc --xinclude \ --stringparam html.stylesheet ./../style.css \ --stringparam header.file ./../header.html \ -o ImagePath.html ./../fvwm.xsl ImagePath.xml.p rm ImagePath.xml.p make[3]: Leaving directory `/var/tmp/portage/x11-wm/fvwm-/work/fvwm/doc/commands' make[2]: *** [all-recursive] Error 1 Dominique Michel -- We have the heroes we deserve.
Re: [PATCH] FvwmButtons transient avoid destroy
Le Fri, 25 Nov 2011 09:18:52 +, Thomas Adam tho...@fvwm.org a écrit : On Fri, Nov 25, 2011 at 12:47:06AM -0600, David Fries wrote: Sending a SIGTERM to FvwmButtons works to gracefully unswallow a program called stalonetray which is a system tray. Setting -transient on the FvwmButtons panel is calling XDestroyWindow and in term causes the programs with items in the system tray to crash with a bad window error. I'm removing the XDestroyWindow call and letting all transient Well, I suppose what's happening here is that if an application has registered with a systray which is then killed, then it's probably defined behaviour that those programs will die along with it, although that to me seems buggy behaviour. It is a buggy behaviour. Such an app must wait for another systray app to show up. As example of good behaviour, qjackctl and claws-mail work that way. You can kill stalonetray and restart the systray with trayer (or the contrary), and their icons will show up into the new systray. Into fvwm-crystal, I have: Test (EnvMatch NotificationAreaManager stalonetray) Test (!EnvMatch trayer_width 0) *FvwmButtons-BottomNotifAera: (1x1, \ Swallow (Close, Respawn, FvwmModule) FvwmStalonePanel TrayerPanel) Test (EnvMatch NotificationAreaManager trayer) Test (!EnvMatch trayer_width 0) *FvwmButtons-BottomNotifAera: (1x1, \ Swallow (Close, Respawn, FvwmModule) trayer TrayerPanel) Module FvwmButtons FvwmButtons-BottomNotifAera ### For stalonetray: DestroyFunc TrayerPanel AddToFunc TrayerPanel + I DestroyModuleConfig FvwmStalonePanel: * ... + I *FvwmStalonePanel: (1x1, Padding 0 0, Swallow (NoClose) stalonetray 'Exec stalonetray \ ... + I Module FvwmButtons -g $[trayer_area_width]x$[trayer_area_heigth]$[trayer_x]$[trayer_y] FvwmStalonePanel AddToFunc ExitFunction I Exec exec killall stalonetray ### For trayer DestroyFunc TrayerPanel AddToFunc TrayerPanel + I Exec exec trayer \ ... AddToFunc ExitFunction I Exec exec killall trayer ### Both stalonetray and trayer will be killed and restarted during a restart. And it work fine with compliant applications. It is some freedesktop specifications here: http://www.freedesktop.org/wiki/Specifications/systemtray-spec It say nothing about a restart. But from An application wishing to provide an icon to the system tray should first locate the system tray by requesting the owner window of the manager selection. If the manager selection has no owner, clients may use the method described in the ICCCM (watching for a MANAGER client message) to be notified when a system tray appears. we can extrapolate that an application that fail to locate a systray should not crash... but be waiting to be notified when a system tray appears. Dominique -- We have the heroes we deserve.
Re: [PATCH] FvwmButtons transient avoid destroy
Le Sat, 26 Nov 2011 11:46:07 +, Thomas Adam tho...@fvwm.org a écrit : On Sat, Nov 26, 2011 at 12:37:16PM +0100, Dominique Michel wrote: Both stalonetray and trayer will be killed and restarted during a restart. And it work fine with compliant applications. Why? The exit handling in FvwmButtons will take care of this, and forcibly killing stalonetray or trayer in ExitFunction goes against settings one might have in FvwmButtons as to what happens to the client it's going to swallow. I don't remember why. But I remember than it is a huge difference of behaviour between trayer and stalonetray, and it was difficult to get stalonetray to work well in case of restart. Don't do this. I will try when I get some time. Anyway, it look like it is other simplifications I can do on this part of code. -- Thomas Adam -- We have the heroes we deserve.
Re: [PATCH] FvwmButtons transient avoid destroy
Le Sat, 26 Nov 2011 11:42:47 +, Thomas Adam tho...@fvwm.org a écrit : On Sat, Nov 26, 2011 at 12:37:16PM +0100, Dominique Michel wrote: Le Fri, 25 Nov 2011 09:18:52 +, Thomas Adam tho...@fvwm.org a écrit : On Fri, Nov 25, 2011 at 12:47:06AM -0600, David Fries wrote: Sending a SIGTERM to FvwmButtons works to gracefully unswallow a program called stalonetray which is a system tray. Setting -transient on the FvwmButtons panel is calling XDestroyWindow and in term causes the programs with items in the system tray to crash with a bad window error. I'm removing the XDestroyWindow call and letting all transient Well, I suppose what's happening here is that if an application has registered with a systray which is then killed, then it's probably defined behaviour that those programs will die along with it, although that to me seems buggy behaviour. It is a buggy behaviour. Such an app must wait for another systray app to show up. As example of good behaviour, qjackctl and claws-mail work It will depend what happens to the application with XDestroyWindow() -- I was referring to the fact that stalonetray is broken with this, which is not surprising. That other programs attached to it bomb out as well does not surprise me, given what happens to stalonetray. Do you know if the developer of stalonetray is aware of this? -- Thomas Adam -- We have the heroes we deserve.
Re: FvwmButtons buggy when using RootTransparent colorsets
Le Mon, 6 Jun 2011 21:50:47 +0100, Thomas Adam tho...@fvwm.org a écrit : On Thu, Apr 28, 2011 at 12:09:10AM +0200, Jesús J. Guerrero Botella wrote: Hello. I am experiencing an odd problem when I use FvwmButtons in conjunction with RootTransparent based colorsets. If I specify a global one for the panel everything seems ok. The problem starts when I want to use a different (also transparent) colorset in a given cell. Then, on Restart, FvwmButtons doesn't die, instead it starts consuming cpu time like mad, and I can see that a new FvwmButtons piles up in the htop list. I have been able to reproduce this problem with the attached config, which I think is minimal enough. The process is as follows: 1.- use the attached config 2.- make sure the first line points to a valid image, otherwise the transparency won't work, and the bug won't show up 3.- start fvwm 4.- restart many times 5.- keep an eye in htop, top or whatever you use Can anyone else reproduce this on fvwm 2.6.1/2.7? Finally, I've fixed this and put it in CVS. Sorry for the delay. -- Thomas Adam I was sometime experimenting the same issue with fvwm-crystal and this look like to be fixed now. I am not able to reproduce it now, even when changing the desktop pages with the mouse-wheel like a damned. Thank you both of you. Maybe other users are experimenting this issue too. So, it can be a good time to make a bug fix release. I will not stress you, it is fine for me running the cvs version of fvwm, and anyway, I have other things to fix into crystal before I can make a new release. Ciao, Dominique -- We have the heroes we deserve.
Re: FVWM 2.6.1 tarballs on FTP site.
Le Sat, 16 Apr 2011 22:56:03 +0100, Thomas Adam tho...@fvwm.org a écrit : Jason, I've updated everything (including this time creating the necessary CVS branches, etc) and now the two 2.6.1 tar.gz and tar.bz2 files are sat awaiting your usual release process. The download links from the website are dead. If I look at ftp://ftp.fvwm.org/pub/fvwm/version-2/, I can see the 2.6.0 tar.* files, but no 2.6.1 tar.* files. Cheers, Dominique As always, the docs/ANNOUNCE file in the tarballs (or on the branch-2_6 in CVS if you're tracking that) contains the relevant information. Thanks. Any questions, do shout. -- Thomas Adam -- We have the heroes we deserve.
Re: FVWM 2.6.1 tarballs on FTP site.
Le Sun, 17 Apr 2011 14:12:03 -0500, Jason L Tibbitts III ti...@math.uh.edu a écrit : TA == Thomas Adam tho...@fvwm.org writes: TA You've been around here long enough by now to *surely* appreciate TA it's up to Jason to move them out of ftp:// to the links shown TA above? Sorry about that; I was busy doing yard work and home stuff all of yesterday and didn't get back to my computer until this morning. I know what this is. Everything's been put in place and announced. Thank you ! Maybe after we finish with the git thing we can work out a better way to handle releases than blocking the process on me. I am just surprised that the release was announced before than the files was in place and avaible. I will remember this for the next time. Dominique - J -- We have the heroes we deserve.
