On Sat, 30 Oct 1999, Alexander Larsson wrote:
> Well, what you say is true. But the reason i don't like the way of
> solving this is:
>
> 1) It doesn't scale. Most probably a lot of connection types for different
> kinds of objects will pop up as more dia objects get written. If each of
> these add just *one* property to the line object in order to draw their
> special stuff the Line object will be very big and bloated. The code will
> be large and hard to understand, and the saved files will be very big. The
> user will also have a hard time using the Line property dialog since it
> contains very many options and properties.
The saved files needn't be that big ; for instance, if you apply my code
(on a throw-away tree), draw a zig-zag line, keeping the corner radius to
its default of 0.0, save the file and look at the result, you'll
(normally) find exactly the same file as without my code.
> 2) It's a developer solution, not a user solution. (At least given how i
> think Dia should be used, which might not be true of course, but is
> nevertheless my idea of Dia.)
>
> The user wanting to do a Entity Relationship diagram (taking an example
> currently in Dia), so he selects the ER sheet. He then wants to create a
[snip]
> lines, which are never used in ER diagrams. He doesn't even want to select
> between "single" or "double" lines, because it would make it harder to
> understand how to create a total participation.
If I follow your logic, we'd have to get rid of
1) the standard objects (not specific enough)
2) the xml shape support code (at least in its current form).
1) because they're not task oriented but require the user to think about
what s/he wants to draw (they require her/him to actually know the
graphic syntax of the diagrams used, which is IMHO not that big a
requirement). If diagram "foo" requires solid lines without arrows, then
let the sheet for diagram "foo" provide solid lines without arrows. Then
let other sheets provide lines with arrow on one end, lines with arrow on
both ends, etc.
2) Have you ever opened the object properties for a shape-defined object ?
In fact, the whole issue boils down to solving (destroying ! not finding a
compromise ) the contradiction between :
- user wants a lot of features
(to draw things
programmers hadn't time to code)
- user wants only the features useful right now
(to keep UI bloat down)
or more simply :
- feature "foo" is useful (in general)
- feature "foo" is useless (right now)
A few ideas, in raw form :
A - I'd kill to have inheritance at the compiler level (never mind)
B - an inherited object could disable the "editability" of some of
the ancestor's properties ; similarily, it could provide different
defaults to these properties, to minimise file bloat.
C - a library should be allowed to "re-brand" an object type by
peeking in the ObjectType records of another library, while possibly
modifying the defaults and/or editability status of properties (that may
introduce tricky dependency issues ; maybe a third step between
register_objects() and register_sheets() ?). Oh, well. C' - Since
libraries are never unloaded, a library could be allowed to snarf another
object's routines, at least in part.
D - currently, more than half of the code for an average object is
persistency and property editing. If properties are stored in a dynamic
array (such as a g_hash) [at the expense of the access time], most of this
code can be factored away ; More importantly, most of the boilerplate code
disappears. The specification for these properties could be done in an XML
file similar to shape files, which would basically say "object foo of
diagram bar uses underlying implementation baz, with the following
properties defined (and then follows the name, type, bounds, editability
and default value of each property). And this leads to :
E - get rid of register_sheets() ! Instead, use the XML shape
support and proposition D ; in essence, we'd de-couple the binary
implementation of an object from its invocation. When two different
objects (as seen by the user) could share their implementation (see UML's
"realises" and "generalisation" arrows, then two different XML
descriptions of the same implementation would be loaded, leading to two
different objects.
C' can be easily implemented right now ; as a proof of concept, I'll
modify my zigzagline patch to create a new "rounded zig-zag line" object
while just changing the zigzagline_draw() routine, and reusing the rest of
the code from zigzagline ; the two objects will be distinct.
(I'll keep the corner radius temporarily fixed, since I'll need D to make
the re-introduction of this property easy).
> I understand your point in that this wouldn't make Dia an ideal editor for
> diagram types that are not yet supported. I hope that in time most diagram
> types will be supported.
This requires removing the "1k lines an object" penalty so that people get
less reluctant to code new objects.
In short, what I think would be good (some of these points are not new !) :
- make the whole handling of sheet contents done via index.sheet
files
- make all potentially editable and persistent properties of a
binary object reside in a dynamic table rather than the object's struct.
That table of course has its place in struct Object. Each property has a
current and default value, an "editable/visible" flag, min/max/step
bounds (where applicable) and a human-readable name (what's put in the
UI's labels). A binary object must absolutely be able to cope with a
missing property, and "do the less stupid thing" in that case (with a
g_warning() )
- Put the specification of the properties in an object XML file,
which is invoked by index.sheet ; in essence, divorce the binary
implementation of an object from its use. Several XML "object" file can
share a single binary implementation, with different property defaults,
labelings, etc.
- replace the current menu midclick system with two functions :
foo_query_verb(object,verb) --> verb is active/inactive/unknown and
foo_execute_verb(object,verb,point) --> do what the verb says. The menu
itself is defined in the foo.object XML file, and is basically a mapping
between verbs (short strings in the C locale, implementation-defined) and
longer, human-friendly context-aware strings.
- Totally get rid of binary implementation when the shape support
is enough (this is already in progress)
- Allow binary objects to snarf bits of implementation on other
binary objects (this allows to limit forking, while keeping the option to
fork or partially fork where this doesn't make the code unreadable)
* at this point, most zigzag-like objects can be folded
back to a couple implementations, instead of a dozen, etc. More
interestingly, a power end-user can build new specific objects based on
the existing implementations, and a programmer can build objects with
brand-new behaviour much faster.
-- Cyrille
PS: back on the subject of rotating stuff : maybe it could be acceptable
to temporarily have the gtk renderer render rotated text letter by letter,
rotating just the baseline and not the glyphs ; once other projects (XFree
extensions, libart, gill or simply the pixmap hack previously described)
are in a useable state, they could be plugged in. And meanwhile, we'd get
rid of the circuit duplicates, and have the FS flow arrows much nicer on
PS output.
------------------------------------------------------------------
Oh, my god ! I'm trapped into a V90 modem ! PGP ID: A879BEF8
