Re: dia components
> > Hi Jasper and Steffen, thanks for your replies - much appreciated! Steffen, in answer to your questions: On 10 September 2011 03:32, Steffen Macke wrote: > Could you give one concrete example? E.g. provide a sample diagram that > contains > one of the elements in question? Or just the sheet/name? Screenshot might > also help. > Here's a link to a scanned image of a simple diagram that I did using Dia on SUSE (unfortunately binary file was deleted): http://dl.dropbox.com/u/23221149/network_diagram.JPG. Some of the elements that I can't find under my Mint installation of Dia are circled in red. > Is your element listed on > >> > http://diashapes.appspot.com/ > > I don't think so, as when I search for "laptop", the link above identifies "Cisco - Computer" and "Network", both of which I have in my Dia install and neither of which contain the laptop element that I've circled in the attached image. I guess this may mean that the particular icons that I circled, aren't part of the default Dia install and that they come from another source? Cheers, Michael ___ dia-list mailing list dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
Re: Non-transparent background for custom shapes - possible?
At 09.09.2011 16:16, Andrey Repin wrote: Greetings, discussions about usage and development of dia! HB> But if you want an opaque textbox with shapes - like the draw background HB> option of Standard - Text - that's indeed not possible with resize="no". :/ That not sounds very good. Should I add it as an enhancement request to the tracker? Feel free. However I do not have a good idea yet, how to add this to the custom shape properties without breaking backward compatibility. The "draw background" option is already used there to decide about 'normal' filling. Or is there a workaround? Like, can I add a subshape with textbox and resize=yes to work around a problem? I don't think so after briefly looking at the source (objects/custom/custom_object.c). The user editable text in custom shapes is rendered independently of subshapes. A shape design without seems to be the best option, but that would probably give you more background than you want ... Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ dia-list mailing list dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
Re: Dia: Why is it so hard to do simple things? dia-list Digest, Vol 89, Issue 7
At 09.09.2011 11:00, Edheldil wrote: On 09/08/2011 11:29 PM, Michael Ross wrote: It is worth noting that many people like this software and work productively with it who did not write it. [ To nobody in particular ] I have been a Dia user for quite a long time, even tried to create a new tool for it (http://www.eowyn.cz/dia/dia-stars.png , if you are interested), More interesting than the screenshot would be the patch ;) The fact is, Dia lacks many needed features and has annoying bugs and limits. Care to be more specific? Of course there is much room for improvement, but I tried to eliminate many of the annoying bugs over the last years. What's worse, its development is at best crawling at snail's pace, so the above mentioned problems have been there for many years. What are these "above mentioned problems"? - Defaults of UML shapes leading to huge elements? => all the UML Style defaults can be changed by the user - Changing multiple object properties at once? => was one of the main improvements of Dia 0.97 - [...] => see other answers in this same thread Working with Dia is often frustrating because of that. Reading the Dia list is often frustrating because of contributions like "Why is it so hard to do simple things?" without even bothering to take a brief look into the manual. Sorry, I'm highly biased because I'm using and contributing to Dia for years. So I probably avoid some of the common pitfalls without even thinking about them. [...] > To make this post a bit more constructive: maybe it would be helpful to have an ideas / wishlist / TODO page on the wiki, something that a would-be contributor could use as a starting point. https://bugzilla.gnome.org/buglist.cgi?product=dia&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ dia-list mailing list dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
Re: External "so" module.
Hi Paul, At 01.09.2011 22:14, Paul Chavent wrote: Thank you Pierre-Louis. Is there any sample project that provide an external lib (to see how it deals with finding the dia source tree... or is there any way to install dia headers) ? Using libdia as SDK (or building Dia plug-ins outside of the tree) is not supported. The libdia API/ABI is not considered stable. It is not prepared for side-by-side installation. And for advanced plug-ins you even need access to app/ provided functionality. Of course there might be out of tree plug-ins I do not know of. Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ dia-list mailing list dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
Re: Non-transparent background for custom shapes - possible?
Greetings, Hans Breuer! >> HB> But if you want an opaque textbox with shapes - like the draw background >> HB> option of Standard - Text - that's indeed not possible with resize="no". >> >> :/ That not sounds very good. >> Should I add it as an enhancement request to the tracker? > Feel free. However I do not have a good idea yet, how to add this to the > custom shape properties without breaking backward compatibility. The "draw > background" option is already used there to decide about 'normal' filling. If you ask me, I don't want a separate background color for a textbox. May be different opacity, if I may. And I don't understand your concerns about backward compatibility. You're using XML, after all... would produce desired results in versions supporting the attribute, and would just draw what it understand on versions that do not. BTW, another issue with custom shape textbox, it's not possible to define default color value for it's text (I mean, inside Dia - double-clicking the shape on palette), although you can still change it once the shape is placed. Seems rather counter-intuitive to me. >> Or is there a workaround? Like, can I add a subshape with textbox and >> resize=yes to work around a problem? >> > I don't think so after briefly looking at the source > (objects/custom/custom_object.c). The user editable text in custom shapes > is rendered independently of subshapes. > A shape design without seems to be the best option, > but that would probably give you more background than you want ... Well, yes. I've misunderstood the "subshape" term. After rereading the relevant part of manual, it became clear that it isn't really a subshape, rather, an independently resizable part of a shape. BTW, link to PDF manual at http://projects.gnome.org/dia/ leading to some 10 sheets cut-down nothing-to-read-about 150kb version of the 1.3Mb http://dia-installer.de/doc/en/dia-manual.pdf -- WBR, Andrey Repin (anrdae...@freemail.ru) 10.09.2011, <20:13> Sorry for my terrible english... ___ dia-list mailing list dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
Re: Non-transparent background for custom shapes - possible?
At 10.09.2011 18:35, Andrey Repin wrote: Greetings, Hans Breuer! HB> But if you want an opaque textbox with shapes - like the draw background HB> option of Standard - Text - that's indeed not possible with resize="no". :/ That not sounds very good. Should I add it as an enhancement request to the tracker? Feel free. However I do not have a good idea yet, how to add this to the custom shape properties without breaking backward compatibility. The "draw background" option is already used there to decide about 'normal' filling. If you ask me, I don't want a separate background color for a textbox. May be different opacity, if I may. Given that color and opacity are stored together, that would result in the same issue. But maybe just one new property textbox-backgound could be added. And the default would be completely transparent. Thus it would not change the appearance of diagrams not having it. And I don't understand your concerns about backward compatibility. You're using XML, after all... would produce desired results in versions supporting the attribute, and would just draw what it understand on versions that do not. That was not the point. If I only have one switch namely "draw background" how is it supposed to toggle four possible states? - only stroke, no fill - stroke and fill both with or without drawing the text background? BTW, another issue with custom shape textbox, it's not possible to define default color value for it's text (I mean, inside Dia - double-clicking the shape on palette), although you can still change it once the shape is placed. Seems rather counter-intuitive to me. Yes, fixed by: http://git.gnome.org/browse/dia/commit/?id=4e5dddbad16c901492fb2f0e2921d65766741d98 Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ dia-list mailing list dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
Re: Dia: Why is it so hard to do simple things? dia-list Digest, Vol 89, Issue 7
At 09.09.2011 11:00, Edheldil wrote: > On 09/08/2011 11:29 PM, Michael Ross wrote: >> It is worth noting that many people like this software and work >> productively >> with it who did not write it. > > [ To nobody in particular ] > Hi, Hans, Nothing I have said has been meant as a criticism of your work - I am sure that your free time is limited and I am glad somebody is working on Dia at all. On 09/10/2011 12:50 PM, Hans Breuer wrote: > The fact is, Dia lacks many needed features and has annoying bugs and >> limits. > Care to be more specific? Of course there is much room for > improvement, but I tried to eliminate many of the annoying bugs over > the last years. Hmm, I did want to be specific, but e.g. bugs: - it's difficult to place a text onto a rectangle elsewhere than into a center - zigzag line was repeatedly switching from _| to |_ or -|_as soon as I moved a handle and features: - rotating objects - editing and adding shape anchors - editable shape constraints - editable properties for SVG shapes - no labels and anchors on lines/connections (something could be old version of Dia - I have Ubuntu's default 0.97.1) Well, I see it's rather features than bugs. My bad. Edheldil ___ dia-list mailing list dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
Re: External "so" module.
So you recommend to concentrate my effort on module integration (i work on a "sozi editor") instead of trying to do an external module ? Paul. On 09/10/2011 02:41 PM, Hans Breuer wrote: Hi Paul, At 01.09.2011 22:14, Paul Chavent wrote: Thank you Pierre-Louis. Is there any sample project that provide an external lib (to see how it deals with finding the dia source tree... or is there any way to install dia headers) ? Using libdia as SDK (or building Dia plug-ins outside of the tree) is not supported. The libdia API/ABI is not considered stable. It is not prepared for side-by-side installation. And for advanced plug-ins you even need access to app/ provided functionality. Of course there might be out of tree plug-ins I do not know of. Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert ___ dia-list mailing list dia-list@gnome.org http://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 http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
Re: External "so" module.
At 11.09.2011 00:15, Paul Chavent wrote: So you recommend to concentrate my effort on module integration (i work on a "sozi editor") instead of trying to do an external module ? Yes. IIRC the main thing blocking the inclusion with Dia was the overlong string for sozi_script. I could do that split for you, but I only want to do it once. So further updates from you should include the fixed approach. Looking once more at your patch: there also needs to be some adjustment from g_snprintf(..., "... %g ...", ... to g_ascii_formatd(). Otherwise the resulting SVG would be broken on system defining a decimal separator other than '.'. Thanks, Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ dia-list mailing list dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
Re: External "so" module.
Hans, On 09/10/2011 10:45 PM, Hans Breuer wrote: At 11.09.2011 00:15, Paul Chavent wrote: So you recommend to concentrate my effort on module integration (i work on a "sozi editor") instead of trying to do an external module ? Yes. IIRC the main thing blocking the inclusion with Dia was the overlong string for sozi_script. I could do that split for you, but I only want to do it once. So further updates from you should include the fixed approach. Yes i have a quick fix for this (yes it isn't really difficult). But i also suggest some packaging patch on the sozi project side. For dia I would like the following scenario : - when running ./configure in dia i look for a sozi installation (sozi.h in some include path) - i use this header when compiling sozi. So we don't need to maintain the sozi player part in dia. If we don't found sozi, we don't try to compile this object. I know that there is someone who is working on the sozi integration to Sketch. So i think it could be easier for everyone to have a system wide installation of sozi... Looking once more at your patch: there also needs to be some adjustment from g_snprintf(..., "... %g ...", ... to g_ascii_formatd(). Otherwise the resulting SVG would be broken on system defining a decimal separator other than '.'. Thank you for this re-read. Paul Thanks, Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert ___ dia-list mailing list dia-list@gnome.org http://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 http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
Re: External "so" module.
On 10/09/2011 14:41, Hans Breuer wrote: > Hi Paul, > At 01.09.2011 22:14, Paul Chavent wrote: >> Thank you Pierre-Louis. >> >> Is there any sample project that provide an external lib (to see how it >> deals with finding the dia source tree... or is there any way to install >> dia headers) ? >> > Using libdia as SDK (or building Dia plug-ins outside of the tree) is > not supported. The libdia API/ABI is not considered stable. It is not > prepared for side-by-side installation. And for advanced plug-ins you > even need access to app/ provided functionality. > > Of course there might be out of tree plug-ins I do not know of. Hi, What features/functionality are missing to Dia in order to support external plug-ins ? There is already a macro "DIA_PLUGIN_CHECK_INIT" used by plugins: increasing "DIA_PLUGIN_API_VERSION" when API is modified isn't sufficient ? Should some functionality provided by app/ moved in lib/ ? Thanks, Pierre-Louis ___ dia-list mailing list dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
