GNOME Bugzilla – Bug 98594
lines/arrows should have gap attribute
Last modified: 2016-11-04 23:16:46 UTC
It would be nice to be able to have lines/arrows that don't reach their anchor or extend beyond their anchor by a 'gap'. This would help make bond-graph modelization possible. User has two attributes to specify. First, the user specifies the gap which defaults to 0. Second, the user specifies with a checkbox if (a) the given gap is to be measured between the arrow tip and the anchor point of the anchored object, or (b) the given gap is to be measured between the arrow tip and the intersection with the anchored object. This way, a gap of zero with (b) can be used for most situations where, for instance, a bunch of arrows or lines converge to a box/circle/etc., and a positive gap can be used for bond graphs. Somebody might need a negative gap so that a line/arrow would pierce the center of an object and go through. It seems important that a user be able to specify whether (a) or (b) be used because a user might wish to have lines/arrows which go through the sides of an object, almost reaching the center, but leaving a certain gap nevertheless. See dia-list Nov 2002 'Bond Graph modeling with Dia' thread for more details.
I have written some preliminary gap code that has been integrated into CVS. The code is more general than what is suggested above. Fractional and absolute gaps are not mutually exclusive, but can be combined. Lars is working on gaps that can be specified relative to object-intersection. I am currently cleaning up the gap code a bit, and the code is in a test phase.
IIRC there was something in cvs. Anyway marking as enhancement
There is indeed something in CVS, and I'm activating it (though without the bits about object edge finding). Want to have it for other kinds of line, too.
there is a lot of gap handling long time in cvs/svn. Probably this bug should have been closed the latest with: 2005-08-02 Lars Clausen <lars@raeder.dk> * objects/standard/arc.c: Patch from Grégoire Dooms <dooms@info.ucl.ac.be>: An almost perfect arc autogap implementation. "There is still a small bug when the non connected end of the arc is very close to the border of the connected object. I think this is due to rounding errors in the code for SHIFT-move handle which is reused to trim the arc in autogap. Also it is not yet possible to have a startgap and an endgap from/to the same central CP."
Thanks for the patch, but in the future bear in mind that all similar errors need to be fixed in the other drivers. The following fixes have been pushed: 76269de aes4000: Fix possible crash if USB init fails 8454a25 aes3500: Fix possible crash if USB init fails a0bbbd7 drivers: Print USB error when libusb_claim_interface() fails
Created attachment 339156 [details] [review] aes4000: Fix possible crash if USB init fails The code was indented, but only the first call was actually in the conditional, which meant that initialisation carried on as normal on top of a failed USB device. Exit early and remove the conditional to fix this.
Created attachment 339157 [details] [review] aes3500: Fix possible crash if USB init fails The code was indented, but only the first call was actually in the conditional, which meant that initialisation carried on as normal on top of a failed USB device. Exit early and remove the conditional to fix this.
Created attachment 339158 [details] [review] drivers: Print USB error when libusb_claim_interface() fails https://bugs.freedesktop.org/show_bug.cgi?id=98594
Sorry about that, git bz fixed https://bugs.freedesktop.org/show_bug.cgi?id=98594 in the GNOME bugzilla...