Re: Maintaining / Helping out on Dia



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 <aimass 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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]