Menu
▾
▴
fvwm-crystal-users — FVWM-Crystal email list for users and developpers
You can subscribe to this list here.
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(6) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2020 |
Jan
|
Feb
(5) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
(1) |
| 2022 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Dominique M. <dom...@gm...> - 2022-02-14 13:16:58
|
Fvwm Crystal 3.7.5 is out. This release remove the Piperead that was used to load FvwmMFL in StartFuction when using fvwm3. Need fvwm3>=1.04 Fvwm Crystal 3.7.4 is out. This release add an extra mplayer parameters preference. It is mainly useful for IPTV watching to set the cache size of mplayer. That will be all for now. I think fvwm-crystal-3.7.5 is one of the best fvwm-crystal release that just work. I begun to work on a key bindings preferences system. I think it is a must have feature for a dektop. It is a relatively complex issue. To not break the exiting configurations, it must take in account the bindings files in both $FVWM_SYSTEMDIR and $FVWM_USERDIR and, from that, generate a new bindings system using one or more fvwm preferences scripts. For now, I think about one main FvwmScript to set the bindings and a second FvwmScript launched when the new binding collide with another existing binding. As it is many bindings, the main script must separate them into categories. Also, the Numlock key must be handled. As I have no idea how long time it will take to do all that, I will create a dedicated new branch on github. Greetings, Dominique Download: https://sourceforge.net/projects/fvwm-crystal/files/3.7.5/ |
|
From: Dominique M. <dom...@gm...> - 2022-02-04 20:13:35
|
Version 3.7.2 ------------- Fvwm Crystal 3.7.2 is out. This release is an important bug fix and new features release. - Initial IPTV support for mplayer. From the playlist menu, fvwwm-crystal can download the playlists from the internet and will incorporate them into the playliste menu. By default, all IPTV categories are supported, but the nsfw cateegory is disabled. Its preference file is into FVWM_CONFIGDIR/preferences, so that only a sysadmin can change it. For the other categories, a preference setting is provided into the playlist menu. - Fix nasty Piperead calls into the mplayer control that could freeze fvwm. - Fix the Fullscreen functions for use with fvwm3. That should also work with fvwm2 and fix these functions for the browser windows and other windows using the F11 Fullscreen mode or similar Fullscreen functions - Fullscreen from fvwm-crystal have the precedence over what the browser think is best. - Various improvements, fixes and cleanup. See ChangeLog for details. Power to the people, Dominique Michel You can download it from sourceforge: https://sourceforge.net/projects/fvwm-crystal/files/latest/download |
|
From: Dominique M. <dom...@gm...> - 2020-12-15 23:56:53
|
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 |
|
From: Dominique M. <dom...@gm...> - 2020-10-07 00:44:37
|
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 |
|
From: Dominique M. <dom...@gm...> - 2020-10-07 00:37:24
|
Le Tue, 11 Aug 2020 17:02:04 +0100, Gianni Ceccarelli <da...@th...> a écrit : > Hello! Hello! Thanks for reporting. > Reverting this change: > https://sourceforge.net/p/fvwm-crystal/code/898/tree//fvwm/components/styles/FVWM?diff=761 > made it work like before, and stay put. I reverted it and it is part of fvwm-3.6.7. > > What was the reason for that change? I feel like I'm missing > something. What I remember is than I was working on the magic button bar and getting some trouble with trayer. Which show me I must be more careful with my comments into the ChangeLog. It is another trayer related fix. After a fvwm Restart, all was and is fine, but with the Custom recipe, when redrawing the magic button from its menu was causing multiple trayer instances and the tray icons getting lost. This should be fixed. Best, Dominique |
|
From: Gianni C. <da...@th...> - 2020-08-11 16:29:13
|
Hello! I've recently upgraded from fvwm-crystal 3.2.3 to 3.6.5 (Gentoo skipped a few releases…) and noticed that trayer now gets moved around when I press the "arrange all windows" button. Reverting this change: https://sourceforge.net/p/fvwm-crystal/code/898/tree//fvwm/components/styles/FVWM?diff=761 made it work like before, and stay put. What was the reason for that change? I feel like I'm missing something. -- Dakkar - <Mobilis in mobile> GPG public key fingerprint = A071 E618 DD2C 5901 9574 6FE2 40EA 9883 7519 3F88 key id = 0x75193F88 |
|
From: Dominique M. <dom...@gm...> - 2020-07-29 08:04:20
|
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/ |
|
From: Dominique M. <dom...@gm...> - 2020-04-05 12:17:22
|
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/ |
|
From: Dominique M. <dom...@gm...> - 2020-02-26 18:44:53
|
The mpd control of fvwm-crystal contain 2 FvwmScripts. I updated them on the svn repo with Gettext support, which imply new strings to translate. I also added support for the Panel font preferences into these scripts. Cheers, Dominique |
|
From: Dominique M. <dom...@gm...> - 2020-02-22 00:01:22
|
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 |
|
From: Dominique M. <dom...@gm...> - 2020-02-20 19:19:21
|
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. https://sourceforge.net/projects/fvwm-crystal/files/ Have fun! Dominique Michel |
|
From: Dominique M. <dom...@gm...> - 2020-02-19 11:35:48
|
Le Mon, 17 Feb 2020 18:39:39 +0100, Dominique Michel <dom...@gm...> a écrit : > Version 3.6.0 > ------------- > Code name "Magic Star" > 3.6.1 will be out very soon. It is 2 horrible bugs with the media players: - xmms2 is broken. I get it to work. I now understand why most of its GUI are more or less abandonware: they changed even its executable name... - The styles of the console media players and of start_[jacx|cadence] are still broken at start and ReStart. I find a solution and I am working on it. It look like fvwm don't apply the styles in the order they are specified when, like in crystal, it is a heavy use of functions to load the stuffs. Cheers, Dominique |
|
From: Dominique M. <dom...@gm...> - 2020-02-17 17:41:15
|
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 |
|
From: Alwin <tra...@zi...> - 2019-11-23 15:21:14
|
That looks fine to me. Although < and > have a special meaning in shell script, I don't think that's the case within quoted strings like "$[gt. ... ]". Dominique Michel schreef: > I replaced the "'" by U+2019 into the existing locales everywhere but > not in constructs like "\\'path\\'". > > For these constructs, I think it could be best to change them to > "<path>", and that including into the original English. What do you > think? > > Cheers, > Dominique > > Le Sun, 17 Nov 2019 12:13:17 +0100, > Alwin<tra...@zi...> a écrit : > >> Hi Dominique, >> >> I think you're right, and counting how much escape characters would >> be needed in every single translation string is too much of a burden. >> >> It seems that FVWM does the gettext conversion before execution of >> the scripting task. Using the Unicode apostrophe U+2019 >> unbackslashed, works under a UTF-8 locale, and it's looking nice. But >> under another character set (8859-1 family) it's replaced again by >> the ASCII apostrophe which is also used by the script, so it ruins >> the menu. Maybe FVWM-Crystal should declare using translations not >> using UTF-8 broken for the time being, and use the Unicode apostrophe >> for now. >> >> The real solution would probably be, that FVWM doesn't take the 'gt.' >> string for gettext into account for the scripting part. >> >> >> Cheers, >> >> >> Dominique Michel schreef: >>> I found a bug when making the French translation. If your language >>> contain the apostrophe "'", to have it into a menu translated >>> string, will screw up the corresponding menu entry and associated >>> function. That imply not only the displayed string can and will be >>> wrong, but that menu entry will not work at all. To escape the "'" >>> into the translation doesn't help, or help randomly in a few cases. >>> >>> The same string into a FvwmForm will work fine. I reported this to >>> the Fvwm workers list, but get no answer at that time. The only >>> workaround I find is to not use "'" into translated menu strings, >>> and when not possible, to replace "'" by something like "_" or " ". >>> I think it will be the same issue with other characters used by >>> fvwm as quoting characters, and I rally hope they will be the only >>> ones causing that issue. >>> >>> Thanks for your time. >>> Dominique -- [alwin] |
|
From: Alwin <tra...@zi...> - 2019-11-23 15:21:08
|
Dominique Michel schreef: > Le Sun, 17 Nov 2019 12:13:17 +0100, > Alwin<tra...@zi...> a écrit : > >> Hi Dominique, > Hi Alwin, >> I think you're right, and counting how much escape characters would >> be needed in every single translation string is too much of a burden. >> >> It seems that FVWM does the gettext conversion before execution of >> the scripting task. Using the Unicode apostrophe U+2019 >> unbackslashed, works under a UTF-8 locale, and it's looking nice. But >> under another character set (8859-1 family) it's replaced again by >> the ASCII apostrophe which is also used by the script, so it ruins >> the menu. Maybe FVWM-Crystal should declare using translations not >> using UTF-8 broken for the time being, and use the Unicode apostrophe >> for now. > Thanks. I changed them to U+2019 into the French translation. And > changed a "don\\'t" into fvwm/scripts/FileEditors/ShowDirectories-Help > order to use it too. Hopefully, it was the only needed change into the > original English. Yes, that was the only one. > I added a comment about that into your addons/make.pot script. > It will be into the pot files, but not necessarily merged into > existing po files. > Also, I added a section for 2 strings which are into the XDG > application menu generated by fvwm-menu-desktop (Alt+A menu). > Will you review these changes? The quoting problem should be temporary, if it could be fixed in fvwm as a bug. Small change for the same hints in make.pot 'Help', and a slash in the relative path. There's actually a setting in Poedit to add a prefix, so the files can be viewed directly. --- make.pot.old 2019-11-23 13:12:58.752340653 +0100 +++ make.pot 2019-11-23 15:58:25.936137186 +0100 @@ -40,6 +40,10 @@ # to search for empty msgstr's, check translations marked by the `fuzzy' # flag, remove the lines containing `fuzzy', and (optionally) remove # marked obsolete entries at the end of the PO files. +# +# Using quoting characters into a translation can confuse fvwm. +# To avoid this, you MUST use other UTF-8 characters like , ‘ ’ “ ” « or ». +# The most used one can be the apostrophe: please use ’ instead of '. @@ -222,11 +226,11 @@ # put non conventional strings here: if [ "$i" = "fvwm-crystal" ]; then - echo '#: ..fvwm/scripts/XDG-Menu' >>$i.pot + echo '#: ../fvwm/scripts/XDG-Menu' >>$i.pot echo 'msgid "Configure"' >>$i.pot echo 'msgstr ""' >>$i.pot echo '' >>$i.pot - echo '#: ..fvwm/scripts/XDG-Menu' >>$i.pot + echo '#: ../fvwm/scripts/XDG-Menu' >>$i.pot echo 'msgid "Regenerate"' >>$i.pot echo 'msgstr ""' >>$i.pot fi > > It is also a sed with these strings into fvwm/scripts/XDG-Menu. That is > to edit the XDG generated menu in order to adapt it to our need. The 2 > strings are just reversed, I think the main issue with these 2 strings > is than fvwm doesn't provide a translation for them. Then that's probably temporary too. ;-) > > Cheers, > Dominique >> The real solution would probably be, that FVWM doesn't take the 'gt.' >> string for gettext into account for the scripting part. >> >> >> Cheers, >> >> >> Dominique Michel schreef: >>> I found a bug when making the French translation. If your language >>> contain the apostrophe "'", to have it into a menu translated >>> string, will screw up the corresponding menu entry and associated >>> function. That imply not only the displayed string can and will be >>> wrong, but that menu entry will not work at all. To escape the "'" >>> into the translation doesn't help, or help randomly in a few cases. >>> >>> The same string into a FvwmForm will work fine. I reported this to >>> the Fvwm workers list, but get no answer at that time. The only >>> workaround I find is to not use "'" into translated menu strings, >>> and when not possible, to replace "'" by something like "_" or " ". >>> I think it will be the same issue with other characters used by >>> fvwm as quoting characters, and I rally hope they will be the only >>> ones causing that issue. >>> >>> Thanks for your time. >>> Dominique -- [alwin] |
|
From: Dominique M. <dom...@gm...> - 2019-11-22 18:19:18
|
I replaced the "'" by U+2019 into the existing locales everywhere but not in constructs like "\\'path\\'". For these constructs, I think it could be best to change them to "<path>", and that including into the original English. What do you think? Cheers, Dominique Le Sun, 17 Nov 2019 12:13:17 +0100, Alwin <tra...@zi...> a écrit : > Hi Dominique, > > I think you're right, and counting how much escape characters would > be needed in every single translation string is too much of a burden. > > It seems that FVWM does the gettext conversion before execution of > the scripting task. Using the Unicode apostrophe U+2019 > unbackslashed, works under a UTF-8 locale, and it's looking nice. But > under another character set (8859-1 family) it's replaced again by > the ASCII apostrophe which is also used by the script, so it ruins > the menu. Maybe FVWM-Crystal should declare using translations not > using UTF-8 broken for the time being, and use the Unicode apostrophe > for now. > > The real solution would probably be, that FVWM doesn't take the 'gt.' > string for gettext into account for the scripting part. > > > Cheers, > > > Dominique Michel schreef: > > I found a bug when making the French translation. If your language > > contain the apostrophe "'", to have it into a menu translated > > string, will screw up the corresponding menu entry and associated > > function. That imply not only the displayed string can and will be > > wrong, but that menu entry will not work at all. To escape the "'" > > into the translation doesn't help, or help randomly in a few cases. > > > > The same string into a FvwmForm will work fine. I reported this to > > the Fvwm workers list, but get no answer at that time. The only > > workaround I find is to not use "'" into translated menu strings, > > and when not possible, to replace "'" by something like "_" or " ". > > I think it will be the same issue with other characters used by > > fvwm as quoting characters, and I rally hope they will be the only > > ones causing that issue. > > > > Thanks for your time. > > Dominique > > -- If you have a problem and you are not doing anything to fix it, you are at the heart of the problem. |
|
From: Dominique M. <dom...@gm...> - 2019-11-22 17:28:25
|
Le Sun, 17 Nov 2019 12:13:17 +0100, Alwin <tra...@zi...> a écrit : > Hi Dominique, Hi Alwin, > > I think you're right, and counting how much escape characters would > be needed in every single translation string is too much of a burden. > > It seems that FVWM does the gettext conversion before execution of > the scripting task. Using the Unicode apostrophe U+2019 > unbackslashed, works under a UTF-8 locale, and it's looking nice. But > under another character set (8859-1 family) it's replaced again by > the ASCII apostrophe which is also used by the script, so it ruins > the menu. Maybe FVWM-Crystal should declare using translations not > using UTF-8 broken for the time being, and use the Unicode apostrophe > for now. Thanks. I changed them to U+2019 into the French translation. And changed a "don\\'t" into fvwm/scripts/FileEditors/ShowDirectories-Help order to use it too. Hopefully, it was the only needed change into the original English. I added a comment about that into your addons/make.pot script. It will be into the pot files, but not necessarily merged into existing po files. Also, I added a section for 2 strings which are into the XDG application menu generated by fvwm-menu-desktop (Alt+A menu). Will you review these changes? It is also a sed with these strings into fvwm/scripts/XDG-Menu. That is to edit the XDG generated menu in order to adapt it to our need. The 2 strings are just reversed, I think the main issue with these 2 strings is than fvwm doesn't provide a translation for them. Cheers, Dominique > > The real solution would probably be, that FVWM doesn't take the 'gt.' > string for gettext into account for the scripting part. > > > Cheers, > > > Dominique Michel schreef: > > I found a bug when making the French translation. If your language > > contain the apostrophe "'", to have it into a menu translated > > string, will screw up the corresponding menu entry and associated > > function. That imply not only the displayed string can and will be > > wrong, but that menu entry will not work at all. To escape the "'" > > into the translation doesn't help, or help randomly in a few cases. > > > > The same string into a FvwmForm will work fine. I reported this to > > the Fvwm workers list, but get no answer at that time. The only > > workaround I find is to not use "'" into translated menu strings, > > and when not possible, to replace "'" by something like "_" or " ". > > I think it will be the same issue with other characters used by > > fvwm as quoting characters, and I rally hope they will be the only > > ones causing that issue. > > > > Thanks for your time. > > Dominique > > -- If you have a problem and you are not doing anything to fix it, you are at the heart of the problem. |
|
From: Alwin <tra...@zi...> - 2019-11-17 11:13:34
|
Hi Dominique, I think you're right, and counting how much escape characters would be needed in every single translation string is too much of a burden. It seems that FVWM does the gettext conversion before execution of the scripting task. Using the Unicode apostrophe U+2019 unbackslashed, works under a UTF-8 locale, and it's looking nice. But under another character set (8859-1 family) it's replaced again by the ASCII apostrophe which is also used by the script, so it ruins the menu. Maybe FVWM-Crystal should declare using translations not using UTF-8 broken for the time being, and use the Unicode apostrophe for now. The real solution would probably be, that FVWM doesn't take the 'gt.' string for gettext into account for the scripting part. Cheers, Dominique Michel schreef: > I found a bug when making the French translation. If your language > contain the apostrophe "'", to have it into a menu translated string, > will screw up the corresponding menu entry and associated function. > That imply not only the displayed string can and will be wrong, but that > menu entry will not work at all. To escape the "'" into the > translation doesn't help, or help randomly in a few cases. > > The same string into a FvwmForm will work fine. I reported this to the > Fvwm workers list, but get no answer at that time. The only workaround > I find is to not use "'" into translated menu strings, and when not > possible, to replace "'" by something like "_" or " ". I think it will > be the same issue with other characters used by fvwm as quoting > characters, and I rally hope they will be the only ones causing > that issue. > > Thanks for your time. > Dominique -- [alwin] |
|
From: Dominique M. <dom...@gm...> - 2019-11-16 19:41:01
|
I found a bug when making the French translation. If your language contain the apostrophe "'", to have it into a menu translated string, will screw up the corresponding menu entry and associated function. That imply not only the displayed string can and will be wrong, but that menu entry will not work at all. To escape the "'" into the translation doesn't help, or help randomly in a few cases. The same string into a FvwmForm will work fine. I reported this to the Fvwm workers list, but get no answer at that time. The only workaround I find is to not use "'" into translated menu strings, and when not possible, to replace "'" by something like "_" or " ". I think it will be the same issue with other characters used by fvwm as quoting characters, and I rally hope they will be the only ones causing that issue. Thanks for your time. Dominique -- If you have a problem and you are not doing anything to fix it, you are at the heart of the problem. |
|
From: Dominique M. <dom...@gm...> - 2019-09-07 10:01:21
|
I just committed a fix for the man pages. Included are a fix for FVWM_DISTROMENUDIR and FVWM_DISTROMENUNAME. And also some documentation about the Custom recipe and the use of its Magic button bar. It's quite intuitive for me as I wrote it, but it was just better to document it. Best, Dominique -- If you have a problem and you are not doing anything to fix it, you are at the heart of the problem. |
|
From: Dominique M. <dom...@gm...> - 2019-09-06 10:55:54
|
The nest fvwm-crystal release is almost ready. It is a few strings which need translations. If you can do it, so please contribue them to that list or with a private message. Note than fvwm have now a native "Maximize Fullscreen". That imply fvwm-crystal depend now on fvwm-2.6.9 that was released today. Alternatively, you can also use the git version of fvwm. That also imply than the fvwm-crystal Fullscreen and Disappear functions was cleaned. Other associated functions used to restore the preceding size of a window was just removed. The result is a much faster and glitch free user experience. Another important dependency change is a bump of fvwm-crystal python scripts to python3*. They will still work with python2, but need a manual change of the shebangs. Anyway, python upstream will end the long term support of python2 at the end of this year. That release provide a new Custom recipe with an autogenerated button bar. That magic bar have its own preferences which allow to put any launcher you may want into it. This will be the biggest visible change. See the ChangeLog for the details. Any testing report will be appreciated. Cheers, Dominique -- If you have a problem and you are not doing anything to fix it, you are at the heart of the problem. |
|
From: Dominique M. <dom...@gm...> - 2019-08-16 13:13:15
|
Just to say I just bumped the 4 python scripts in fvwm-crystal from python2 to python3. Python upstream will end its long term support of python2.7 by the end of that year, which should imply than it will disappear from most distributions. It is in the svn and will be part of the coming release. Cheers, Dominique -- If you have a problem and you are not doing anything to fix it, you are at the heart of the problem. |