Re: What's wrong with Dia the way it is?

[Thomas Harding <tom thomas-harding name>]

Le 5 décembre 2018 18:32:47 GMT+01:00, Steve Litt <slitt troubleshooters com> a écrit :

> What's wrong with Dia just the way it is? It works. It's exportable
> into Inkscape for conversion to SVG. 

Good point, but that also means to repeatidly rewrites by hand the diagram shapes and so on.

An UNIX way would be to implement a "Dia import" plugin for Inkscape.

> Sure, I have a few qualms with the way Dia works, mainly having to do
> with the relationship between text and shapes, but perhaps some good
> workaround documentation would settle that. I'd love to have
> Visio-quality diagram components, and perhaps if somebody writes some
> docs on how to make your own components with the connection points
> *you* want, that will be solved. 

/think the connection points would embed nodes like "special" scripts (as an array), next endpoint, former 
endpoint, (last) relation with endpoint.

We can imagine a typical scripts collection (encoded strings can embed anything, such as Python). All scripts 
would have an id on diagram, but moreover a "name" and "version" you can refer, and especially having a 
"local" scheme if customized.

One thing impairing shapes development is that anything dynamic involves C.

I think the used shapes would be embedded as "not visible" in a properties path, 
then the rendered shapes on diagram would use xml id / path. So, scripts would control how to 
add/delete/modify a node  and its properties, and what to pass to parent node. That needs shapes to be 
rewritten really consistent regarding xml.


> Plus the fact that if everyone
> authoring new components puts them together in an online hierarchical
> library, perhaps with keyword search, our diagrams could start to rival
> those of visio users.

There were attempts to create shapes libraries (actually, they are), but the only way to get a consistent 
collection would be a branch in Dia git for that, with a QA process (such as bug reports).
/plus a document oriented database (json is back in discussion) (because it is fast enough), read-only for 
end-users.




> If some of the libraries used by Dia are in the process of being
> deprecated, then those certainly must be replaced by their successors.
> But other than that, why the emphasis on maintenance? Sometimes
> something's so good it needs no more maintenance (fetchmail is one
> example).
>
> Right now Dia works for people on all sorts of computers. It's very
> DIYable. My experience has been that in many cases, people in a hurry
> to "improve" software end up making it into a buggy, DIY-not-allowed
> monolithic entanglement.
>
> SteveT
>
> Steve Litt 
> December 2018 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
> _______________________________________________
> dia-list mailing list
> dia-list gnome org
> https://mail.gnome.org/mailman/listinfo/dia-list
> FAQ at http://live.gnome.org/Dia/Faq
> Main page at http://live.gnome.org/Dia

-- 
Je suis née pour partager, non la haine, mais l'amour.
Sophocle, /Antigone, 442 av. JC