Well, i can't say anything much wiser than 'Works For Me'
Could you also provide some output when run in console mode (start the deskbar with -w option) ?

ok i did it :

 /usr/Gnome-2.14/lib/deskbar-applet/deskbar-applet -w
Running installed deskbar, using [/usr/Gnome-2.14/lib/python2.4/site-packages/de skbar:$PYTHONPATH]
Data Dir: /usr/Gnome-2.14/share/deskbar-applet
Handlers Dir: ['/home/eloi/.gnome2/deskbar-applet/handlers', '/usr/Gnome-2.14/li b/deskbar-applet/handlers']
Binding Global shortcut <Alt>F3 to focus the deskbar
Starting Deskbar instance: <gnome.applet.Applet object (PanelApplet) at 0xb6499c d4> None
Layout changed to 1

XML-CRITICAL **: Input is not proper UTF-8, indicate encoding !
Bytes: 0xE9 0x66 0xE9 0x72

aborting...

i also did a rm -fr /home/eloi/.gnome2/deskbar-applet/handlers
just to check if it was from my conf

no the issue still the same

note i use libxml-2.0 2.6.22

Regards

Well, i'm a bit confused here, this has never been brought up before, and i definitely don't see it here.. I don't know what we should do !

Probaby you can try cleaning everything and restarting from scratch ? Other than that.. i can't say many more unfortunately seems like a libxml problem anyhow

I can confirm this bug. It crashes with same critical xml message. Today I found, that running it with LC_ALL=C solves the problem. So, propably only non english deskbar-applet users are affected (my default setting is pl_PL)

i confirm the LC_ALL variable issue but for me it only cashes when this variable is undefined then when i set it to fr_FR or C or anything it works well
thus i've updated my profile to take care of this
thanks

could i close it ? 
Because it's not due to a deskbar-applet bug but a missing environment variable

Closing as invalid, since this is not a deskbar bug but some obscure lang bug affecting one of the libraries in the stack..

Wait wait wait...

when you set LC_ALL to 'pl_PL' it crashes, when i set it to 'fr_FR' (i made a mistake in my last comm) it also crashes but when you set it to 'C' or when i set it to 'fr' it works properly

i read the locale manpage and i saw that if LC_ALL set to a non-empty string value, override the values of all the other internationalization variables

so
do we need to only set internationalization variables with the two first alphabetical characters ?? (the manpage(s) i read say no)
is it reproducible with all locales ?? (i think yes pl/pl_PL fr/fr_FR)
is it an deskbar only bug ?? (maybe no, but it worked well some weeks ago with the same locale configuration)
is it an libxml2 bug ?? (i think no)

that's why i think this "bug" is not yet resolved invalid it's only fixed by playing with locales variables

i've checked my locales and recreated them according to my conf
then deskbar works without problem, the fact is
as deskbar get better with time it won't work on system where defined locales are missing, you were true it wasn't an deskbar bug

Best regards
Eloi Primaux

It's not a missing enviroment variable!. My LC_ALL is _always_ set to pl_PL, and only 2.13.92 version is affected. I've just checked 2.13.{90,91} and it works perfectly in same enviroment (running libxml2 2.6.23 since 06.01.2006).

you're true and if you want to make it work you should check if you have all yours locales, i mean : if the /usr/share/locales/pl_PL exist and is populated, in doubt do this : localedef -i pl_PL -f ISO-8859-1 /usr/share/locale/pl_PL
this will recreate your pl_PL locale and deskbar will work correctly

My locales are generated properly. Setting LC_ALL is propably not best solution, so I've changed my .zshrc. LC_ALL is not set at all, only LANG is set to pl_PL, but deskbar-applet still crashes. Next try was setting LANG to pl_PL.UTF8 (default pl_PL encoding is ISO-8859-2 aka Latin2). Strange, but it works! Why deskbar-applet assumes that my default encoding is UTF8? So, I guess that something changed beetwen 2.13.91 and 2.13.92 that touches some parsing methods or something like that. The problem is: I'm not a python hacker, so making a vim -d will be propably pointless (I will try anyway ;>)

Can i stress that it isn't directly a deskbar bug, since deskbar by itself doesn't manipulate any of these variables.

I know it uses lignome-desktop which might be affected, it also uses a lot of libraries to manipulate xml, python stuff, glib stuff, blah blah..

Maybe...  maybe not...
 But as far i understood this "bug" (which is not a bug) is due to some missing system locales, which make xml interpreters to fallback to C with incompatible system defined internationalization variables like LANG LC_TYPE ... .
This is,(i think) how the bug appears.
I don't think there will be an user friendly way of doing, to track and fix misconfigured systems and missing locales.
As an example my first system was an LFS-3.1, i have now an 6.1 (since a year) but locales setting has always been (for me) something from the dark side. And i never had any clue (or time) of how to do it correctly. This was, because none of all the applications i was using then, had issuing to me something like deskbar did.
In fact, i can say: "thanks to deskbar's trouble, i was able to fix my locales and now i have a clue of how to do it."

And to answer you, no i don't think you should stress with it.
But may i suggest you to put a sentence dealing with it in a FAC or the README, since locales setting is not deskbar's goal.

Regards

So, I've made a small investigation. Copying old Deskbar_Applet.xml (from 2.13.91) over file from 2.13.92 solves the problem.
Only difference is:
<menuitem name="Clear" verb="Clear" _label="_Clear History" pixtype="stock" pixname="gtk-delete"/>
And problematic place is white space between _Clear and History.

Why is it problematic ?

It is problematic, because it causes a crash (removing white space solves the problem)

One more:
replacing _Clear History with _Clear\ History solves the crash too.

Well then it's clearly a libbonobo-somewhere bug, that's parsing the bonobo xml file ?

It not so clear, libbonoboui works without smallest problem (there is small 'hello-world' test-program in tarball, I've just added some white spaces to _label and it works and shows such label properly).
Same test is present in gnome-python package. It works too, but everything after white space in _label is not shown.
Seems like bonobo.ui from gnome-python 2.12.x won't work with bonoboui 2.13.x properly (there is no gnome-python release for GNOME 2.14!).

From
"""
XML-CRITICAL **: Input is not proper UTF-8, indicate encoding !
Bytes: 0xE9 0x66 0xE9 0x72

aborting...
"""

I can only deduce that probably the french translator has put a message not in UTF-8 in the translation for "_Clear History".  Changing this string in the UI solves the crash because gettext no longer finds a translation therefore uses the original string which has no UTF-8 problem.

PS: there is no need for a new release of gnome-python for GNOME 2.14; unless people request new features or APIs, branching gnome-python is pointless.

If translation of a string from Deskbar_Applet.xml contains special UTF8 characters deskbar-applet crashes. Yes, it crashes with properly encoded string!
I've ripped out special chars from "_Clear History" translation and it works.
And it crashes *only* on that xml bonoboui file. For example de.po translation contains not UTF8 chars and only a warning is shown:

/usr/lib/python2.4/site-packages/deskbar/ui/DeskbarPreferencesUI.py:12: GtkWarning: Failed to set label from markup due to error parsing markup: Fehler in Zeile 1, Zeichen 9: UngĂźltiger UTF-8-kodierter Text
/usr/lib/python2.4/site-packages/deskbar/ui/DeskbarPreferencesUI.py:12: GtkWarning: Invalid input string
/usr/lib/python2.4/site-packages/deskbar/ui/DeskbarPreferencesUI.py:77: PangoWarning: Invalid UTF-8 string passed to pango_layout_set_text()

I've tested one more time hello.py from gnome-python tarball. I've changed _label="_About..." in Bonobo_Sample_Hello.xml and replaced "About" with some UTF8 special chars and it works without any warnings... 

Well it seems that the UTF-8 war isn't yet finished, thus i writted a small script to convert any file to UTF-8:


#!/bin/bash
# Begin iso2utf8 script
# use : iso2utf8 file
# eloi AT bliscat DOT org

cat "$1" | iconv -f UTF-8 -t UTF-8 >/dev/null
if [ $? = 0 ]; then
	echo "$1 is UTF-8"
	exit 2
fi
# The first matching ISO will be used
  CLIST="ISO-8859-1 \
	ISO-8859-2 \
	ISO-8859-3 \
	ISO-8859-4 \
	ISO-8859-5 \
	ISO-8859-6 \
	ISO-8859-7 \
	ISO-8859-8 \
	ISO-8859-9 \
	ISO-8859-10 \
	ISO-8859-11 \
	ISO-8859-13 \
	ISO-8859-14 \
	ISO-8859-15"
for i in $CLIST; do
cat "$1" | iconv -f $i -t $i >/dev/null
if [ $? = 0 ] ; then
	iconv -f $i -t UTF-8 "$1" >"$1.utf-8"
	mv "$1" "$1.old"
	mv "$1.utf-8" "$1"
	echo "$1 converted to UTF-8"
	exit 2
fi
done
# End iso2utf8 script

This is very nice try, but pl.po is _correctly_ encoded in UTF-8.

Can you try to add

gettext.bind_textdomain_codeset('deskbar-applet', 'utf8')

after line 41:
     41 gettext.textdomain('deskbar-applet')
in deskbar/deskbar-applet.py

and see if it works..

still same critical warning. critical warining...?
How could I be so stupid :\

% G_DEBUG='' /usr/lib/deskbar-applet/deskbar-applet -w
Running installed deskbar, using [/usr/lib/python2.4/site-packages/deskbar:$PYTHONPATH]
Data Dir: /usr/share/deskbar-applet
Handlers Dir: ['/home/users/fritz/.gnome2/deskbar-applet/handlers', '/usr/lib/deskbar-applet/handlers']
Binding Global shortcut <Alt>F3 to focus the deskbar
Starting Deskbar instance: <gnome.applet.Applet object (PanelApplet) at 0xb626f43c> None
Layout changed to 1

(deskbar-applet:24850): XML-CRITICAL **: Input is not proper UTF-8, indicate encoding !
Bytes: 0xB6 0xE6 0x20 0x5F


(deskbar-applet:24850): XML-CRITICAL **: AttValue: ' expected


(deskbar-applet:24850): XML-CRITICAL **: attributes construct error


(deskbar-applet:24850): XML-CRITICAL **: Couldn't find end of Start Tag menuitem line 4


(deskbar-applet:24850): XML-CRITICAL **: Premature end of data in tag popup line 3


(deskbar-applet:24850): XML-CRITICAL **: Premature end of data in tag popups line 2


(deskbar-applet:24850): XML-CRITICAL **: Premature end of data in tag Root line 1

Loading module 'SieÄ' from file /usr/lib/deskbar-applet/handlers/web_address.pyc.

A visual result of this trick is: there is no right mouse click menu at all.

This is not reproducible, your locales may be corrupted:

I've created polish locale according of what you told me upper, and also created an user inwhich the environment is exactly the same as you reported (pl_PL) and the result is:
No errors, no error on special utf-8 character, no error whith deskbar even with the last release.

Then, sorry but it's your system which produce these errors.

Please could you recreate all your locales, i mean, everything including the C one.
Or more i think you should re-install glibc

note (it was fun to read gnome in polish)

I can reproduce this.

But, how could you explain that 'on my box' it was solved by recreating all locales ?

i've recreated the polish environment to track it, and i've seen no error

i also modified the pl.po file to volumtary insert a non UTF-8 character and also add and remove special UTF-8 characters, the results were the same (after had reinstalled deskbar;)) : no errors

i also reproduced this on the fr.po file, same result

i know that i'm not a developer and i may be wrong, but my experience has shown me that most of bugs i encountred were specific to my system.

But if it works here, with an LFS, shouldn't be working with the most of known distribs ?

i'll be pleased to try other tests, but i really think it comes from yours locales.

Regards

When i said no errors, i said no fatal errors

Try:
G_DEBUG=fatal-criticals /path/to/deskbar-applet/deskbar-applet -w

sorry, but this bug has nothing to do with locale settings (see my note about de_DE locale). deskbar-applet (or something used by d-a) can't parse translated UTF-8 strings from ../data/Deskbar_Applet.xml.h. Wrong locale setting causes fallback to C and problem disappears...

Created attachment 61102 [details] [review]
fix

Actually the locale.bind_textdomain_codeset call is enough to fix this bug, gettext.bind_textdomain_codeset doesn't make any difference.

patch attached in #32 solves the problem. :D Thanks Christian!

Cool, marking as fixed then !