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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
