Re: Maintaining / Helping out on Dia
On Wed, Dec 5, 2018 at 7:36 PM Andrey Repin via dia-list wrote: > Greetings, Alejandro Imass! > > > No reason at all. Just thought that since the effort is relatively big to > > modernize DIA to GTK 3 it would be worthwhile to at least discuss it. > > Moreover, I think a future Web-based interface to DIA (even if not the > > primary/native one) will be important for the long-term survival of DIA > from a product standpoint. > > This raises a completely different point, actually. > Dia as a [base for] an application server. > > And I can see it working quite well, given Dia's limited set of basic > actions. > > > Right now DIA has the ability to create information from a diagram. Imagine the opposite: take information and make a diagram and/or animate a diagram. Some time ago I built a POC using SVG to demonstrate how easy it was to build SCADA type screens by animating SVG produced from Inkscape. It was just a POC and not too practical but proved a point of how JS was already (back in 2012 or so) to manipulate SVG on the Web. Imagine DIA for making IoT dashboards, SCADA screens, etc. whether it's an output format that can be easily manipulated (e.g. SVG) or maybe through an engine/API. In other words, change a property of an object and see how the drawing changes. Example: a tank object has a level property from 0 to 100 that animates the liquid level. Anyway, I think we can all agree that DIA is much more than a drawing tool. The concept that the templates can produce structured objects with named properties is probably the most important aspect of this software. We use it extensively for UML to SQL DDL but I can think of so many other applications ___ 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
Re: What's wrong with Dia the way it is?
Greetings, Steve Litt! > What's wrong with Dia just the way it is? It works. It's exportable > into Inkscape for conversion to SVG. "It works" is the most you can say about it. When you start to actually USE it, you immediately discover different small annoyances, the more - the deeper you dive. Even its SVG export (which is supposed to be its primary use outside itself) is a dirty mess. > 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. We'd all (I think I can safely say that) would prefer to have a program where you don't have to use workarounds for things you do daily. > I'd love to have Visio-quality diagram components, It's largely possible already, you can design any types of shapes. But the in-program treatment is a little bit lacking, and you won't see the results until export. > and perhaps if somebody writes some docs on how to make your own components > with the connection points *you* want, that will be solved. Basically - SVG. All high-quality shapes are hand-made. > 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. That's a separate project, and, by the way, such a repository exists (or it was, at one point). > 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? Replacing the whole program UI is not a fingersnap activity. And THAT is what needs a replacement, as the UI library used by Dia is not supported for a decade. > Sometimes something's so good it needs no more maintenance (fetchmail is one > example). Even fetchmail requires regular maintenance, as new protocols take place. > Right now Dia works for people on all sorts of computers. Barely works. For me at least. > 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. It would require to rewrite Dia entirely to rip out things that build it. I doubt anybody want to take on such task. -- With best regards, Andrey Repin Thursday, December 6, 2018 3:32:42 Sorry for my terrible english... ___ 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
Re: What's wrong with Dia the way it is?
Le 5 décembre 2018 18:32:47 GMT+01:00, Steve Litt 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
Re: Maintaining / Helping out on Dia
On Wed, 2018-12-05 at 14:31 -0500, Alejandro Imass wrote: > On Wed, Dec 5, 2018 at 2:04 PM Zander Brown wrote: > > On Wed, 2018-12-05 at 12:59 -0500, Alejandro Imass wrote: > > > What I was thinking is that we could channel some funds to a > > > University and have them work on it. My native country > > > (Venezuela) is in pretty bad shape but top-notch Universities are > > > still operating despite the crisis. This would be a win-win IMHO. > > > > Worth investigating > > > > I reached out to a professor I know in one University to see what the > real possibilities are. > > > > > Not sure directly competing with draw.io would work especially well > > > > > > No, but it is the closest competitor AFAICT. > > [...] > > > Personally I'd like to see Dia remain a 'native' application (which > > seems to be the general view of others on the list as well) and > > plugable interfaces generally get very messy very fast (esp when we > > do a lot of custom rendering) so I'd rather Dia remains true to > > it's roots as a Gtk application > > > > > > That's fine. My idea was just to stir things up a little and see what > would come out of this discussion. No harm in discussion! > I think the main objective is saving DIA from being shunt out of the > Linux distros and see how to maintain the Windows and Mac binaries. > > BTW, IIRC Steffen's widow received some revenue from the > http://dia-installer.de/ Website so I think that even if Gnome takes > over the maintenance of the Windows and Mac binaries somehow, perhaps > they could still be distributed through http://dia-installer.de/ in > coordination with her, in respect to Steffen all the years of effort > that he put into maintaining these binaries all by himself. Sounds like a nice thing to do, not sure what GNOME can offer in terms of Windows/macOS packaging but I'm up for supporting http://dia-installer.de/ > Best, > Alex > -- Zander Brown GNOME signature.asc Description: This is a digitally signed message part ___ 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
Re: Maintaining / Helping out on Dia
On Wed, Dec 5, 2018 at 2:04 PM Zander Brown wrote: > On Wed, 2018-12-05 at 12:59 -0500, Alejandro Imass wrote: > > > > What I was thinking is that we could channel some funds to a University > and have them work on it. My native country (Venezuela) is in pretty bad > shape but top-notch Universities are still operating despite the crisis. > This would be a win-win IMHO. > > > Worth investigating > > I reached out to a professor I know in one University to see what the real possibilities are. > > Not sure directly competing with draw.io would work especially well > > No, but it is the closest competitor AFAICT. [...] > Personally I'd like to see Dia remain a 'native' application (which seems > to be the general view of others on the list as well) and plugable > interfaces generally get very messy very fast (esp when we do a lot of > custom rendering) so I'd rather Dia remains true to it's roots as a Gtk > application > > That's fine. My idea was just to stir things up a little and see what would come out of this discussion. I think the main objective is saving DIA from being shunt out of the Linux distros and see how to maintain the Windows and Mac binaries. BTW, IIRC Steffen's widow received some revenue from the http://dia-installer.de/ Website so I think that even if Gnome takes over the maintenance of the Windows and Mac binaries somehow, perhaps they could still be distributed through http://dia-installer.de/ in coordination with her, in respect to Steffen all the years of effort that he put into maintaining these binaries all by himself. Best, Alex ___ 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
Re: Maintaining / Helping out on Dia
On Wed, 2018-12-05 at 12:59 -0500, Alejandro Imass wrote: > On Wed, Dec 5, 2018 at 12:25 PM Zander Brown > wrote: > > On Wed, 2018-12-05 at 11:34 -0500, Alejandro Imass wrote: > > [...] > > > > You seem to know exactly what needs to be done to get through the > > > GTK 2 bump, and it awesome that at least someone does and > > > understands the urgency to AT LEAST bump it up to GTK 3. We use > > > DIA on daily basis and don't want to see it die. So we could > > > cough up some cash and finance some of this effort. > > > > I'll investigate what the policy for that is (don't want to get > > anyone is trouble esp myself) > > > > > > What I was thinking is that we could channel some funds to a > University and have them work on it. My native country (Venezuela) is > in pretty bad shape but top-notch Universities are still operating > despite the crisis. This would be a win-win IMHO. Worth investigating > > > In your opinion is is too crazy to suggest separating the UI/UX > > > from the logic and salvaging the C code, templates and all the > > > other non-UI stuff as a "backend". > > > > It seems reasonable to have a more formal split between Dia & > > libdia but I'm not sure it's worth reimplementing the UI in JS. > > > > > > For sure not right now, and it's quite obvious to me that a straight > GTK 3 upgrade is the logical next step for DIA. But if we work > towards the goal of at least foreseeing that additional UIs to be > able to bolt-on, then I think it would be great for DIA. Especially a > web-based version that competes with draw.io. Not sure directly competing with draw.io would work especially well > > To implement the UI in anything other than C/Vala would make the > > build quite complex and we would lose the advantage of compile time > > checks however we should be able to somewhat simplify the UI > > implementation by taking advantage of GtkBuilder (once we make it > > to Gtk3) to define our UI in XML but until the Cairo port is done > > we are largely talking hypotheticals here > > > > Was there any particular reason you wanted to see Dia's interface > > reworked in JS/JSX? > > > > > > No reason at all. Just thought that since the effort is relatively > big to modernize DIA to GTK 3 it would be worthwhile to at least > discuss it. Moreover, I think a future Web-based interface to DIA > (even if not the primary/native one) will be important for the long- > term survival of DIA from a product standpoint. Personally I'd like to see Dia remain a 'native' application (which seems to be the general view of others on the list as well) and plugable interfaces generally get very messy very fast (esp when we do a lot of custom rendering) so I'd rather Dia remains true to it's roots as a Gtk application -- Zander Brown GNOME signature.asc Description: This is a digitally signed message part ___ 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
Re: Maintaining / Helping out on Dia
On Wed, Dec 5, 2018 at 12:25 PM Zander Brown wrote: > On Wed, 2018-12-05 at 11:34 -0500, Alejandro Imass wrote: > > > > [...] > You seem to know exactly what needs to be done to get through the GTK 2 > bump, and it awesome that at least someone does and understands the urgency > to AT LEAST bump it up to GTK 3. We use DIA on daily basis and don't want > to see it die. So we could cough up some cash and finance some of this > effort. > > > I'll investigate what the policy for that is (don't want to get anyone is > trouble esp myself) > > What I was thinking is that we could channel some funds to a University and have them work on it. My native country (Venezuela) is in pretty bad shape but top-notch Universities are still operating despite the crisis. This would be a win-win IMHO. > In your opinion is is too crazy to suggest separating the UI/UX from the > logic and salvaging the C code, templates and all the other non-UI stuff > as a "backend". > > > It seems reasonable to have a more formal split between Dia & libdia but > I'm not sure it's worth reimplementing the UI in JS. > > For sure not right now, and it's quite obvious to me that a straight GTK 3 upgrade is the logical next step for DIA. But if we work towards the goal of at least foreseeing that additional UIs to be able to bolt-on, then I think it would be great for DIA. Especially a web-based version that competes with draw.io. > To implement the UI in anything other than C/Vala would make the build > quite complex and we would lose the advantage of compile time checks > however we should be able to somewhat simplify the UI implementation by > taking advantage of GtkBuilder (once we make it to Gtk3) to define our UI > in XML but until the Cairo port is done we are largely talking > hypotheticals here > > Was there any particular reason you wanted to see Dia's interface reworked > in JS/JSX? > > No reason at all. Just thought that since the effort is relatively big to modernize DIA to GTK 3 it would be worthwhile to at least discuss it. Moreover, I think a future Web-based interface to DIA (even if not the primary/native one) will be important for the long-term survival of DIA from a product standpoint. ___ 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
Re: What's wrong with Dia the way it is?
+1 (from an occasional user) On Wednesday, December 05, 2018 12:32:47 PM Steve Litt wrote: > What's wrong with Dia just the way it is? It works. It's exportable > into Inkscape for conversion to SVG. > > 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. 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. > > 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 ___ 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
Re: Hello Everyone
On Wed, 2018-12-05 at 12:16 -0500, Steve Litt wrote: > On Tue, 4 Dec 2018 22:24:58 + > Alexander Brown wrote: > > > Whilst I am a member of the GNOME Foundation and would like to see > > Dia > > modernised I recognise the fact Dia is very much a cross platform > > application and therefore has a sort of 'special status' within the > > GNOME Project and have no intention of breaking KDE/macOS/Windows > > compatibility > > And are you going to guarantee Dia's continued useability for those > of > us who run sans-systemd distros? This is an important question > because > Gnome itself no longer runs without systemd as its PID1 and early > boot > library. I find it highly unlikely that our main dependencies (Gtk, GLib) will ever become dependent on systemd and cannot foresee any reason at all for Dia to depend on systemd itself As I've stated I'm committed to maintaining support for macOS & Windows neither of which use systemd so yes I have every intention of supporting Dia on 'sans-systemd distros' Hopefully that resolves your concerns > > SteveT > > Steve Litt > December 2018 featured book: Rapid Learning for the 21st Century > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.troubleshooters.com%2Frl21data=02%7C01%7C%7C07df255358994c7bab4808d65ad595dc%7C84df9e7fe9f640afb435%7C1%7C0%7C636796270721383503sdata=d7tPMY61Avm7lyuBT5d0Gfqy1pLpQ6w%2BM0vGNE75s4Y%3Dreserved=0 > ___ > dia-list mailing list > dia-list@gnome.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.gnome.org%2Fmailman%2Flistinfo%2Fdia-listdata=02%7C01%7C%7C07df255358994c7bab4808d65ad595dc%7C84df9e7fe9f640afb435%7C1%7C0%7C636796270721383503sdata=wSB4dqUb1%2BGztp4o1FsM67uRgmVX02X%2FwgQZSZ5g8e4%3Dreserved=0 > FAQ at > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flive.gnome.org%2FDia%2FFaqdata=02%7C01%7C%7C07df255358994c7bab4808d65ad595dc%7C84df9e7fe9f640afb435%7C1%7C0%7C636796270721383503sdata=j3Qcx2gIuOyKkLpqqNKGqMFpgzToWduKrJy2Zxr8avM%3Dreserved=0 > Main page at > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flive.gnome.org%2FDiadata=02%7C01%7C%7C07df255358994c7bab4808d65ad595dc%7C84df9e7fe9f640afb435%7C1%7C0%7C636796270721383503sdata=eG%2Bp%2B3vlIERl9PWO2y5TIMZi4oSVnQRSiXjOCTi9xSE%3Dreserved=0 > -- Zander Brown GNOME signature.asc Description: This is a digitally signed message part ___ 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
What's wrong with Dia the way it is?
Hi all, What's wrong with Dia just the way it is? It works. It's exportable into Inkscape for conversion to SVG. 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. 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. 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
Re: Maintaining / Helping out on Dia
On Wed, 2018-12-05 at 11:34 -0500, Alejandro Imass wrote: > On Wed, Dec 5, 2018 at 3:50 AM Zander Brown wrote: > > On Tue, 2018-12-04 at 22:20 -0500, Alejandro Imass wrote: > > > > The Gtk3 -> 4 transition should be much smoother, just a bit > > monotonous > > > > > I have heard of people suggesting to use JSX for GTK 4, so not > > > sure why the "shit" comment about React earlier. In fact, React > > > would probably be the best bet of survival or rebirth for DIA. > > > But heck what do I know, right ? > > > > That's more of a general play with GObject and is unrelated to Gtk4 > > (And nobody is seriously suggesting we scrap Dia and start again in > > JavaScript are they?) > > > > > > Well, actually I did suggest that, at least that we discuss the > different options and listen to the users to where they want this > product to go next. > > My comments are just general and I haven't honestly looked into the > technical details and up to this point. > > You seem to know exactly what needs to be done to get through the GTK > 2 bump, and it awesome that at least someone does and understands the > urgency to AT LEAST bump it up to GTK 3. We use DIA on daily basis > and don't want to see it die. So we could cough up some cash and > finance some of this effort. I'll investigate what the policy for that is (don't want to get anyone is trouble esp myself) > In your opinion is is too crazy to suggest separating the UI/UX from > the logic and salvaging the C code, templates and all the other non- > UI stuff as a "backend". It seems reasonable to have a more formal split between Dia & libdia but I'm not sure it's worth reimplementing the UI in JS. To implement the UI in anything other than C/Vala would make the build quite complex and we would lose the advantage of compile time checks however we should be able to somewhat simplify the UI implementation by taking advantage of GtkBuilder (once we make it to Gtk3) to define our UI in XML but until the Cairo port is done we are largely talking hypotheticals here Was there any particular reason you wanted to see Dia's interface reworked in JS/JSX? On a related note: Is anyone using PyDia? Personally I've never got it to work and it might be more valuable to develop a new plugin system powered by libpeas so people can script Dia in Python, JS or others (clearly this a much more long term goal) -- Zander Brown GNOME signature.asc Description: This is a digitally signed message part ___ 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
Re: Maintaining / Helping out on Dia
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!) - is free, open source and is not controlled by a company (yEd fails this - also OmniGraffle, Enterprise Architect, Visual Paradigm, etc) - simple, does not require learning a new language (graphviz and any other text->UML tools fail this) - lightweight, but still fairly rich in features (libreoffice draw fails the lightweight requirement) - offers a simple interface which is very easy to pick up (I tried Inkscape, but for whatever reason I was never able to get working as fast as I could in Dia) - portable: works on Windows (my main requirement), *BSDs and maybe others. I might be heavily biased towards Dia, but I have searched for a better alternative since I knew it wasn't being maintained and couldn't find one. Hoping I have not missed anything? I think there will always be a need for an offline, open source, portable lightweight diagram SW, so I think Dia still has a lot of life left in it. Also it is nice to see that it is still top-search result for anything like "diagram open software", "diagram software linux" even after so many years. Hope this helps, Ed On Mon, 3 Dec 2018, 18:42 Andrey Repin via dia-list Greetings, Alejandro Imass! > > > IMHO maybe a fork is required to take DIA to the next level and separate > it > > from GNOME even if you decide to keep using GTK and move to 3 or > whatever. > > More than the actual graphics library I would look into taking the things > > that are really valuable from the current code and perhaps think of a > > complete re-write with React, Anguar, Ember or whatever. I would get out > of > > XML and go to JSON and re-write the app into a React front-end with a > > corresponding backend and API. IMHO the greatest long term existential > > threat to DIA is not Visio or Omnigraffle, it's draw.io > > Sounds so much NIH, I don't even want to start arguing. > XML (specifically SVG) is a solid base. You can do wonders with it, all > that > is needed is an improvement in rendering (handling) of shapes. > > There's very little need to be changed, only moved forward in the basically > same direction it has been always moving. > > All your fancy "Angular, React, and shit" are just overgrown, > uncontrollable shit. > > > -- > With best regards, > Andrey Repin > Monday, December 3, 2018 21:31:34 > > Sorry for my terrible english... > > ___ > 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
Failure
Hello I am trying to save a file in the program day and when I give it to save or save as the following message appears: \FP ASIR\XBD Xestión de bases de datos\Tarea02\__dia0808SZ»: Bad file descriptor neither does it let me export the file to any format!! I hope you can help me solve the problem, thanks ___ 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
Re: Maintaining / Helping out on Dia
Hi, On Sun, 2018-12-02 at 17:38 +, Eduard Nicodei wrote: > Tomas Harding also suggested getting in touch with the authors > directly, the only email I could find was Steffen Macke's (CC'ed) or > even with the Gnome Bugmaster (also CC'ed). The technical administrators of bugzilla.gnome.org don't have any authority in deciding who maintains which applications. :) As per https://wiki.gnome.org/Projects/Unmaintained and https://wiki.gnome.org/Apps/Unmaintained , I recommend contacting maintainers in https://gitlab.gnome.org/GNOME/dia/blob/master/dia.doap and bringing this up on desktop-devel-l...@gnome.org Cheers, andre -- Andre Klapper | ak...@gmx.net https://blogs.gnome.org/aklapper/ ___ 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
Re: Maintaining / Helping out on Dia
On Wed, Dec 5, 2018 at 8:40 AM Andrey Repin via dia-list wrote: > Greetings, Alejandro Imass! > > > [...] > In the contrast, I can use Dia on my netbook with just 2 GB RAM > comfortable. > And not just starting and closing. The diagram I'm working with contains > 1336 > objects. > All it takes is… about 70 MB RAM. Two orders of magnitude less than > anything > you can name. > > > Thanks for the insight and it's a good benchmark to compare to. But that doesn't mean that a stand-alone App developed with Chromium and Node.js would perform any worse and require that much more resources. For example the Atom editor uses around 100 MB of RAM on my Mac. ___ 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
Re: Maintaining / Helping out on Dia
On Wed, Dec 5, 2018 at 3:50 AM Zander Brown wrote: > On Tue, 2018-12-04 at 22:20 -0500, Alejandro Imass wrote: > > > > > The Gtk3 -> 4 transition should be much smoother, just a bit monotonous > > I have heard of people suggesting to use JSX for GTK 4, so not sure why > the "shit" comment about React earlier. In fact, React would probably be > the best bet of survival or rebirth for DIA. But heck what do I know, right > ? > > > That's more of a general play with GObject and is unrelated to Gtk4 (And > nobody is seriously suggesting we scrap Dia and start again in JavaScript > are they?) > > Well, actually I did suggest that, at least that we discuss the different options and listen to the users to where they want this product to go next. My comments are just general and I haven't honestly looked into the technical details and up to this point. You seem to know exactly what needs to be done to get through the GTK 2 bump, and it awesome that at least someone does and understands the urgency to AT LEAST bump it up to GTK 3. We use DIA on daily basis and don't want to see it die. So we could cough up some cash and finance some of this effort. In your opinion is is too crazy to suggest separating the UI/UX from the logic and salvaging the C code, templates and all the other non-UI stuff as a "backend". ___ 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
Re: Maintaining / Helping out on Dia
Greetings, Alejandro Imass! > Just for reference: > https://blogs.gnome.org/desrt/2016/08/17/a-quick-look-at-using-jsx-in-gnome/ > So why not think in this direction or node-gtk or something along these > lines and get some fresh blood in here. > Not so "shit" now, eh? I was forced to switch to Chrome-based browser - there's simply no other browsers exist nowadays, if you don't take IE into account. I use VS Code daily. I need 2 GB RAM upfront just to start either, starting both is 4 GB already, and it quickly grows into 10-15 GB range as you work. Anything but a stationary system simply unsuitable to use them. In the contrast, I can use Dia on my netbook with just 2 GB RAM comfortable. And not just starting and closing. The diagram I'm working with contains 1336 objects. All it takes is… about 70 MB RAM. Two orders of magnitude less than anything you can name. -- With best regards, Andrey Repin Wednesday, December 5, 2018 16:14:41 Sorry for my terrible english... ___ 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
Re: Maintaining / Helping out on Dia
On Wed, 2018-12-05 at 00:24 -0500, Alejandro Imass wrote: > On Wed, Dec 5, 2018 at 12:14 AM Alejandro Imass > wrote: > > On Tue, Dec 4, 2018 at 11:58 PM timothy b via dia-list < > > dia-list@gnome.org> wrote: > > > > > > > > > > > > > > > > > > > > > The question isn’t so much as to what utilities that Día uses, > > > nor what platform is managing the code. > > > > > > > > > > > > > > > > > > > > > The discussion should be about is there anyone that wants to > > > maintain Dia for Windows, and who is prepared to maintain Día for > > > Linux. > > > > > > > > > > > > > Also, you are forgetting the Mac binaries. Although the MacPorts > > version works flawlessly at least up to High Sierra. Not sure who > > maintains the MacPorts version but it could be derived from the > > FreeBSD ports (not sure), and these distros are compiled so they > > are generally easier to maintain that installable binaries. > > > > Linux versions would be generally no-issue since they are mostly > > maintained by the two main distribution sources: RPM and DEB. > > > > > Until those to questions are answered, any other discussion is > > > academic. > > > > > > > > > > > > > > > > > > > Disagree. I don't think that maintaining the Windows and Mac > > binaries solves the underlying problem here. Maintaining those > > binaries is probably very tedious and people will avoid this like > > the plague. Precisely the problem is aging technology (e.g. GTK2) > > that may eventually prove impossible to maintain. > > > > > > > > > > For reference. One day, in the very near future we may wake up and > find DIA has been removed from Linux distros altogether: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885686 > > "As announced [1], we do not intend to release Debian 10 "Buster" > with the old libgnome (and related) libraries. These libraries have > been deprecated and unmaintained for several years." > > So it's not an academic discussion. DIA as it stands is really on > it's way out but no one seems to understand the severity of no > releases since 2010. Agreed, removing the likes of libgnome* and others should be a top priority so we can get some kind of release together ASAP > > > > > > ___dia-list mailing > listdia-l...@gnome.org > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.gnome.org%2Fmailman%2Flistinfo%2Fdia-listdata=02%7C01%7C%7C43fce4e6865945074bdb08d65a7217f9%7C84df9e7fe9f640afb435%7C1%7C0%7C636795843406325651sdata=pAKIZreFjufhFV2aMwcF65mnUAPbks6iD0gXIpS5wRo%3Dreserved=0 > FAQ at > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flive.gnome.org%2FDia%2FFaqdata=02%7C01%7C%7C43fce4e6865945074bdb08d65a7217f9%7C84df9e7fe9f640afb435%7C1%7C0%7C636795843406325651sdata=a1rBM47WSuaO9fMUq8HQqh0QpnehvUw9pQiNeZMUzKk%3Dreserved=0 > Main page at > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flive.gnome.org%2FDiadata=02%7C01%7C%7C43fce4e6865945074bdb08d65a7217f9%7C84df9e7fe9f640afb435%7C1%7C0%7C636795843406325651sdata=qVjIF%2B6pdlOoOHzlPwneTvDmc3dG%2BrkABLc0DLWiZ90%3Dreserved=0 > -- Zander Brown GNOME signature.asc Description: This is a digitally signed message part ___ 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
Re: Maintaining / Helping out on Dia
On Tue, 2018-12-04 at 22:20 -0500, Alejandro Imass wrote: > On Tue, Dec 4, 2018 at 6:12 PM Thomas HARDING < > t...@thomas-harding.name> wrote: > > Hi, all ! > > > > > > > > So, > > > > > > > > Le 04/12/2018 à 11:21, Eduard Nicodei via dia-list a écrit : > > > So, I think that's a good start point : why Dia, an unmaintained > > > > software, has *no* competitor /on its segment/ ? > > > > > > DIA is very unique I give you that. But draw.io is a huge risk for > DIA and similar programs, and that's just naming one. > Sure draw.io is probably our main 'competitor' but I believe there is space for both (and we do slightly different things) > [...] > > > Obviously, Dia could _also_ work networked, in the future, or > > produce > > > > fancy views, MS-Visio like, when you need to impress commercials > > (we can > > > > imagine a toggle button "turn on fancy"), or at option use/produce > > other > > > > data structures such as Json. > > > > > > > > But keep in scope to keep the tool simple, stupid and powerfull. > > > > Yeah these things are important. But there are other problems. For > example, GTK2 is completely obsolete. GTK 3 was released in 2011. I > mean, seriously? > The port to GTK3 is probably not straightforward (and never mind 4 > which should be quickly approaching) , so again, IMHO it would be a > good time to re-think where people want to take this project. Having played with such a port on various occasions the main blocker is rendering, Currently we still use Gdk to render just about everything but that was deprecated by the end of the 2x cycle and removed in 3. If we can rework the rendering to use Cairo (via https://developer.gnome.org/gdk2/stable/gdk2-Cairo-Interaction.html) whilst still targeting Gtk2 then much of the work is about using getters instead of direct access (gtk_toggle_button_get_active(toggle) instead of toggle->active) and find replacing removed symbols Obviously this would result in a Dia full of depreciation warnings but we have them already on Gtk2 The Gtk3 -> 4 transition should be much smoother, just a bit monotonous > I have heard of people suggesting to use JSX for GTK 4, so not sure > why the "shit" comment about React earlier. In fact, React would > probably be the best bet of survival or rebirth for DIA. But heck > what do I know, right ? That's more of a general play with GObject and is unrelated to Gtk4 (And nobody is seriously suggesting we scrap Dia and start again in JavaScript are they?) > Best, > Alex > > > > > > ___dia-list mailing > listdia-l...@gnome.org > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.gnome.org%2Fmailman%2Flistinfo%2Fdia-listdata=02%7C01%7C%7C351aa65065ce4c92f65008d65a60d425%7C84df9e7fe9f640afb435%7C1%7C0%7C636795769250183889sdata=oc1JHzFMmsWZBmiOCm%2BrNzAT7X7cH1%2FAgWQYrrBSeQ8%3Dreserved=0 > FAQ at > https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flive.gnome.org%2FDia%2FFaqdata=02%7C01%7C%7C351aa65065ce4c92f65008d65a60d425%7C84df9e7fe9f640afb435%7C1%7C0%7C636795769250183889sdata=a0kWw9xi05x3W6RCjbElXgAyfyfEIJuavv0hBSmShcE%3Dreserved=0 > Main page at > https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flive.gnome.org%2FDiadata=02%7C01%7C%7C351aa65065ce4c92f65008d65a60d425%7C84df9e7fe9f640afb435%7C1%7C0%7C636795769250183889sdata=XJD6sdhvPmu2th65%2FTcFflz5mav2NoY4y1rVuSL4dt4%3Dreserved=0 > -- Zander Brown GNOME signature.asc Description: This is a digitally signed message part ___ 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
Re: Hello Everyone
On Wed, 2018-12-05 at 00:52 +0100, Thomas HARDING wrote: > Hi! > Le 04/12/2018 à 23:24, Alexander Brown a écrit : > > Hello! > > > > I've been interested in seeing Dia move forward for sometime now > > and > > I'm glad others are as well > > > > I don't want to step on anyone's toes but as the current > > maintainers > > are unaccounted for I'm volunteering as acting-maintainer (I have > > commit access). I've already reached out to Thomas directly asking > > them > > having "commit access" makes you as a god on this mailing list, > > even if not solving QA process (bug reports/patches managment). > > > to submit some of their patches as MRs to > (unsure whose Thomas it is (Popisek ?)) Sorry, yes Thomas = Tomas Pospisek > > Whilst I am a member of the GNOME Foundation and would like to see > > Dia > > modernised I recognise the fact Dia is very much a cross platform > > application and therefore has a sort of 'special status' within the > > GNOME Project and have no intention of breaking KDE/macOS/Windows > > compatibility > > > > That said I would like to see Dia move to modern APIs like Cairo & > > Gtk3 > > (or 4) and ideally be built with meson to allow for easier > > development > > and ensure we are not dropped by distributions > > > > (I'm new to mailing lists so constructive feedback is welcome) > > > Greetings! > > At least one offered to be maintainer in the past two weeks, I believe that was Tomas, there is a slight unwillingness to "give him the keys" as (from GNOME's perspective) they are fairly unknown. Should they become a member i am happy to come to some sort co-maintainer relationship (in fact I'd welcome it as i don't have as much time for Dia as i would like) > > One key point is effectively "Gnome integration", which must not be > turned too strong (dependancies has to be optionals, especially > loosed > functionalities from one to other would never impair usage, or be > replaced "from start" by design). Sometimes portability is a high > price > /at first/, but finally /you gain/ (and, most important, user gains) > :-). Whilst I would like to get some people from the GNOME Design Team to give us some mockups for reworking various dialogs I have no intention to redesign the whole UI with HeaderBars or anything like that > > That said, "anything you can give will help". > > I think something new for years is that most of writers on list > talks > now about what they want to DO, so we can expect for rants and > argues > for a few days as a /normal process/. > > That's a good signal for Dia. > > (I'm retired) > > Regards, > > Tsfh > > ___ > dia-list mailing list > dia-list@gnome.org > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.gnome.org%2Fmailman%2Flistinfo%2Fdia-listdata=02%7C01%7C%7Cc19b5385dde8420b97ba08d65a44096a%7C84df9e7fe9f640afb435%7C1%7C0%7C636795645592714494sdata=vgjDMZTizWUCnYbKiZ%2FrUthDafW8R87Qt10i5WCC430%3Dreserved=0 > FAQ at > https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flive.gnome.org%2FDia%2FFaqdata=02%7C01%7C%7Cc19b5385dde8420b97ba08d65a44096a%7C84df9e7fe9f640afb435%7C1%7C0%7C636795645592714494sdata=SAxujcH82GTtqCQ5vOAZWL7BuM9SKswcGcfu8yleIT8%3Dreserved=0 > Main page at > https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flive.gnome.org%2FDiadata=02%7C01%7C%7Cc19b5385dde8420b97ba08d65a44096a%7C84df9e7fe9f640afb435%7C1%7C0%7C636795645592714494sdata=1FDycoAGXoI6uR6sGG2Mtk%2FUNRdC23QznlnoSOunmrs%3Dreserved=0 > -- Zander Brown GNOME signature.asc Description: This is a digitally signed message part ___ 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
