On Aug 10, 2005, at 11:25 AM, Bryan Stearns wrote:
I'm looking forward to declaring UI elements in Python because
Python is much more flexible and concise than XML. For instance,
if you look at the detail view's parcel.xml today, you see a lot of
the same structures (like "an area containing a label and an
attribute editor") and constants (like the borders around various
blocks).
I was under the impression that one would be free to mix python
declarations & cpia xml. Using python for something complex like the
detail view would be quite useful, but for a hierarchy of a dozen
menus & menu items cpia xml could be useful.
I'm also imagining CPIA XML to use for little fragments you load in
installParcel() python then swap around places -- for example, define
a dialog UI in one little cpia xml file, then save the block tree to
an array of dialog blocktrees somewhere, or something like that.
So I know that everyone here dislikes or hates parcel.xml, but it did
manage to do one thing: abstract away the parcel loading process into
a declarative system. It was successful enough that I, a chandler
semi-newcomer, didn't really understand anything about the parcel
loading system for months even though I was hip deep in CPIA
refactoring the calendar UI into CPIA blocks. Everything I wrote was
either declarative parcel.xml, or else methods on the python Kind
classes.
I guess you all understood parcel.xml was an abstraction, and had
more experience where the abstraction broke down, but I was thinking
in terms of it enough that the lower-level procedural approach
installParcel() was a bit counterintuitive for a while.
There's TWO types of python code: (1) installParcel() loading code,
and (2) declaration of Kind classes. You're always going to have to
do (2), but either CPIA XML or a GUI builder could replace (1). (For
the CPIA XML you'd need 3 lines of boilerplate installParcel() of
course.) In either a GUI builder or CPIA XML world, a new developer
could get away with only writing python class/Kind declarations, and
then if they wanted to do something advanced (like the detail view)
they could learn installParcel() -- which makes sense because it's
lower-level & procedural.
that story is basically how I learned things over the past few
months, though it would have been much nicer with cpia xml instead of
parcel.xml. None of my UI work involved complex manipulations or
patterns of blocks, so if installParcel() had never come out, I still
would've been happily thinking in declarative terms today.
Brendan
The thing I hate most about parcel.xml is that there's no way for
me to represent or encapsulate this repetiton; the new proposal
suffers from the same problem. Declaring things in Python will let
me parameterize generation of these elements. (Getting names of
blocks right is trivial, but getting things to align consistently,
given native-control weirdness across platforms, has consumed
inordinately-huge amounts of my time.)
...Bryan
Alec Flett wrote:
I feel like folks are leaning towards pje's python .update
mechanism as the GUT of item declaration.. and I think that's a
mistake and I think its because people feel burned by parcel.xml.
Its the underlying API sure, but if we never HAD parcel.xml, I can
guarantee you that I wouldn't be the first one to say ".update()
is really tedious for the UI - lets find a simpler way to declare
this stuff.. what about xml?"
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
