Le 5 décembre 2018 18:32:47 GMT+01:00, Steve Litt <sl...@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 _______________________________________________ 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
