On Fri, Sep 16, 2005 at 09:40:15PM +0100, Jonathan Chetwynd wrote:
> OS X build* for inkscape
>
> Bryce,
>
> someone once built inkscape for OS X, not so long ago.
> If that person can provide build instructions, I may be able to make
> regular builds, especially whilst inkscape is improving so fast.
Great, thanks! Kees, can you point Jonathan towards the build
instructions for OSX?
Bryce

On Fri, Sep 16, 2005 at 12:02:55PM +0300, Nicu Buculei wrote:
> Bryce Harrington wrote:
> >
> >The number to check out this time is the number of feature requests.
> >We dropped the total from 471 a couple months ago to under 450
> >now, or from a ratio of 62% to under 50%. Quite a jump!
>
> I bet the decrease in the number of RFE is partly due to a more
> aggressive triaging, with some closed as duplicates.
Certainly that's the case; it's good to see the number come down
none-the-less.
Bryce

On Fri, Sep 16, 2005 at 02:41:35PM +0300, Nicu Buculei wrote:
> >On 9/16/05, Nicu Buculei <nicu@...> wrote:
> >>Bryce Harrington wrote:
> >>> 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!
Due to the summer of code students, it was our intent to push out 0.43
pretty quickly. However, I think there might have been some confusion
in that between the 0.42.0 release and 0.42.2, CVS HEAD was open for
0.43 work for about a month.
> >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 ...
What you describe is pretty much how we work. I think you might have
come in at the middle, and the 0.42.2 patch release might have been
confusing.
> >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).
Yes, we go through two bug fixing phases; the first we set a point goal
and accept any bug fixes, and discourage feature work, in order to allow
the codebase to stabilize. The second is a hard freeze, where identify
a set of up to a dozen 'must fix' bugs and limit CVS commit access to
two 'release wardens'. During that phase all work must be sent to them
as patches for review and integration, and they provide a tight final
quality control before we go ahead and branch the release. This ensures
we as a project place maximum focus on QC ahead of a release.
> >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'd love to see us have zero bugs, but of course there's a balance
between being perfect and releasing regularly. ;-)
Where we've been drawing the line is achieving zero bugs that lead to
crashes or data corruption. Cosmetic bugs, usability issues, and
incompatibilities are also important, but getting all those solved is
more of a long term objective.
> >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.
Yup, we do this quite regularly, and we've gotten quite a few good
volunteers to help with this prioritization work. Of course, we could
always use a few more! Both bugs and RFEs need some prioritization
effort right now.
> >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.
I think you'll find as you get involved with the bug efforts that we
actually do get remarkably good participation from the user community in
replicating bug reports and in validating fixes. This has been
especially true for some of the bugs related to localization. I think
we actually have a fair number of Win32 devs, and we're even starting to
see some OSX-based devs, however I think we could really use more of
each.
> >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 ...
Actually, we started doing this semi-officially with the 0.42 release.
0.43 is being considered a bit more development-oriented, and 0.44 will
be considered a more aggressive bug-killing release. If you're strongly
interested in seeing us get our bug count down closer to zero, I'd
definitely encourage you to jump in on the 0.44 release. I'd love to
see us cut our current open bug count in half at least (we've done it
before, I think we could do it again.)
> >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 ...
Of course, keep in mind that as an open source project, the personal
desires of the participants play a very large role in determining what
the project as a whole focuses on. A commercial organization can force
its developers to work on whatever it wants, but with Inkscape since
we're volunteer driven and since we put a high value on keeping things
fun, the project doesn't work that way.
I think we actually get better productivity and make most efficient use
of our resources by letting people work on what interests them rather
than trying to drive it top-down. I think enough of us get top-down
driving from work. ;-) I think when the developer has the freedom to
work on what they feel the urge to work on, they enjoy the work more,
and spend more of their time on it. It usually turns out that the bugs
still get fixed, the features still get implemented, just maybe not
quite in the order you'd have planned for. Looking back over our
roadmap for the past couple years, I see that the stuff we wanted to
achieve has been getting done quite rapidly, even though (or because?)
we don't give out assignments or require weekly status reports or
whatnot.
Ultimately, in my view, while we love our users, their input regarding
prioritization of bugs and features is probably less worthwhile than
just having them interact directly with the developers and let the
developers' personal judgement be what sets the priorities. Ideally, if
a user has a need that is a high priority, the best solution is to
encourage her to contribute towards that thing - even if she doesn't
code, there's still plenty of ways she can help, through testing, bug
analysis, creation of mockups for new features, writing documentation,
and so forth. It often turns out that once you put in some time
yourself towards some issue, it builds momentum as others take interest
and chip in where they see they can help, and before you know it the
bug's fixed or the feature's implemented, and everyone's had a bunch of
fun. :-)
Bryce

Quoting bulia byak <buliabyak@...>:
> And by the way, your method will still need to be tweaked to
> account for markers and for gaussian blur (when we have it).
We're okay for markers, since (within the canvas, at least), they're
child objects who contribute to their parents' bounding box.
Filter effects are a separate issue -- the output of some filters
(e.g. feFlood, feImage, feTurbulence, etc...) is not related to the
origin shape at all. So it's probably best to use larger of either
the normal bbox or the filter effects region[1].
-mental
[1] http://www.w3.org/TR/SVG11/filters.html#FilterEffectsRegion
If otherwise unspecified, the filter effects region is going to be
the object's bounding box, without stroke, plus 10% padding on all
sides.

The name Boolean operators is questionable but i think that they
should be in the own sub menu most defiantly or their own menu.
Renaming effects to scripts makes sense to me, regardless of language
they are wrote in they still preform a set of predetermined actions.
scripts is a fairly universally understood to mean exactly that. gimp
has script-fu so it is not that far a leap to have users think the
same about scripts in inkscape.
joshua blocher

On 9/16/05, mental@... <mental@...> wrote:
> When you're using miter joins, the necessary padding to the path
> bounding box will be the stroke width * the miter limit, instead of
> the stroke width.
>=20
> That's the only adjustment required to fix the bug.
No. This will give much too big bbox inflation than necessary in the
big majority of cases. It's extremely rare that the real object bbox
srtetches to the entire stroke width * the miter limit. So compared to
that, the current method (just adding stroke width) gives correct
results in a much bigger % of cases, and when it's wrong, its error is
much lower.
The only advantage of your method is that it always gives a
_guaranteed_ inclusion (i.e. upper limit for the bbox), but I don't
think we're interested in that.
--=20
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

On 9/1/05, Gavin Band <gavinband@...> wrote:
> First, when using Inkscape on a large file such as this one:
>=20
> http://www.liv.ac.uk/~gband/shift_class_classification.svg
>=20
> it's impossible to zoom out so one can see the whole picture at once.
I have now reduced the minimum zoom from 4% to 1% in CVS, and this
particular file now shows in its entirety. Try this out.
However, it was not exactly easy to do this. I had to address numerous
issues in the spinbutton precision, ruler display etc. All this
suggests that making minimum zoom dependent on image size (i.e. in
effect, make it unlimited) won't really work all that well. Infinities
are nasty, and this one is no exception. Not to mention that this
change will only benefit a really tiny percentage of users. So I'm
currently opposed to this proposal.
--=20
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

On 9/16/05, mental@... <mental@...> wrote:
> Quoting bulia byak <buliabyak@...>:
>=20
> > The only advantage of your method is that it always gives a
> > _guaranteed_ inclusion (i.e. upper limit for the bbox), but I
> > don't think we're interested in that.
>=20
> This would be specifically for computing update regions -- there, we
> certainly are.
Ah, that makes sense then. But anyway, we also need the correct bboxes
calculation for presenting to the user and for most other purposes.
And by the way, your method will still need to be tweaked to account
for markers and for gaussian blur (when we have it).
> My own feeling is that bounding boxes for other purposes -- for
> example tile layout -- shouldn't include the stroke width at all.
> But I wouldn't insist on it.
No, that's the way it was in Sodipodi and early Inkscape versions, and
we got many bug reports on that, until Fred coded the simplistic "add
the stroke width" thing we still use today.
--=20
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

Quoting bulia byak <buliabyak@...>:
> The only advantage of your method is that it always gives a
> _guaranteed_ inclusion (i.e. upper limit for the bbox), but I
> don't think we're interested in that.
This would be specifically for computing update regions -- there, we
certainly are.
Without guaranteed inclusion, we get "trails" and unpleasant
rendering artifacts, which is what the bug was about.
My own feeling is that bounding boxes for other purposes -- for
example tile layout -- shouldn't include the stroke width at all.=20
But I wouldn't insist on it.
-mental

Quoting Ben Fowler <ben.the.mole@...>:
> 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 ...
Yeah. What you describe has been our practice since the beginning.
Now, the 0.43 release cycle has been atypically short, with a long
freeze relative to the overall length of the cycle. But we did
unfreeze immediately after the 0.42 release...
> 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.
It would be nice if the Sourceforge tracker supported that kind of
annotation -- ideally I would like the ability to stick in a
"release bug", and make its closing dependent on the resolution of
various "must-fix" tasks and bugs.
But SF's tracker is too primitive to really support that. :/
-mental

Quoting Ben Fowler <ben.the.mole@...>:
> or have protected releases when we only do bug fixes.
That's the proper role for the 0.x.y releases, yes.
I don't think anyone would object to doing them more frequently, for
less severe bugs, if someone wanted to volunteer to do the
backporting of fixes, but right now we don't have anyone available
for that.
(I did it for the 0.42.x releases, but that was at the expense of a
lot of work I might have done for 0.43, including groundwork for
the oft-requested layers dialog)
-mental

Quoting Nicu Buculei <nicu@...>:
> I don't think we plan to have 0.nn.x releases, as those should
> happen only in case of major breakages (we had such things, but
> those were not planned)
We should plan on unplanned breakage though. :)
-mental

Quoting Peter Moulder <Peter.Moulder@...>:
> On Fri, Sep 16, 2005 at 11:56:58AM +0200, Stephen Schrenk wrote:
>
> > 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.
>
> Yes. This is a long-outstanding bug.
When you're using miter joins, the necessary padding to the path
bounding box will be the stroke width * the miter limit, instead of
the stroke width.
That's the only adjustment required to fix the bug.
-mental

On 9/16/05, Joshua A. Andler <joshua@...> wrote:
> So, perhaps we have a policy in place that if they don't respond within
> a month of our "inquiry" or suggestion, it is closed with the assumption
> that the bug is fixed or no longer relevant.
That sounds sensible, and it's more or less what we've been doing.
--=20
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

bulia byak wrote:
> On 9/16/05, Alan Horkan <horkana@...> wrote:
>
>>Ban anonymous reports immediately.
>
>
> In my experience, the quality of a report does not directly depend on
> its anonymity.
>
I'm not sure that banning is the solution, because for me it's not the
quality that I take issue with. It's the inability to follow up. We have
a number of bugs that anonymous people report, yet they never respond
once we start investigating it (and that usually is us responding to the
initial report with questions).
So, perhaps we have a policy in place that if they don't respond within
a month of our "inquiry" or suggestion, it is closed with the assumption
that the bug is fixed or no longer relevant.
Just my .02
-Josh

> 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).
thanks! I had nearly come to think that this build was of no
intereset (execpt for me at least!) ;-)
I tried to log into shell.sf.net and then navigated to /home/groups/i/
in/inkscape/inkscape_web I creat an osx-snap directory here where I
put the dmg right?
But then how I the website modified? do I do it? does someone else
takes care of that?
> If you've got CVS changes for packaging, put it in the patch tracker
> first, then we can move on to CVS.
wow, not sure to understand here. changes for packaging are changes
in the packaging process or in the packaging section of the web site
(=what is written above about the web page).
anyway I don't know how to make such patches. I found some things on
google about other projects but I don't want to make any mistake.
could somebody correct this if necessary:
cvs -d:pserver:anonymous@...:/cvsroot/inkscape login
cvs -z3 -d:pserver:anonymous@...:/cvsroot/inkscape co
-P inkscape
then when I need to make the patch, in the root directory of the cvs
repository on my computer I type:
cvs update
cvs add
cvs remove
cvs diff -urN mypatch.patch
I hope I am not appearing too dumb but I am not familier with this yet.
> 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
>
JiHO
---
Windows, c'est un peu comme le beaujolais nouveau :
a chaque nouvelle cuvee on sait que ce sera degueulasse,
mais on en prend quand meme par masochisme.
---
http://jo.irisson.free.fr/

On Sep 16, 2005, at 1:22 AM, bulia byak wrote:
> On 9/16/05, Jon A. Cruz <jon@...> wrote:
>
>> 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.
>>
>
> At the very least, I very much want to test a fix to the bug which
> currently has Inkscape crashing upon start on win98 (since Ishmal
> switched to the new libs). Once that is resolved, I hope I will be
> able to provide more help with Windows debugging.
Turning on the magic "Bulia" options might help.
"options.bulia.dumpOne"
"options.bulia.dumpOneD"
"options.bulia.dumpOneD2"
and
"options.bulia.dumpMk"
"options.bulia.dumpMkD"
"options.bulia.dumpMkD2"
'D and 'D2' give them more info.
There's no UI on them, so you'll just have to edit the preferences
xml directly.

On 9/16/05, Ted Gould <ted@...> wrote:
> On Fri, 2005-09-16 at 12:06 +0200, Tavmjong Bah wrote:
> > "Effects", is there a way to put in the Notification region a short
You mean the status bar?
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

On Fri, 16 Sep 2005, bulia byak wrote:
> Date: Fri, 16 Sep 2005 13:18:39 -0300
> From: bulia byak <buliabyak@...>
> To: Nicu Buculei <nicu@...>
> Cc: Inkscape ML <inkscape-devel@...>
> Subject: Re: [Inkscape-devel] Inkscape stats 9/15/05
>
> On 9/16/05, Nicu Buculei <nicu@...> wrote:
> > 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.
>
> But that number is growing by approximately 50 every release. And for
> most part, this is not a healthy growth. By this I mean that most of
> the new bugs are unclear, unreproducible, undocumented, duplicate,
> etc. It's with addressing this, not bug fixing proper, that we really
> need everyone's help.
Ban anonymous reports immediately.
Zero tolerance isn't something I'm normally in favour of but I think
anonymous reports are great big waste of time to put it bluntly.
Wont solve anything but will at least reduce the quantity of crappy bug
reports and make me less reluctant to spend time fleshing out the other
requests into something easier for the developers to work with.
- Alan

On Fri, 2005-09-16 at 12:06 +0200, Tavmjong Bah wrote:
> Will the default menus be changed to those proposed by Joshua Blocher?
> The arrangement that he proposed is better than the current one. The
> only comments I have are:
>=20
> 1. I don't like the path "boolean operators" buried in a submenu. (And
> the term "boolean" is not quite appropriate, I think.) The "offsets"
> would be a better choice to put in a submenu.
Personally, I'm not too picky about the menus, but it seemed that the
discussion pretty much stopped after he posted that. I don't know if
that means that his suggestions were perfect or fundamentally flawed.
Perhaps reposting your update of what you'd like to see would be best.
Move the boolean submenu! Feel liberated! :)
> 2. "Effects" might be better than "Scripts". As pointed out by Ted
> Gould, some of the effects are programmed in C++. Speaking of
> "Effects", is there a way to put in the Notification region a short
> description of each entry in the this menu?
I do prefer effects. I've also been toying with the word "Transformers"
as I don't think anyone else is using that. But, it isn't very sexy :)
Submit an RFE on the notification region stuff. I won't get to it for
0.43, but I think it is a good idea for the future.
--Ted

On Fri, Sep 16, 2005 at 05:15:23PM +0400, Alexandre Prokoudine wrote:
> On 9/16/05, Nicu Buculei <nicu@...> wrote:
>
> > 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?
>
> Sounds like a good idea. It's practically impossible to keep track of
> all of them for any human being. All you need then is work out
> criteria for evaluation of priorites.
I like this idea too. Would either or both of you like to organize a
bug party for this weekend?
Bryce

Attached
On Fri, 2005-09-16 at 13:25 -0300, bulia byak wrote:
> On 9/16/05, Tavmjong Bah <tavmjong@...> wrote:
> > Will the default menus be changed to those proposed by Joshua Blocher?
> > The arrangement that he proposed is better than the current one.
>
> I always meant to review that menu proposal but didn't have time.
> Where can I see it again? Or, if others are in favor, maybe we can
> just commit it and then I will propose my changes if necessary?
>

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