- Inkscape Devel - Inkscape Mailman

Connector avoidance fix for ellipses and translated objects
by Michael Wybrow 18 Sep '05

18 Sep '05

Hello, I have posted a fix for the previously discussed problems with connector avoidance for circles, ellipses and arcs as well as translated objects. I am curently in the UK with a very bad internet connection and very limited computer access so I can't easily read mail or get on Jabber to tell where we are in the release. For this reason I have put the patch in the tracker: https://sourceforge.net/tracker/index.php?func=detail&aid=1294687&group_id=… If the release hasn't already happened can someone please apply the patch before it does! Also, please check it compiles fine because while I fixed the problem on my laptop, I had to copy the changes by hand to get them anywhwere near the internet, and coulndn't connect to any of the machines at Monash where I would actually have been able to compile the change. I'll try to check replies to this message in the list in the next day or so. I'm back in Australia in a week so \i'll talk to you all then. Thanks, Michael

2 1

Is pressure sensitivity supported in X11 running under OS X?
by Jonathan Chetwynd 18 Sep '05

18 Sep '05

Is pressure sensitivity supported in X11 running under OS X? if it is, what configuration instructions are there? if not, what is the issue, and why hasn't it been fixed in the past three or four years? regards Jonathan Chetwynd please take care when replying not to copy across lists. Howtos for linux X11 regarding pressure sensitivity: http://linuxwacom.sourceforge.net/index.php/howto/inputdev http://ubuntuforums.org/archive/index.php/t-25151.html Wacom or other tablets use pressure sensitivity and applications such as GIMP and Inkscape use this facility, when available. Adobe Illustrator is a commercial application frequently used with wacom tablets and OS X. http://lists.apple.com/archives/X11-users OS X X11 mailing list archive

2 2

Inkscape stats 9/15/05
by Ben Fowler 18 Sep '05

18 Sep '05

I would respectfully disagree with both of the substantive points in this thread(!): On 9/16/05, Nicu Buculei <nicu@...398...> wrote: > Bryce Harrington wrote: > > > > [ snip ] > > > Where the project needs help right now is in closing bugs. > > We have our bug tracker quite well under control, but there > > are 258 open bugs, and it would be wonderful if we could cut > > that down significantly before the 0.43 release. If you can > > code, please check out if you can help close one or two, ... I am sitting on three patches, waiting for a thaw so that I can commit without endangering other's activities. There was never much of a thaw after 0.42! Ideally, the tree should be open just after a release for new work including patches for minor bugs, also for developers' prized features, as there will be a period for stabilisation before the next release. Just before a release, the emphasis should be on testing, packaging and to a lesser extent on 'blocking bugs'. Cutting down the number of open bugs by commiting is highly likely to expose other bugs or problems with the code that require stabilisation and should be done (IMHO) early in the release cycle. I suspect that I am missing something ... Personally, I would suggest that some manageable number bugs (somewhere between 10 an 50 given the number of developers) are marked as must fix before 0.43 and patches for other bugs (the 'minor bugs' I mentioned above) are held over. Ideally this should be based on the importance to the end-user rather than priority or ease of fixing. (High priority and easy to fix bugs should most certainly be fast tracked, but again, at the beginning or in the middle of a release cycle). > Other projects keep from time to time some events called "bug > party", when people clean the bug/feature tracker, collaborating > over IRC and closing as much as possible as DUPLICATE, WON'T > FIX, INVALID, RESOLVED or prioritizing. It may have the benefit > of attracting new contributors and giving non-developers a way > to contribute. > > What do you think about the opportunity/usefulness of such a > bug party? > > At 258 bugs and 448 RFEs the number may be small enough and > the action not needed. I wholeheartedly agree with these data and your suggestions, until the last line, where there is the implication that 250 open bugs is a small number. Really, we should be aiming at zero bugs, and should have 10 or fewer open ones. I would urge every effort to getting non-coders interested in triaging bugs and assigning priorities at all times. It is especially helpful to have end-users prioritising bugs, as bugs which do not impact the user community can be left to a future when there is more time. I also note that many of the open bugs refer to the Windows operating system, and unless those they are easily reproducible they may never get seen by a developer unless the user community can get behind them and insist that (some of) such bugs are indeed important. Finally, if we are going to have hundreds of open bugs, we should consider an even/odd policy, and do 'bug fixes only' for even numbered releases ... That may not desirable if we have a large number of RFEs and/or features which developers are interested in. Certainly in the proprietary world, there are products which have benefitted from a period of stability in which six months of the developers time was spent on stabilisation, performance and bug fixing rather than new features. Ideally we need to know whether the user community would vote for quality and bug fixes or new features ... Ben

10 22

Is pressure sensitivity supported in X11 running under OS X?
by Jonathan Chetwynd 17 Sep '05

17 Sep '05

Is pressure sensitivity supported in X11 running under OS X? if it is, what configuration instructions are there? if not, what is the issue, and why hasn't it been fixed in the past three or four years? regards Jonathan Chetwynd please take care when replying not to copy across lists. Howtos for linux X11 regarding pressure sensitivity: http://linuxwacom.sourceforge.net/index.php/howto/inputdev http://ubuntuforums.org/archive/index.php/t-25151.html Wacom or other tablets use pressure sensitivity and applications such as GIMP and Inkscape use this facility, when available. Adobe Illustrator is a commercial application frequently used with wacom tablets and OS X. http://lists.apple.com/archives/X11-users OS X X11 mailing list archive

1 0

Bounding Boxes
by Stephen Schrenk 17 Sep '05

17 Sep '05

Hi, I believe there is a problem with the way bounding boxes are calculated. At the moment the calculation assumes that lines have a >Round< join and cap style if the stroke is visible. This means, for example, that the bounding box of a 30-60-90 degree triangle does not preserve the proportions of the triangle and that a triangle with a Miter join style extends past the bounding box. It also means that a non-horizontal or vertical line with a Square cap extends outside the bounding box and that a line with a Butt cap doesn't reach the bounding box. I can't see any advantage to this particular definition. A better choice for defining the bounding box would be to use the entire visible area covered by an object. Advantage: More intuitive and probably what most people would expect. Disadvantage: More CPU intensive? May not be what is wanted for lines with markers - could ignore. There may be occasions where a different definition could be advantageous such as defining a bounding box assuming a Miter join style or using only the nodes (both preserve the proportions of regular objects). Perhaps these could be added as per object options. Tav

5 13

Re: [Inkscape-devel] Mac OS X developpement build
by Kees Cook 17 Sep '05

17 Sep '05

Hey, I just noticed your email didn't get sent to the list.... sorry I didn't respond; I didn't see it. :) We'll give you group access on sourceforge, and you can just upload it there (not through CVS or the file release section, but to the website area). If you've got CVS changes for packaging, put it in the patch tracker first, then we can move on to CVS. On Thu, Sep 15, 2005 at 05:41:41PM +0200, jiho wrote: > >We can make another directory up on sourceforge, alongside the win32 > >snapshots. > > I'll need CVS acces for that, which I don't have at the moment. my > sourceforge user account name is "irisson". > Where should I put the file exactly? I'm browsing inkscape CVS > without finding the win32 snapshot... > Then I guess that this must be linked from the download page. I would > be able to modify the download-en.inc file but I am no good in > german. How should I modify it: download the website, modify and > commit by CVS? -- Kees Cook @outflux.net

3 3

Re: [Inkscape-devel] Inkscape stats 9/15/05
by Nicu Buculei 16 Sep '05

16 Sep '05

Ben Fowler wrote: > I would respectfully disagree with both of the substantive points in this > thread(!): But you forgot to reply to the list ;) > On 9/16/05, Nicu Buculei <nicu@...398...> wrote: > >>Bryce Harrington wrote: >> >>>[ snip ] >> >> > Where the project needs help right now is in closing bugs. >> > We have our bug tracker quite well under control, but there >> > are 258 open bugs, and it would be wonderful if we could cut >> > that down significantly before the 0.43 release. If you can >> > code, please check out if you can help close one or two, ... > > > I am sitting on three patches, waiting for a thaw so that I can commit > without endangering other's activities. There was never much of a thaw > after 0.42! > > Ideally, the tree should be open just after a release for new work > including patches for minor bugs, also for developers' prized features, > as there will be a period for stabilisation before the next release. > > Just before a release, the emphasis should be on testing, packaging > and to a lesser extent on 'blocking bugs'. Cutting down the number > of open bugs by commiting is highly likely to expose other bugs or > problems with the code that require stabilisation and should be done > (IMHO) early in the release cycle. > > I suspect that I am missing something ... > > Personally, I would suggest that some manageable number > bugs (somewhere between 10 an 50 given the number of developers) > are marked as must fix before 0.43 and patches for other bugs (the > 'minor bugs' I mentioned above) are held over. > > Ideally this should be based on the importance to the end-user > rather than priority or ease of fixing. (High priority and easy to fix bugs > should most certainly be fast tracked, but again, at the beginning > or in the middle of a release cycle). > > >>Other projects keep from time to time some events called "bug >>party", when people clean the bug/feature tracker, collaborating >>over IRC and closing as much as possible as DUPLICATE, WON'T >>FIX, INVALID, RESOLVED or prioritizing. It may have the benefit >>of attracting new contributors and giving non-developers a way >>to contribute. >> >>What do you think about the opportunity/usefulness of such a >>bug party? >> >>At 258 bugs and 448 RFEs the number may be small enough and >>the action not needed. > > > I wholeheartedly agree with these data and your suggestions, until > the last line, where there is the implication that 250 open bugs is > a small number. Really, we should be aiming at zero bugs, and > should have 10 or fewer open ones. I said "may be" because I really don't know what we should consider a large or small number of bugs, compared with larger projects like Mozilla or OOo, 258 open bugs is very little. > I would urge every effort to getting non-coders interested in triaging > bugs and assigning priorities at all times. It is especially helpful to > have end-users prioritising bugs, as bugs which do not impact > the user community can be left to a future when there is more > time. > > I also note that many of the open bugs refer to the Windows > operating system, and unless those they are easily reproducible > they may never get seen by a developer unless the user > community can get behind them and insist that (some of) such > bugs are indeed important. Well, it may also be the case some of those bugs can't be reproduced at all or referring to old versions of Inkscape and can be simply closed. > Finally, if we are going to have hundreds of open bugs, we should > consider an even/odd policy, and do 'bug fixes only' for even > numbered releases ... > > That may not desirable if we have a large number of RFEs and/or > features which developers are interested in. Certainly in the > proprietary world, there are products which have benefitted > from a period of stability in which six months of the developers > time was spent on stabilisation, performance and bug fixing > rather than new features. Ideally we need to know whether the > user community would vote for quality and bug fixes or new > features ... > > Ben > -- nicu

5 7

Using Inkscape.
by Gavin Band 16 Sep '05

16 Sep '05

Hi, First let me thank the developers for the fantastic Inkscape. I have a couple of questions about its usage. (It's a wish-list, really. I am using Inkscape 0.42.2). First, when using Inkscape on a large file such as this one: http://www.liv.ac.uk/~gband/shift_class_classification.svg it's impossible to zoom out so one can see the whole picture at once. Secondly, it would seem to me that one should "export" to file types which are not rich enough to recover the whole file, and "save" to other file types. But in Inkscape one has to "save as" (for example) Postscript. Then, if you want to keep a master copy for later editing you has to save as .svg as well, forcing you to keep choosing between the two filenames. This also seems inconsistent with the command-line switches where there is a --export-ps switch. Can't "Export bitmap" be turned into "Export", offering a choice of bitmaps, and remembering the chosen filename? Thanks, gav.

12 35

Win32 help
by Jon A. Cruz 16 Sep '05

16 Sep '05

I've got a few bugs open for Win32 issues, and a few ideas on how to address them. What I don't have is a good way to compile or run Win32 tests here on my Mac. :-) What would be helpful would be anyone who could either build win32 versions with some tweaks or anyone who could run quick tests with those builds. Especially given our freeze state, I don't want to check anything in to CVS that hasn't gone through actual build and user testing. So... If anyone could help with either of those aspects (I've had a few people mention this in chat), just drop me a quick email directly and say if you can compile, test, or both. (no need to clutter the mailing lists to responses to this) Thanks.

3 3

web-site translation / gettext
by Alexandre Prokoudine 16 Sep '05

16 Sep '05

Hi, I didn't catch up when you were discussing details of i18n implementation for our beloved www.inkscape.org. All I want is to point out that web-sites can be translated via gettext just like applications. Example is http://audacity.sf.net, where you just download a .pot file (from http://audacity.sourceforge.net/community/translation), translate it in KBabel, poEdit, GTranslator or whatever else and commit it to CVS or send to one of developers. When anything at ("on" is the right preposition?) the site updates, .pot files updates as well (currently manually, but this could be done automatically, I think). Translators then only need to merge changes tro translations and send them back to developer or commit themselves. This is quite handy. I don't know details of implementation, but I think that Matt Brubeck, who is in charge for that site, could help you. His e-mail address is mbrubeck =at= cs.hmc.edu Alexandre

8 11