Inkscape Project Status 2004-10-01
As can be seen from the numbers, Inkscape has a great deal of momentum. Judging from the number of CVS commits, bugs fixed, and rfe's closed for the past two weeks, development seems to be continuing steadily. We hit 35th rank on the 19th of September; while that doesn't beat our record of 22nd, it's certainly close.
It's been a while since our last release, and a lot of new features have gone in. Unfortunately, we're not near to having the Gtkmm work done, so I'm wondering if we should be thinking of putting out an interim release (like a 0.39.5, or maybe a 0.40 where we bump the current 0.40 tasks forward a milestone). Opinions?
Bryce
Statistics Nov 15 May 15 Aug 15 Sep 15 Oct 1 ========== ====== ====== ====== ====== ====== Lifetime Rank on SourceForge: 4391 1028 774 733 729 (68.5%) (92.7%) (94.6%) (94.9%) (94.9%) Max Week's Rank on SourceForge: 62 36 53 189 35 (99.6%) (99.8%) (99.7%) (98.9%) (99.8%) Total SF Page Views * 475,000 900,566 1,072,842 1,218,185 Total SF Downloads * 27,400 47,278 56,571 60,728 Total Freshmeat URL Hits 746 * 9,382 10,322 11,043 Total Freshmeat Subscriptions 16 74 114 118 122 Lines of Code in src/: 115,901 189,116 276,437 298,454 302,624 Code lines 147,471 200,684 213,351 215,549 Comment line 16,757 43,558 51,098 52,042 Blank 25,886 37,425 40,484 41,549 Lines of Docs in doc/: 1,135 4,544 16,358 16,795 16,802 Lines of content in website: 1,173 6,008 7,106 7,527 7,676 Size of the Inkscape wiki: 3,700 18,638 19,665 20,207 20,274 Minutes since last ChangeLog mod: 360 * * * * Bugs open/total: 9/15 57/365 110/568 126/616 138/638 Features open/total: 18/18 183/238 266/361 250/376 251/388 Patches open/total: 1/ 6 4/ 83 5/120 6/123 6/124 CVS Commits (as per inkscape-cvs): 481 3391 6,822 7,296 7,606 Inkscape-devel membership: 49 78 104 113 113 Inkscape-announce membership: 9 43 74 85 91 Inkscape-user membership: 71 109 120 129 Num Translations : 33 33 33 Ave Translation Ratio: 44.9% 45.0% 41.6%
* - Statistics unavailable
I think 0.40 is a good number. Maybe we should move to bug fixes and consider gtkmm halfway and to be finished in the next release. It seems that the work on POTRACE, usability fixes, and more refinements are good for a release...
Jon
----- Original Message ----- From: "Bryce Harrington" <bryce@...260...> To: inkscape-devel@lists.sourceforge.net Sent: Saturday, October 02, 2004 2:15 AM Subject: [Inkscape-devel] Inkscape Project Status 2004-10-01
As can be seen from the numbers, Inkscape has a great deal of momentum. Judging from the number of CVS commits, bugs fixed, and rfe's closed for the past two weeks, development seems to be continuing steadily. We hit 35th rank on the 19th of September; while that doesn't beat our record of 22nd, it's certainly close.
It's been a while since our last release, and a lot of new features have gone in. Unfortunately, we're not near to having the Gtkmm work done, so I'm wondering if we should be thinking of putting out an interim release (like a 0.39.5, or maybe a 0.40 where we bump the current 0.40 tasks forward a milestone). Opinions?
Bryce
Statistics Nov 15 May 15 Aug 15 Sep 15 Oct 1 ========== ====== ====== ====== ====== ====== Lifetime Rank on SourceForge: 4391 1028 774 733 729 (68.5%) (92.7%) (94.6%) (94.9%) (94.9%) Max Week's Rank on SourceForge: 62 36 53 189 35 (99.6%) (99.8%) (99.7%) (98.9%) (99.8%) Total SF Page Views * 475,000 900,566 1,072,842 1,218,185 Total SF Downloads * 27,400 47,278 56,571 60,728 Total Freshmeat URL Hits 746 * 9,382 10,322 11,043 Total Freshmeat Subscriptions 16 74 114 118 122 Lines of Code in src/: 115,901 189,116 276,437 298,454 302,624 Code lines 147,471 200,684 213,351 215,549 Comment line 16,757 43,558 51,098 52,042 Blank 25,886 37,425 40,484 41,549 Lines of Docs in doc/: 1,135 4,544 16,358 16,795 16,802 Lines of content in website: 1,173 6,008 7,106 7,527 7,676 Size of the Inkscape wiki: 3,700 18,638 19,665 20,207 20,274 Minutes since last ChangeLog mod: 360 * * *
Bugs open/total: 9/15 57/365 110/568 126/616 138/638 Features open/total: 18/18 183/238 266/361 250/376 251/388 Patches open/total: 1/ 6 4/ 83 5/120 6/123 6/124 CVS Commits (as per inkscape-cvs): 481 3391 6,822 7,296 7,606 Inkscape-devel membership: 49 78 104 113 113 Inkscape-announce membership: 9 43 74 85 91 Inkscape-user membership: 71 109 120 129 Num Translations : 33 33 33 Ave Translation Ratio: 44.9% 45.0% 41.6%
- Statistics unavailable
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I would certainly welcome turning our attention to bugfixing, but I think a new release is not too close at this time. Here's an overview of what remains to do.
Fred's text refactoring still contains a number of serious bugs and fixes. He promised to fix them but I don't know when this will happen. Most of these bugs are not in the tracker, as I reported them to him directly; I can put them into the tracker if anyone wants to have a look. Plus there's something seriously bad with text export into PS (#1015845) and with rendering of text with gradients (#1038594).
The UI that I'm doing for the new text features is barely started. I just added one command, put text to path. Several more commands are needed for this to become useful.
Mental's work on layers is, by his words, 25% ready. I'm not sure what is needed for it to become release-able, but I think at least the statusbar widget with visibility and locking toggles must become functional. Now it's pretty broken. Plus we need to create new document templates with layers and test them thoroughly.
Aubi's work on gtkmmfication of dialogs is unfinished and is left in a pretty borken state (e.g. Find dialog is in two copies). Someone needs to at least clean this up.
Ishmal's file dialogs are wonderful, but they still feel very rough with several bugs and usability bads (# 1018798). I would like to fix whatever possible before the release.
I don't know the status of Ted's work on plugins.
Myself, I haven't yet finished some feature work I'm working on. There are also several pet bugs I want to fix, some of which may turn out very difficult. And finally I cannot delay updating tutorials any more. It's a lot of writing with all the new features that need to be described.
Simarilius still cannot do a compile on Windows. Can anyone please help him? He wants to do developing and bugfixing but cannot.
Last but not least, Brisgeek hasn't yet done a new About box for 0.40.
So overall, it's all in a pretty disconcerted state. Let's focus our efforts on achieving releaseability, but I don't think we can enter a freeze in less than a couple of weeks.
A couple more things:
We have this Spalah program for Flash export. Someone needs to test it and report problems to its author (sorry, Anatoly, I always meant to do this but didn't have time). Then we need to incorporate it into our distribution so that no extra installation is needed. Flash export is a very useful thing, even if static only.
With all the new libs, we need to create and thoroughly test a few (mostly-)static-linked builds to find out problems. We have a frightening number of bugs where people cannot compile or run CVS because of library problems, and probably many crashes can also be attributed to this. So, for this release, we need a different approach to packaging; just releasing the tarball and waiting for binaries won't work. We need to have binaries which are tested and work with minimum dependencies on the major platforms/distros, only then we can announce a release.
On Sat, 2 Oct 2004, bulia byak wrote:
Date: Sat, 2 Oct 2004 14:15:02 -0300 From: bulia byak <buliabyak@...400...> To: Bryce Harrington <bryce@...260...>, inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape Project Status 2004-10-01
A couple more things:
We have this Spalah program for Flash export. Someone needs to test it and report problems to its author (sorry, Anatoly, I always meant to do this but didn't have time). Then we need to incorporate it into our distribution so that no extra installation is needed. Flash export is a very useful thing, even if static only.
Tried to build it, failed.
Sent a message to the author, dont think he has replied yet (lot of mail to sort through), when he does I'll try again.
Could well be my own fault but at the very least proves it could be easier and provide a better error message.
Sincerely
Alan Horkan
http://advogato.org/person/AlanHorkan/ Inkscape, Draw Freely http://inkscape.org Free SVG Clip Art http://OpenClipArt.org
On Sat, Oct 02, 2004 at 02:15:02PM -0300, bulia byak wrote:
We have this Spalah program for Flash export. Then we need to incorporate it into our distribution so that no extra installation is needed. Flash export is a very useful thing, even if static only.
We use external software for a number of input formats (dia, pstoedit, sketch, libwmf-bin). Dia is a very useful thing -- as is gimp -- but we don't and shouldn't include them in our distribution.
It's useful for users to be able to upgrade Spalah and Inkscape independently of each other.
Flash export may be extremely useful to some people, but not everyone, and I'd venture to say not useful for most people.
If spalah were distributed as part of inkscape, then we'd have to choose between installing it in ${exec_prefix}/bin (which would be inconvenient for distributions that package both inkscape and spalah) or in ${libexec} (which would make it harder for people to use spalah other than from in inkscape, unless they'd installed a second copy, in which case there may be confusing and typically undesirable differences between the two versions).
Adding spalah to the inkscape distribution would also lengthen compile times, make it harder for people to make their way around inkscape's source tree (e.g. more false hits from grep -r), increase disk space requirements, probably complicate compilation (e.g. do we have a separate configure.in or do we merge into tour existing build system, thereby increasing maintenance cost).
The "extra installation" isn't a problem for people who use tools like apt and emerge: these tools provide a better solution than bundling together anything that might be useful to some people. Incidentally, tools like apt & emerge also make it easy for people to get source code for things, which in turn makes it more likely that users will submit patches for things.
I request that Spalah not be added to inkscape source tree.
pjrm.
On Mon, Oct 04, 2004 at 12:48:33PM +1000, Peter Moulder wrote:
probably complicate compilation
Also note that spalah-swf has at least two dependencies not needed for the rest of inkscape, namely libart-2.0 and ming (http://ming.sourceforge.net/). Ming isn't yet in many (any?) distributions, in part because of its lack of maturity (e.g. the most recent release (8 months old) fails to compile out of the box). If we added spalah-swf to inkscape sources, then presumably we'd also want to add [a working version of] ming.
pjrm.
Thanks for bugreports! I will try to fix this at this week.
About internal or external exstension. We have disscused it earlier. It will be external exstension.
On Sun, 2004-10-03 at 19:48, Peter Moulder wrote:
I request that Spalah not be added to inkscape source tree.
I agree, and also think that we will need to start to develop a community of external software that works with Inkscape. I think that if we work with Spalah to make sure that there continues to be continuity and interoperability we will have started on a path to more sustainability in the future.
I know that Debian can add a 'recommends' for a dependency, I think we should put Spalah as a 'recommends'. That way, when users install Inkscape they are likely to install Spalah, but don't have to. Do other package formats allow for that?
--Ted
On Mon, 4 Oct 2004, Peter Moulder wrote:
Date: Mon, 04 Oct 2004 12:48:33 +1000 From: Peter Moulder <Peter.Moulder@...38...> To: inkscape-devel@lists.sourceforge.net Subject: spalah Re: [Inkscape-devel] Inkscape Project Status 2004-10-01
On Sat, Oct 02, 2004 at 02:15:02PM -0300, bulia byak wrote:
We have this Spalah program for Flash export. Then we need to incorporate it into our distribution so that no extra installation is needed. Flash export is a very useful thing, even if static only.
We use external software for a number of input formats (dia, pstoedit, sketch, libwmf-bin). Dia is a very useful thing -- as is gimp -- but we don't and shouldn't include them in our distribution.
that is a bit disingenuous, the dia and gimp are both massive and it would not make sense to compile them in, libraries like libwmf and spalah are relatively small.
It's useful for users to be able to upgrade Spalah and Inkscape independently of each other.
I'd be inclined to argue that the kind of user that would want to upgrade Spalah independantly of Inkscape would also be the kind of user capable of compiling their own non-statically compiled builds.
We want users to test things like spalah.
Inkscape has not yet had an official stable release and as such all users should be considered testers, and with all due respect I think Inkscape could currently be described as 'alpha software' (to me beta implies some sort of freezed prerelease destined for an official release).
The "extra installation" isn't a problem for people who use tools like apt and emerge: these tools provide a better solution than bundling
for apt and emerge users it would be a better solution (and from Gentoo users it seems like a moot point as they will be compling from source anyway)
for ordinary users who dont really care either way it would not be a solution
If Debian and Gentoo themselves wish to provide specialised packages that would be great but until there is an official stable release I think users should be presented with the full Inkscape experience and not left unware of the possibilities.
When it comes time for a stable official release I hope both non-static and big fat static binaries can be provided to make it dead easy for users to run Inkscape where ever they want.
I request that Spalah not be added to inkscape source tree.
I'm not suggestion it be permanently added but to encourage testing and development I think it should be added at least for the next few releases.
Sincerely
Alan Horkan
http://advogato.org/person/AlanHorkan/ Inkscape, Draw Freely http://inkscape.org Free SVG Clip Art http://OpenClipArt.org
On Mon, Oct 04, 2004 at 05:48:01PM +0100, Alan Horkan wrote:
the dia and gimp are both massive and it would not make sense to compile them in, libraries like libwmf and spalah are relatively small.
Actually, libwmf and pstoedit aren't all that good examples either, as they have big dependencies. (libwmf wants ghostscript fonts, pstoedit wants ghostscript itself.)
Adding current versions of spalah-swf and ming to inkscape would increase the size by about 17%.
potrace is an interesting comparison. It increases inkscape's size by about 1%.
However, I think size is less important than other things like adding to the build requirements (flex, bison, libart), making it harder to grep through the source tree, increasing compile times, increasing bandwidth usage and disk usage on developers' machines and servers, adding complexity to installation for people who already have spalah-swf and/or ming installed.
It's useful for users to be able to upgrade Spalah and Inkscape independently of each other.
I'd be inclined to argue that the kind of user that would want to upgrade Spalah independantly of Inkscape
When a new version of spalah-swf or ming is released, I'd guess that most of the users for whom swf export from inkscape is important would be interested in upgrading.
We want users to test things like spalah.
Not sure. I'm more interested in people using SVG than a proprietary format.
Conversely, for improving spalah-swf, there are advantages in it being separate from inkscape: people can be testing a more up-to-date version, and the sources are easier to understand when not entangled with inkscape code, and people are more likely to download the sources if it's separate from inkscape. Adding spalah-swf to inkscape makes it harder to install separately.
If Debian and Gentoo themselves wish to provide specialised packages that would be great but until there is an official stable release I think users should be presented with the full Inkscape experience and not left unware of the possibilities.
Personally I don't consider swf export an integral part of "the full inkscape experience".
This may depend in part on how good our swf import & export is. If we could do a reasonable job of round-tripping with the swf format, then that increases the value. Presumably we'll always do better at round-tripping SVG than SWF though. I don't know of any software for converting SWF to SVG yet.
Instead of adding spalah-swf and ming to inkscape sources, how about providing a links page (or pages, e.g. one page for .tar.gz, one page for FC .rpm, maybe different pages for different distributions), so that people can download inkscape and all interesting related software from one page?
That seems like a reasonable way of making it easy for people to get related software, while avoiding making our source tree harder for people to work with?
pjrm.
On Tue, 5 Oct 2004, Peter Moulder wrote:
However, I think size is less important than other things like adding to the build requirements (flex, bison, libart), making it harder to grep through the source tree, increasing compile times, increasing bandwidth usage and disk usage on developers' machines and servers, adding complexity to installation for people who already have spalah-swf and/or ming installed.
Agreed. I'm a fan of keeping things external from the core as much as possible. Of course, until the extensions stuff comes on line, we're going to need to maintain a balance in what's included, but from the discussion it sounds pretty clear that Spalah is beyond the line and should be left external.
Instead of adding spalah-swf and ming to inkscape sources, how about providing a links page (or pages, e.g. one page for .tar.gz, one page for FC .rpm, maybe different pages for different distributions), so that people can download inkscape and all interesting related software from one page?
This is a good idea. There's been a few SVG tools mentioned lately, and it would be valuable for users if we expanded our tool list.
Bryce
I agree that there is no reason to make from Inkscape big fat monster :). It be better to make it like in gnumeric or firefox. There is core and pugins. User can select which plugin to install.
So Inkscape have to contain file somethihg like /etc/inkscape.rc or /etc/inkscape.xml where plugin can receive info about paths to inkscape binary, inkscape exstensions, etc.
On Tue, 5 Oct 2004, Peter Moulder wrote:
Instead of adding spalah-swf and ming to inkscape sources, how about providing a links page (or pages, e.g. one page for .tar.gz, one page for FC .rpm, maybe different pages for different distributions), so that people can download inkscape and all interesting related software from one page?
That seems like a reasonable way of making it easy for people to get related software, while avoiding making our source tree harder for people to work with?
This sounds like a good idea. We have a tools page in the website. Check out inkscape_web and edit tools.php to add those links (or send me all of the relevant info and I can add it).
Bryce
On Mon, 4 Oct 2004, Alan Horkan wrote:
Inkscape has not yet had an official stable release and as such all users should be considered testers, and with all due respect I think Inkscape could currently be described as 'alpha software' (to me beta implies some sort of freezed prerelease destined for an official release).
Hmm, one thing to consider is that if SuSE and other major distros are now including Inkscape, it may not be accurate to be describing it as alpha software. Regardless of what we may think, users are using it in production environments.
With the "release early / release often" philosophy, the standard proprietary software notions of alpha/beta/official/etc. aren't good fits anyway.
Also, I believe we did refer to the 0.38.1 release as a stability release - the main focus of that release was bug fixing. ;-)
Bryce
On Sat, 2 Oct 2004, bulia byak wrote:
Aubi's work on gtkmmfication of dialogs is unfinished and is left in a pretty borken state (e.g. Find dialog is in two copies). Someone needs to at least clean this up.
Well, I'm guessing Aubi will probably pop back in at some point, but if she doesn't, I've reviewed what she's done and could work it into a more finished state. Stylistically there's a few things I want to correct anyway to ensure it fits with the new Gtkmm code.
Bryce
On Sat, 2 Oct 2004, bulia byak wrote:
I would certainly welcome turning our attention to bugfixing, but I think a new release is not too close at this time.
I've gone through and prioritized all the incoming bugs. I closed or moved a few to rfe. This reduced our bug count to 128. We have a lot of critical bugs... Many crashes and assertions being reported.
I notice we have 7 patches in the patch tracker; it'd probably be wise to incorporate all of those that can be easily added asap so we have plenty of time to test them (and to encourage the submitters to send in more patches.)
Bryce
On Sat, 2004-10-02 at 10:06, bulia byak wrote:
I don't know the status of Ted's work on plugins.
Basically, right now, things are workable but I wouldn't want anyone writing to the interface -- I don't consider it stable. But, I don't think it would hurt anything if we released today as long as we didn't promote it.
As for what I'd like to get done before a release, when Bryce and I set down and wrote the extensions document there were some differences in the configuration files that were written in. I think all of them were good, but also they should get into the codebase as soon as possible, to remove further incompatibilities later. Also, at the same time I'd like to improve the error handling there so that users can discover failed dependencies or other reasons why they don't have a feature.
Also, I have quite a few bugs assigned to me that I haven't worked on.
I think that adding in effects is going to have to wait until next release. After redoing verbs I think that the infrastructure is there now, it is just a matter of implementing the effects portion. But, I think the above stuff is higher priority.
I think we're all talking about finishing some stuff up, but, in general we think that there are enough features to justify a release -- with a little bit of cleaning. I was looking and noticed that the project was registered with Sourceforge on 10/26. Should we target that as a date for a release? (Yes, I understand the probability of us actually hitting it is next to none, but I thought we should have a target)
--Ted
On Sat, Oct 02, 2004 at 09:22:08AM -0700, Jon Phillips wrote:
I think 0.40 is a good number. Maybe we should move to bug fixes and consider gtkmm halfway and to be finished in the next release. It seems that the work on POTRACE, usability fixes, and more refinements are good for a release...
Agreed. I haven't been following development, but this status email woke me up. Agh! Text-on-path!! yaaaay!
Anyway, looks like crazy-icon-man will have to strike again; there are lots of new menu items without icons. *rub hands*
Anyway, looks like crazy-icon-man will have to strike again; there are lots of new menu items without icons. *rub hands*
Honestly, I think it's the least of our problems :)
Kees, BTW, could you look into the metadata-related bugs? In particular there should be no metadata on plain SVG export/save.
Also you were working on the right-click menu. Has there been any progress?
On Sat, Oct 02, 2004 at 02:26:24PM -0300, bulia byak wrote:
Honestly, I think it's the least of our problems :)
Heh, but it's something that makes the menus feel fuller, and I enjoy doing it. :) (BTW: why did the "deselect" icon disappear? I realize my icons suck, but it seems they should stay unless _replaced_ by a better one...)
Kees, BTW, could you look into the metadata-related bugs? In particular there should be no metadata on plain SVG export/save.
Okidoky. I'll have to go dig through the "plain SVG" code and see where it fishes out XML it doesn't want to include. Should be easy, since all the metadata is in one giant tag. :)
Also you were working on the right-click menu. Has there been any progress?
Never made any progress on it; it required creating a whole new approach to the object handling (most verbs were designed originally for selection-oriented actions, but the right-click stuff needs to work per-object). I'll need to re-familiarize myself with the code too, since it's seen a lot of changes. :)
On Sat, Oct 02, 2004 at 10:35:57AM -0700, Kees Cook wrote:
Okidoky. I'll have to go dig through the "plain SVG" code and see where it fishes out XML it doesn't want to include. Should be easy, since all the metadata is in one giant tag. :)
Uhmmm... were is the pull-down for what file type to save-as in the new file dialog?
On Sat, 2 Oct 2004 11:21:53 -0700, Kees Cook <inkscape@...62...> wrote:
On Sat, Oct 02, 2004 at 10:35:57AM -0700, Kees Cook wrote:
Okidoky. I'll have to go dig through the "plain SVG" code and see where it fishes out XML it doesn't want to include. Should be easy, since all the metadata is in one giant tag. :)
Uhmmm... were is the pull-down for what file type to save-as in the new file dialog?
That's one of the usability problems with the new dialog. As far as I understand, it determines the save type by the extension. But I honestly don't know how one selects plain SVG :( I think we need a file type selector back. Ishmal?
On Sat, Oct 02, 2004 at 03:53:55PM -0300, bulia byak wrote:
Uhmmm... were is the pull-down for what file type to save-as in the new file dialog?
That's one of the usability problems with the new dialog. As far as I understand, it determines the save type by the extension. But I honestly don't know how one selects plain SVG :( I think we need a file type selector back. Ishmal?
Ah, okay. Well, I can't work on this unless I figure out a way to short-circuit that dialog or get the pull-down added.
Honestly, I think it's the least of our problems :)
Heh, but it's something that makes the menus feel fuller, and I enjoy doing it. :) (BTW: why did the "deselect" icon disappear? I realize my icons suck, but it seems they should stay unless _replaced_ by a better one...)
Frankly, I don't think all menu items need icons. Some of them are clearly secondary in importance or even temporary. Icons for everything just makes it look overloaded and noisy. I think if a group of commands (within horizontal separators) contains commands of different levels of importance, we should make an icon for the important one only. Otherwise it will be the same as making all of the text boldface, instead of just the key words.
As for unselect, I think it was particularly suited for having no icon, due to its meaning :)
participants (8)
-
Alan Horkan -
Anatoly Podlesnuk -
Bryce Harrington -
bulia byak -
Jon Phillips -
Kees Cook -
Peter Moulder -
Ted Gould