[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XML GNUstep defaults (was: [flame] NEWS file is useless)

From: Richard Frith-Macdonald
Subject: Re: XML GNUstep defaults (was: [flame] NEWS file is useless)
Date: Fri, 27 Nov 2009 08:39:05 +0000

On 26 Nov 2009, at 17:35, Wolfgang Lux wrote:

> Richard Frith-Macdonald wrote:
>>> I think directly ~/GNUstep/Defaults/.GNUstepDefaults ?
>>> That's XML for me now and it wasn't.
>> Oh, that's a hidden file for private use by the base library ... kind of 
>> surprising that anyone would notice, and certainly not something which 
>> should appear in news/release notes as it's internal information.
> Indeed, one shouldn't notice -- except that there was a bug in 
> NSPropertyList.m, which did use an incorrect translation for ASCII control 
> characters (it was using the old Java \Uxxxx notation instead of numerical 
> character encodings). Due to this bug the position of menus was no longer 
> persistent. I've just committed a fix for this in svn and now torn-off menus 
> will reappear again the next time you start an app.

I partially reverted that ... the code to generate the escape sequences was 
correct, the problem was a failure to parse them on reading the result back.

The underlying issue is that certain characters are illegal in XML, even when 
encoded using the &#...; syntax!
The list of illegal characters includes ascii code 27 (escape), yet OSX uses 
the escape character as the key for the top-level menu.
If you feed such data to a proper XML parser (such as libxml2), it will abort 
parsing when it encounters the illegal character.
The OSX property list parser is not actually an XML parser .... it's really 
handling something which just looks a lot like XML.
So the use of the \U... syntax was/is there to encode characters in property 
lists, hiding them from the XML parser ...
then the property list parser needs to decode these sequences after the XML 
parser has done with them.

Now, we have a (rather immature) XML parser in base which is currently being 
trialled as a replacement for libxml2.  It treats all characters as legal and 
can therefore handle property lists containing illegal characters.  So perhaps 
we can remove the additional encoding of illegal characters.
The question is, do we want to write illegal XML in property lists?  At the 
moment the code can write legal XML or illegal (OSX compatible) XML depending 
on the OSX compatibility defaults setting.  If we assume that 'XML' property 
lists will never actually be processed by real XML parsers, we don't need the 
additional encoding.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]