[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.
- [flame] NEWS file is useless, Wolfgang Sourdeau, 2009/11/25
- Re: [flame] NEWS file is useless, Riccardo Mottola, 2009/11/25
- Re: [flame] NEWS file is useless, Richard Frith-Macdonald, 2009/11/25
- Re: [flame] NEWS file is useless, Richard Frith-Macdonald, 2009/11/25
- Re: [flame] NEWS file is useless, Riccardo Mottola, 2009/11/25
- Re: [flame] NEWS file is useless, Richard Frith-Macdonald, 2009/11/26
- XML GNUstep defaults (was: [flame] NEWS file is useless), Wolfgang Lux, 2009/11/27
- Re: XML GNUstep defaults (was: [flame] NEWS file is useless),
Richard Frith-Macdonald <=
- Re: XML GNUstep defaults (was: [flame] NEWS file is useless), David Chisnall, 2009/11/27
- Re: XML GNUstep defaults (was: [flame] NEWS file is useless), Lars Sonchocky-Helldorf, 2009/11/27
- Re: XML GNUstep defaults (was: [flame] NEWS file is useless), Richard Frith-Macdonald, 2009/11/27
- Re: XML GNUstep defaults (was: [flame] NEWS file is useless), Lars Sonchocky-Helldorf, 2009/11/27
- Re: XML GNUstep defaults (was: [flame] NEWS file is useless), Richard Frith-Macdonald, 2009/11/27
Re: [flame] NEWS file is useless, David Chisnall, 2009/11/25