Re: Groups and depths
On Fri, 11 May 2001, James Henstridge wrote: > On 10 May 2001, Lars Clausen wrote: > >> >> Here's a problem with groups I just noticed: Grouping objects destroys >> their depths. When you create a group, it becomes a new object on top >> of the other objects, and the depth of the objects is ignored. Try >> this: >> >> Create three partially overlapping rectangles. Select the two lowest. >> Group them. They jump to the front. >> >> The objects in the group retain their relative depth, which is good. >> But the group object should not really have a depth of its own, rather >> the individual objects should be at their original depths. (And the >> Group/Ungroup operations should be idempotent inverses.) That, however, >> is tricky to do with the current implicit ordering. >> >> Is this something we should work on? Have anyone been bothered by this? >> I only noticed now that I look at groups for XFig. > > I always considered groups as being a single object. It sounds a bit > weird for another object to be `in between' a group. Maybe creating a > group shouldn't cause the objects to raise to the top of the stack, but > grouped objects have always acted as one position in the depth stack in > all the drawing software I have used. It depends on what a group is. It makes sense to say a group is a bunch of objects you manipulate together, in which case grouping shouldn't change their depth. But I know how hard it would be to change that in Dia, and I got a reasonable fix for XFig import (it puts it at the highest depth involved), so I don't think we should worry. -Lars -- Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause) | Hårdgrim of Numenor "I do not agree with a word that you say, but I| Retainer of Sir Kegg will defend to the death your right to say it."| of Westfield --Evelyn Beatrice Hall paraphrasing Voltaire | Chaos Berserker of Khorne
Re: Define closed object with different types of line segments ...
On Fri, 11 May 2001, Richard Sharpe wrote: > Hi, > > I would like to be able to define an object made up of different types of > line segments (beziers, straight, curved, etc) ... > > Then it would be nice to have that object available as something I could > add anywhere, rescale it, etc. I don't want to have to write a progam for > it. > > I would also like to fill the object ... Use the Beziergon, and use the middle menu to make the midpoints Cusp controls. That will give you the straight lines. It won't quite give you curved lines, but you can get pretty close. There is no way to define a filled multi-line object the way you describe, as fill is implemented with filled boxes, ellipses, and beziers rather than a fill-in. -Lars -- Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause) | Hårdgrim of Numenor "I do not agree with a word that you say, but I| Retainer of Sir Kegg will defend to the death your right to say it."| of Westfield --Evelyn Beatrice Hall paraphrasing Voltaire | Chaos Berserker of Khorne
Re: Define closed object with different types of line segments ...
On Fri, 11 May 2001, Richard Sharpe wrote: > Hi, > > I would like to be able to define an object made up of different types of > line segments (beziers, straight, curved, etc) ... > > Then it would be nice to have that object available as something I could > add anywhere, rescale it, etc. I don't want to have to write a progam for it. > > I would also like to fill the object ... Have you looked at the documentation on writing custom shapes? It is in doc/custom-shapes in the dia tarball. It may do what you want, and requires no knowledge of C programming, and not much about dia's architecture. Take a look in the shapes/ directory for examples of objects using the code (maybe half the objects in dia use it). James.
Define closed object with different types of line segments ...
Hi, I would like to be able to define an object made up of different types of line segments (beziers, straight, curved, etc) ... Then it would be nice to have that object available as something I could add anywhere, rescale it, etc. I don't want to have to write a progam for it. I would also like to fill the object ... Any chances? Regards --- Richard Sharpe, [EMAIL PROTECTED] Samba (Team member, www.samba.org), Ethereal (Team member, www.ethereal.com) Contributing author, SAMS Teach Yourself Samba in 24 Hours Author, Special Edition, Using Samba
Re: dia-0.87.tar.gz available
James Henstridge wrote: Okay, now I feel stupid -- I changed the prefix name for all of the object types included in the plugin, and forgot to update the sheet file, so it was looking for non-existant object names. Doh! Lennon Day-Reynolds >On Thu, 10 May 2001, Lennon Day-Reynolds wrote: > >>Does anyone know of a reason why custom sheets wouldn't load with the >>0.87 release? I had a plugin working with 0.86, and the two-day-old CVS >>version, and now, I can't get my custom sheet to show up in the toolbar. >> >>I'm supposed to demo this plugin soon, and I'm starting to get nervous. >>Any suggestions? >> > >The XML namespace for the SVG portion of custom objects has been changed >to the W3C's final recommendation. Change occurences of >http://www.w3.org/TR/2000/03/WD-SVG-2303/DTD/svg-2303-stylable.dtd >with http://www.w3.org/2000/svg > >James. >
Re: Groups and depths
On 10 May 2001, Lars Clausen wrote: > > Here's a problem with groups I just noticed: Grouping objects destroys > their depths. When you create a group, it becomes a new object on top of > the other objects, and the depth of the objects is ignored. Try this: > > Create three partially overlapping rectangles. Select the two lowest. > Group them. They jump to the front. > > The objects in the group retain their relative depth, which is good. But > the group object should not really have a depth of its own, rather the > individual objects should be at their original depths. (And the > Group/Ungroup operations should be idempotent inverses.) That, however, is > tricky to do with the current implicit ordering. > > Is this something we should work on? Have anyone been bothered by this? I > only noticed now that I look at groups for XFig. I always considered groups as being a single object. It sounds a bit weird for another object to be `in between' a group. Maybe creating a group shouldn't cause the objects to raise to the top of the stack, but grouped objects have always acted as one position in the depth stack in all the drawing software I have used. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: dia-0.87.tar.gz available
I will keep an eye out for that if I start writing SVG-based custom objects; as I said, though, I'm having problems loading a custom *sheet*. The shapes included in it are all implemented in C. Lennon Day-Reynolds James Henstridge wrote: >On Thu, 10 May 2001, Lennon Day-Reynolds wrote: > >>Does anyone know of a reason why custom sheets wouldn't load with the >>0.87 release? I had a plugin working with 0.86, and the two-day-old CVS >>version, and now, I can't get my custom sheet to show up in the toolbar. >> >>I'm supposed to demo this plugin soon, and I'm starting to get nervous. >>Any suggestions? >> > >The XML namespace for the SVG portion of custom objects has been changed >to the W3C's final recommendation. Change occurences of >http://www.w3.org/TR/2000/03/WD-SVG-2303/DTD/svg-2303-stylable.dtd >with http://www.w3.org/2000/svg > >James. >
Re: dia-0.87.tar.gz available
On Thu, 10 May 2001, Lennon Day-Reynolds wrote: > Does anyone know of a reason why custom sheets wouldn't load with the > 0.87 release? I had a plugin working with 0.86, and the two-day-old CVS > version, and now, I can't get my custom sheet to show up in the toolbar. > > I'm supposed to demo this plugin soon, and I'm starting to get nervous. > Any suggestions? The XML namespace for the SVG portion of custom objects has been changed to the W3C's final recommendation. Change occurences of http://www.w3.org/TR/2000/03/WD-SVG-2303/DTD/svg-2303-stylable.dtd with http://www.w3.org/2000/svg James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Xfig import doesn't crash now (+intl)
The good news is that Xfig import no longer crashes on any of my samples. It should probably be marked as incomplete, though, as it doesn't do polylines and beziers and such. The bad news is that I noticedabout 70 instances of message_error(), message_warning() or message_notice() being called without the string being in _(). -Lars -- Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause) | Hårdgrim of Numenor "I do not agree with a word that you say, but I| Retainer of Sir Kegg will defend to the death your right to say it."| of Westfield --Evelyn Beatrice Hall paraphrasing Voltaire | Chaos Berserker of Khorne
Re: dia-0.87.tar.gz available
Does anyone know of a reason why custom sheets wouldn't load with the
0.87 release? I had a plugin working with 0.86, and the two-day-old CVS
version, and now, I can't get my custom sheet to show up in the toolbar.
I'm supposed to demo this plugin soon, and I'm starting to get nervous.
Any suggestions?
Lennon Day-Reynolds
James Henstridge wrote:
>After getting all the "make distcheck" bugs out of the way, I have put
>together the new dia tarball. It will be available at:
>
> ftp://ftp.gnome.org/pub/GNOME/stable/sources/dia/dia-0.87.tar.{gz,bz2}
>
>(once ftp.gnome.org syncs with master.gnome.org). I haven't announced
>this very widely yet, but if no one finds anything serious, I will put out
>announcements tomorrow.
>
>James.
>
Groups and depths
Here's a problem with groups I just noticed: Grouping objects destroys their depths. When you create a group, it becomes a new object on top of the other objects, and the depth of the objects is ignored. Try this: Create three partially overlapping rectangles. Select the two lowest. Group them. They jump to the front. The objects in the group retain their relative depth, which is good. But the group object should not really have a depth of its own, rather the individual objects should be at their original depths. (And the Group/Ungroup operations should be idempotent inverses.) That, however, is tricky to do with the current implicit ordering. Is this something we should work on? Have anyone been bothered by this? I only noticed now that I look at groups for XFig. -Lars -- Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause) | Hårdgrim of Numenor "I do not agree with a word that you say, but I| Retainer of Sir Kegg will defend to the death your right to say it."| of Westfield --Evelyn Beatrice Hall paraphrasing Voltaire | Chaos Berserker of Khorne
Re: where can I find m4 macro AM_PATH_PYTHON
I just remembered one of the things I had to "tweak" to get everything
running: I had to create a dummy 'dia.pot' file in the 'po'
subdirectory, or the compilation step failed with make complaining about
having no rule to create it.
I'm beginning to think that my workstation is braindamaged, and that RH
and Ximian are to blame...it's about time to go back to Potato...
Lennon Day-Reynolds wrote:
> Well, after some tweaking of it, I did get the tarball to compile and
> install correctly; I copied gtkcons.py to python-startup.py as a test
> replacement, and it works fine, as well. The only problem I'm having
> now is that I can't get the sheet for my custom plugin to appear in
> the drop-down list in the master tool window, which is very odd. The
> plugin worked under 0.86, and under the CVS version circa ~48-72 hours
> ago, but now, nothing.
>
> The diagnosis marches on, though; I should be able to let you know
> some more details once I've had more time to shake down the install.
>
> Lennon Day-Reynolds
>
> James Henstridge wrote:
>
>> On Wed, 9 May 2001, Lennon Day-Reynolds wrote:
>>
>>> I'm not sure where it *supposed* to come from, but I was able to get a
>>> copy of python.m4 (the Automake macro for Python configuration options)
>>> from the CVS version of Ammonite. I've attached it in case anyone else
>>> is having problems -- drop it in your aclocal directory ('aclocal
>>> --print-ac-dir' for the uncertain).
>>>
>>> I'm still having problems with the build on RH7, but am working through
>>> them; on SuSE 7, though, the newest CVS version absolutely refuses to
>>> compile -- something to do with their screwy placement of all the GNOME
>>> core libraries and apps, I think.
>>
>>
>>
>> I have no idea why you are seeing this problem. The macro is in
>> acinclude.m4, so should get coppied into aclocal.m4 and get used.
>>
>> The AM_PATH_PYTHON macro in CVS automake sucks, which is why I made the
>> modified AM_PATH_PYTHON_JH macro (the changes are being fed upstream),
>> which says it provides AM_PATH_PYTHON, so the other macros should use
>> it.
>> I don't know what is causing the problems for you.
>>
>> Does the tarball release work okay? (other than the missing
>> python-startup.py problem :(
>>
>> James.
>>
>
>
>
>
Re: where can I find m4 macro AM_PATH_PYTHON
Well, after some tweaking of it, I did get the tarball to compile and
install correctly; I copied gtkcons.py to python-startup.py as a test
replacement, and it works fine, as well. The only problem I'm having now
is that I can't get the sheet for my custom plugin to appear in the
drop-down list in the master tool window, which is very odd. The plugin
worked under 0.86, and under the CVS version circa ~48-72 hours ago, but
now, nothing.
The diagnosis marches on, though; I should be able to let you know some
more details once I've had more time to shake down the install.
Lennon Day-Reynolds
James Henstridge wrote:
> On Wed, 9 May 2001, Lennon Day-Reynolds wrote:
>
>> I'm not sure where it *supposed* to come from, but I was able to get a
>> copy of python.m4 (the Automake macro for Python configuration options)
>> from the CVS version of Ammonite. I've attached it in case anyone else
>> is having problems -- drop it in your aclocal directory ('aclocal
>> --print-ac-dir' for the uncertain).
>>
>> I'm still having problems with the build on RH7, but am working through
>> them; on SuSE 7, though, the newest CVS version absolutely refuses to
>> compile -- something to do with their screwy placement of all the GNOME
>> core libraries and apps, I think.
>
>
> I have no idea why you are seeing this problem. The macro is in
> acinclude.m4, so should get coppied into aclocal.m4 and get used.
>
> The AM_PATH_PYTHON macro in CVS automake sucks, which is why I made the
> modified AM_PATH_PYTHON_JH macro (the changes are being fed upstream),
> which says it provides AM_PATH_PYTHON, so the other macros should use it.
> I don't know what is causing the problems for you.
>
> Does the tarball release work okay? (other than the missing
> python-startup.py problem :(
>
> James.
>
DIA 0.87 fails to compile on a RedHat 7.0 machine
Hi! I downloaded dia-0.87.tar.gz and on a RedHat 7.0 machine I typed: rpm -ta dia-*.tar.gz After a while I get the following error message: for file in $dists; do \ /usr/bin/install -c -m 644 ./$file /var/tmp/dia-0.87-root/usr/share/gettext/intl/$file; \ done; \ else \ : ; \ fi make[2]: Leaving directory `/usr/src/redhat/BUILD/dia-0.87/intl' Making install in app make[2]: Entering directory `/usr/src/redhat/BUILD/dia-0.87/app' Makefile:789: warning: overriding commands for target `run_dia.sh' Makefile:559: warning: ignoring old commands for target `run_dia.sh' make[3]: Entering directory `/usr/src/redhat/BUILD/dia-0.87/app' Makefile:789: warning: overriding commands for target `run_dia.sh' Makefile:559: warning: ignoring old commands for target `run_dia.sh' /bin/sh ../mkinstalldirs /var/tmp/dia-0.87-root/usr/bin mkdir /var/tmp/dia-0.87-root/usr/bin /bin/sh ../libtool --mode=install -s dia /var/tmp/dia-0.87-root/usr/bin/dia libtool: unrecognized option `-s' Try `libtool --help' for more information. make[3]: *** [install-binPROGRAMS] Error 1 make[3]: Leaving directory `/usr/src/redhat/BUILD/dia-0.87/app' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/usr/src/redhat/BUILD/dia-0.87/app' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/dia-0.87' make: *** [install-strip] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.45534 (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.45534 (%install) I am ready to give more information about what is happening if required. Daniel -- *** Daniel TOURDE E-mail : [EMAIL PROTECTED] Tel : +46 8 55 50 43 44 FOI, Swedish Defence Research Agency; Aeronautics Division - FFA Dept. of Wind Energy and Aviation Environmental Research SE-172 90 Stockholm, SwedenFax : +46 8 25 34 81 ***
Dia ChangeLog report for Thu May 10 08:25:01 2001 (UTC)
*** Recent ChangeLog entries: 2001-05-09 Lars Clausen <[EMAIL PROTECTED]> * plug-ins/xfig/xfig-import.c: Improvements to error handling and group manipulation. 2001-05-09 Cyrille Chepelov <[EMAIL PROTECTED]> * lib/ps-utf8.[ch]: * lib/Makefile.am: fix makefile breakage which led to not including ps-utf8.[ch] in the released tarballs. 2001-05-09 James Henstridge <[EMAIL PROTECTED]> * Makefile.am (core-translation-report): dist scripts needed for this target, and change to $(srcdir) before running. * sheets/Makefile.am (EXTRA_DIST): actually dist the sheets. DATA files aren't automatically included in the tarball by automake because they could be generated files. * objects/EML/Makefile.am (EXTRA_DIST): fix directory names. * doc/en/Makefile.am (install-data-hook): fix up where graphics are installed. * configure.in: up version number to 0.87 * plug-ins/python/*.py: no longer necessary to explicitly set sys.argv, as python.c does it for us now (like it should). * plug-ins/python/gtkcons.py: fix up so it plays nicely as a dia python plugin. * plug-ins/python/python-startup.py: startup script that imports all modules in $(datadir)/dia/python and ~/.dia/python. * plug-ins/python/python.c (dia_plugin_init): change so that it only runs the $(datadir)/dia/python-startup.py script. Make sure that sys.argv and __main__.__file__ are set when calling the startup script. * plug-ins/python/Makefile.am: update makefile. Make it install gtkcons.py plugin. I haven't set any other plugins to install, as they look like they are mainly for debugging purposes. * configure.in: add tests to detect if python is available, so we can build the python plugin. Only run if --with-python passed to configure.
