Genmon doesn't print the output if it contains an `&'. To reproduce echo 'jack and jill' > file then set genmon to do `cat file' - it will work. then echo 'jack & jill' > file and it will not update
Yes, I've found that you have to use & to get an ampersand. Of course, it shouldn't be this way...
It's because genmon accepts XML tags in its input. But yes, it should probably be smart enough to tell the difference between XML and plaintext.
Created attachment 4198 Add a raw tag for non-Pango text. How about providing a <raw> tag that passes the text to gtk_label_set_text instead of gtk_label_set_markup?
Seems like there ought to be a command line utility out there somewhere that would do XML escaping. That would accomplish the same thing as adding support for a <raw> tag, no? But maybe such a thing doesn't exist, I don't know. Anyway, the patch looks fine; I'll try to look more closely at it and merge it in the next few days. I was thinking of doing a simple test to try to guess whether the input was XML (something like just looking for a '<' and '>'). This would make life easier for people who don't know or don't care about the XML features of genmon and just want to show a bit of text in the panel. One more thing on my TODO list ...
I would be in favor of keeping script-writing as simple as possible (e.g, not telling the user to "use an xml sanitizer filter"). A <raw> tag accomplishes the goal unambiguously, and can be documented in the same place that <txt> is, so anyone who knows about <txt> will know about <raw>. If the writer doesn't know about <txt> (the use case you suggested where people just want to naively display some text), I would actually recommend disabling Pango entirely (e.g. use gtk_label_set_text if newVersion==0). Especially since you can control the font in the properties dialog, I doubt that anyone would notice that you can use Pango markup without having looked at the documentation, in which case they can see that they need to use <txt>. I feel that making a "smart" detector for Pango would simply make the "gotcha" even more obscure, and bite people at (even stranger) unexpected times.
(Apologies for posting twice.) The other thing to consider is existing script breakage. There are four types of scripts: 1) Scripts that do not use <txt> and do not want Pango markup. (#1) 2) Scripts that do not use <txt> and expect Pango markup. (#4) 3) Scripts that use <txt> and do not want Pango markup. (#2) 4) Scripts that use <txt> and want Pango markup. (#3) The #'s at the end are my guess as to the popularity of that kind of script, with #1 being most popular. Perhaps #2 and #1 are swapped. Current version: Scripts 1 and 3 are broken. Possible changes: A) Adding a <raw> tag: Script 1 will remain broken (assuming B is not done). Script 3 will remain broken until the developer/user notices the existence of <raw> and updates their scripts. New users creating 3 will use <raw> and will have working scripts. B) Removing Pango markup for simple scripts: Script 1 will automagically be fixed. Script 2 will be obviously broken (it will display the pango tags). User will check the docs (since their script obviously broke) and see that they need to switch to <txt>. They will fix their script. This does not affect 3 or 4 (can do A as well). C) Making a <pango> tag, and making the current <txt> tag mean raw text. Script 3 will be automagically fixed. Script 4 will be obviously broken (it will display the pango tags). For the same reason as in B, the user will fix their script to use <pango>. This does not affect 1 or 2 (can do B). Now that I consider this, I would actually recommend B and C: making a <pango> tag and making <txt> and old-style interpreted as raw text. Scripts 1 and 3 will be fixed (users may not even realize their script was broken before), and 2 and 4 (which I believe far rarer) will break in a very obvious way that is easily remedied when the user checks the docs. Using the attached patch does not help the people who do not realize why their script is broken (since the issue is rare and hard to catch).
Created attachment 4200 Add an explicit pango tag and assume other text is raw. Applies my recommendation.
Created attachment 4202 Fix for incorrect text offset in recommendation Whoops, forgot to change the text offset. This patch works.
I don't think this is the right approach. The reason for expecting text between the XML tags to be XML-encoded is not specifically to allow Pango markup (though that is a cool side effect) but simply because you can't expect to put raw text within XML without messing things up. Certain characters (for example, '&', '<', '>') have special meanings in XML; that's why they must be escaped. Summary: if you want to use the XML tags, you have to XML-encode your text. The problem that needs fixing is that Genmon doesn't behave as it is documented[1]: "If you want the plugin to display only text (original version), enter the command in the Command field of the Property section of the plugin." My interpretation of this is, as I suggested before, that if there are no XML tags in the input, then Genmon should assume that it is *not* XML-encoded. The simple fix: change gtk_label_set_markup() to gtk_label_set_text(), but only within the "if (newVersion == 0)" block. [1] http://goodies.xfce.org/projects/panel-plugins/xfce4-genmon-plugin
Joseph, please see if this fix works for you: http://git.xfce.org/panel-plugins/xfce4-genmon-plugin/commit/?id=14640c291ad12d4ae822cc24e98e0c2bc8ab48cd
As a heavy user of Genmon, I don't really see the <txt> interface as XML so much as it is simply a set of sentinel strings that mark sections of the command's output, hence the surprise that & didn't work. I'd like to be able to make scripts as simple as possible while still being able to use the full features of Genmon, which includes not requiring escaping when the only things we have to avoid in practice are the strings </txt>, <img>, <tool>, <cmd>, and <bar>. It's really no different from the non-"XML" version requiring you to avoid having <txt>.*</txt>, <img>.*</img>, etc in your output. My two cents is that I'd prefer ease-of-scripting over the fuzzy feeling knowing that my "XML" is true XML any day :)
Mass-reassign all bugs from florian@ to goodies-dev@, thanks for the maintenance work! (and sorry for the bugmail spam..)
Testing this now with the 4.x series, the original example works fine.I'm not sure that this bug report is relevant anymore. I'm going to close it, but please re-open if you feel the issue is not resolved.