Just to support the point made below about Dia as a component of a wider workflow. The ability to extract the definition data from a diagram easily was the major reason I chose to use Dia. The python interface is simple and exposes all the content in a clear object oriented way. I looked at Visio but the interface was horribly complex to understand.
I hope Dia continues to survive ... Rob > On 4 Dec 2018, at 14:44, Alejandro Imass <aim...@yabarana.com> wrote: > > > >> On Tue, Dec 4, 2018 at 5:22 AM Eduard Nicodei via dia-list >> <dia-list@gnome.org> wrote: >> I don't think we need to argue. Alejandro's comment however raises an >> important issue: "what are Dia's competitors"? >> >> I think actually Dia can live alongside online diagram editors such as >> draw.io and formats such as XML/SVG have nothing to do with it. >> >> The reason why I have used Dia in the past is that I could not find any >> other solution for the following requirements: >> >> - be fully offline (draw.io & co fail this - plus I'm not trusting them with >> any work-sensitive material!) > > The main advantage for DIA IMHO is being able to integrate the drawing into > another workflow. For example UML Class diagrams into SQL DDL or imagine > Ladder Diagram to IEC 61131. If the purpose is just to vector-draw with > templates, then DIA has little hope for the future. IMO it must focus on the > ability to turn the diagram objects into other information and provide APIs > to this. That is why I’m suggesting a complete revision on both the purpose > and the architecture. > > React is not “ fancy shit” but a way to write JS that can create complex and > maintainable apps. Why JavaScript? Well the reasons are obvious, and of > course it could work “off-line”. But better than that is that it would be > truly universal and run in any JS container. The back-end should be clean and > portable, and perhaps it could also be JS. The idea of the back-end is to > provide a consistent API into the information contained in the diagrams and > integrate those diagrams into a live system. Imagine for example an IoT > dashboard built with DIA. > > Lastly, XML May be a strong foundation but it’s quickly becoming obsolete. > Besides, if DIA was so XML formal it should have had formal XSDs and things > like dia2code should have used XSLT a long time ago, but all of those > technologies are quickly fading away. > > Look, you can sit here and argue all you want and be blind. But the truth is > that anywhere we try to push DIA in our customer’s workflow we get pushback > and Draw.io is providing all these things and more, and it’s free. It would > be great if DIA could evolve into an OpenSource draw.io or something even > better. > > > >>> > _______________________________________________ > 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 >
_______________________________________________ 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
