[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Shapes layout proposal

Well the whole point of putting everything in XML is that there is a consistent
scripting interface (the DOM) and XML separates the logic from the data.  Hard
coding only allows access to API's that the developer thought of including.
Sure you can create an object model so that all objects created in C conform to
an API but that is just reinventing the wheel.  Imagine if HTML was an api in
C.  Shapes are data and data shouldn't be coded in C.  Actions and behaviors
should be coded in C or for that matter any language you choose.

>C coded objects aren't "hard coded". A simple recompile and their behavior
is changed...

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.  Not to mention other programs
can utilize the code for things you may have not thought of.  I know my way
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.

As for your worries, I am working with someone else and we will provide a proof
of concept patch before we ask for CVS access.  On that note I would like to
hear your "specific" concerns so that I can address them and perhaps use the
feedback in the design.

-J5



Cyrille Chepelov wrote:

> Le mar, jun 12, 2001, à 03:59:25 +0100, John Palmieri a écrit:
>
> > While this doesn't answer all layout questions it seems like a good
> > start to getting rid of hard coded shapes (I'm thinking of UML) and
>                   ^^^^^^^^^^^^^ ^
> > pushing dia to become a pretty nifty frontend/widget for a wide range of
> > development tools.
>
> You're not actually saying that C-coded objects are evil, aren't you ?
>
> C coded objects aren't "hard coded". A simple recompile and their behaviour
> is changed...
>
> Really, designing a DTD complex enough to totally describe the behaviour of
> all the objects we have (remember we don't have just UML... unless you can
> make a chronoline out of XML stuff, I'm not sure I'll like all the
> complexity your system looks like it'll bring) and then designing the XML
> representation of these objects might prove to bring a result much more
> complex than a simple (shapes for easy stuff ; C for more complex stuff)
> dichotomy (however, enhancing the properties code to encompass UML Classes
> is certainly a good thing to do. While keeping old files readable...).
>
> Oh well. Maybe you'll make me eat my words one day. That'll be an
> interesting thing to watch, anyway.
>
>         -- Cyrille
>
> --
> Grumpf.
>
> _______________________________________________
> Dia-list mailing list
> Dia-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/dia-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] Mail converted by Mofo Magic and the Flying D

 
All trademarks and copyrights are the property of their respective owners.

Other Directory Sites: SeekWonder | Directory Owners Forum

GuideSMACK