Dia changes
Hello, This is my first post to this list. I have been working on dia for the past week, and thought I would summarise some of the changes I have made. The biggest change I have made is the addition of the custom shape library. When it is complete, it will allow non coders to add shapes to dia by writing some simple XML files. For an example of of the XML files, see the following: http://cvs.gnome.org/lxr/source/dia/objects/custom/Circuit/npn.shape Currently loading, saving, moving, resizing and drawing is working. The shape description is a subset of the SVG format. Currently the line, polyline, polygon, rect, circle and ellipse elements are supported. The style attributes of these elements are currently ignored, but I plan to allow you to set line width (relative to the user specified value) and maybe allow swaping foreground/background for a particular element. I also plan to add support for fixing the aspect ratio on a shape, and maybe flipping (or even rotating?) a custom shape. Support for setting the sheet icon for custom shapes also needs to be done. Another thing is to allow internationalisation of the descriptions. It looks like the best way to do this is with the use of the xml:lang attribute on the description element. I have also added a line style and arrow style selector to the main toolbox. There is an screenshot of it available here: http://www.daa.com.au/~james/dia-tbox.png This allows you to change the line style before placing an element in a way that is consistent between tools. So if you want to draw a dotted line and then a dotted arc, you only need to set tat property once, rather than setting the default for each tool. It is also a bit quicker to access. I have modified the standard line types to use these settings, but I still need to get the standard shapes to use the line style. You can test this out in the latest CVS version of dia. If you want to test the custom shape code a bit, that would be great. Do not expect the file format to stay absolutely compatible as I develop it though. Any comments are welcome. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
bezier renderer methods
Hello,
I have been looking at implementing SVG path elements in the object. Part
of this would require drawing/filling paths made up of both bezier curves
and lines. The current API does not really allow for this (unless I use
degenerate bezier curves).
What would people think of changing the renderer API for the beziers to
accept an array of structures like this:
struct {
enum {LINE_TO, CURVE_TO} type;
Point p1, p2, p3;
}
As far as I can see, beziers are only used in one shape, and it would not
be hard to add support for this in the different renderers.
What do people think of this?
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
Re: TODO
What you are describing is guides (see gimp-1.1.x or corel draw for examples of guides). They are very useful, and it would be nice to have support for them in dia. Maybe we could swipe some of the code from gimp. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 31 Aug 1999, Stefan Seefeld wrote: > hi there, > > I'm using dia for writing UML diagrams and I'd like to propose > some little enhancements: > > It would be nice to be able to snap control points of objects not > only to the grid but to arbitrary other objects as well. Take as > an example multiple lifelines. Imagine that I want them to start > at the same hight. Having seen my girl friend (a graphics designer) > at work I'd like to be able to insert some temporary horizontal > line object at an arbitrary position and snap all lifelines to it. > Once this is done, the temporary line can be removed. > In fact, this idea could be extended to arbitrary alignments so > that one can align not only to curves but to intersction points etc. > > There is a nice postscript drawing editor which has similar features: > IPE (http://www.cs.ust.hk/~otfried/Ipe/) > > Best regards, Stefan > > ___ > > Stefan Seefeld > Departement de Physique > Universite de Montreal > email: [EMAIL PROTECTED] > > ___ > > ...ich hab' noch einen Koffer in Berlin... >
Custom shape status report
I just thought I would give a bit of a status report on the custom shape code I have been working on. Recently I have added support for internationalising the descriptions of custom shapes, support for an `sheet index', which gives the ordering of shapes in the toolbox, and translated name/description for the sheet. In the latest commit, I added support for SVG path elements in the shape description. This last one allows the use of bezier curves in a custom shape. For a look at some of the features in the custom shape code, install the latest CVS version, and try out the shapes in the circuit sheet. They demonstrate drawing with lines (capacitor), polylines (resistor), bezier curves (inductor). It also demonstrates locking the aspect ratio on an object (either transistor). After playing around with the shapes, look at the files in $(prefix)/share/dia/shapes/Circuit to see how the shapes are described. Some of the features the circuit sheet does not demonstrate are use of rectangles, ellipses, polygons, filled bezier paths, text areas associated with a shape, setting line width for part of the shape, swapping background/foreground for part of a shape, and specifying a range of aspect ratios for a shape. Some features that are not in there yet, but I am thinking about implementing include overriding the user selected line style for part of the shape, and maybe also override the colours for parts of the shape. The code is just about ready for general use. I think the current shape file format should be able to describe most shapes, so probably won't change much. I will have to write some small docs on creating new shapes so others can start doing new shapes for dia. Not having to know C or the libdia interface should make this a bit easier :) If anyone has any suggestions for this code, please tell me. Hopefully we can make dia one of the most popular free diagram editors available. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Custom shape code
I have put up some docs on writing new custom shapes if people want to try making new ones. They should be available soon at: http://cvs.gnome.org/lxr/source/dia/objects/custom/README I have also added a few more circuit shapes to demonstrate some other drawing elements that can be used in custom shapes. I was thinking about moving the circuit shapes from dia/objects/custom/Circuit to dia/shapes/Circuit, so we can organise custom shapes in that directory. What do you think of that idea? James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: Custom shape code
Currently the custom shape code creates new sheets. However, if the other object shared libraries had access to the custom object symbols, it would not be difficult to mix C and custom shapes on the one sheet. There is one function to load the shape from a file: ShapeInfo *shape_info_load(const gchar *filename); And another one to create the ObjectType and SheetObject for the shape: void custom_object_new(ShapeInfo *info, ObjectType **otype, SheetObject **sheetobj); Since there is no way to get a reference to another libraries sheets when they are being created (assuming that the libraries are loaded in random order), it might be easier to make sure that the custom shape library is loaded first, and loaded with the RTLD_GLOBAL flag, so other libraries can use its symbols. It would probably be best to place shapes for the other libraries in directories like $(prefix)/share/shapes-private or something, so they don't get read in when the custom shape library is loading. As for using the SVG export filter to model new shapes, this should work pretty well. There are a few bugs in its output which need to be fixed (mainly to do with style attributes), but it should be good for producing the outlines. Note that the custom shape code does not understand elliptic arcs yet, so it may have trouble with them. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Thu, 2 Sep 1999, Alexander Larsson wrote: > Sounds very good. > > Some of the other object types should probably be converted to custom > shapes too. Most network object are pretty simple for instance. Would this > be easy if you use the SVG export function to create the initial data for > the shape? > > Is it possible to mix custom shapes with C shapes in a sheet? > > / Alex > >
Re: Building dia from CVS
It should be possible to build the current CVS version. What build errors were you getting? As for an archive of the list, I don't know if there is one. I could probably get www.mail-archive.com to start archiving this list (it would take a while due to the low volume of the list though). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 7 Sep 1999, Stephen Martin wrote: > Hi, > > I am a dia user and was looking for an updated version as 0.41 has > some annoying problems. I tried to build the latest version from CVS but > failed miserably due to missing symbols, files and directories. Can > someone > provide me with some help to do this, or better yet point me at at > tarball > of the latests buildable source. > > Also is there an online archive of this list? > > Thanks > Steve > -- > __ > Stephen Martin _ _ |/_ \ MORTICE KERN SYSTEMS INC. > [EMAIL PROTECTED] ,/ \ / \ | / |( | 185 Columbia Street West > (519)883-3215| | | |/ | \ / Waterloo, Ontario > Fax: (519)884-8861 | | | | \ | _) Canada N2L 5Z5 > \__/ > "If Bill Gates had a nickel for every time Windows crashes... Oh wait! > He Does!" >
Re: Building dia from CVS
I just checked, and it looks like it is already being archived at http://www.mail-archive.com/dia-list@lysator.liu.se/ James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 7 Sep 1999, James Henstridge wrote: > It should be possible to build the current CVS version. What build errors > were you getting? > > As for an archive of the list, I don't know if there is one. I could > probably get www.mail-archive.com to start archiving this list (it would > take a while due to the low volume of the list though). > > James. > > -- > Email: [EMAIL PROTECTED] > WWW: http://www.daa.com.au/~james/ > > > On Tue, 7 Sep 1999, Stephen Martin wrote: > > > Hi, > > > > I am a dia user and was looking for an updated version as 0.41 has > > some annoying problems. I tried to build the latest version from CVS but > > failed miserably due to missing symbols, files and directories. Can > > someone > > provide me with some help to do this, or better yet point me at at > > tarball > > of the latests buildable source. > > > > Also is there an online archive of this list? > > > > Thanks > > Steve > > -- > > __ > > Stephen Martin _ _ |/_ \ MORTICE KERN SYSTEMS INC. > > [EMAIL PROTECTED] ,/ \ / \ | / |( | 185 Columbia Street West > > (519)883-3215| | | |/ | \ / Waterloo, Ontario > > Fax: (519)884-8861 | | | | \ | _) Canada N2L 5Z5 > > \__/ > > "If Bill Gates had a nickel for every time Windows crashes... Oh wait! > > He Does!" > > >
Re: DIA and printing
I have been looking at adding gnome-print support to dia. It looks like all the required hooks are there, including what is needed to do multi page printing. I can't say when/if it will become usable, but I just thought I would mention it (I am currently just implementing a renderer for gnome-print -- doing multipage printing should sit quite nicely on top of it). This could also give print preview support for free. Alexander said he was looking at implementing postscript printing at some point as well, which would not require the gnome libraries. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 7 Sep 1999, Brian Aker wrote: > Has anyone come up with a good solution on how to > print from dia? The way that dia scales its EPS > output means that I get portions of documents > cut off whenever I go to print something. > Any solutions? > -Brian >
RE: DIA and printing
Actually, it can't print arbitrary X fonts. The list of fonts gnome-print can use is contained in $(prefix)/share/fonts/fontmap. The default install will use all the type1 outline fonts that came with X and the URW fonts (free, high quality versions of the standard postscript fonts) that come with ghostscript though. Getting fonts correct is one of the most difficult things to get right. I still have not got font issues completely sorted out for my SVG output filter. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Wed, 8 Sep 1999, Arjan J. Molenaar wrote: > Hi, > > > > > I have been looking at adding gnome-print support to dia. It > > looks like > > all the required hooks are there, including what is needed to do multi > > page printing. I can't say when/if it will become usable, but I just > > thought I would mention it (I am currently just implementing > > a renderer > > for gnome-print -- doing multipage printing should sit quite > > nicely on top > > of it). This could also give print preview support for free. > > An additional advantage of gnome-print is the ability to print normal X-fonts. That >will make dia more "sellable", since the average user wants to use it's favourite >fonts. > > > Alexander said he was looking at implementing postscript > > printing at some > > point as well, which would not require the gnome libraries. > > > > James. > > Arjan >
RE: DIA and printing
There is no reason why true type font support could not be added to gnome-print. I think they just implemented type1 support because it fits in with post script well and Raph Levien already had a type1 parser which could be used with other formats. If you really want to see true type support, I am sure they would appreciate your help. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Wed, 8 Sep 1999, Arjan J. Molenaar wrote: > Hmmm... I thought I read it in the gnome-print design paper... > > sorry for the mistake... > > I hope they will make True-Type printing work, though. > > Arjan >
First attempt at gnome-print support
Hello, I have just checked in my first attempt at print support in dia. It uses gnome-print, and is disabled by default. To enable the code, run configure with the --enable-gnome and --enable-gnome-print arguments. This will add a print item to the right click menu that can be used to print the diagram. There are a few bugs, and the postscript it produces seems to be a bit broken. I am not sure if it is my code or gnome-print that is causing breakage though (any postscript gurus welcome to tell me!). Also, the gnome-print API does not have support for elliptic arcs, so ellipses and arcs will not print properly at the moment. Either support needs to be added to gnome-print, or I could approximate them with beziers. Other than that particular brokenness, it does multipage printing, and clips each page so that it does not draw to the margins. It also only draws the objects that overlap with the page area when rendering each page. It will completely skip empty pages. A lot of the pagination code could probably be used for a straight postscript output renderer. As I said in a previous message, the gnome-print backend will also allow printing to non postscript printers such as most ink jets, and has print preview support. This gives a fairly complete printing architecture. If anyone has any comments, or patches to fix bits of the code, please share them. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: First attempt at gnome-print support
I just fixed one of the bugs in the code (the bit which sets the line style). It turned out gnome-print was a little bit broken. If you want to test out this code, I recommend getting the latest CVS version of gnome-print as well. I just tried printing samples/UML-demo.dia, and it seemed to work quite well, splitting the file over a number of pages. I should probably add the ability to scale the image before printing as well. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Wed, 8 Sep 1999, James Henstridge wrote: > There are a few bugs, and the postscript it produces seems to be a bit > broken. I am not sure if it is my code or gnome-print that is causing > breakage though (any postscript gurus welcome to tell me!). Also, the > gnome-print API does not have support for elliptic arcs, so ellipses and > arcs will not print properly at the moment. Either support needs to be > added to gnome-print, or I could approximate them with beziers.
Re: DIA and printing
Dia does not rely on gnome. This particular implementation of printing support does rely on gnome though. As I said earlier, there will probably also be a straight postscript printing option for dia as well. In fact, it will probably be able to use some of the ideas in the gnome-print support code, as gnome-print is quite similar to the postscript imaging model. The gnome-print support I did was about a two day hack to see how easy it would be to add print support, and it looks like it is pretty easy. If anyone wants to have a go at a pure postscript print driver for dia, it could probably be done in a few hours by hacking up render_eps.c and using a bit of code from paginate_gnomeprint.c. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 7 Sep 1999, Andreas Micklei wrote: > Hi, > > On Wed, Sep 08, 1999 at 12:16:52AM +0800, James Henstridge wrote: > > [gnome-print] > > Please don't make dia rely on gnome to much. I use the current > stable release of dia on a SPARC/Solaris machine quite happily. > Installing gnome under Solaris is a nightmighare. I did not > manage to do it yet. > Integrating gnome support as an option via GNU autoconfuse would > be nice though. Relying on a single library that can be easily > installed without all the other gnome stuff is also okay. > > Again. Just my 0.02 Euro. > >bye... > Andreas Micklei > > -- > | Andreas Micklei - [EMAIL PROTECTED] / [EMAIL PROTECTED]/ Public key | > | V 3.1: GCS d- s:-- a- C++$ UBLS++$ P>++ L++(+++)$ E---/\ / available | > | W++(-) N++ o-- K++ w--- O? M V? PS++ PE- Y+>++ PGP+ t+ ( ) on request | > | 5 X(+) R(+) tv-(+) b+ DI++ D+(---) G e>+++ h--- r++ y+ .( o ).| >
Re: Building dia from CVS
Alright, do you have the following on your system? automake-1.4 autoconf (whatever version automake-1.4 requires) gettext-0.10.35 libtool-1.3 If you have those on your system, you should be able to compile dia from CVS. From the errors, it looks like you are missing gettext. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Wed, 8 Sep 1999, Stephen Martin wrote: > A couple of days ago I complained that I could not build dia from CVS. > Here is what happens when I try: > > ./autogen.sh > I am going to run ./configure with no arguments - if you wish > to pass any to it, please specify them on the ./autogen.sh command line. > Running gettextize... Ignore non-fatal messages. > ./autogen.sh: gettextize: command not found > Running libtoolize > You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'. > aclocal: configure.in: 106: macro `AM_GNU_GETTEXT' not found in library > configure.in: 106: required file `./ABOUT-NLS' not found > Makefile.am:3: required directory ./intl does not exist > loading cache ./config.cache > ./configure: syntax error near unexpected token `AM_INIT_AUTOMAKE(dia,' > ./configure: ./configure: line 531: `AM_INIT_AUTOMAKE(dia, 0.41)' > > Now type 'make' to compile dia. > > Any sugestions? > > Steve > -- > __ > Stephen Martin _ _ |/_ \ MORTICE KERN SYSTEMS INC. > [EMAIL PROTECTED] ,/ \ / \ | / |( | 185 Columbia Street West > (519)883-3215| | | |/ | \ / Waterloo, Ontario > Fax: (519)884-8861 | | | | \ | _) Canada N2L 5Z5 > \__/ > "If Bill Gates had a nickel for every time Windows crashes... Oh wait! He Does!" >
Gnome-print support again
I have got the gnome-print support pretty much working. Since there is not elliptic arc support in it (yet), I have implemented the ellipse rendering functions in terms of bezier curves. The arc functions are not implemented though. I fixed the pagination code so that it does not print blank pages when it shouldn't (it still will for some non square objects such as lines). I have also added a paper selector and a scaling entry to the print dialog. You can now print the diagram at 0.5 size on B4 if you really want to. If having gnome print support but no non-gnome print support really bugs people, I could take a look at implementing it as well if I have time. The only thing I don't know how best to implement is getting paper metrics. The gnome-libs has some functions to do this, so it was a non-issue there. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
printing without gnome-print
I have just commited some more printing code. It should now be possible to print from dia without gnome-print. To get this working, I added a few modifications to the EPS renderer so that it could be initialised in such as way that it could be used to print multiple areas of the page. I then ported my gnome-print pagination code to straight postscript. It should handle piping the output directly to lpr or printing to a file. It also has some knowledge of different page metrics, and allows scaling. It outputs the document structuring comments that allow you to jump between pages in ghostview/gv. Try out the latest CVS version and see if you can find any problems. It is pretty similar to the gnome-print version, except it supports elliptic arcs and ellipses correctly. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: MS to buy Visio corp
If you look at the current CVS version of dia, you will see that it has an SVG output filter and code to load shapes from XML files that use a subset of SVG to describe the shape. I don't think SVG (or PGML, etc) would be a very good native format to store dia drawings in, for the same reasons I don't think it would be best to store them in postscript -- it is more low level than we want. Of course there is also multipage printing support in CVS. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Wed, 15 Sep 1999 [EMAIL PROTECTED] wrote: > > Adobe is pushing PGML as an alternative. See > > http://www.xml.com/xml/pub/98/06/22 > > > > I think DIA ought to adopt one or the other if it makes sense technically. > > > > The WWW Consortium has codified these into a single standard, SVG, that > is moving into its final drafts. It's already drawing quite a bit of > industry support as well, and Raph Levien's vector graphics project for > GNOME uses it, so there's code available. Lots of info available here: > > http://www.w3.org/graphics/svg > http://www.levien.com/svg > > Alan >
custom shape code
I just commited a bit of stuff to the custom shape code. It now acts a bit closer to the SVG spec so that if you don't set the fill colour, a drawing element will be unfilled. I also added the ability to force a particular colour (ie. to get red, you would use "fill: #ff"). It is also possible to set the stroke or fill colours to the shape's foreground colour (using foreground or fg) or background colour (with background or bg) or text colour (with text). You can also use default or inverse which behave differently depending on whether you are setting the stroke or fill colour. I am planning on adding support for a few attributes for line style (line caps and join styles and dash pattern). This would allow you to overrride the user specified values. After that, it should be possible to draw most shapes with the custom shape code. On the subject of using the custom shape code to fill out the current set of palettes, the best way to do this would be to statically link the code into dia so that it will be available to other object libraries. What do people think of this idea? James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: custom shape code
I was just asking about this because someone suggested it a while back. If it helps flesh out some of the sheets (such as the network sheets or flowcharts), it may be worth it. Here are some other changes I think may be worth looking at for the next release of dia: - Move the page size/zoom selectors from the print dialog to a page setup dialog, and save the settings with the actual diagram. Probably also allow changing of the margins here. - When paginating the diagram for printing, make the origin fall on a page boundary, and show the page breaks on the diagram (this would just be a simple modification on the current grid display code). - Instead of using dlopen directly, use gmodule to load the object libraries. This way we don't have to worry about whether underscores are prepended to symbols, and dia will have a better chance of working on systems that don't support dlopen. - Maybe move the files installed in the home directory to a .dia subdirectory: ~/.diarc -> ~/.dia/diarc ~/.dia_shapes/ -> ~/.dia/shapes/ ~/.dia_libs/ -> ~/.dia/lib/ or ~/.dia/objects/ This should cut down on clutter in the home directory. The ~/.dia heirachy could be created the first time a user runs dia. I think it would be a good idea to get a new tarball release out some time. The current CVS version is much better than the last released tarball (undo, custom shapes, printing, SVG export, more objects, line style selector in toolbox, etc). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Thu, 7 Oct 1999, Alexander Larsson wrote: > On Thu, 7 Oct 1999, James Henstridge wrote: > > > On the subject of using the custom shape code to fill out the current set > > of palettes, the best way to do this would be to statically link the code > > into dia so that it will be available to other object libraries. What do > > people think of this idea? > > I'm not sure why this is absolutely necessary, but i think it's a very > good idea anyway. > > / Alex > >
RE: custom shape code
Each custom object can have a text area attached to it (specified with the element). You can set the font for this as you would on any other object. The shape will grow if the text does not fit into the text box. None of the circuit shapes I did have a text area attached (the code does work though). Is this what you were wondering about? One other feature that would be nice to have would be a default font selector in the toolbox. From some of the comments in one of the stories about dia I posted to Gnotices (news.gnome.org), some people think dia only supports courier. It was for a similar reason I designed the line style selector that is in the CVS version (when I first started using dia I couldn't see how to set arrows on lines at all). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Thu, 7 Oct 1999, Arjan J. Molenaar wrote: > Hi, > > I have a question about this (for adding it to DiaCanvas, if I may): how can it >handle text, is it possible to edit text the way you would if it was a "programmed" >object? It would be nice for lots of object (use cases, classes). > > regards, > > Arjan > > > > > I just commited a bit of stuff to the custom shape code. It > > now acts a > > bit closer to the SVG spec so that if you don't set the fill colour, a > > drawing element will be unfilled. > > > > I also added the ability to force a particular colour (ie. to > > get red, you > > would use "fill: #ff"). It is also possible to set the > > stroke or fill > > colours to the shape's foreground colour (using foreground or fg) or > > background colour (with background or bg) or text colour > > (with text). You > > can also use default or inverse which behave differently depending on > > whether you are setting the stroke or fill colour. > > > > I am planning on adding support for a few attributes for line > > style (line > > caps and join styles and dash pattern). This would allow you to > > overrride the user specified values. After that, it should > > be possible to > > draw most shapes with the custom shape code. > > > > On the subject of using the custom shape code to fill out the > > current set > > of palettes, the best way to do this would be to statically > > link the code > > into dia so that it will be available to other object > > libraries. What do > > people think of this idea? > > > > James. > > > > -- > > Email: [EMAIL PROTECTED] > > WWW: http://www.daa.com.au/~james/ > > > > >
RE: custom shape code
Currently, the object will grow with a fixed aspect ratio when you type in more text. It does not shrink if you remove the text (the user has to do this manually). The text box is not actually specified as part of the SVG section of the shape file. There isn't really support for text entry fields in SVG. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Thu, 7 Oct 1999, Arjan J. Molenaar wrote: > > > Each custom object can have a text area attached to it > > (specified with the > > element). You can set the font for this as you would on any > > other object. The shape will grow if the text does not fit > > into the text > > box. None of the circuit shapes I did have a text area > > attached (the code > > does work though). > > > > Is this what you were wondering about? > > Basically: yes. > > The problem with text is the kind of element they are connected to: > 1. elements that grow and shrink as the text grows/shrinks, with or without a fixed >aspect ratio; > 2. elements that don't grow nor shrink. > > I don't know if SVG supports extentions for these kinds of behaviour, but it would >simplify the creation of new elements a lot (you don't have to do the C thing >anymore). If you can shed a light on this matter I'd be thankful. > > Arjan >
Re: custom shape code
Mainly I just want to see where the page boundaries are. I was printing out a UML diagram for one of my courses at uni, and many of the boxes were split over multiple pages. If you can see where the page boundaries are, you can arrange the objects so that they look nice when printed. Of course the page boundaries are dependent on page size, margins and scaling factor, which is why I was thinking it would be better to store this information with a diagram. Having the page boundaries aligned with the origin would also be necessary for this feature to work correctly. If anyone else has some ideas for how to make printing better, please tell us (it probably won't get implemented if no one knows what you want). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Thu, 7 Oct 1999, Alexander Larsson wrote: > > - When paginating the diagram for printing, make the origin fall on a page > > boundary, and show the page breaks on the diagram (this would just be a > > simple modification on the current grid display code). > Do you mean something like "print preview"? >
Re: custom shape code
This is for printing support only. With the EPS export filter, you just get a single diagram. I think I saw something like this in ABC flowcharter, and it is very useful when preparing diagrams to be printed on multiple pages. It won't affect the EPS output, but it makes it much easier to produce diagrams that print nicely on multiple pages. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Thu, 7 Oct 1999, Alejandro Aguilar Sierra wrote: > On Thu, 7 Oct 1999, James Henstridge wrote: > > > Mainly I just want to see where the page boundaries are. I was printing > > out a UML diagram for one of my courses at uni, and many of the boxes were > > split over multiple pages. If you can see where the page boundaries are, > > you can arrange the objects so that they look nice when printed. > > But if you want a scalable EPS, does it still makes sense a page boundary? > > Alejandro >
gmodule support
I just saw this log message: >1999-10-10 Fredrik Hallenberg <[EMAIL PROTECTED]> > > * configure.in: > * app_procs.c: > * objects/flowchart/box.c > * objects/flowchart/ellipse.c > * objects/flowchart/flowchart.c > Use gmodule for dynamic linking. As gmodule is using > RTLD_GLOBAL i had to change flowchart box and ellipse > so the typenames doesn't conflict with the standard > box and ellipse. I had not realised that gmodule hard codes the RTLD_GLOBAL flag. This could cause some problems in the future if we have heaps of object libraries. There are a few other ways around this: 1) create a file objects/object_symbols.sym that contains the lines: get_version register_objects register_sheets Then edit the makefile and add "-export-symbols $(srcdir)/../object_symbols.sym" to the end of the libtool link flags. This will limit the number of symbols exported by the library to a minimum, thus getting around the problem. Unfortunately it says that this option has no effect on some systems. 2) Try to get gmodule modified to let you turn off the RTLD_GLOBAL flag. 3) Start using a naming scheme for global variables in the object libraries where the name of the library is prepended to the variable name. 3) Switch back to using dlopen. It would be nice to use gmodule (if anyone wanted to port dia to a unix that uses DLD, windows or OS/2, it would greatly simplify things). I have also done a bit more work on the custom shape code. I have got to a stage where I think the file format will handle most shapes people want to draw. It gives the person creating the shape control over line styles, so you can override the user's setting for parts of the shape. One area that is still not perfect is selection. Right now it is just using a bounding box for selection purposes. The distance algorithms for bezier paths and polygons look like they would be most difficult. If anyone else wants to take a crack at this, feel free. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Custom shape code as static library
I have converted the custom shape code to a static library that is linked into the main dia executable. I also added a shape defined in XML to the flowcharts sheet as an example. It should now be easy for people who don't know C to fill out the network sheets in dia. There are some instructions on creating new shapes in the file objects/custom/README. With a bit of help, we should be able to get quite a large number of shapes ready that can be used with dia. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Print support extensions
As part of the printing support extensions I was proposing for dia, page layout information needs to be stored with the diagram. I have been looking at creating a nice dialog for manipulating these settings. I put together a mock up with glade, and would be interested in people's comments about it: http://www.daa.com.au/~james/pagelayout.png If there is any other page layout information that should be in that dialog that I have missed, please tell me. The idea is that this information would be stored with the diagram, and the page breaks would be displayed when editing the diagram so that objects can be layout out nicely on multiple pages. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: Print support extensions
I guess I will code that dialog then. The page view was just a pixmap in that image -- it should give an idea of the page dimensions and margin positions when I actually code it. As for the fit to page idea, Maybe I could add a button to do this to the scaling frame. From the margins and paper size, it should be possible to work out the correct scaling factor. It looks like it should be possible to store all this page layout info in the diagramdata section of the diagram file, which means that the changes won't affect compatibility between new and older versions of dia. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 12 Oct 1999, Alexander Larsson wrote: > On Tue, 12 Oct 1999, James Henstridge wrote: > > > As part of the printing support extensions I was proposing for dia, page > > layout information needs to be stored with the diagram. I have been > > looking at creating a nice dialog for manipulating these settings. > > > > I put together a mock up with glade, and would be interested in people's > > comments about it: > > http://www.daa.com.au/~james/pagelayout.png > > It looks *very* good. > > > If there is any other page layout information that should be in that > > dialog that I have missed, please tell me. The idea is that this > > information would be stored with the diagram, and the page breaks would be > > displayed when editing the diagram so that objects can be layout out > > nicely on multiple pages. > > I still miss fit-to-page, but i don't really know how it would fit in the > dialog. And for easier use (for non programers/mathemeticians) maybe the > scaling should be in percent. > > / Alex > > > >
Re: Feature freeze
The page setup dialog can wait. It is not finished and yet, and I haven't started integrating it into dia, so this is not a problem. I still want to add a few shapes to the flowchart sheet, but I am doing this with the custom shape code, so should not introduce bugs. If you are going for a feature freeze, I suggest releasing a test release (maybe 0.49 or something) and announcing it on gnome-announce-list or one of the gtk lists with a short list of the new features, and ask people to test it to find bugs. You should be able to use the gnome bug tracking system to collect the bugs. You should ass a line to the Maintainers file in the debbugs module saying where you want the bugs sent (maybe dia-list would be appropriate?) James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 12 Oct 1999, Alexander Larsson wrote: > I'd like to announce a feature freeze for Dia. > > We need to get a new version out soon. > > Here are the stuff on my TODO-before-release list: > > * last part (marked todo in paginate_psprint.c) of print_save.diff dialog > stuff. > > * bigger main window on startup. > > * Problem loading old files with OrthConn based object. > > * Keyboard accels must be disabled whilst dragging an object or > handle, else stuff can crash easily by deleting (Ctrl-X) while dragging. > > * Should zigzagline default to three segments? > > There is also the print dialog stuff James is working on. James, how long > do you think It'll take? Do you want it in this release? > > Is there anything else anyone wants fixed or added before release? > > / Alex > > > > > >
Re: Print support extensions
I was thinking more of a normal push button that would change the scaling factor to get the diagram to fit to the page. This is probably easier to implement. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 12 Oct 1999, Alexander Larsson wrote: > On Tue, 12 Oct 1999, James Henstridge wrote: > > > As for the fit to page idea, Maybe I could add a button to do this to the > > scaling frame. From the margins and paper size, it should be possible to > > work out the correct scaling factor. > > Yes. Maybe a checkbox that says fit-to-page, which dims the scale widget > when selected. >
Re: Feature freeze
To get bugs.gnome.org to handle dia, checkout the debbugs module from CVS and add a line for dia to the Maintainers file. You may also need to mail Vincent Renardias <[EMAIL PROTECTED]> to make sure it gets set up correctly. You are correct that it is using the same software as the Debian Bug tracking system. It should then be possible to submit dia bugs to [EMAIL PROTECTED] One thing to think about is where you want bug reports sent by default. The two obvious places would be straight to you or dia-list. Either way, the bug tickets will be viewable at http://bugs.gnome.org/ James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Wed, 13 Oct 1999, Alexander Larsson wrote: > Traditionally the new release would be called 0.50, but i feel that there > is so much new stuff in this release, and it's really getting usable now. > By having a version number closer to 1.0 I think it will attract more > causal users. What about 0.80? With a more internal 0.80beta release > before that? > > > You should be able to use the gnome bug tracking system to collect the > > bugs. You should ass a line to the Maintainers file in the debbugs module > > saying where you want the bugs sent (maybe dia-list would be appropriate?) > > How do i add a new package to bugs.gnome.org? > What do you mean by debbugs? The Debian bugtrack system? > > / Alex > >
Page setup widget
I did a bit more work on the page setup dialog, and got something that looks close to the mock up I posted here a few days ago. It is not currently in dia (partly because of the feature freeze for the release, and partly because I haven't finished it yet). If you want to test it out, update your cvs tree and run the following: cd app make diapagelayout.o gcc -o pl_test diapagelayout.o `gtk-config --libs` Then run the program. The margin display page should display in the bottom right hand corner of the window, and should have dimensions similar to the actual paper size (test this by changing the paper size). The widget has changed and fittopage signals. The test program has simple dummy handlers attached to them. Any comments/ideas for improvement are welcome. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Flowchart shapes
I have just finished adding a whole lot of shapes to the flowchart sheet for dia. This brings the total up to 28 flowchart shapes, which should make dia very useful for this type of diagram. A lot of the shapes have been done with the custom shape code, so may be useful if someone wants to use it to flesh out some of the network sheets. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: Flowchart shapes
The development source of dia is in the gnome CVS tree. There are instructions on how to get things out of CVS at www.gnome.org. The module is dia, as you would expect. It does not depend on any development libraries, so you shouldn't need any other modules from CVS -- just whatever you needed to build the tarball releases. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Fri, 15 Oct 1999, Donald St. Denis wrote: > > Hi, > > I decided I would like to test the newest dia off the CVS Gnome, > but from the standard dia download site I can't figure out how to > do the download of the source. I have Redhat Linux 6.0 installed > and running, and can do the compile, link, etc. I also have some > experience in this area. > > I've gone through the Gnome CVS, but don't see anything about > downloading that pertains... > > Where (how) do I look for the download? > > ( \|/ ) > Don ( Sunshine --O-- ) St. Denis > ( /|\ ) > > > James Henstridge writes: > > I have just finished adding a whole lot of shapes to the flowchart sheet > > for dia. This brings the total up to 28 flowchart shapes, which should > > make dia very useful for this type of diagram. A lot of the shapes have > > been done with the custom shape code, so may be useful if someone wants to > > use it to flesh out some of the network sheets. > > > > James. > > > > -- > > Email: [EMAIL PROTECTED] > > WWW: http://www.daa.com.au/~james/ > > > > >
Re: Archives?
See http://www.mail-archive.com/dia-list@lysator.liu.se/ James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On 15 Oct 1999, Daniel Wang wrote: > > Are there archives of the mailing list available? > > >
New version
I think I have put in all the stuff I wanted to for the new version of dia. If everyone else has as well, maybe it would be a good idea to put out a test release soon. I am sure there are lots of people on gnome-list and one of the gtk lists (and dia-list of course) who would be happy to submit bug reports which should be helpful. I have not seen any showstopper bugs, so the test period should not be too long. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: Bug flowchart diamond
If you could send me the offending file, that would be great. It would probably be best to send the file to me as private mail. As for the default font for new objects, it would be a good idea to have something like this in the main toolbox along with the colour, line style, line width and arrow style selectors. I may be able to code it for the next release (it is a bit late to get it ready for 0.80). Do you have any ideas about what sort of interface would be best for this? Ideally, it should be small and obvious how it works (like the other selectors). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On 16 Oct 1999, Daniel Wang wrote: > > > I just compiled the latest version out of CVS and there seems to be a bug > with the flowchart "A diamond with text inside object". > > After creating one and moving it around, it seems that somethings goes wrong > with its computation of the bounding box or routing of events to it. > When I click a "random" locations that are nowhere near the diamon object it > gets selected. I can send you a .dia file that contains the bug. Saving and > loading the file seems to keep this bug working > > I just started playing with dia, it's quite cool. > > BTW on another note is there a way to change the default text font to > helvetica-bold for all the objects? >
Re: custom shapes with XML
If you want your object to have a fixed aspect ratio, add the following lne to the shape file: By default, shapes have a free aspect ratio. Maybe it would be a good idea to have new shapes inserted with the same aspect ratio as they were drawn. Setting aspect ratio to fixed will also make sure that the shape keeps the aspect ratio when it is resized. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Sun, 17 Oct 1999, Siegfried Stepke wrote: > Hello, > > I play around with custom shapes and find some wierd behaviour: > > Whenever I try to create a rectangle (6x1 or 4x1) it gets inserted as > a square rectangle with 2x2 in the grid... > > This is the source of my rect.shape: > > http://www.daa.com.au/~james/dia-shape-ns" >xmlns:svg="http://www.w3.org/Graphics/SVG/svg-19990730.dtd"> > Rect > A Rectangle 6x1 > router.xpm > > > > > > > > > > > > > > Also a brings up a square... > > Any hints? > > BTW: a pointer to "objects/custom/README" in the README, INSTALL or HACKING > file would be great! > > thanks, > Siegfried > > - > netz.at - mehr als nur statische seiten[EMAIL PROTECTED] > Ziegelofengasse 21-23/5 Tel +43-1-544 86 79 > A-1050 Wien Fax DW 10 > - >
Re: Version 0.80 candidate in cvs
One other person had a problem like this. It turned out that he had automake-1.3 rather than 1.4. If you have an old automake, then this would be your problem. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Sun, 17 Oct 1999, Brian Jepson wrote: > On Sat, 16 Oct 1999, Alexander Larsson wrote: > > > Ok, now i have a version in CVS which i think is good enough for a > > release. Any comments on it? Any known problem? Did i forget any change in > > the NEWS file? > > Sorry this is so late, but on Debian 2.1 for SPARC, with a fresh checkout > of CVS, the compilation fails when it tries to link everything into the > dia executable: > > commands.o: In function `file_print_callback': > /home/bjepson/src/dia/app/commands.c:585: undefined reference to `diagram_print_ps' > make[2]: *** [dia] Error 1 > make[2]: Leaving directory `/home/bjepson/src/dia/app' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/bjepson/src/dia' > make: *** [all-recursive-am] Error 2 > > I ran autogen.sh with: > > ./autogen.sh --prefix=/opt/dia-latest/ > > Here are the various versions of stuff I have: > > libxml-dev 1.0.0-0.1 > gdk-imlib-dev 1.9.4-3 > imlib-dev 1.9.4-3 > libgtk1.2-dev 1.2.1-1 > > Thanks, > > Brian Jepson * ([EMAIL PROTECTED]) * http://users.ids.net/~bjepson >
Re: Version 0.80 candidate in cvs
It is generally a good idea not to put generated files like this in CVS. CVS is really meant for developers, who could be expected to have the build tools installed on their system. If you want to build stuff from cvs (this applies to just about everything in the gnome cvs tree), it is a good idea to have up to date build tools. Note that these packages are not required if building from tarballs. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On 17 Oct 1999, Daniel Wang wrote: > > Brian Jepson <[EMAIL PROTECTED]> writes: > > > On Mon, 18 Oct 1999, James Henstridge wrote: > > > > > One other person had a problem like this. It turned out that he had > > > automake-1.3 rather than 1.4. If you have an old automake, then this > > > would be your problem. > > > > Thank you - that appears to be the problem - I have automake 1.3-2 from > > the Debian 2.1 distribution. I'll get a newer version and try it out. > > Is there any reason not to check in the configure script itself into the CVS > repository? > > I know it's a derived file and really shouldn't be checked in, but I think > it would solve a lot of these versioning issues, and make it easier for > random people to just suck sources from the repository type configure and > build.. >
Re: Cyrillic
If you have any idea about what is wrong with the EPS output of dia (ie. why the output is broken for cyrillic), this would be helpful. If the EPS output is broken for cyrillic, it probably isn't intentional. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Mon, 18 Oct 1999, Sergey V. Udaltsov wrote: > Hello all > > Thank you very much for 0.80 release. It is realy usable tool. > The only problem I have is about cyrillic characters: Dia shows them > correctly but prints (and exports to EPS) in a wrong way. I think, this > is a bug... What about i18n policy of dia? > > Regards, > > Sergey V. Udaltsov > > PS. I probably the oddiest member of the comminity - right now I am also > fighting for i18n in AbiWord :) I really believe in strength of OS so I > think it should be better than now - for all users, without > discrimination. M$ sucks but its i18n is much better than one of GNU. > Pity:( >
Re: Bug flowchart diamond
Corel Draw also uses this key combo for duplicate. It also allows you to do some weird things like specify the exact offset where the duplicated shape will appear, which allows you to quickly create many aligned duplicates. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On 18 Oct 1999, Daniel Wang wrote: > > > Changing Ctrl-D to duplicate would be a nice feature too... :) > > > > Are you used to that? From what app? > > I think that's a Macism, that's been hardwired into me... :) Or maybe I > picked it up from idraw... >
Re: dia fails to read hand-generated file
Dia prints that error if the document is not a valid XML file (ie.
openning and closing tags don't match or the header is
missing). Looking at your code, the only thing I see that could cause
this is this line:
print qq{
^
This is probably supposed to say "http://www.daa.com.au/~james/
On Tue, 19 Oct 1999 [EMAIL PROTECTED] wrote:
>
> I've written the following dumb perl script to generate a dia file
> from my database table layout (pretending that each table is a UML object
> with just attributes). So, I run this, and try to read the resulting
> file. I get "Error loading diagram: /tmp/dbinfo Unknown file
> type". What am I doing wrong?
>
> I suspect that the problem has to do with not knowing up-front what
> the width/heights should be for everything. How do I calculate those,
> if I don't know the font, etc?
>
Page setup widget
I have been doing a little more hacking on the page setup widget for dia. I realised that there was no indication of what units were being used for the margins. So I created a new DiaUnitSpinner widget, which is basically a GtkSpinButton that understands units. You can now type in "1.0in" into the dialog, and press enter, and it will convert it to "2.54cm" for you. I also made the page setup widget display the dimensions of the currently selected paper. To test out these changes, update your CVS checkout and run: cd app make diapagelayout.o diaunitspinner.o gcc -o pl_test diapagelayout.o diaunitspinner.o `gtk-config --libs` Any comments on the widget are welcome. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: libxml.so.1 ?
This is the libxml package. You should get an up to date version from ftp.gurulabs.com. If you are using gnome, consider grabbing the updated gnome RPMs as well. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 19 Oct 1999, Bae Jungmin wrote: > Hello. > I want to install dia by rpm. > but, libxml.so.1 must be needed. > In www.redhat.com, there is not that. > where? > If u send me that, then Thank u very much.^^ > > p.s. > My English is very poor. sorry. >
Re: lib-versions
It is a bit difficult to tell, since you haven't said why you couldn't compile 0.80 (ie. what error messages did the compiler spit out?). If you can give that information, then we may be able to work out what the problem is. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Thu, 21 Oct 1999, Marc Michalewicz wrote: > Hi, > > i successfully compiled and linked dia in Version 0.41 but have problems > to compile V. 0.80 (final linking of "dia"), do one need new versions of > some libraries ? And if yes, which ones ? > > Thanks in advance, > Marc > >
Re: missing standard objects
The standard objects are stored under $(prefix)/lib/dia (where prefix is where dia was installed). What is the contents of this directory? Also, what OS/architecture are you using? James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Thu, 21 Oct 1999, Marc Michalewicz wrote: > after having a look to another mail in the archive i found that some > libraries were missing in my linking process, something with the > configure-script failed (as in 0.41), do not know why, but now it > successfully linked, but - failed to execute with the message > "Couldn`t find standard objects when looking for object-libs, exiting..." > > Can anybody give me a hint whats wrong here ? > > Thanks, > Marc > >
Re: XML for lines and arrows
Having some method of adding new arrows in dia (through C code or XML), in such a way that object libraries could install new arrows (eg. ER object library installs crow's foot arrows), would be very useful. Currently, it looks like all that would be needed would be an arrow drawing implementation that arrow_draw() could use, and possibly a GDK renderer for the arrow selection widget in the main toolbox. If you do decide to do an SVG/XML based format, feel free to swipe code from objects/custom/shape-info.c. It has support for reading a useful subset of SVG (including some of the style information). That together with a bit of work with affine transformations, and you should be able to render arrow heads quite easily. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Wed, 20 Oct 1999, Scott Wimer wrote: > Hi folks. > > I'm wanting to develop some new arrows (crowsfeet for ER diagrams), > and while it doesn't look too hard to just make them in arrows.c, > I'm wondering if it might not be better for me to try figuring out > how to define the arrows as custom SVGs using XML (like the custom > objects). > > Anyway, i'll be making an attempt at this later this week, unless > other folks are in the process of doing so. > > Regards, > scottwimer > -- > Scott Wimer > Play: [EMAIL PROTECTED]www.cgibuilder.com > Work: [EMAIL PROTECTED]www.earthlink.net >
Re: Bounding box errors
This is probably due to mitered corners on some of the lines. I suppose the code should take account of this, or use some other line join style such as rounded or beveled. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On 21 Oct 1999, Lars Clausen wrote: > > I saw a couple problems with the bounding boxes today: If you create a > very large arrowhead (like 10x10), it goes outside the BB. Also some of > the shapes go outside, for instance the PNP shape in circuits. Just FYI. > > -Lars > > -- > Lars R. Clausen (http://shasta.cs.uiuc.edu/~lrclause) Hårdgrim of Westfield > "I do not agree with a word that you say, but I will defend to the death your > right to say it." -- Voltaire (?) >
Re: --enable-gnome
I think I saw this bug a while back. It seems to occur when trying to
draw a bezier curve where all the end points and control points coincide.
This seems to happen sometimes if you place a shape that uses bezier
curves by clicking and slowly dragging out the size of the shape. When
this happens, it tries to draw the shape very small for a little while.
If anyone wants to look at this bug, this is probably a good place to
start.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
On 22 Oct 1999, Daniel Wang wrote:
>
> Alexander Larsson <[EMAIL PROTECTED]> writes:
>
> > On 21 Oct 1999, Daniel Wang wrote:
> >
> > >
> > > Alexander Larsson <[EMAIL PROTECTED]> writes:
> > >
> > >
> > > > You need to remove your old object libs $prefix/lib/dia/*.so.0.0.0 (*.so
> > > > is the new ones).
> > >
> > > Did this and did a fresh recompile... still segfaults for me...
> >
> > Have you got files like objects/*/.libs/*.so.0.0.0
>
> Nope...
> >
> > Can I see a backtrace?
>
>
>
> This GDB was configured as "i386-redhat-linux"...
> (gdb) run
> Starting program: /mnt/fs1/home/danwang/dia/app/dia
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x8066dc5 in bezier_add_lines (ddisp=0x815ea08, points=0xbf8000bc,
> bezier=0x8089378) at render_gdk.c:687
> 687 {
> (gdb) bt
> #0 0x8066dc5 in bezier_add_lines (ddisp=0x815ea08, points=0xbf8000bc,
> bezier=0x8089378) at render_gdk.c:687
> #1 0x80671ab in bezier_add_lines (ddisp=0x815ea08, points=0xbf8001d0,
> bezier=0x8089378) at render_gdk.c:751
> #2 0x80671ab in bezier_add_lines (ddisp=0x815ea08, points=0xbf8002e4,
> bezier=0x8089378) at render_gdk.c:751
> #3 0x80671ab in bezier_add_lines (ddisp=0x815ea08, points=0xbf8003f8,
> bezier=0x8089378) at render_gdk.c:751
> #4 0x80671ab in bezier_add_lines (ddisp=0x815ea08, points=0xbf80050c,
> bezier=0x8089378) at render_gdk.c:751
> #5 0x80671ab in bezier_add_lines (ddisp=0x815ea08, points=0xbf800620,
> bezier=0x8089378) at render_gdk.c:751
> #6 0x80671ab in bezier_add_lines (ddisp=0x815ea08, points=0xbf800734,
> bezier=0x8089378) at render_gdk.c:751
> #7 0x80671ab in bezier_add_lines (ddisp=0x815ea08, points=0xbf800848,
> bezier=0x8089378) at render_gdk.c:751
> #8 0x80671ab in bezier_add_lines (ddisp=0x815ea08, points=0xbf80095c,
> bezier=0x8089378) at render_gdk.c:751
> #9 0x80671ab in bezier_add_lines (ddisp=0x815ea08, points=0xbf800a70,
> bezier=0x8089378) at render_gdk.c:751
> #10 0x80671ab in bezier_add_lines (ddisp=0x815ea08, points=0xbf800b84,
> bezier=0x8089378) at render_gdk.c:751
> #11 0x80671ab in bezier_add_lines (ddisp=0x815ea08, points=0xbf800c98,
> bezier=0x8089378) at render_gdk.c:751
> #12 0x80671ab in bezier_add_lines (ddisp=0x815ea08, points=0xbf800dac,
> bezier=0x8089378) at render_gdk.c:751
> #13 0x80671ab in bezier_add_lines (ddisp=0x815ea08, points=0xbf800ec0,
> bezier=0x8089378) at render_gdk.c:751
> #14 0x80671ab in bezier_add_lines (ddisp=0x815ea08, points=0xbf800fd4
>
> this goes on and on forever.
>
> my guess is that it's in some sort of inifite loop because of bogus data
> leading to a stack overflow...
>
Re: Default behaviour of adding new classes
Choose preferences from the file menu. The first item on the first page of the preferences dialog should say "Reset tools after create". This sounds like what you want. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Sat, 23 Oct 1999, Andy Bradford wrote: > Hello all, > I just finished building RPMs for OpenLinux and I must admit that DIA is an > excellent program for UML design. I have a simple question about adding > new objects (classes, text, whatever) to the drawing board. After adding > one I would like it to automatically switch to the "Modify object(s)" > dialog so that the next click doesn't place another object of the selected > type on the board. Is there a preference setting that controls this or > will I need to tweak the code to achieve this? > Andy > -- > +== Andy == TiK: garbaglio ==+ > |Linux is about freedom of choice| > +== http://www.xmission.com/~bradipo/ ===+ > >
Page Setup dialog
I have just commited code to enable the page setup dialog. Currently the printing code does not take any notice of those settings, but that won't take long to fix. The dialog uses gnome stock buttons if gnome support is enabled (BTW, should the other dialogs use GnomeDialog if gnome support is enabled?), and the apply button sensitivity changes when you would expect it to. The fit to page button will set the scaling factor to the appropriate value to fit the whole diagram on a single page. The settings in the page setup dialog are saved with the diagram as well. This did not involve any changes to the DTD (it stores all the settings in a composite attribute under the diagramdata section). Now I have to get the print code to use these values, work out what transformations are needed to do landscape printing and look at drawing page breaks on the display. Just a reminder for those people who don't want to use dia for stand alone diagrams, none of this will affect the EPS files that the EPS renderer produces -- it is mainly for printing support. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
landscape printing working
I have just checked in a bit of code to make the postscript printing backend use the settings from the new page setup dialog. I also got landscape printing working correctly, which some people should find useful. The fit to page button also works, which should remove some of the guesswork of scaling a diagram to print on one page. Please report any bugs in this code to me, or through bugs.gnome.org. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
run_dia.sh shell script now works again
When adding all the flowchart shapes I did in XML to dia, I unintentionally made it so that you needed to install dia before running it. I modified it a bit so you can set an environment variable to locate the `internal shapes' (ones that make up part of a sheet with objects written in C). I have updated the run_dia.sh script so that it sets this, and now things should work again. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: --enable-gnome
The one problem with this patch is that it will not draw valid beziers where the start and end points are the same (ie. a closed curve made of one bezier). I don't know if this is a big problem or not though. Perhaps the other points in the bezier should be taken into account. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 26 Oct 1999, Alexander Larsson wrote: > > I think I saw this bug a while back. It seems to occur when trying to > > draw a bezier curve where all the end points and control points coincide. > > This seems to happen sometimes if you place a shape that uses bezier > > curves by clicking and slowly dragging out the size of the shape. When > > this happens, it tries to draw the shape very small for a little while. > > > > If anyone wants to look at this bug, this is probably a good place to > > start. > > Yes, this was probably it. I got the same backtrace making a bezier > (Sybase log) object very small. I fixed this in CVS. > > Daniel, can you try the latest CVS and see if it fixes your problem? > > / Alex > >
Re: --enable-gnome
I suppose so. The other option would be to use the other formula for drawing a bezier curve. It looks something like: 3 ___ x(t) = \ ( 3 ) * x * t^i * (1-t)^(3-i) / ( i )i --- i=0 3 ___ y(t) = \ ( 3 ) * y * t^i * (1-t)^(3-i) / ( i )i --- i=0 (t runs from 0 to 1) Where the first coefficient is the binomial coefficient (ie. 1 for i = 0 or 3, 3 for i = 1 or 2). This way you could decide on a fixed number of points (say 10 or 20), and calculate them. By precomputing the powers of the various values of t, to calculate each point you would only need 24 multiplications and 6 additions. Also, the process is constant time rather than a recursive algorithm. This is potentially not as high a quality, but may be sufficient for on screen display. Another place to look is the algorithms used in libart from gnome-libs (in the art_vpath_bpath.c file). It looks like it uses a similar approach to dia's renderer, except that it looks at `smoothness' to decide when to break out of the recursion rather than spacing of the points. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 26 Oct 1999, Alexander Larsson wrote: > On Tue, 26 Oct 1999, James Henstridge wrote: > > > The one problem with this patch is that it will not draw valid beziers > > where the start and end points are the same (ie. a closed curve made of > > one bezier). I don't know if this is a big problem or not though. > > Perhaps the other points in the bezier should be taken into account. > > Yes, this is true. But from what i can read that would have had problems > before too (division by zero). > > Would this be fixed if we always subdivide at least once? > > / Alex > >
Re: --enable-gnome
You can probably optimise this a bit further -- by precomputing ( 3 ) * t^i * (1-t)^(3-i) for say twenty values of t and i = 0,1,2,3, the ( i ) calculations would reduce to 8 multiplications and 6 additions for each point. All this would require would be a table of about 80 constants. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 26 Oct 1999, James Henstridge wrote: > points (say 10 or 20), and calculate them. By precomputing the powers of > the various values of t, to calculate each point you would only need 24 > multiplications and 6 additions. Also, the process is constant time > rather than a recursive algorithm. This is potentially not as high a > quality, but may be sufficient for on screen display.
Re: Suggestions / wish-list
Maybe having get_attr, set_attr and list_attr methods for objects would be a good idea. For most shapes, these would be enough to build up the properties box for the shape, and would allow you to create a properties box to set attributes on multiple objects (of course, some of the UML shapes will always need their own property dialogs, as they are quite complex). This would also be useful for language bindings and scripting support for dia, which would be a nice addition (for instance, it may be possible to build skeleton code from a UML diagram through a few scripts if we could script dia). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On 26 Oct 1999, Lars Clausen wrote: > > 8. The line thickness and arrow selectors on the toolbox are quite nice. > >Could they be made to affect existing objects, instead of just newly > >created ones? > > Some way of setting attributes for a bunch of objects is sorely needed. I > was working on a standardization of properties that would allow this when > the undo code cut across it. > > -Lars
Re: Two more bugs.
Actually, the gimp-1.1 layers dialog does switch to the `active image' automatically (active image being the most recent one with a button or key event -- motion and focus events are ignored, since there would be problems with that and focus follows mouse). As for the crash with an invalid print command, it may be possible to just ignore SIGPIPE signals while printing. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 26 Oct 1999, Alexander Larsson wrote: > > ** This should be quite easy to fix it anyone knows the code :) ** > > I don't know if this is a bug. I don't think Dia should automatically > change which file is shown in the layer dialog. Gimp does not for > instance. > > > > If i print to a file in a directory which do not exist the program will > > core-dump. That should be checked and there should be a "browse" button, I > > think. It would be nice though. > > This has been fixed by James. It still crashes if i enter an invalid > print command though. > > / Alex > >
Re: Difference between shapes and internal shapes
Currently in dia each sheet of objects in the toolbox has to be defined by a single library. The Circuit sheet for instance is completely loaded from XML files. There are some shapes that will probably never be able to be implemented in XML (the ethernet bus in the networks sheet for instance). But still, the custom shape code is a very easy way of adding shapes. The question is, where to put these XML files. If we put them under $(prefix)/share/dia/shapes, the custom shape code will create a second networks or flowcharts sheet for those particular objects, which is not what I wanted. The idea was to put them outside of the normal shape search path, and that directory name seemed as good as any (if you have a better name, then maybe we can use that). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On 26 Oct 1999, Lars Clausen wrote: > > Before I confuse myself too much and do something rash, could somebody > explain what the internal shapes are for? In the installation, they seem > to just define the flowchart shapes, in no way different from how the > non-internal circuit shapes are handled. > > BTW, I'm quite impressed with the way X and Gtk handles having several > hundred windows pop up. > > -Lars > > -- > Lars R. Clausen (http://shasta.cs.uiuc.edu/~lrclause) Hårdgrim of Westfield > "I do not agree with a word that you say, but I will defend to the death your > right to say it." -- Voltaire (?) >
Re: --enable-gnome
This implementation looks fine. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 26 Oct 1999, Alexander Larsson wrote: > Ok. I've made another attempt. What do you think of this one? > > / Alex
Re: Say hi and nice work.
The latest CVS version of dia can do the fit to page thing. Just right
click on the diagram, choose file then page setup. Set the page size,
orientation and margins appropriately, then click fit to page. It will
set the scaling constant so that image will fit to the page.
I guess this will be available in 0.81 which may come out in a bit (there
were a number of brown paper bag over the head type bugs in 0.80 -- quite
a few in the code I added). Another reason for putting out a 0.81 release
would be to bring translations up to date.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
On Thu, 28 Oct 1999, Cyrille Chepelov (home) wrote:
> On Wed, 27 Oct 1999, Douglas Nichols wrote:
>
> > The only thing I can see that I really need is to be able to make it
> > print right- like on one page..., but maybe I can and haven't figured it
> > out yet. It would be most great if I could just tell it to print on one
> > page and have it scale appropiately.
>
> main.tex :
> %%
> \documentclass{article}
> \usepackage{graphics}
> \usepackage{geometry}
> \geometry{verbose,a4paper,tmargin=20mm,bmargin=20mm,lmargin=20mm,rmargin=20mm}
> \begin{document}
> {\centering
> \resizebox*{17cm}{!}{\includegraphics{foo.eps}}
> }
> \newpage
> {\centering
> \resizebox*{!}{25.7cm}{\includegraphics{foo.eps}}
> }
> \end{document}
> %%
>
> now just odvips that out through gv to select the right page.
>
>
> -- Cyrille
>
> --
> Oh, my god ! I'm trapped into a V90 modem ! PGP ID: A879BEF8
>
>
Re: exporting/printing for a Web page
For now, the best way to do this is to use a postscript converter such as the netpbm pstopnm + whatever combination. I was thinking about what would be needed to get proper bitmap output from dia for web pages and the like. What I was thinking of was creating a thin band GdkPixmap -- say the diagram's width and 25 to 50 pixels high. The top band of the diagram would be rendered to the pixmap by the standard gdk renderer. The gdk_image_get() function can be used to create a GdkImage from the contents of the GdkPixmap, from which we can get the pixel values from the image with gdk_image_get_pixel(). The band of image data could be passed off to the image library (eg. libpng or libtiff). The process would be repeated for the other bands in the image. You would want to be able to tune the band height. If the bands are large, more memory is used. If they are small, more rendering may be required by the X server. On the other hand, it may be possible to get nice antialiased bitmap output by using libart. This would also remove the dependence on an X server while doing the conversion, which may be a plus. Of couse, there is also the SVG export filter in dia, so when the web browsers catch up, you will be able to insert scalable dia drawings in your web page, which would be a fraction of the size. AFAIK, recent versions of IE support the (rejected) VML standard, but there is no export filter for it (and I am not going to write one -- look at the specification document on www.w3.org to see why). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Wed, 27 Oct 1999, Jeff Taylor wrote: > I need to get a UML diagram from Dia to GIF or PNG format to put on my > Web page. Anyone have some suggestions? > > TIA, > Jeffrey > >
Re: Line style
On Fri, 29 Oct 1999, Cyrille Chepelov (home) wrote:
> okay, so, where should I add this ? Should I modify the line objects
> themselves ? But then, I have to modify every single object which uses
> lines and where wobbly lines might make sense ?
What do you need to draw with wavy lines? If it is just a connection
line, you should probably just create a new line object. This is probably
a better idea than adding that feature to the existing objects in this
case.
> ones, I fear. Currently, I have automake 1.4, autoconf 2.13, libtool 1.3.3
> correct ?
Those look like the correct versions to use. Do you also have
gettext-0.10.35? How are you building dia from cvs? You should just
need:
./autogen.sh --prefix=/whatever
make
make install
> Hmmm... X doesn't, but SVG and EPS do, right ?
> If X doesn't, it might be possible to emulate that behaviour, by drawing
> into a private {bit|pix|whatever}map, rotating it, and then blitting it on
> the canvas ; well, this won't be precisely fast, but at least functional.
>
Drawing rotated text is never going to be efficient with the current X
APIs. There is talk of extended APIs in XFree86 4.0 which handle anti
aliased text, and they may also support this. I think it would be better
to wait for this. Currently, to rotate text, you need to create a
GdkPixmap big enough to hold the string, draw the text to the pixmap,
create a GdkImage of the pixmap so you can access the pixel values, rotate
the bitmap and finally draw the rotated pixel data to the screen (maybe
using gdkrgb). This is not very efficient.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
Re: Line style
I wasn't aware that you could do this with X fonts directly. I guess I will have to look it up in the X documentation. One other option I didn't mention is the display postscript extension, but it is still quite rare -- especially on free unix's. This seems to have held up projects like gnustep and gyve, since display ghostscript has been taking a while to complete. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Fri, 29 Oct 1999, Alexander Larsson wrote: > It might actually be possible to get rotated fonts if you specify a > transformation matrix in the XLFD font name. This doesn't work on all > Xservers though, and you still have to handle placement of chars manually. > > I don't see this in Dia anytime soon. Sorry. > > / Alex > >
Re: Line style
On Fri, 29 Oct 1999, Cyrille Chepelov (home) wrote: > On Fri, 29 Oct 1999, James Henstridge wrote: > > > What do you need to draw with wavy lines? If it is just a connection > > I need to, period. I use a model I haven't defined, so I'm not right to > modify the graphic language. This modeling uses wavy line, I have to draw > wavy lines. > I was more talking of wavy lines as a graphics primitive and wondering which objects you needed the primitive for. > > line, you should probably just create a new line object. This is probably > > a better idea than adding that feature to the existing objects in this > > case. > > this basically requires me to fork the current line object :-( > Probably better to add a property to the line object (Alex's explanations > and more code digging made obviously clear why doing that at the renderer > level is not a good idea ; besides, I don't really want to code the > drawing of a filled rectangle with wavy borders) > There are already a number of different line objects -- take a look at the UML sheet for examples. If you need a wavy connecting line for a particular type of diagram, it probably makes sense to create a new line object. > > > Drawing rotated text is never going to be efficient with the current X > > APIs. There is talk of extended APIs in XFree86 4.0 which handle anti > > aliased text, and they may also support this. I think it would be better > > to wait for this. Currently, to rotate text, you need to create a > > GdkPixmap big enough to hold the string, draw the text to the pixmap, > > create a GdkImage of the pixmap so you can access the pixel values, rotate > > the bitmap and finally draw the rotated pixel data to the screen (maybe > > using gdkrgb). This is not very efficient. > > Who really cares ? I want nice EPS graphics ; if people find that feature > too slow for their machines, they simply don't need to use it. Well if you can convince Alex of this, I guess it will go in. But it is still very difficult to get arbitrarily rotated text with the current X api's (the work around code would be very ugly), so I don't know how likely it is that it will go in. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: [dia] Special network objects
The flowchart sheet has a mixture of objects defined in XML and C, so this is possible. I haven't written code to do full affine transformations needed for lines. Also, with lines, you usually want non linear stretching (the lightning example you gave may be an exception) -- that is, you may want the ends to stay the same and the middle of the line to stretch, or you may want the middle to repeat. Both of these things are quite difficult to do correctly and with a simple interface. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Fri, 29 Oct 1999, Dan Cohn wrote: > 2) If (1) cannot be accomplished with the current custom code for the > moment, i'm fairly certain it can be done the old way (ala ethernet bus in > the network panel), but is there a way to mix the old method with the > custom method of defining shapes within the same subpanel? I'm not clear > on how this would be done. I want to start adding networking icons that > are actually practical for designing routed and switched enterprise > networks, but would of course prefer to do these as custom shapes from now > on.. > > Thanks for helping me understand this... > > dc > > -- > > Daniel Cohn, InterNAP >
Re: Line style
There is one other way to do rotated text, which may be the best way. This involves directly reading Type1 font files and doing the text rendering ourselves. This seems to be the approach taken by Raph Levien in his Gill SVG renderer and the print preview code in the gnome-print library. As for what is at the url http://www.daa.com.au/~james/dia-sheet-ns, there is nothing, and never has been. In the XML namespace spec, it just says you need some unique identifier for an XML name space, and it recommends using a URI as the ID as domain names are unique. I don't have a DTD for either the shape or sheet files, but the .shape and .sheet files distributed with dia and the objects/custom/README file should be enough to work out what is and isn't possible with the current custom shape code. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Sat, 30 Oct 1999, Cyrille Chepelov (home) wrote: > [rotating X fonts] > > Well if you can convince Alex of this, I guess it will go in. But it is > > still very difficult to get arbitrarily rotated text with the current X > > api's (the work around code would be very ugly), so I don't know how > > likely it is that it will go in. > > Mmmmh, I'm afraid I don't have the time (and GDK wizardry knoweldge) to > code this for the moment. I'll come back on this when I have something > worth looking at (such as benchmarks). > > --Cyrille > > PS: where's now the stuff which used to be at > http://www.daa.com.au/~james/dia-sheet-ns ? > > -- > Oh, my god ! I'm trapped into a V90 modem ! PGP ID: A879BEF8 > >
Re: [patch] rounding the corners on zig-zag lines
Note that using special shapes that are specific to a particular diagram type has its uses. At some point in the future, I would like to see a generic scripting interface to dia which would allow walking over the diagram and looking at all the objects and connections. By using the appropriate object types, a program can make much more sense out of the diagram. One possible use would be to actually add code generation features for the UML diagram objects. By using the standard line types and just changing line styles and arrows, such a program may not be able to reliably generate code. I do agree that there is quite a bit of code duplication in dia, which makes it difficult to fix bugs (one bug in some of my objects was replicated in about 4 places :( This is one of the reasons I wrote the custom shape code -- do all the C code once and get it correct. Then write small XML files to describe individual shapes. Maybe doing something similar for lines would be useful (not necessarily using XML to describe things). Maybe having some generic line objects, and being able to override just the methods you need to (ie. maybe leave some members blank, and call some function to fill in the blanks in the ObjectOps/ObjectTypeOps structures. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Sat, 30 Oct 1999, Cyrille Chepelov (home) wrote: > Of course, dia is great at building UML diagrams. Now, not everyone does > UML modeling, and dia doesn't claim to be an UML modeling tool (for which > it would dearly lack a code generator) but a generic, top-notch diagram > editor (which, in the specific case of UML, it is).
Re: [demo patch] 'borrowing' the implementation of an object...
I had mentioned something about simplifying the property dialogs for shapes a while back. Most shapes have a number of properties of a limited number of types. If we knew the types and names of the properties of an object, we coult create the properties dialog for it. Now to simplify things further, when the apply button is pressed, all the object needs to know is the new values of its properties. This could be implemented by getting each object to implement the following methods: list_props -- list the names and types of all the properties of this type of object. This would fit in the ObjectTypeOps structure, as it is not tied to a particular instance of the object. get_props -- get the current values of a number of named properties. set_props -- set the current values of a number of named properties. This would be enough to build the properties dialog, and would be a lot simpler to implement. It could probably also be used to implement the defaults dialog. Of course, the old methods should remain and take precedence over these new methods (I don't think we will be able to automatically generate the UML class object's property sheet). This also has the benefit of being able to select a number of shapes and getting a dialog of the intersection of their properties. This could also be used with grouped objects. Another use would be for programatically manipulating a diagram (ie. scripting). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Sat, 30 Oct 1999, Cyrille Chepelov (home) wrote: > The next steps would be to add a property manager 'layer', in order to > make persistency and most of dialogbox work automatic, and a way to > encapsulate the binary-defined objects into XML-defined ones (including > various fun stuff on properties) (see my previous message) > > Comments ? > > -- Cyrille > > -- > Oh, my god ! I'm trapped into a V90 modem ! GPG ID: A879BEF8 > >
Re: Problems Re-Loading .dia files
There is a few bugs in some of the shapes (mainly the circuit and flowchart sheets). If you have access to CVS, try grabbing the latest version, as it fixes the problem. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Sat, 30 Oct 1999, John D. Funk wrote: > Developers, > > Release .8 is fantastic. It has all the stuff in it that I wanted!! My > only problem with it is that I have to create the > diagram in a single session and export to .eps to use it. I can not > read the files created with .80. I can read old ones > created with .41 though. Something is messed up on the save process. > > I would be of more help in the future if I was good at programming. I'm > learning. Would like to contribute eventually! > > All the best! > John Funk >
Re: DIA
AFAIK, the visio file format is still secret and aparently obfuscated. There are some people who have put a bounty on producing a visio file conversion utility, but nothing has been produced yet. At the moment, I think the most likely way that we will get an import filter is with Microsoft's help. Since they recently bought visio and are in `lets use XML for everything' mode, they may release a version of visio that can save in an XML format that does not loose information. This would probably be a lot easier to convert. This does not really help much at the moment though. You can probably shorten your EPS -> TIFF conversion process a bit though. Try the following command: pstopnm epsfile.eps | pnmtotiff > tifffile.tiff James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Sun, 31 Oct 1999, Ollivier Civiol wrote: > Hi, > > I was a Windows user and just move to linux. > I use StarOffice to replace the shitty Office suite that MS sales but I > was using VISIO for my schemas, I got DIA, I like it a lot but it lacks > the ability to load and eventu&allt save in VISO file format. > > Do you know of a tool that would convert my visio files in DIA files ? > How can I use DIA in StarOffice ? So far I have to save to EPS, convert > to TIFF with GIMP and load in StarOffice, little heavy don't you think ? > > Any help will be appreciated. > > -- > Sincèrement, > >- > Ollivier Civiol > B.N.P. DOSI/MP > Email: [EMAIL PROTECTED] > Tel: 01.4014.8043 > > >
Re: Some impractical wishlist items.
Some of the stuff I have been doing with the print code in dia is to get nice multi page printing working correctly. Dia 0.81 stores page setup information with the file which is the first step. The next thing is to show where the actual page breaks are in the diagram display. This way, objects can be placed so they print nicely on multiple pages. This may help you. If dia is enough for your presentation work, then that is great. However, there are also a number of presentation app projects. One other project that may be of interest to you some time in the future is Achtung, which aims at producing a presentation program like power point. I don't think it is in a usable state at the moment though. It is in the GNOME CVS tree at the moment. With bonobo support, it would be possible to use both dia and achtung together. Another project I have heard about is magicpoint, but I have not tried it. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 2 Nov 1999 [EMAIL PROTECTED] wrote: > Dia is great. It is the first vector oriented drawing tool that I have ever > liked. As well as its intended diagram generation it could be used to > prepare presentations, in much the same way as PowerPoint. To do this, > I think only a few changes are needed; I have no idea if they are practical > or not. > > 1) Multiple page documents; perhaps just a wrapper that surrounds file names > with individual dia XML files, or maybe you would be better off with new tags > to wrap pages. > > 2) Most of the effects I ever use are already supported; about the only > thing I can think of is some kind of gradient fill object. This would do most of > the common things like background colour washes. > > 3) If you have some sort of multipage document, then minor printing revisions > (Print Current Page etc.) would be needed. > > 4) More ambitious, a thumbnail view / navigator. > > 5) Slide-show mode. > > Just my 2c worth. > > Julian Satchell > <[EMAIL PROTECTED]> >
Re: New user - modelling Q's
There is a dtd in the diagram.dtd file in the dia CVS module (which I just noticed is not included in the tarballs). It would probably be possible to extract the required info from the XML files, but I think that a scripting interface to dia (maybe using CORBA) would be more useful, as it allows dia to parse the file, and following connections between objects would be easier. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 2 Nov 1999, Doug Kelly wrote: > > > Hi > I finally picked up dia .81 yesterday, and am suitibly impressed. You guys > should have better PR - I thought it was basically a sketch program. How wrong > I was. > I checked the archives, and it looks like the bulk of the discussion is > drawing/graphically oriented. My interest is more in Object Modelling, and > there doesn't seem to be much discussion on that, so I thought I'd try to bring > myself up to speed. > Obviously, at some stage the ability to generate code/SQL etc out of the > models is desired. Is the basic philosophy that this will be done as a part of > the core program, or is the idea that this will be done by utilities that parse > the XML output of the main engine? My guess is that you could get more mileage > out of the latter, as it is much more flexible. > Given that, there are a couple quesitons: > -is there a DTD available or in progress? > -is the XML handling sufficiently modular that the program itself can serve as > the basis of an XML handling lib (I'll investigate this, but bootstrapping help > is welcome) > - if not, is there an XML parser that people are using? This looks like a > great opportunity to finally get to know the IBM XML/Java stuff. > > > thanks for a great program > > Doug Kelly > [EMAIL PROTECTED] >
Re: svg import
I don't know if it will ever be possible to do proper SVG import in dia. The SVG spec is quite expressive, so it would be difficult to get an import filter that would work on all SVG files. Also, most dia diagrams are at a slightly higher level. The SVG export filter looses a lot of information in the conversion (that is, semantic information -- not rendering info). There are a few other apps being developed that aim at being SVG editors (it sounds like you are looking for a program more like corel draw). There is gill (currently only available from the GNOME CVS tree), and one called sodi podi (I think that is the name). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Wed, 3 Nov 1999, Uwe Assmann wrote: > Hello, > > I just discovered dia, and it is great. I'm looking urgently for a tool to > edit about 100 figures in a document. Requirements: > > - UML diagrams > - XML based (so that I can manipulate the figs with sed) :-) > - nice editing features. > > Dia has everything, except svg import. When is it planned? If this would > come soon, I'd like to switch to dia.. > > Regards > > Uwe > > > -- > Dr. Uwe Assmann Universität Karlsruhe, Institut für Programmstrukturen, > Am Zirkel 2, Postfach 6980, Prof. Goos, Rechenzentrum, 76128 Karlsruhe, > Germany > tel:+49/721/608-6088 http://i44www.info.uni-karlsruhe.de/~assmann > fax:+49/721/30047mailto:[EMAIL PROTECTED] >
Re: svg import
On Thu, 4 Nov 1999, Uwe Assmann wrote: > Thanks for your information. I discovered that I had to switch off option > 'compressed saving'; then XML appears in a dia DTD. Wonderful! Using gziped XML gives the best of both worlds -- small file size and human readable/editable format. > > Now I need just two other things: > > - how to shadow a diagram (a rectangle)? StarOffice has a 'shadow button' > which does this nicely. And this looks immediately as if it was 3-d. Currently this is not implemented in dia. I have an idea of how to do this though. It would require writing a new filtering renderer. It would basically set the colour to black (or grey) for all drawing operations, and offset coordinates by some value. This way we could use each object's current drawing routine to draw the shadow by using the shadow renderer. This is not implemented at the moment. > > - how to define own libraries? I'm developing a new box model, so I need > boxes and special lines. > For shapes, you can choose either to use the custom shape XML format (which uses SVG internally) to draw the shapes, provided that they only need to be stretched affinely when scaling them and don't have any weird properties like the Networks sheet's ethernet bus or UML sheet's class objects. The docs for the custom shape XML format is in objects/custom/README. If you need any special behaviour, you will need to code the new shapes in C. Lines also have to be done in C at present. There is no documentation on the C interface at the moment, so you would need to look at some of the other object libraries for ideas. Your best bet is to copy the C code of an object that is similar to what you need and modify it to do what you want. > > /Uwe > James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: Circuit objects are fat
Have you tried resizing them? I suppose I should fix the aspect ratio on a few more of the shapes. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Thu, 4 Nov 1999, [ISO-8859-1] Gustavo João Alves Marques Carneiro wrote: > Hi. I've been trying to use Dia to produce electric circuits and > verified that all of it's objects are square. I mean that they all have a > square bounding box and that makes them very 'fat'. Resistors look very > ugly this way. Is it a bug or a feature? I hope it's a bug! :) > > -- > Gustavo J.A.M. Carneiro > World::Portugal::FEUP::DEEC::LEEC::TEC > [reinolinux.fe.up.pt/~ee96090] > >
Re: Binary-only libraries, and interface structs.
I don't know if it is worth getting rid of the SheetObject structures all together. Maybe just have it so that instead of registering a SheetObject with a particular sheet, you just register it. Some other code could construct the actual sheets from XML files. The current code in objects/custom could be extended to take something like: Standard - Box As well as the tags. This way binary objects retain the use of the user_data argument. We may want to use some other tag to identify a sheet object rather than the object name. In objects/UML/class.c, the two sheet objects for class and template class have the same object name, but we want to distinguish them. I would be interested to see what you come up with. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Fri, 5 Nov 1999, Cyrille Chepelov (home) wrote: > Now, since I'll get rid of compile-time SheetObject, to have it described > in XML, I'll have to loose the flexibility of giving a "void *" user_data. > Would two arguments (int_user_data and string_user_data) do the trick ? > > -- Cyrille > > -- > Grumpf. > > >
Re: Binary-only libraries, and interface structs.
Do you want to reference custom shapes by object name or file name? If
you do it by object name, how we know which shapes to load up? Other than
that, your format looks good. Note that the custom shape code uses the
user_data field to pass the ShapeInfo structure to the custom_create()
function, and it will not work very well with just an integer.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
On Fri, 5 Nov 1999, Cyrille Chepelov (home) wrote:
> On Fri, 5 Nov 1999, James Henstridge wrote:
>
> > I don't know if it is worth getting rid of the SheetObject structures all
> > together. Maybe just have it so that instead of registering a SheetObject
> > with a particular sheet, you just register it. Some other code could
> > construct the actual sheets from XML files. The current code in
> > objects/custom could be extended to take something like:
> > Standard - Box
>
> Hmmm. Up to now, we had two structures (three for shapes) :
> ObjectType and SheetObject. The former describes the object type ; the
> second describes some decoration and that user_data field only two object
> use, in integer form.
> Now, we would have to have three structures (four) : ObjectType,
> SheetObject, and the (or , whatever) node.
> Hmmm. What I've begun coding is to have a ${pkgdatadir}/sheets (with
> perhaps a way to specify the order of sheets in diarc), and sheet files a
> bit more featureful :
>
>
>
> http://www.crans.ens-cachan.fr/~chepelov/dia-sheet-ns">
> Test
> Une feuille de test
> A test sheet
>
>
> a template uml class
> foo.xpm
>
>
> Antenna
>
>
>
>
>
> The object and shape objects are to be identically processed, save the
> optional intdata and chardata properties (for objects).
> Each object or shape node is converted into a SheetObj structure and
> registered in the relevant sheet.
> The description and icon elements override whatever could have previously
> be given (in ObjectType or in ShapeInfo).
>
> index.sheet files are deprecated ; All shapes available are loaded, their
> ObjectType registered ; I'll just need a routine to retrieve information
> from the name_to_info hash (not really an issue, is it ?).
>
> I have something working right now, but limited to binary objects. I think
> I'll have shapes as well later this evening.
>
> --Cyrille
>
> --
> Grumpf.
>
>
Re: Feature Request UXF support
This sort of thing would probably be best handled by a generic scripting interface for dia (which has not been written yet). There is no reason not to support something like this in the future, but at present it may be a bit difficult to implement. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Fri, 5 Nov 1999, Scott Robertson wrote: > > I think a great feature for DIA would be to support the XML standard UML > Exchange Format UXF. > > http://www.yy.cs.keio.ac.jp/~suzuki/project/uxf/ > > I really love the way diagraming works in dia but for various > reasons/policies I'm forced to use ObjectDomain, which has great > documentation generating features by the way. I think it would be great if > dia could generate UXF which I could then use to import into ObjectDomain. > > Just a thought if someone has any spare time on their hands. =) > > --- > - Scott Robertson Phone: 714.972.2299 - > - CodeIt ComputingFax: 714.972.2399 - > -http://codeit.com- > --- >
Re: Binary-only libraries, and interface structs.
If you are planning on loading all the custom shapes you find before constructing the sheets, is there any point to specifying them differently inside the new sheet files? Also, do we want to allow objects to provide their own pixmap icon, or shoud that be up to the sheet code. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Sat, 6 Nov 1999, Cyrille Chepelov (home) wrote: > On Sat, 6 Nov 1999, James Henstridge wrote: > > > Do you want to reference custom shapes by object name or file name? If > > you do it by object name, how we know which shapes to load up? Other than > > Simple : I (want to) load just every .shape file I can find in the > relevant subtrees. Afterwards, I forget the file names, and use only > ObjectType names. [Currently, I let the older code find the index.sheet > files and load the shapes, if I have time before this afternoon, I'll > change that, write the remaining .sheet files and eliminate the old sheet > registration mechanism] > > > that, your format looks good. Note that the custom shape code uses the > > user_data field to pass the ShapeInfo structure to the custom_create() > > function, and it will not work very well with just an integer. > > yup, I found that while coding (ahem...). Since I originally didn't want > to expose user_data for shapes (there's no attribute intdata in ), > it wasn't a problem. > > -- Cyrille > > -- > Grumpf. > >
Re: Binary-only libraries, and interface structs.
The N_() macro does nothing in the compiled program, but the xgettext program will extract strings marked with it for translation. You need to use this rather than _() because structure initialisers need to be constant. All you need to remember is to use _(structname->field) to get the labels to display in the GUI, so that the strings eventually get translated. There is probably no point going through and fixing up references at object initialisation time. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Sat, 6 Nov 1999, Alexander Larsson wrote: > > Oh, I noticed that a lot of strings in newzzline.cpp are defined N_() > > though they seem to appear in the UI (see property_list and object menu). > > How's i18n to be handled ? > > Well, I'm no expert on i18n (hallon?), but i suppose they have to be > fixed up at some stage of reading objects.
Re: Custom Lines
Currently line arrows are not really saved in the dia files in an extensible way. They are stored as the integer value representing their position in the ArrowType enumeration. This does not really lend itself to having arbitrary arrow heads where not every head may be available on every computer. We will probably want to change it to save a string name of the arrow head instead. There was one person who said he was interested in adding this feature. Check the archives at http://www.mail-archive.com/dia-list@lysator.liu.se if you want to get in contact with him. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Sat, 6 Nov 1999, Sam Phillips wrote: > > Hi, > > First I like to say that dia is pretty awesome. Everyone at work is > starting to use it so they don't have to use NT/Visio. > > We use a line end symbol for some of our projects that dia doesn't > have built in. So using the power of open source I hacked a new arrow > shape into it. > > The problem is right now our documents aren't standard anymore. > > We'd like to have a line type similar to the UML lines, but we don't > want to write an object lib in C. We'd prefer to use custom XML/SVG > objects. > > Are there any plans for this kind of support in the custom module? Or > is it already there and I'm blind? > > Thanks > Sam > > === > Sam Phillips <[EMAIL PROTECTED]> http://www.usaworks.com/~sam > I do not fear computers. I fear the lack of them. > -- Isaac Asimov > >
Re: Binary-only libraries, and interface structs.
If the object creation routine got a pointer to the ObjectType structure corresponding to the object, and I could associate a piece of data with the ObjectType structure, I would not need to use the current user_data method (maybe this makes sense -- the ShapeInfo is associated with the object type rather than the sheet object). One other good thing about splitting off the sheet loading code is that we can move the custom shape code back to being a dynamically loaded library, rather than being statically linked (ther reason for statically linking it was so other object libraries could load up custom shapes for their sheets -- if sheet organisation is split off from the object libraries, this is no longer needed). If you interested in doing more work on dia, would you like to get a CVS account? (the rules of proposing changes before making them would still apply). If so, we could probably organise it. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Sun, 7 Nov 1999, Cyrille Chepelov (home) wrote: > On Sat, 6 Nov 1999, James Henstridge wrote: > > > If you are planning on loading all the custom shapes you find before > > constructing the sheets, is there any point to specifying them differently > > inside the new sheet files? Also, do we want to allow objects to provide > > their own pixmap icon, or shoud that be up to the sheet code. > > Sorry if I'm a bit lagging behind.. > > I thought there was a point, because binary objects can have a user_data > (which I had to restrict to int), while shapes can't (user_data is a > ShapeInfo *) ; Of course, this can be easily lifted. As for the pixmap, > currently the code uses the object's pixmap unless another icon is > selected. > > -- Cyrille > > PS: congrats for the Cup > -- > Grumpf. > >
Re: Polyline usage?
Try middle clicking on the line and choose add segment/add point (I can't remember which label is used off hand). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Wed, 10 Nov 1999, Scot E. Wilcoxon wrote: > I can't seem to get a polyline which is different than a normal line. > How do I add more points to the polyline? (Apparently one item which > needs mention in the man page...) >
Re: problem selecting flowchart diamonds
This bug has been fixed, and the fix is in dia-0.81, which you should probably get (it fixes a number of bugs that were found just after the 0.80 release). There is instructions for subscribing to this list on the dia web site (under the developers section). Just send a message to [EMAIL PROTECTED] with the word subscribe in the subject. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Thu, 11 Nov 1999, Todd Goldenbaum wrote: > Hi, > > There appears to be a bug in dia v.80, wherein all flowchart diamonds (the > kind that can have text inside) are selectable by clicking in a much larger > area than just within the bounds of the diamond's area. > > In other words, after you create a flowchart diamond, you can select that > diamond by clicking in many different areas of the diagram, far far outside > the boundaries of the diamond itself. This makes it very difficult to work > with the flowchart thereafter, as many objects cannot be selected unless > the diamond is dragged far out of the way, so its false-selection-boundary > is not overlapping other objects. > > I tested this on a new diagram, so I know it's not just a corrupt file I > have. I'm using dia v.80 On Redhat Linux 6.0 with xml_lib 1.4. > > btw I am not on the mailing list for dia, as i dont' see any signup > information for such a list (I'm a dia user, not a developer) so please > respond to me personally. > > Thanks! > Todd > >
move tool
I was wondering what people would think of changing the move tool to something like the `grabbing hand' type move you get in programs like adobe acrobat and the like. The current implementation seems a bit weird, and does not scroll at all if you can see the edge of the diagram you are scrolling towards. I was wondering if it would be worth coding up a replacement move tool, or adding the `grabbing hand' type move as a control+click action for the tool. What do other people think? James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: Lines going the way I need with dia
Try middle clicking on the line and choosing add segment and delete segment where appropriate to get the desired segments. This is one thing that ABC flowcharter in particular does a lot better than dia. If anyone is interested, it sort of assigns a `direction' that orthogonal lines should connect at, and adds extra segments (new versions also wind the line so it does not overlap other shapes, but this is even more difficult). AFAIK, it decides which direction lines should connect from by having a virtual connection point at the center of the shape, and using the position of a connection point relative to the virtual one. That is, if the connection point is above the virtual one, the last segment in the line should be vertical. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Fri, 12 Nov 1999, Mike Machado wrote: > I am having trouble making lines go the way I need. I see your > screenshots have them, but I cannot get the UI to do it! > > > I need a line like the following > > |> > | > | > |> > > > Now it seems with all the different line types (both in UML lines and > standard tool lines) they only want to do this > > > ^ > | > |_ >| >| >\/ > > I tired properties dialogs to find where I can rotate it, but no go. Any > help would be very appreciated. > > > -- > Mike Machado > [EMAIL PROTECTED] > InnerCite > Network Specialist >
Re: EPS Problem
The EPS file format allows for placing a `preview' of the image in TIFF or windows metafile format in the file. StarOffice may use this to display the EPS image, which would be why it is not showing up correctly (dia does not generate a preview). Have you checked what the output is like if you print the staroffice document? You may find that even though it does not display correctly when editing, it may display correctly when printing. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Sat, 13 Nov 1999, Siegfried Stepke wrote: > Hi, > > StarOffice won't read eps-Files exported from DIA (it just shows the > text-Remarks from the top of the file); ghostview has no problems at all... > > Using "convert" to get .gif, .jpg or .bmb results in bad quality :-( > > I'm using dia 0.81 > > thanks for any hints, > Siegfried > > - > netz.at - mehr als nur statische seiten[EMAIL PROTECTED] > Ziegelofengasse 21-23/5 Tel +43-1-544 86 79 > A-1050 Wien Fax DW 10 > - >
Re: dia 0.81
What is the contents of the /usr/lib/dia directory? This should contain a number of shared libraries, including libstandard_objects.so. Also, check that you are executing the copy of dia you think you are with "which dia". James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 16 Nov 1999, Keith Gray wrote: > Great product! > > Now I am on the mail list? > > I liked the 0.80 but it lacked Landscape and fit-to-page. Of course you > fixed that! > > I run RedHat 6.0 and installed the 0.80 from RPM file... > > I got the .gz for 0.81 and put it into /usr/local/src managed to... > > ./configure --prefix=/usr > make > > ...and it runs the local sh script... > > ./app/run_dia.sh > > > ...however when I did the... > > make install > > ...dia cannot resolve the "standard" library location. > Do I need another arguement to configure? > Do I need to move the LIB files? > > I would like to contribute to network .xbm files... > > > > > > Keith >
Re: Dia 0.81 configure
Do you have libxml-devel installed? If you are compiling dia, you will need a number of devel packages installed as well. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 16 Nov 1999, Arne Claassen wrote: > I've tried Dia 0.80 which was very cool but unusable since save files > would never load, just segfault. So i tried getting 0.81 which complains > that i don't have gnome-xml (which the install says its the same thing > as libxml). rpm -qa claims that i have libxml10-1.0.0-2 and > libxml-1.4.0-1. Do i need 0.99.3 or should later versions work as well? > > thanks, > > arne claassen >
scroll tool changes
I have added the grab style scrolling capability to the scroll tool in dia. Just press the shift key when using the scroll tool and it should change into a hand, and it should scroll as if you had grabbed a bit of the image and you were draggin it around. You only need to have been holding shift when pressing the mouse button -- you can release shift before the mouse button. The main problem is that the scrolling seems to be a bit jittery. I did not use ddisplay_scroll(), as I did not want it to stop scrolling at the edge of the diagram. This may be the cause of the problem. One other cosmetic problem is that when you press shift, the hand cursor does not appear until the mouse is moved or a button pressed. This could be fixed by passing some keyboard events to the current tool. It may be a good idea to make use of different cursors a bit more in later releases -- such as adding a plus sign to the cursor when you hold shift when using the normal select/modify tool. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
scroll tool
I figured out what the problem with the grab style scroll tool I added. It now works correctly. I don't think it should have any bugs in it now. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: messed up file
That is a weird file. When I load it and save it again without changing anything, I get differences between the two files. Here is an interesting part of the diff output: - + - + - + - + This particular object had some Inf's in it, which look like they were causing some problems in constructing the diagram. When saving the file again, I got some Inf's occuring in one other shape. My guess is that these weird values are causing the problems. Now it would be really great if someone can outline a procedure to create an evil file with Inf's or NaN's in them :) (for those who may be a bit lost by this, Inf is infinity which is what you get when you divide a floating point number by 0. NaN is what you get when you multiply Inf by 0 or maybe divide by Inf). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Wed, 17 Nov 1999, Bas van Gils wrote: > Hi, > > as I noted earlier; somtims ida messes up diagrams :( here's an > example-file... > > yours > > Bas > > -- > Bas van Gils ([EMAIL PROTECTED])http://stuwww.kub.nl/people/b.vangils > tel# +31-6-24614919 (also SMS) fax# +49-89-66617-61693 > System Administrator of StuWWW at http://stuwww.kub.nl/ > Student of Information Management and Technology at Tilburg University > > The author of this E-mail requests that you regard this as a private message. > Please do NOT distribute it! Thank you very much in advance... >
Re: Redhat RPM of Dia 0.80 for i386, compiled for RH6
You have two options: 1) use rpm -i instead of rpm -U (or choose install rather than upgrade in gnorpm). Upgrade means delete old version and install new version. You want to install the new version of the libxml package without removing the old one. 2) Also get the libxml10 package from RH6.1 and upgrade tp the new libxml, libxml-devel and libxml10 packages at the same time (ie. with one call to rpm -U). The second option is probably easier. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Thu, 18 Nov 1999, Daniel Tourde wrote: > Hejsan ! > > I have downloaded the RedHat RPM of Dia 0.80 for RH6. I have RedHat 6.0 > with libxml-1.0.0-2.i386.rpm and libxml-devel-1.0.0-2.i386.rpm installed > > /usr/lib/libxml.so.0 > /usr/lib/libxml.so.0.0.0 > /usr/lib/libxml.a > /usr/lib/libxml.la > /usr/lib/libxml.so > > dia-0.80-1.i386.rpm requires /usr/lib/libxml.so.1 which comes from > libxml-1.4.0-1.i386.rpm which is a part of RedHat 6.1 ! I tried to > update libxml-1.0.0-2.i386.rpm with libxml-1.4.0-1.i386.rpm but this > does not work cause it would break other dependencies. I don't want to > upgrade to RH6.1 (too many troubles for the moment with 6.1). > > So, I just wanted to mention that this rpm does not work as it is with > RH6 but with RH6.1... I will try to compile dia 0.81 on my machine. > > Thanks anyway for what you're doing. Best regards > > Daniel > > > -- > *** > Daniel TOURDE E-mail : [EMAIL PROTECTED] > The Aeronautical Research Institute of Sweden Tel : +46 8 55 54 93 44 > P.O. Box 11021 S-161 11 BROMMA, Sweden Fax : +46 825 34 81 > *** >
Re: bug in dia_image_release()
segfaults are caused much easier than that. The most common causes are referencing a bit of memory that has already been freed. Another cause is freeing a bit of memory which has already been freed (this is very bad, and can cause errors in weird locations). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 23 Nov 1999, Bas van Gils wrote: > Good morning ... > > This is w out of my league, but I want to give it a shot anyway. > Segv refers to a segmentationfault (at least, that's what I assume ;)...) > so we have a memory-problem. Aparantly there is an object in the memory > (with it's on segment) and one is trying to reference it. This is where it > goes wrong... Possible reason: corrupt virtual-page-table is corrupt. > > I know this doesnt actually *solve* the problem but it might give someone > an idea ... ? > > Bas > > -- > Bas van Gils ([EMAIL PROTECTED])http://stuwww.kub.nl/people/b.vangils > tel# +31-6-24614919 (also SMS) fax# +49-89-66617-61693 > System Administrator of StuWWW at http://stuwww.kub.nl/ > Student of Information Management and Technology at Tilburg University > > The author of this E-mail requests that you regard this as a private message. > Please do NOT distribute it! Thank you very much in advance... >
Re: http://www.lysator.liu.se/~alla/dia/menu.html
If the error message was about libxml.so.1, I recommend grabbing the libxml, libxml1 (or is it libxml10?) and libxml-devel (only if you currently have libxml-devel on your system) from your closest Red Hat 6.1 mirror. Install all these using a command something like "rpm -Uvh libxml*.rpm" and things should work. BTW, did you install the dia rpm with --force or --nodeps? I would not have thought it would let you install the RPM if you did not have the appropriate shared libraries on your system. The dependency errors are there for a reason. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Tue, 23 Nov 1999, Gustavo Adolfo Alday Fernandez wrote: > Hi, > I'm getting some problems trying to run your dia. I got your last > release and installed rpm under RedHat 6.0. I also installed > libxml, but when trying to install rpm it says I don't have any libxml. > So I installed dia forced and when trying to run it I receive a message > like this: 'error in loading shared libs: libxml.so.xxx' > Any help would be appreciated. > Regards. >
A python scripting interface
I was thinking of adding a python scripting interface to dia. From what I can see, it should be possible to make it into a shared library, just like the object libraries. One question though is where to put it in the dia source tree? Its interface with the rest of dia would be closest to that of the libraries in objects/*, but it won't add any extra objects for dia to use. Would it be more appropriate to create a new toplevel directory for things like this? It would also be necessary to add a few more APIs to dia/lib. Specifically a way to add extra menu items. At a minimum to the right click diagram menu, and maybe also the toolbox's menu as well. It would be nice if this allowed adding a pixmap to the menu item if gnome support has been enabled, but this is not necessary. For any of these support features, I don't want to make them python specific -- I am sure people might want perl, tcl or guile bindings as well. I aim to make the bindings capable of fully manipulating a diagram, and also accessing any properties of objects (this was one of the motives for wanting standard set/get property functions for objects :). The idea being that they be powerful enough to write filters to import/export UXF or XMI files to dia UML diagrams, or export a SPICE network from a circuit diagram. I also have a bit of code that would also give an interactive console (written using pygtk) to alow you to programatically modify the diagram. What do people think of this? James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: A python scripting interface
CORBA interfaces would be nice as well. They would probably also be useful for when/if a dia bonobo component is created. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Wed, 24 Nov 1999, Carsten Zerbst wrote: > James Henstridge wrote: > > > For any of these support features, I don't want to make them python > > specific -- I am sure people might want perl, tcl or guile bindings as > > well. > > I think scripting dia is a great idea, e.g to create UML diagrammes from > a implementation repository etc. I'd propose making a corba interface > for dia, then you could use any scripting language you ever like to > use. > > Bye, Carsten >
Re: A python scripting interface
Well as I said, any enhancements I make to make the python language bindings possible should not be python specific. The reason I want to do python bindings is because that is the scripting language I am most familiar with (both the language and the C API). I don't want to discourage others from writing other bindings. I suppose other bindings will be easier to write after the first one is done though. Gnumeric is a good example of this, as it has interfaces for python, perl, guile and maybe a few others I haven't mentioned. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Wed, 24 Nov 1999, Chris Winters wrote: > Although I'd lean toward perl as a language (personal biases :), I > think it would be a great idea. Being able to generate code/database > structures from diagrams would be fantastic! > > Thanks
