On Sat, 30 Oct 1999, Cyrille Chepelov (home) wrote:
> On Sat, 30 Oct 1999, James Henstridge wrote:
>
> > I was more talking of wavy lines as a graphics primitive and wondering
> > which objects you needed the primitive for.
>
> Hmmm, okay, I mis-interpreted your post, sorry.
>
> OTOH, Dia has already dozens of types of "boxes with some text inside
> it". Now, dozens of "special kind of lines", each forking from the
> archetype. Indeed, there's already a big amount of code duplication in
> the project. The rationale behind adding a "line geometry" property to
> every basic object which draws line is to limit a bit that forking.
Yes, this is why the "base classes" element and connection exists.
The core idea of Dia is to have lots of "specialized" object that do
exactly what you want in a specific domain. This way, you (the user) don't
have to use some swiss army style general objects that have five million
settings of which 99% are illegal for the type of diagram you're drawing.
> > There are already a number of different line objects -- take a look at the
> > UML sheet for examples. If you need a wavy connecting line for a
> > particular type of diagram, it probably makes sense to create a new line
> > object.
>
> well, since that type of diagram I want to draw makes uses of only text
> and arrows (solid, dotted and wavy ones), I'll end up with a really useful
> and senseful one-object (wavy arrow) sheet (I can see the logic, such as
> in the Flowchart sheet ; and then, when the original line gets upgraded
> (or fixed, or tweaked), there's going to be a quite heavy work of
> retrofitting the changes into the forked objects. Ugh.). Besides, that
> sheet, while probably named "SFM", will contain, to an user who doesn't
> know anything about TRIZ just a simple wavy line, which might be useful on
> another page as well, and then here we fork again.
Well, there is nothing stopping you from having standard objects on you
specific sheet. The SheetObject is created using only string references
to the object just because of this.
I don't know anything about TRIZ or SFM, but i bet that all the properties
of the standard lines aren't usable (or even legal) in that kind of
diagram. I also think the user would rather see high-level options that
specify what type of "connections" there are, instead of focusing on just
selecting how thay are rendered.
> There must be a better way.
> An idea :
> We let dia drop the direct loading of binary libraries' objects
> into sheets. Instead, we handle the loading of a binary object into
> a sheet through the index.sheet mechanism (of course, this
> requires tweaking the DTD, but well). This would allow any new sheet to
> "re-brand" an already existing object type for a different use (if done
> properly, even the icon xpm should be overrideable).
This is already possible. Just create a SheetObject with references to
the other object (just names) and then call sheet_append_sheet_obj().
All object libraries are guaranteed to be loaded before any
register_sheets() function is called, so there should be no ordering
constraints either.
> And with ~/.dia/shapes, we let the user re-organise her/his sheets the
> way s/he want.
Having a user created sheet is something that i'd like. No need to do any
major changes for this though.
/ Alex
