fvwm-crystal-users Mailing List for FVWM-Crystal

Hello!

I just updated to fvwm3, and noticed a small problem:

https://github.com/fvwm-crystal/fvwm-crystal/blob/main/fvwm/components/functions/LoadCommonStuffs#L20-L25

cleans up possibly-left-over sockets and pid-files before starting
``FvwmMFL``

This is fine when first starting on a new X session.

It is less fine when *restarting* fvwm3: the net effect is that the
socket is gone, but ``FvwmMFL`` is still running, and there's no way to
talk to it.

If I comment out those two ``PipeRead`` lines, everything works after
a restart.

-- 
	Dakkar - <Mobilis in mobile>
	GPG public key fingerprint = A071 E618 DD2C 5901 9574
	                             6FE2 40EA 9883 7519 3F88
	                    key id = 0x75193F88

FVWM-Crystal version 3.7.6
--------------------------

This release is a new features and major bug fixes release.
- It introduce universal physical constants of the universe into
FVWM-Crystal and is therefore dedicated to the One that made it
possible, Pr. Marc Henry, and that release is named Universe.

It is 2 new settings into the Speed Music Menu for alsaplayer and
mplayer: A 432 and A 429.62. Most songs song are tuned at A=440 Hz, and
they will detune it to A=432 Hz (because folks use it) or A=429.62 Hz.
That last diapason was calculated by Prof. Marc Henry and Sylvain
Bridoux. The A4 = 429.62 Hz value is based on the universal physical
constants of our universe and on the mass of the water molecule H²O,
the most abondant molecule in the universe and our bodies. See
	Symmetry, Music and Water:
    https://www.preprints.org/manuscript/202401.1231/v1

The fixes includes fixes for the desktop icons (Preferences ->
Desktop Manager - FVWM-Crystal) after Restart, confused button when Show
Partition was off, not showing partitions when the user have no access
rights on them.

The Exit menu was reworked to support systemctl (systemd),
logind (gentoo version for openrc systems) and pm-utils.

On some distributions, hibernation may fail to work as expected when
Secure Boot is enabled in the bios. It will run, but the result will be
a frozen system. That issue concern the kernel (WIP) and is out of the
scope of FVWM-Crystal.

Internals: The Exec accelerators was reworked to be in sync with current
systems and should be faster to maintain on the long run.

A lot of other fixes. See ChangeLog for the details.

Enjoy!
Dominique Michel

Download: https://sourceforge.net/projects/fvwm-crystal/files/
Website: https://fvwm-crystal.sourceforge.io/screenshots.html
Development: https://github.com/fvwm-crystal/fvwm-crystal

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/

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

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

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

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 

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

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/

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/

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

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

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

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

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

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]

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]

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.

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.

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]

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.

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.

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.

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.