Font preference menu (quoting...)

I try to make a font preferences setting in fvwm-crystal. The code look like this:

[code]DestroyMenu /Preferences

  • ‘%22x22/fvwm-crystal/user-desktop.png%$[gt.Characters fonts]’ Popup /Preferences/Fonts

DestroyMenu /Preferences/Fonts
AddToMenu /Preferences/Fonts

  • MissingSubmenuFunction Fonts-generator
  • ‘%22x22/fvwm-crystal/user-desktop.png%$[gt.Panels]’ Popup Panel
  • ‘%22x22/fvwm-crystal/user-desktop.png%$[gt.Title bar]’ Popup Title

DestroyFunc Fonts-generator
AddToFunc Fonts-generator

  • I DestroyMenu recreate $0
  • I AddToMenu $0
  • I PipeRead ‘fc-list | sed -e ‘s/\(:style=[[:alpha:]]\) ./\1/’ -e ‘s/\(:style=[[:alpha:]]\),./\1/’ -e ‘s/\(,.\):\(style=.\)/\2/’ -e ‘s/style=//’ | sort > $[FVWM_USERDIR]/FontList;
    while read myline ; do echo “AddToMenu $0 ‘${myline}’ $0Font-Set ‘${myline}’”; done < $[FVWM_USERDIR]/FontList;’

DestroyFunc PanelFont-Set
AddToFunc PanelFont-Set

  • I SavePreferences PanelFont “SetEnv panel_font \”"$*"\""
  • I Style * Font “xft:$:pixelsize=12:Bold"
    Test (EnvIsSet FVWM_FLAG_UTF-8) + I Style * Font "xft:$
    :pixelsize=12:Bold:encoding=iso10646-1”

DestroyFunc TitleFont-Set
AddToFunc TitleFont-Set

  • I SavePreferences TitleFont “SetEnv title_font \”"$*"\""
  • I Style * Font “xft:$0:pixelsize=12:Bold”
    Test (EnvIsSet FVWM_FLAG_UTF-8) + I Style * Font “xft:$0:pixelsize=12:Bold:encoding=iso10646-1”
    [/code]
    When the menu is called and a submenu Panel or Title is called, the Fonts-generator function create the file $[FVWM_USERDIR]/FontList and the corresponding submenu with the entries form this file. When a font is clicked in this submenu, a preference setting is written into PanelFont or TitleFont and the font is applied to the titlebar (In both cases, I will do the panel when the titlebar will work).

The only thing that doesn’t work is that the font is not applied when it is some space in its name. It look like only the part of the fontname before the first space is send. as example, “Bitstream Cyberbit:Roman” is saved correctly into the Title or Panel pref file, but only “Bitstream” is send to the style.

$[FVWM_USERDIR]/FontList look like:

Aerial:Bold Aerial:Italic Aerial Mono:Bold ...

For the Bitsrteam Cyberbit, the Panel or Title pref file will look like:

SetEnv title_font "Bitstream Cyberbit:Roman"

The same non working fonts are working fine at restart with this 2 lines into the theme file:

Style * Font "xft:$[title_font]:pixelsize=14:Bold" Test (EnvIsSet FVWM_FLAG_UTF-8) Style * Font "xft:$[title_font]:pixelsize=14:Bold:encoding=iso10646-1"

I suspect a quoting issue but is completely lost after spending a lot of time to try to make it to work.

So you never once bothered to check what SavePreferences does? That’s the first thing I did.

DestroyFunc SavePreferences
AddToFunc SavePreferences
+ I Exec echo $1 > $[FVWM_USERDIR]/preferences/$0

And lookey here, it’s ballsed. Here’s the correct version:

DestroyFunc SavePreferences
AddToFunc SavePreferences
+ I Exec exec echo "$1" > "$[FVWM_USERDIR]/preferences/$0"

Whilst I was at it, here’s another broken function from the same file:

DestroyFunc AppendPreferences
AddToFunc AppendPreferences
+ I Exec exec touch $[FVWM_USERDIR]/preferences/"$0"
+ I Exec exec echo "$1" >> $[FVWM_USERDIR]/preferences/"$0"

Note that this is the correct way to do things – much like how one doesn’t need to quote $[…] for proper expansion from within FVWM, these functions should quote the input for you. Much better.

As for your problem, I cannot reproduce it at all. It’s working fine. I ignored your red-herring suggestion of only a single word being sent as a style line as a font – that’s simply not the case.

So… This time, reduce all the lines you’ve posted to two or three which clearly illustrates your problem, including your ExecUseShell line if you’ve set one, then I’ll look again.

– Thomas Adam

Thank you for the explanation. I try it but it removed the simple quote from the Windows decoration. I will investigate it later.

I don’t have any ExecUseShell line in my config. So, fvwm will use sh. Into FVWMConsole: Exec exec eek /bin/sh: line 0: exec: eek: not found so this is definitely sh.

For the problem, all is working fine at the exception of the font that fail to be set when it is some space in its name (like in Bitsteam Charter). This is between the second command in this PipeRead (the while read myline stuff):

+ I PipeRead + I PipeRead 'fc-list | sed -e \'s/\\(:style=[[:alpha:]]*\\) .*/\\1/\' -e \'s/\\(:style=[[:alpha:]]*\\),.*/\\1/\' -e \'s/\\(,.*\\):\\(style=.*\\)/\\2/\' -e \'s/style=//\' | sort > $[FVWM_USERDIR]/FontList; \ while read myline ; do echo \"AddToMenu $0 \'${myline}\' $0Font-Set \'${myline}\'\"; done < $[FVWM_USERDIR]/FontList;'
and the Font-Set function:

[code]DestroyFunc TitleFont-Set
AddToFunc TitleFont-Set

  • I Style * Font “xft:$0:pixelsize=12:Bold:encoding=iso10646-1”[/code]

Nope, still nothing wrong. If I do this:

PipeRead 'fc-list | sed -e \'s/\\(:style=[[:alpha:]]*\\) .*/\\1/\' -e \'s/\\(:style=[[:alpha:]]*\\),.*/\\1/\' -e \'s/\\(,.*\\):\\(style=.*\\)/\\2/\' -e \'s/style=//\' | sort > $[FVWM_USERDIR]/FontList;    while read myline ; do echo \"AddToMenu Title \'${myline}\' TitleFont-Set \'${myline}\'\"; done < $[FVWM_USERDIR]/FontList > $[HOME]/fuck'

Then look in ~/fuck – it’s quoted fine. Issuing a:

Read $[HOME]/fuck

Works fine. If I modify TitleFont-Set to:

DestroyFunc TitleFont-Set
AddToFunc TitleFont-Set
+ I Echo Style * Font "xft:$0:pixelsize=12:Bold:encoding=iso10646-1"
+ I Style * Font "xft:$0:pixelsize=12:Bold:encoding=iso10646-1"

It’s fine, and changes the font just fine.

What FVWM version is this? If I find out this is fvwm-crystal specific (because there’s some other function doing $STUFF you’ve neglected to mention) I’m going to be annoyed (but not surprised, frankly). Try it for yourself, not loading any FVWM config:

fvwm -f /dev/null

– Thomas Adam

You was faster as me to post, thank you again!

Nice, you don’t changed anything. I begin to understand something to quoting. But I am still not really sure of anything.

Same here, it’s fine now. I changed it further:

[code]DestroyFunc TitleFont-Set
AddToFunc TitleFont-Set

  • I SavePreferences TitleFont “SetEnv title_font \”"$*"\""
  • I Style * Font “xft:$0:pixelsize=12:Bold”
  • I Test (EnvIsSet FVWM_FLAG_UTF-8) Style * Font “xft:$0:pixelsize=12:Bold:encoding=iso10646-1”[/code]

I put it into my .xinitrc and issued a startx. I get only a black screen with the mouse cursor and the intern FVWM menu.

Fvwm is the last one from portage ] $ fvwm -V
fvwm 2.5.26 compiled on Jun 21 2008 at 18:12:06
with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS
[/code] I was using a non patched cvs version before that and updated it yesterday to the portage version just to be 100 % sure that the problem was not into fvwm.

About the other function that can change $STUFF, what are them and how I can test them?

I was in the way to post another solution that was working for me before I run “fvwm -f /dev/null” (and is still working now):

[code]DestroyFunc TitleFont-Set
AddToFunc TitleFont-Set

  • I SavePreferences TitleFont “SetEnv title_font \”"$*"\""
  • I Style * Font “xft:$[0]:pixelsize=12:Bold”
  • I Test (EnvIsSet FVWM_FLAG_UTF-8) Style * Font “xft:$[0]:pixelsize=12:Bold:encoding=iso10646-1”[/code]
    Using $[0] instead of $0 made it to work. But now it also work with $0, so I guess that running “fvwm -f /dev/null” erased or changed some files in ~/.fvwm or somewhere else. I was thinking that fvwm-crystal use only files into ~/.fvwm-crystal, but it doesn’t seam to be the case.

3 questions. It is a lot of font settings like the following into fvwm-crystal:

Style * Font "xft:some font:pixelsize=12:Bold" Test (EnvIsSet FVWM_FLAG_UTF-8) Style * Font "xft:some font:pixelsize=12:Bold:encoding=iso10646-1"[/code]
Would it not be better to do the following so that the font is set just one time instead of 2 times:

Test (EnvIsSet FVWM_FLAG_UTF-8) Style * Font "xft:some font:pixelsize=12:Bold:encoding=iso10646-1" TestRc (NoMatch) Style * Font "xft:some font:pixelsize=12:Bold"

Into the TitleFont-Set function, the first line (the one with [code]

  • I SavePreferences TitleFont “SetEnv title_font \”"$"\""
    [/code] need "$
    ". With “$0”, the font name and all that follow is clipped at the first space into the font name. That doesn’t changed after “fvwm -f /dev/null”.
    In the 2 other lines, $0 is needed. I don’t understand why.

And the final question: which is the best version of TitleFont, yours with $0 or mine with $[0]?

After more test, the version with $[0] is working better because I get some strange results with $0: I added some functions in order to make a menu font setting and $0 with Agate:Normal give me a menu that was more width that the screen width after the font update (only at realtime, it was fine after a restart). It work fine with $[0].

That’s a red-herring of course. There’s definitely some odd interaction happening elsewhere to see what you are – again, since you’ve not really told me anything new, I can’t help you.

– Thomas Adam

See my other post about why this is bollocks.

Pass. You’re the one using fvwm-crystal, not I.

Of course not. It will go through the process of loading files in $(fvwm-config -d)/ConfigFvwm*

$0, of course.

– Thomas Adam

I understand that, but will try to fix it later.

OK. I was thinking to stuff like $IFS into the shell. I already investigated fvwm-crystal and it doesn’t seam to be the case. But I will investigate it further.

I will investigate it too.

I guess that the correct line is the one with :encoding=iso10646-1 at the end. That way, fvwm will not use string conversion.

I also see that this is a lot of work to do into fvwm-crystal in order to replace most of the environment variables by PipeRead or other functions. I see a strange bug report about those environment variables on gentoo http://bugs.gentoo.org/show_bug.cgi?id=210580. They break portage, but only when using konsole in fvwm-crystal to do portage work. I cannot understand how the use of “-” into the name of those variables can break portage and that only with konsole. The proposed fix look like a workaround for some gentoo or konsole specific problem to me. But I can be wrong because the fact is that it will be a good thing to get ride of those variables.

It’s nothing to do with IFS.

There’s nothing to investigate here either – since nothing which loads there affects your singular issue.

Please not PipeRead.

It has nothing to do with Konsole – the use of - in env names breaks POSIX. In order to fix this, you’re better off removing most of the env var use, and sanitising the names.

Are you now the maintainer of this then?

– Thomas Adam

Ouch, I understand the problem now. I will have to learn POSIX too.

Yes I am. I am almost the only one that contribute to crystal, so this was a logical move.

Hahahahahaha.

– Thomas Adam

^That wasn’t very encouraging. In fact, that was downright rude. :open_mouth:

Depends how you read it; and you’ve misread. :wink:

– Thomas Adam

You know, I don’t trust what peoples said because I know that it is very easy to miss understand something. Sometime, it is already not easy to say what you mean. And how can you be sure that other people will understand what you said? It is a difficult matter. It is why in all the army of the world, one must repeat the orders. But even in that case, the only thing that you know for sure, is that someone is able to repeat what you said. It doesn’t mean that what you mean is understood.

I trust one thing with other peoples : what they are doing. I call this the prof by the act!

And Tomas is the guy on this forum that answer the most.

I just found a great UUOS in Crystal: an unused env variable! I removed it without merci!

I begun to look into this. I am a little confused.
This is places where it must be possible to replace the pref setting in crystal pref files by lines that can be read by fvwm.

But it will be still some variables where I don’t have much choices because they are determined by the output of some command. If I understand well and in that case, the only choices are to use a Piperead or an “Exec echo …”. I experimented with Exec echo, but that doesn’t worked.

Original line:

PipeRead 'echo *FvwmPager: Geometry $[FvwmPager_Width]x$[FvwmPager_Height]-$[FvwmPager_Width]+$[FvwmPager_Height]'

Working line, I get ride of FvwmPager_Width and FvwmPager_Height with it but still use a PipeRead:

PipeRead 'echo *FvwmPager: Geometry $((28*$[Desk_Pages_X]))x$((24*$[Desk_Pages_Y]))-$((28*$[Desk_Pages_X]))+$((24*$[Desk_Pages_Y]))'

Non working line:

Exec "echo *FvwmPager: Geometry $((28*$[Desk_Pages_X]))x$((24*$[Desk_Pages_Y]))-$((28*$[Desk_Pages_X]))+$((24*$[Desk_Pages_Y]))"

with result:

/bin/sh: echo *FvwmPager: Geometry 224x24-224+24: command not found

I try with “Exec exec echo blabla” and with result “not found”.

According to Fvwm man page, the construct Exec "echo blabla > somefile" Read somefile can give unexpected result. Same result for the Exec line in my case that without the redirection.

What can I do?

Obviously – that’s asking the shell to load that command up — you cannot avoid PipeRead here to to arithmetic comparisons, so don’t try to circumvent it.

Err – that will give you a race condition between the file being written to, and FVWM reading from the file, yes. Generally you don’t want to do this.

Err, use PipeRead.

Maybe you misunderstood my comment, or I was wasn’t clear enough. I spent a long time removing the extraneous cruft in fvwm-crystal, sanitising functions which were using excessive env vars to achieve nothing; one-shot calculations in PipeRead, etc. Harnir was mostly responsive to them, but not all – not sure why. I have no interest contributing to fvwm-crystal anymore as a result. What I will say though is your time is better spent not trying to rewrite PipeRead to use Exec, but to get rid of a lot of env vars.

But even then, there’s stacks of other things you could be doing — one of them is looking at the music player functions in FVWM-Crystal; they all use the same code with just different options. Amalgamating them all into the one function would be easier.

– Thomas Adam

I guess most of the pref settings. I am thinking to write the functions directly into somefile instead of just the variable and read those files from the recipe. So, it will be no race condition, and no env varriable.

I guess because some lines can become quite complicated to read and the maintenance become more complicated. But I agree with you, when a value is used one time, it is best to not use a variable for that.

I begun to do that, but it will take some time.

That’s right. They are complicated to use into the recipes and the addition of Alsaplayer and mplayer make them even more complicated. A full rewrite is needed here.