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: 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: 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: 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
Difference between shapes and internal shapes
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
On 26 Oct 1999, Daniel Wang wrote: > > "Peter C. Norton" <[EMAIL PROTECTED]> writes: > > > On Tue, Oct 26, 1999 at 04:17:33PM -0400, Daniel Wang wrote: > > > *sigh* I've played various games trying to isolate this... I guess you really > > > need purify to make sure you don't read from properly initialized memory... > > > > Try using ElectricFence. It's good at catching the basic nasties like this. > > Tried this already it wasn't useful... > Efence just catches buffer overruns from what I can > tell from the documentation. I ran it in efence and got the same crash you did. I found the bug. It's the same one that was in all the flowchart objects. Evidently there was some cut-n-paste od bugs going on here. / Alex
Re: XML for lines and arrows
To add-to the xml thread... I've just started using visio, and one neat feature it has for the diagramming of networked installations is constraints. If I use it to model a 19" relay rack, I can tell it that the lines representing "shelves" can only move along the vertical, and it should remain perpendicular to it. It seems this would be pretty useful for chemical bonds, circuts, network design, etc. Are these sorts of congruency and behavior rules planned to be among the xml info that dia will support? -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one.
Re: --enable-gnome
On 26 Oct 1999, Daniel Wang wrote: > > > > Alexander Larsson <[EMAIL PROTECTED]> writes: > > > > > > > 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? > > > > > > Just, did. I'm still getting the same behavior... I think this is a storage > > > allocation bug. > > Ugh? Do you get the same backtrace? That fix i did might not be the > > best, but it sure should stop that crash. > > > Yep still does... > I just got extra paranoid and did a make distclean and complete rebuild and > I'm still getting the core dump. I did the fix in a new way. Still a crash? Are you loading the same file as before (work.dia)? / Alex
Re: --enable-gnome
"Peter C. Norton" <[EMAIL PROTECTED]> writes: > On Tue, Oct 26, 1999 at 04:17:33PM -0400, Daniel Wang wrote: > > *sigh* I've played various games trying to isolate this... I guess you really > > need purify to make sure you don't read from properly initialized memory... > > Try using ElectricFence. It's good at catching the basic nasties like this. Tried this already it wasn't useful... Efence just catches buffer overruns from what I can tell from the documentation. Rather than just calling calloc, I hacked a version of malloc the consistently initalized the memory to some pattern. I was able to cause it to crash with certain patterns, but I didn't have the time to isolate what particular pattern it needed to break.
Re: --enable-gnome
On Tue, Oct 26, 1999 at 04:17:33PM -0400, Daniel Wang wrote: > *sigh* I've played various games trying to isolate this... I guess you really > need purify to make sure you don't read from properly initialized memory... Try using ElectricFence. It's good at catching the basic nasties like this. > Oh, well.. I seem to be able to work around this... for now... > Thanks... I hope you get lucky and find the bug... Solaris gcc-2.8 seems to be pretty liberal wrt what you can get away with with unitialized pointers. -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one.
Re: --enable-gnome
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. Ok. I've made another attempt. What do you think of this one? / Alex
Re: --enable-gnome
> > Alexander Larsson <[EMAIL PROTECTED]> writes: > > > > > 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? > > > > Just, did. I'm still getting the same behavior... I think this is a storage > > allocation bug. > Ugh? Do you get the same backtrace? That fix i did might not be the > best, but it sure should stop that crash. Yep still does... I just got extra paranoid and did a make distclean and complete rebuild and I'm still getting the core dump. > > After I redefine malloc to be a wrapper around > > calloc so that all memory is zeroed out. The bug goes away. Maybe there's a > > bug where you should be calling g_malloc0 rather than g_malloc or you're > > assuming some values are 0.0 by default when they aren't? > > Maybe. It'll be a bit hard to find for me though, as i don't get the > crash. Doesn't anyone have purify for Solaris? *sigh* I've played various games trying to isolate this... I guess you really need purify to make sure you don't read from properly initialized memory... Oh, well.. I seem to be able to work around this... for now... Thanks... I hope you get lucky and find the bug...
Re: Two more bugs.
On Tue, Oct 26, 1999 at 09:30:37PM +0200, Alexander Larsson wrote: > On Fri, 22 Oct 1999, Ola Lundqvist wrote: > > > I have found out why the layers disappear sometimes. The problem is that the > > layer-box aren't updated when switching focus and or open a new file. It is > > updated when closing the box. > > > > If a file is opend it assumes it only have one layer = backgound. > Ok. I fixed this. Nice > > > If a file is opend and another are already open it (layer) does not update. > And this i suppose. Nice > > > When switching focus it (layer) is not updated > > > > When closing it does update (always?)... Well always when I have tested. > > > > When a new diagram is created it does not update if there is already one > > open file. > > > > ** 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. Doesn't it? Ohh then there are an anoying thing in gimp. Juste tested... I use gimp 1.1.10 and it do switch which file is shown... > > 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 > Thats all for now... -- - // Ola Lundqvist \\ /[EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ |[EMAIL PROTECTED] 584 36 LINKÖPING | \http://h81.ryd.student.liu.se +46 (0)13-17 69 83 / \\ UIN/icq: 4912500 +46 (0)70-332 1551 // -
Re: Suggestions / wish-list
On Tue, 26 Oct 1999, Data wrote: > > Dear Dia-folk, > > I LOVE this program. Hence I have a few suggestions. > > I'm willing to help out developing it to a limited extent; if anyone's > willing to give me a few pointers as to where to start on any of these > items, I'll look into it. (Of course, you may not even _want_ these > 'features' .. :) ) > > It's possible that Dia can do what I want, but I just don't know how > to make it do it. Sorry if any of these sound stupid. > > 1. I think it would be awfully cool if polygons had what I'll call 'sticky >sides'. Right now, you can only attach connection points to other >connection points; what if you could attach an arrow-head to the side >of a rectangle, for example, and have that stick just as if it were >attached to a connection point? > Reason being is that I'm often finding myself doing drawings where >I want two (or more) line-ends stuck to the side of a box; but a box >only has one connection point on its side, and that's in the middle. > Another possibility would be movable or even addable connection points. >Pick up a connection point from the toolbox and drag it onto the side of >a rectangle, for example. Maybe not so easy to code though :) This is unforunately very hard. Both in the current Dia design and in general. What you really would need is some kind of generic constraint system. These are a fair bit more heavy-weight than Dia's current design though. The problem is that all objects doesn't scale lineary (or affine), they can have arbitrary complex behaviour, so how to move the connectionpoints when the object changes is not at all simple. Maybe one could add some kind of connection-lines. I dunno. > 2. On most Mac drawing programs, you can hold down the shift key to >constrain object movement to 90 or sometimes 45 degrees. I don't think >Dia does this, but it would be nice. A 'Manhattan' mode like on Xfig >(bless its heart) would also be quite nice .. > Actually, I only want this because I often find that the 90-degree >line can't do two-segment right-angle lines very well, especially if >I'm using arrowheads. I really am glad that you brought back the >old-style 90-degree line though (i.e. movable middle segment) - it >was one of my favourite things about the original Dia (i.e. <=0.3) As Lars said, this exists. Uses control instread of shift though. What does Manhattan mode do? One other thing in this line that could be added is holding down shift to scale objects (if possible) homogenous in x/y. > 3. This is not so much Dia's fault, but I'll mention it anyway: font support. >I've had trouble with this for some time. Really it's an X issue, and >I know how long-standing it is, and that it's a universal problem, and >that you guys are probably hard at work fixing the font menu so that it >has the fonts in your system on it instead of only the PS 35. I've heard >that Gnome-Print is supposed to solve this, but I've found documentation >on it to be rather scarce. Anybody have any tips? No. This is a really hard problem. It might be worth checking out libart, but i have a real problem depending on to many external libraries. > 4. This may be contrary to the Dia/Visio UI design, but I'm a Mac veteran, >and I do wish you could select ranges of text and so forth on text >objects. This could probably be done. Might be some work though. > 5. Currently the properties dialog seems to be associated with one object >only - to get the properties for a different object you have to double >click it, getting another properties dialog. Could this dialog be made >persistent, so that clicking on a different object caused that object's >properties to appear in the properties dialog? Ehh? Double-clicking on another object makes that objects properties appear in the old properties dialog? (In fact, there is only one properties-dialog). > 6. Can objects be rotated? I'd like to be able to turn objects by 90-degree >increments at least. No. This is currently a limitation in Dias renderer interface. Text can't be rendered rotated, nor can ellipses. This is really a problem originating from X too. It is possible to fix this, but just like the font issue it's a lot of work. > 7. Right now there are no defaults for the Text tool. I'd like to see it >have some defaults - these would be the same as the object properties. >There are perhaps other objects where this would be useful as well. Oops. Fixed in CVS (by lars). > 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? Yes, this should be possible. Would need some kind of callback to the selected objects. Anyone wanna do this? > Incidentally, I'm pleased to report that Dia 0.80 has performed beauti
Re: Two more bugs.
On Fri, 22 Oct 1999, Ola Lundqvist wrote: > I have found out why the layers disappear sometimes. The problem is that the > layer-box aren't updated when switching focus and or open a new file. It is > updated when closing the box. > > If a file is opend it assumes it only have one layer = backgound. Ok. I fixed this. > If a file is opend and another are already open it (layer) does not update. And this i suppose. > When switching focus it (layer) is not updated > > When closing it does update (always?)... Well always when I have tested. > > When a new diagram is created it does not update if there is already one > open file. > > ** 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: problem building dia 0.80 (fwd)
On Tue, 26 Oct 1999, Fredrik Hallenberg wrote:
> On Tue, Oct 26, 1999 at 03:50:15PM +0200, Alexander Larsson wrote:
> > Heres an i18n problem for the experts to think about.
> > How can we fix this? Why was en.po renamed to en_GB.po?
> >
> > / Alex
> >
> > -- Forwarded message --
> > Date: Tue, 26 Oct 1999 09:13:59 -0400
> > From: Philip Long <[EMAIL PROTECTED]>
> > To: Alexander Larsson <[EMAIL PROTECTED]>
> > Subject: Re: problem building dia 0.80
> >
> > The problem is that RH 6.1 sets the LINGUAS variable, in my case to en. This
> > messes up all sorts of building. When I unset LINGUAS, everything builds
> > fine. Thanks for dia.
> >
>
> The purpose of the LINGUAS env variable is to allow the user to select which
> translations to build and install. Of course, if a user selects a language
> in LINGUAS that is not available in the program that is going to be built
> this language should just be ignored. gettext.m4 tries to do this, but
> there is a bug that will (in this example) try to build "en" if it is in the
> LINGUAS if there is something the matches "*en*" in ALL_LINGUAS (like
> en_GB).
>
> I think this patch (which probably can be improved) will fix this:
>
> --- gettext.m4Tue Oct 26 17:46:16 1999
> +++ /usr/share/aclocal/gettext.m4 Fri Oct 22 13:02:06 1999
> @@ -229,8 +229,7 @@
> NEW_LINGUAS=
> for lang in ${LINGUAS=$ALL_LINGUAS}; do
> case "$ALL_LINGUAS" in
> - *\ $lang\ * | $lang\ * | *\ $lang )
> - NEW_LINGUAS="$NEW_LINGUAS $lang" ;;
> + *$lang*) NEW_LINGUAS="$NEW_LINGUAS $lang" ;;
> esac
> done
> LINGUAS=$NEW_LINGUAS
Ok. I've applied this to my /usr/share/aclocal/gettext.m4. The next time
i make a release this will then work better i hope. Maybe we should
contact the gettext maintainer about this?
Btw. You got the patch backwards.
/ Alex
Re: --enable-gnome
On 26 Oct 1999, Daniel Wang wrote: > > Alexander Larsson <[EMAIL PROTECTED]> writes: > > > 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? > > Just, did. I'm still getting the same behavior... I think this is a storage > allocation bug. Ugh? Do you get the same backtrace? That fix i did might not be the best, but it sure should stop that crash. > After I redefine malloc to be a wrapper around > calloc so that all memory is zeroed out. The bug goes away. Maybe there's a > bug where you should be calling g_malloc0 rather than g_malloc or you're > assuming some values are 0.0 by default when they aren't? Maybe. It'll be a bit hard to find for me though, as i don't get the crash. Doesn't anyone have purify for Solaris? / Alex
Re: run_dia.sh shell script now works again
On 26 Oct 1999, Lars Clausen wrote: > On Mon, 25 Oct 1999, [EMAIL PROTECTED] wrote: > > > 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. > > Er... when I use it (after make distclean && ./autogen.sh && make), I get a > gazillion alerts about duplicate objects (one for each object under > objects/). I suppose the internal shape reading and the normal object > reading collides. This is with a CVS update from today. Have you removed your old object/*/.libs/*.so.0.0.0 ? / Alex
Re: Suggestions / wish-list
On Tue, 26 Oct 1999, [EMAIL PROTECTED] wrote: > > Dear Dia-folk, > > I LOVE this program. Hence I have a few suggestions. > > I'm willing to help out developing it to a limited extent; if anyone's > willing to give me a few pointers as to where to start on any of these > items, I'll look into it. (Of course, you may not even _want_ these > 'features' .. :) ) > > It's possible that Dia can do what I want, but I just don't know how > to make it do it. Sorry if any of these sound stupid. > > 1. I think it would be awfully cool if polygons had what I'll call >'sticky sides'. Right now, you can only attach connection points to >other connection points; what if you could attach an arrow-head to the >side of a rectangle, for example, and have that stick just as if it >were attached to a connection point? Reason being is that I'm often >finding myself doing drawings where I want two (or more) line-ends >stuck to the side of a box; but a box only has one connection point on >its side, and that's in the middle. Another possibility would be >movable or even addable connection points. Pick up a connection point >from the toolbox and drag it onto the side of a rectangle, for >example. Maybe not so easy to code though :) It's one of my top things-to-code-when-I-ever-get-some-spare-time. Unfortunately, it doesn't seem to be that easy to implement. > 2. On most Mac drawing programs, you can hold down the shift key to >constrain object movement to 90 or sometimes 45 degrees. I don't >think Dia does this, but it would be nice. A 'Manhattan' mode like on >Xfig (bless its heart) would also be quite nice .. Actually, I only >want this because I often find that the 90-degree line can't do >two-segment right-angle lines very well, especially if I'm using >arrowheads. I really am glad that you brought back the old-style >90-degree line though (i.e. movable middle segment) - it was one of my >favourite things about the original Dia (i.e. <=0.3) The control key does that. Though not in an optimal way (try using it for dragging the size of a box). > 3. This is not so much Dia's fault, but I'll mention it anyway: font >support. I've had trouble with this for some time. Really it's an X >issue, and I know how long-standing it is, and that it's a universal >problem, and that you guys are probably hard at work fixing the font >menu so that it has the fonts in your system on it instead of only the >PS 35. I've heard that Gnome-Print is supposed to solve this, but >I've found documentation on it to be rather scarce. Anybody have any >tips? > > 4. This may be contrary to the Dia/Visio UI design, but I'm a Mac >veteran, and I do wish you could select ranges of text and so forth on >text objects. Would be nice indeed. So should movement be restricted to just grabbing the handles? That I think doesn't sit well with the way moving objects works... > 5. Currently the properties dialog seems to be associated with one object >only - to get the properties for a different object you have to double >click it, getting another properties dialog. Could this dialog be >made persistent, so that clicking on a different object caused that >object's properties to appear in the properties dialog? That shouldn't be difficult. > 6. Can objects be rotated? I'd like to be able to turn objects by >90-degree increments at least. Not yet, though I don't see anything in the way of doing this. > 7. Right now there are no defaults for the Text tool. I'd like to see it >have some defaults - these would be the same as the object properties. >There are perhaps other objects where this would be useful as well. Very easy to do, I believe. In fact, let me... there, diff sent. > 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 -- 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: run_dia.sh shell script now works again
On Mon, 25 Oct 1999, [EMAIL PROTECTED] wrote: > 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. Er... when I use it (after make distclean && ./autogen.sh && make), I get a gazillion alerts about duplicate objects (one for each object under objects/). I suppose the internal shape reading and the normal object reading collides. This is with a CVS update from today. -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: Suggestions / wish-list
On Tue, Oct 26, 1999 at 10:09:46AM -0700, Dan Cohn 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? > > I have been working on support for this for a while, and have it mostly > working on a pre-undo version.. i havent had a chance to check out the > code since its been clean ;), so i'll try to do that in the next few days > and submit the new diffs. This should be no problem if the property dialog follows youre mouse selections. Then you'll have that feature... // Ola -- - // Ola Lundqvist \\ /[EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ |[EMAIL PROTECTED] 584 36 LINKÖPING | \http://h81.ryd.student.liu.se +46 (0)13-17 69 83 / \\ UIN/icq: 4912500 +46 (0)70-332 1551 // -
Re: Suggestions / wish-list
On Tue, 26 Oct 1999, Data wrote: > I LOVE this program. Hence I have a few suggestions. woo. > 1. I think it would be awfully cool if polygons had what I'll call 'sticky >sides'. Right now, you can only attach connection points to other >connection points; what if you could attach an arrow-head to the side >of a rectangle, for example, and have that stick just as if it were >attached to a connection point? > Reason being is that I'm often finding myself doing drawings where >I want two (or more) line-ends stuck to the side of a box; but a box >only has one connection point on its side, and that's in the middle. > Another possibility would be movable or even addable connection points. >Pick up a connection point from the toolbox and drag it onto the side of >a rectangle, for example. Maybe not so easy to code though :) this is somethig that always frustrated me abt visio.. i support the idea, but have no idea how it will be added to the codebase.. i'll leave that for others to answer. > 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? I have been working on support for this for a while, and have it mostly working on a pre-undo version.. i havent had a chance to check out the code since its been clean ;), so i'll try to do that in the next few days and submit the new diffs. dc
Suggestions / wish-list
Dear Dia-folk, I LOVE this program. Hence I have a few suggestions. I'm willing to help out developing it to a limited extent; if anyone's willing to give me a few pointers as to where to start on any of these items, I'll look into it. (Of course, you may not even _want_ these 'features' .. :) ) It's possible that Dia can do what I want, but I just don't know how to make it do it. Sorry if any of these sound stupid. 1. I think it would be awfully cool if polygons had what I'll call 'sticky sides'. Right now, you can only attach connection points to other connection points; what if you could attach an arrow-head to the side of a rectangle, for example, and have that stick just as if it were attached to a connection point? Reason being is that I'm often finding myself doing drawings where I want two (or more) line-ends stuck to the side of a box; but a box only has one connection point on its side, and that's in the middle. Another possibility would be movable or even addable connection points. Pick up a connection point from the toolbox and drag it onto the side of a rectangle, for example. Maybe not so easy to code though :) 2. On most Mac drawing programs, you can hold down the shift key to constrain object movement to 90 or sometimes 45 degrees. I don't think Dia does this, but it would be nice. A 'Manhattan' mode like on Xfig (bless its heart) would also be quite nice .. Actually, I only want this because I often find that the 90-degree line can't do two-segment right-angle lines very well, especially if I'm using arrowheads. I really am glad that you brought back the old-style 90-degree line though (i.e. movable middle segment) - it was one of my favourite things about the original Dia (i.e. <=0.3) 3. This is not so much Dia's fault, but I'll mention it anyway: font support. I've had trouble with this for some time. Really it's an X issue, and I know how long-standing it is, and that it's a universal problem, and that you guys are probably hard at work fixing the font menu so that it has the fonts in your system on it instead of only the PS 35. I've heard that Gnome-Print is supposed to solve this, but I've found documentation on it to be rather scarce. Anybody have any tips? 4. This may be contrary to the Dia/Visio UI design, but I'm a Mac veteran, and I do wish you could select ranges of text and so forth on text objects. 5. Currently the properties dialog seems to be associated with one object only - to get the properties for a different object you have to double click it, getting another properties dialog. Could this dialog be made persistent, so that clicking on a different object caused that object's properties to appear in the properties dialog? 6. Can objects be rotated? I'd like to be able to turn objects by 90-degree increments at least. 7. Right now there are no defaults for the Text tool. I'd like to see it have some defaults - these would be the same as the object properties. There are perhaps other objects where this would be useful as well. 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? Incidentally, I'm pleased to report that Dia 0.80 has performed beautifully on my RH6 / October Gnome setup. The instability problems that 0.41 suffered from seem to be completely gone. Thanks for doing such a great job. I'd report some bugs, but I haven't run across any yet :) cheerio Michael Ashton
Re: problem building dia 0.80 (fwd)
On Tue, Oct 26, 1999 at 03:50:15PM +0200, Alexander Larsson wrote:
> Heres an i18n problem for the experts to think about.
> How can we fix this? Why was en.po renamed to en_GB.po?
>
> / Alex
>
> -- Forwarded message --
> Date: Tue, 26 Oct 1999 09:13:59 -0400
> From: Philip Long <[EMAIL PROTECTED]>
> To: Alexander Larsson <[EMAIL PROTECTED]>
> Subject: Re: problem building dia 0.80
>
> The problem is that RH 6.1 sets the LINGUAS variable, in my case to en. This
> messes up all sorts of building. When I unset LINGUAS, everything builds
> fine. Thanks for dia.
>
The purpose of the LINGUAS env variable is to allow the user to select which
translations to build and install. Of course, if a user selects a language
in LINGUAS that is not available in the program that is going to be built
this language should just be ignored. gettext.m4 tries to do this, but
there is a bug that will (in this example) try to build "en" if it is in the
LINGUAS if there is something the matches "*en*" in ALL_LINGUAS (like
en_GB).
I think this patch (which probably can be improved) will fix this:
--- gettext.m4 Tue Oct 26 17:46:16 1999
+++ /usr/share/aclocal/gettext.m4 Fri Oct 22 13:02:06 1999
@@ -229,8 +229,7 @@
NEW_LINGUAS=
for lang in ${LINGUAS=$ALL_LINGUAS}; do
case "$ALL_LINGUAS" in
- *\ $lang\ * | $lang\ * | *\ $lang )
- NEW_LINGUAS="$NEW_LINGUAS $lang" ;;
+ *$lang*) NEW_LINGUAS="$NEW_LINGUAS $lang" ;;
esac
done
LINGUAS=$NEW_LINGUAS
--
Fredrik Hallenberg [EMAIL PROTECTED]
http://www.lysator.liu.se/~hallon [EMAIL PROTECTED]
Re: --enable-gnome
Alexander Larsson <[EMAIL PROTECTED]> writes: > 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? Just, did. I'm still getting the same behavior... I think this is a storage allocation bug. After I redefine malloc to be a wrapper around calloc so that all memory is zeroed out. The bug goes away. Maybe there's a bug where you should be calling g_malloc0 rather than g_malloc or you're assuming some values are 0.0 by default when they aren't?
Re: problem building dia 0.80 (fwd)
Heres an i18n problem for the experts to think about. How can we fix this? Why was en.po renamed to en_GB.po? / Alex -- Forwarded message -- Date: Tue, 26 Oct 1999 09:13:59 -0400 From: Philip Long <[EMAIL PROTECTED]> To: Alexander Larsson <[EMAIL PROTECTED]> Subject: Re: problem building dia 0.80 The problem is that RH 6.1 sets the LINGUAS variable, in my case to en. This messes up all sorts of building. When I unset LINGUAS, everything builds fine. Thanks for dia. Phil Long Alexander Larsson wrote: > On Thu, 21 Oct 1999, Philip Long wrote: > > > ../configure > > make > > > > builds for a while unitl > > > > echo DIA_LIB_PATH=\$DIA_LIB_PATH:`pwd`/../objects/flowchart/.libs >> > > run_dia.sh > > echo DIA_SHAPE_PATH=`pwd`/../shapes >> run_dia.sh > > echo >> run_dia.sh > > echo "`pwd`/dia \$*" >> run_dia.sh > > chmod a+x run_dia.sh > > make[2]: Leaving directory `/home/plong/dia-0.80/app' > > Making all in samples > > make[2]: Entering directory `/home/plong/dia-0.80/samples' > > make[2]: Nothing to be done for `all'. > > make[2]: Leaving directory `/home/plong/dia-0.80/samples' > > Making all in po > > make[2]: Entering directory `/home/plong/dia-0.80/po' > > make[2]: *** No rule to make target `en.gmo', needed by `all-yes'. > > Stop. > > make[2]: Leaving directory `/home/plong/dia-0.80/po' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/plong/dia-0.80' > > make: *** [all-recursive-am] Error 2 > > lyta:~/dia-0.80 1010$ > > > > Please help > > I don't really understand this. I get no such problem. en.gmo shouldn't > be needed. It should use en_GB.gmo instead. This doesn't happend to me. If > you want to help you could try to figure out why it wants en.gmo. > > If you just want to run dia, just do "touch po/en.gmo" (or maybe "touch > po/en.po"?) > > / Alex
Re: --enable-gnome
On Tue, 26 Oct 1999, James Henstridge wrote: > 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. It would demand that you always do a subdivision that is good enought for all curvatures, even when it's not needed. This is probably slower than doing recursive subdivision which doesn't create many segments for curves with low curvature. Also, the code basically works. You just need to: a) Fix the previous problem in some other way than my patch. (Limiting subdivision comes to mind.) or b) Always subdivide at least once. / Alex
Re: --enable-gnome
On Tue, 26 Oct 1999, James Henstridge wrote: > 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. Dia doesn't look at the point spacing. Consider this bezier-curve: P1P2 * * u /|x \ / |\ ** P0 y v P3 P0-P3 are the bezier points. u = P1-P0 v = P3-P0 y = u projected on v x = u-y; Then the value of |x| decides if the curve is "smooth" enough to draw as a line. Then the same is checked on the other |x| (P3-P2 projected on P0-P3). / 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: --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
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
On Sun, 24 Oct 1999, James Henstridge wrote:
> On 22 Oct 1999, Daniel Wang wrote:
> > Alexander Larsson <[EMAIL PROTECTED]> writes:
> > > 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
> >
> > 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...
> >
> 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: A few bugs in 0.80
On Mon, 25 Oct 1999, Ronald L. Chichester wrote: > Dear Dia: > > Thank you for making such a wonderful program. I was using Visio and > was looking for a substitute on Linux. Your program fits the bill quite > nicely. > > I did notice a few apparent bugs in the 0.80 version of Dia, to wit: > > 1.The delete hot key Ctrl-D did not work, even when the object was > highlighted. Very strange, it works for me. What locale (language) do you use? > 2.The properties dialog box for classes lost its tab text after the > first opening. Specifically, when a class object was created and then > double clicked to show the properties dialog box, there were four tabs > and each tab had a label. However, if that dialog box is closed and > then reopened (by double-clicking the class in question), the tab labels > are missing. This is a know problem (although i can't reproduce it myself right now). It is probably some kind of reparenting bug in the tab widget in Gtk+. > I don't mean to complain. However, I thought you ought to know the > problems. Sure, cool. > Why didn't I just fix the bugs via the source code? Because I'm a much > better attorney than I am a programmer. I would be better suited to > writing the documentation than I would be fixing the source. No problems. Not everyone can fix stuff themself, but we can never fix bugs if we don't know about them. / Alex
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 > >
