> > John/James L./Andre:
> >
> > I like (and have argued for) the idea of a 'mini-DOM' API, based on a
> > subset of SVG, being used as the internal structure of these Ur-Shapes.
> > For the arbirary additional properties, we need a portable,
> > language-agnostic set of datatypes, which can come
Lennon Day-Reynolds wrote:
> John/James L./Andre:
>
> I like (and have argued for) the idea of a 'mini-DOM' API, based on a
> subset of SVG, being used as the internal structure of these Ur-Shapes.
> For the arbirary additional properties, we need a portable,
> language-agnostic set of datatype
John/James L./Andre:
I like (and have argued for) the idea of a 'mini-DOM' API, based on a
subset of SVG, being used as the internal structure of these Ur-Shapes.
For the arbirary additional properties, we need a portable,
language-agnostic set of datatypes, which can come from XML Schemas.
(N
> That's what I thought of. But the interface will have some extensions
> of which some might not be in a DOM (i.e. integer handling). The
> tree-handling interface would be as close as possible to libxml-DOM.
>
Great!
>
> > Since we are building our own tree then yes SAX is the way to go.
> One
> Andre,
>
> I think the general consensus is to use libxml for loading and saving only
> since libxml only supports text data and no way to attach extra data to
> nodes. We also want to build a mini-DOM interface for accessing UrShapes.
That's what I thought of. But the interface will have some
Andre,
I think the general consensus is to use libxml for loading and saving only
since libxml only supports text data and no way to attach extra data to
nodes. We also want to build a mini-DOM interface for accessing UrShapes.
Comments inline:
>
> Time for a few more thoughts:
> James has writ
James,
Ok, good we are on the right track now. What I need from everyone is a short
description on how
they want to help out in this effort so we can assign tasks and not duplicate each
other work. I
can basically manage this effort for right now - write the DTD's, assign tasks, code
reviews
> > From my perspective, the library that gets the UrShape off the
> > disk and into an instantiated object is the object to use. I'm
> > still hoping 1) not to do this alone and 2) not to write the I/O
> > code. The latter because I've done it so often it would feel like
> > work (or sleep).
On Wed, 20 Jun 2001, James K. Lowden wrote:
> I take the silence from everyone else to be anything this side of
> "are you nuts?" That is, they either agree or are taking a
> wait-and-see approach.
Well, in my case, it's rather the "agreed" approach, but I seem to
have lost the line of discussi
John,
I take the silence from everyone else to be anything this side of "are you nuts?"
That is,
they either agree or are taking a wait-and-see approach. For now, we're in. So let
me firm
up where I think we're going, you and I, at least.
> I think tables are harder to work with than nested
Ok well I'm just going to comment on the points I have some knowledge on. Comments are
inline:
"James K. Lowden" wrote:
> Recap
>
>
> There is some controversy over just how far the generic Shape property & behavior can
> be carried. As James said, "hand coding a property dialog for a few shape
Cyrille, James, Lars, Lennon, John, Andre, all
One of the difficulties faced by anyone approaching a new project is understanding its
technical design. In need of a top-down document that says "Here is the problem,
here's how we went about attacking it, here're the pieces and how they behave", o
James Henstridge wrote:
> As well as switching over to GObjects for the diagram objects, I would
> also like to see this switched over to GObject properties, which seem
> like a more flexible system, and have support for default values
> (which is something you were talking about adding to the c
Slightly off-topic, but very tempting...
Lars Clausen wrote:
>
> I won't be coding anything for the entire next week, as I am going
> off to Ragnarok http://www.dagorhir.com/ragnarok/>.
>From the web page:
"RAGNAROK STARTS ON MONDAY JUNE 18, 2001."
Aha! Good thing I was warned in the last m
Le ven, jun 15, 2001, à 01:05:29 +0800, James Henstridge a écrit:
> Hopefully properties will make it easy to have generic save/load code.
> We already have some generic code for this with the current propeties
> implementation, but in many cases, it doesn't quite duplicate the save
> format of t
On 14 Jun 2001, Lars Clausen wrote:
> On 14 Jun 2001, Lars Clausen wrote:
>
> > On Thu, 14 Jun 2001, Andre Kloss wrote:
> >
> >> On 14 Jun 2001, Lars Clausen wrote:
> >>
> >>> The reason for GUIs to have the equal-spacing setup is that the actual
> >>> widget layout may be determined by somebody
On Thu, 14 Jun 2001, Cyrille Chepelov wrote:
>
> James,
>
> Part A) I'll begin by summarising the various kind of objects we had in this
> project ; the evolution of "how to write objects" is IMO interesting and
> pretty much explains what I think about the project.
>
> We have had no less than f
On 14 Jun 2001, Lars Clausen wrote:
> On Thu, 14 Jun 2001, Andre Kloss wrote:
>
>> On 14 Jun 2001, Lars Clausen wrote:
>>
>>> The reason for GUIs to have the equal-spacing setup is that the actual
>>> widget layout may be determined by somebody else. I don't think we
>>> really need that here.
On Thu, 14 Jun 2001, Andre Kloss wrote:
> On 14 Jun 2001, Lars Clausen wrote:
>
>> The reason for GUIs to have the equal-spacing setup is that the actual
>> widget layout may be determined by somebody else. I don't think we
>> really need that here. Just using relative resizing is probably mor
On 14 Jun 2001, Lars Clausen wrote:
> The reason for GUIs to have the equal-spacing setup is that the actual
> widget layout may be determined by somebody else. I don't think we really
> need that here. Just using relative resizing is probably more useful and
> easier.
Agreed. Do you know where
James,
sorry for the slightly late answer ; as Nemo will tell you tomorrow
9:30am (my time), while I've had enjoyed almost two weeks with plenty of free
time, there are times where real work has to be done . What's good is
that in the mean-time, things have cooled and look technically much
On Thu, 14 Jun 2001, Andre Kloss wrote:
> On 14 Jun 2001, Lars Clausen wrote:
>
>> > 1. Abstraction of subshapes
>> Sounds good. Nothing problematic there.
> I'm glad you like it ;)
>
>> > 2. Subshape-Arrays
>> With this comes the possibility of multiple levels of nesting and
>> resizing based
On 14 Jun 2001, Lars Clausen wrote:
> > 1. Abstraction of subshapes
> Sounds good. Nothing problematic there.
I'm glad you like it ;)
> > 2. Subshape-Arrays
> With this comes the possibility of multiple levels of nesting and resizing
> based on contents. Fortunately, there's been a lot of rese
On Thu, 14 Jun 2001, John Palmieri wrote:
> Of course we must first work on layout and then move on to designing a
> way to deal with functionality; so this is all a quick snapshot of what
> the future may hold. It is just an idea of what I am think of. As for
> waiting till Gtk-2.0, you have a
>
> The latter, in my mind. While the looks of the UML object can be made with
> the above-mentioned SVG extension, the functionality of the attributes,
> operations and interfaces are more complex than would be workable in XML.
>
> The rework that would be nice at some point (probably after GTK
On Thu, 14 Jun 2001, James K. Lowden wrote:
> Cyrille Chepelov wrote:
>
>> if you show me a shiny new dia core, with DOM as its kernel, and the
>> resulting stuff is not only as featureful (including all current object
>> types) as the "classic" dia of then, but also naturally is able to
>> rel
On Thu, 14 Jun 2001, Andre Kloss wrote:
> Hi folks.
>
> I think there are exactly 3 extensions for the custom XML shapes that
> would be extremely useful when it comes to extending this shapes'
> usability:
>
> 1. Abstract from textboxes. XMLshapes should be able to contain
> multiple sub-shape
Andre, that is exactly what we want to add.
Ok, well here is a new proposal that should make most people happy for the
time being. All the SVG extensions will be handled by a new shape code
and will not effect the core of dia. I think the SVG stuff is handled by
the generic shape. Am I correct
Hi folks.
I think there are exactly 3 extensions for the custom XML shapes that
would be extremely useful when it comes to extending this shapes'
usability:
1. Abstract from textboxes. XMLshapes should be able to contain
multiple sub-shapes (As long as they're rectangle-shaped). One simple
shape
Cyrille Chepelov wrote:
> if you show me a shiny new dia core, with DOM as
> its kernel, and the resulting stuff is not only as featureful (including all
> current object types) as the "classic" dia of then, but also naturally is
> able to reload older files (though it might be through an incomp
> Netscape 4.X does not use JavaScript to render (except pages that use
> JavaScript, but I tend to avoid them and run with JavaScript turned off).
> Mozilla, however, uses XML internally to define everything, including
> menus, dialogs and rendering, and it's annoyingly much slower than
> Netscap
Le mer, jun 13, 2001, à 12:14:26 -0700, Lennon Day-Reynolds a écrit:
> Just for comparison, let's take the following snippet of code. If
> objects in Dia were internally represented using the libxml tree
> interfaces, then the following would work as a 'get_state' function for
> *all* object t
Lars Clausen wrote:
> On Wed, 13 Jun 2001, Lennon Day-Reynolds wrote:
>
> > Okay, I just have to weigh in here...this looks like too much fun.
> >
> > Cyrille Chepelov wrote
> >
> > > Anyway, if you prove me wrong with working code (I've got a P133 to
> > > check the speed side...), then alri
On Wed, 13 Jun 2001, Lennon Day-Reynolds wrote:
> Okay, I just have to weigh in here...this looks like too much fun.
>
> Cyrille Chepelov wrote
>
> > 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 [:-)]
Okay, I just have to weigh in here...this looks like too much fun.
Cyrille Chepelov wrote
> 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.
Just for comparison, let's tak
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
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
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
Hmm, ascii art doesn't seem to work well. Hopefully you get the idea.
-J5
___
Dia-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/dia-list
Well, I was racking my head for a simple algorithm that could be used
for layouts involving dynamic shapes (ie UML shapes that "grow" when
data is placed in them). I hadn't realized how simple the algorithm
could be. First off I must introduce the concept of a container shape.
Container shapes w
40 matches
Mail list logo
