[Chandler-dev] Use of ConfigParser for styles

[Philippe Bossut]

Hi,

It occurs to me that there are several points right now where we are 
dealing with "Styles" and implementing ad-hoc solutions:
- some i18n issues 
(https://bugzilla.osafoundation.org/show_bug.cgi?id=3824) (Markku)
- code in parcel/osaf/framework/blocks/Styles.py (Bryan)
- newly added code by Jeffrey in application/styles.py (Jeffrey)
- a generic task to come up with a style mechanism 
(https://bugzilla.osafoundation.org/show_bug.cgi?id=2981) (John)
- a Wiki page proposing a plan to address the issue of Styles 
(http://wiki.osafoundation.org/bin/view/Projects/StylesProject) (Jed)

Looks like it's time to tighten a little those different threads before 
we create a tangle of disparate solutions. Some elements of history and 
engineering first:
- there is a component in Bugzilla to hold those Styles issues: "Styles 
and Appearance"
- this component was owned by Jed and is now owned by John
- John is the driver/coordinator for this issue

That being (re)established, some comments on what we have so far:
- The Wiki document is more a declaration of intent and a list of issues 
than a road map for implementation. It gives a good idea though of the 
problem at hand (and why we think it is a problem).
- The code in parcel/osaf/framework/blocks/Styles.py compensate the font 
size disparity among the different platforms. It doesn't provide 
designers or users a way to modify the styles coded in Chandler. That 
was not its objective. Nevertheless, it addresses a pesky problem and 
should be taken into account in whatever "styles" solution we come up with.
- The new application/styles.py is based on the Python ConfigParser 
(http://docs.python.org/lib/module-ConfigParser.html). The idea is to 
give user (or designer) a way to specify data using a syntax similar to 
Python but much more forgiving. For the moment, it's used  by Jeffrey in 
a very ad-hoc way but we should consider if this is something we want to 
generalize application wide.
- Whatever we do with Styles, we need to take OS wide user specified 
data into account. That's the intent of bug 3824 and is important for 
i18n (default font different in each language) and accessibility (colors 
and font sizes in particular set desktop wide by users with vision 
handicap).

My comments: I like the use of ConfigParser introduced by Jeffrey. It 
solves the problem of the "style file" introduced by Jed in his Wiki 
doc, avoiding reinventing the wheel (or CSS...) and staying close to 
Python. Basically, all it does is externalize some (name,value) pairs 
that we would code in Python a way or another. I can see such a 
mechanism used more generally throughout the application though we need 
to decide on some elements of code design:
- What about proliferation of .conf files all over the place? This could 
go against the reuse of well known styles application wide. Also it 
would make the job of designers difficult and miss the original intent 
of styles. That's where we need a coordinated approach here (John?)
- We can't avoid to have .conf files for some parcels though: especially 
the 3rd party ones using some yet unknown style. So, how do we cascade them?
- i18n: colors and fonts in particular are very much tied to 
localization. Will we put such .conf files in translation eggs? I'd say 
yes but that's something else we need to discuss
- Are we somewhat reinventing resource files? (looks like it really...) 
Is there a better well known Python alternative to conf files? A 
wxWidgets/wxPython way of doing this?

Cheers,
- Philippe