GNOME.org
 

Re: Shapes layout proposal

Le mar, jun 12, 2001, à 05:39:56 +0100, John Palmieri a écrit:


That is like saying configuration files should be written in C or PNG should be
a series of putpixel commands.  Abstracting your data into XML files allows for
an easier to manage and more flexible program.  


Have you ever read libxml C code ? I prefer a thousand times a struct member
access rather than the contorsions lib/dia_xml.c has to do to access its
data, thank you.


Not to mention other programs
can utilize the code for things you may have not thought of.  I know my way


Using useful snippets of C code in another project isn't much more
complicated than a cut and paste thing, is it ? (assuming there's no problem
with data types, of course).


around a C file but I find it easier to look at an XML file and say what
functionality is missing to get what I need done.  As for your complexity
concerns, the way I am thinking of going about all this will not increase the
complexity of current shapes.  Their XML representations will stay the same.
If you want the extra layout functionality and widgets you can add it ontop.
Just like DHTML compliments HTML you are not force to write anything more
complex than <html><body>hello world</body></html>.  I could do a whole theses
on the advantages of using XML for data abstraction.  When I get the chance I
will write a research paper on the subject.


The proper equivalent of HTML files in dia terms is .dia files -- already
XML. Shapes and objects are the image in HTML land of individual visual
elements (ie, images, chunks of text, separators, from controls and tables). 
When you want to add on your site a special widget the W3C hasn't thought about, 
you basically write another object in a compiled language, which conforms to a
specific API (java applets / COM+Windows objects). DHTML isn't a silver
bullet, and it's very quickly pushing CPUs to their limit (see what happens
in the big Bugzilla query page when you select the dia module -- if your
code is going to make complex objects that slow, then no thanks !)

On the complexity side, I'm absolutely not worried about current *shapes*
(ie, static objects). They work already well, adding (yet another) a
standard way of accessing properties can't really hurt. What worries me is
your plan to "get rid of [objects]" in favour of an overextended shape
format. I claim that defining a file format able to have as much flexibility
as the current offering of binary objects and actually putting that file
format in use, and keep things open for new object types of wildly varying
appearance and behaviour (like the dynamic simulation display capabilities
someone wrote about a few weeks ago), is going to lead to XML files much more
complicated than the reasonably readable C files we have now (what _is_
needed is a general clean-up of the C files we have ; most objects still
don't completely conform to the StdProp interface, and would gain a serious
shrink by doing so).

The W3C hasn't defined a way to describe new controls in an XML-based
format, has it ? Perhaps there's a reason... 

One area where I see the XMLification might make sense, with DOM stuff and
scripting etc, would be to replace the current "define a struct and then
pass a pointer to a pair of big descriptive constant arrays" way of telling
the Properties code how the object's data look like with an XML-based
approach (keeping all behavioural stuff, ie selection, movement, updates, 
drawing in the C file). But I'm not sure that would buy much: again, the
problem of ease of access for the C side. However, one thing that could be
_very_ nice would be to build a DOM tree out of the existing PropDescription 
array. That would buy you DOM access on C objects which would still be defined 
the exact way they are now (finally, we have a relatively non-redundant of
telling the core what an object is). And _that_ would probably be a cool thing 
for scriptability.

Anyway, if you prove me wrong with working code (I've got a P133 to check
the speed side...), then alright, I would have been wrong :-)

        -- Cyrille

-- 
Grumpf.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]