Hello,
does someone will update the roadmap page ? It still lists the 0.42 as next goal.
http://wiki.inkscape.org/cgi-bin/wiki.pl?Roadmap
Adib. ---
On Wed, Sep 21, 2005 at 08:19:28PM +0200, Adib Taraben wrote:
Hello,
does someone will update the roadmap page ? It still lists the 0.42 as next goal.
Okay, I'll take care of updating it. But I need some advice and opinions.
I've reshuffled things so that we have all DONE tasks for 0.42 and 0.43, so we can move those milestones off to the history page.
However, I need to know people's desires for what we want to do going forward.
The problem is actually a pretty good one to have - as a project we've completed a LOT of the major work we'd set out for ourselves at the initiation of the project. Many, many, many major features have been implemented. There's still a few big things like Cairo, Gtkmm, LittleCMS, and so on, but a huge amount of feature work is now solidly under our belt. Today Inkscape is also well known and well respected both by the Open Source and art communities.
The main issue is that we need a compelling objective to focus on for the coming year; something that most of us would be motivated to work on, and that needs a team effort (as opposed to simply requiring one of our several UberHackers to knock out over a couple weekends!)
A roadmap is more than just a todo list; if that's all we needed, then we'd not need anything more than the Bug/RFE tracker. A roadmap is supposed to be a longer range, larger scope thing that helps guide us to some goal far in the distance. It's a blueprint we can use to enable ourselves to achieve something extremely ambitious.
So anyway, what largish objectives do folks feel like having our project focus on for the next year or so? What would you all like to contribute to as a team?
Bryce
On Wed, 21 Sep 2005, Bryce Harrington wrote:
Date: Wed, 21 Sep 2005 22:58:45 -0700 From: Bryce Harrington <bryce@...961...> To: Adib Taraben <taraben.a@...50...> Cc: inkscape-devel inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] update of roadmap
On Wed, Sep 21, 2005 at 08:19:28PM +0200, Adib Taraben wrote:
Hello,
does someone will update the roadmap page ? It still lists the 0.42 as next goal.
Okay, I'll take care of updating it. But I need some advice and opinions.
I've reshuffled things so that we have all DONE tasks for 0.42 and 0.43, so we can move those milestones off to the history page.
I went ahead and moved 0.42 didn't want to move 0.43 until it was released.
However, I need to know people's desires for what we want to do going forward.
The main issue is that we need a compelling objective to focus on for the coming year; something that most of us would be motivated to work on, and that needs a team effort (as opposed to simply requiring one of our several UberHackers to knock out over a couple weekends!)
A roadmap is more than just a todo list; if that's all we needed, then we'd not need anything more than the Bug/RFE tracker. A roadmap is supposed to be a longer range, larger scope thing that helps guide us to some goal far in the distance. It's a blueprint we can use to enable ourselves to achieve something extremely ambitious.
So anyway, what largish objectives do folks feel like having our project focus on for the next year or so? What would you all like to contribute to as a team?
Animation is a pretty Large goal.
Full SVG Tiny support is a smaller goal, and looking back at implementing the SVG specifications seems like a good way to refocus Inkscape on its core goals.
Need I say more?
- Alan Horkan
On Thu, Sep 22, 2005 at 10:20:45PM +0100, Alan Horkan wrote:
However, I need to know people's desires for what we want to do going forward.
The main issue is that we need a compelling objective to focus on for the coming year; something that most of us would be motivated to work on, and that needs a team effort (as opposed to simply requiring one of our several UberHackers to knock out over a couple weekends!)
A roadmap is more than just a todo list; if that's all we needed, then we'd not need anything more than the Bug/RFE tracker. A roadmap is supposed to be a longer range, larger scope thing that helps guide us to some goal far in the distance. It's a blueprint we can use to enable ourselves to achieve something extremely ambitious.
So anyway, what largish objectives do folks feel like having our project focus on for the next year or so? What would you all like to contribute to as a team?
Animation is a pretty Large goal.
Full SVG Tiny support is a smaller goal, and looking back at implementing the SVG specifications seems like a good way to refocus Inkscape on its core goals.
Need I say more?
SVG Tiny is a good idea. I think previously we identified SVG Tiny compliance as our condition to releasing Inkscape 1.00.
What do others think? What if we restructured the roadmap to enable us to attack and achieve this objective?
Bryce
On 9/23/05, Bryce Harrington <bryce@...961...> wrote:
SVG Tiny is a good idea. I think previously we identified SVG Tiny compliance as our condition to releasing Inkscape 1.00.
What do others think? What if we restructured the roadmap to enable us to attack and achieve this objective?
My personal impression is that having SVG Tiny full compliance will also be the key to enhancements to the SVG spec (e.g. more gradient types than 2 basic ones etc), which many users and developers will find useful.
Alexandre
On Thu, 2005-09-22 at 17:53 -0700, Bryce Harrington wrote:
SVG Tiny is a good idea. I think previously we identified SVG Tiny compliance as our condition to releasing Inkscape 1.00.
What do others think? What if we restructured the roadmap to enable us to attack and achieve this objective?
I don't think it's sufficient for Inkscape 1.
However, I do think it is a very good idea for our next major goal.
-mental
MenTaLguY wrote:
On Thu, 2005-09-22 at 17:53 -0700, Bryce Harrington wrote:
SVG Tiny is a good idea. I think previously we identified SVG Tiny compliance as our condition to releasing Inkscape 1.00.
What do others think? What if we restructured the roadmap to enable us to attack and achieve this objective?
I don't think it's sufficient for Inkscape 1.
However, I do think it is a very good idea for our next major goal.
-mental
You know what? Amen. (sorry, no other way to put it)
-Josh
On Thu, Sep 22, 2005 at 10:39:32PM -0400, MenTaLguY wrote:
On Thu, 2005-09-22 at 17:53 -0700, Bryce Harrington wrote:
SVG Tiny is a good idea. I think previously we identified SVG Tiny compliance as our condition to releasing Inkscape 1.00.
What do others think? What if we restructured the roadmap to enable us to attack and achieve this objective?
I don't think it's sufficient for Inkscape 1.
Why's that?
However, I do think it is a very good idea for our next major goal.
Okay, great, if we can get a few more ayes, I'll look into how to restructure the roadmap to help us do this. I suppose we'd want to just identify what features need to be implemented, and sort them in some fashion, and plan to knock out one or two per release until we get there.
Bryce
hey guys just my humble 2c about the roadmap and the priorities as i see them
- copy/paste with gimp & scribus - perspective transform - proper style implementation (stylesheets) - enhanced vector deformation commands ( envelope, smear(nudge), etc ) - animation
i really think animation should be a goal for inkscape 2.0 and interactivity design stuff for inkscape 3 not that thinking that far ahead is logical its still nice to have these as RFE's
what really needs to be done is the basics: copy/paste and more complex vector transforaitons need to be added to prove inkscape is the best illustraion package in the world ( it already is but these features are a must )
stylesheet support makes for a more grokkable use of svg ( especially for things like the desktop) id love to design an icon set based off classes and hooks that align with a stylesheet . think of the potential customisations to artwork. based of a single stylesheet ( or even a stylesheet from a single place within a document )
animation is also a very solid goal and an important one. we can use our existing set of tools to so much more of a benefit if we just included simple frame based animation and animation export . even if it were as simple as managing a svgz file that contained an array of svg files each representing a frame in the animation. then providing the ability to batch export all of those frames in sequence as a video file or juse a sequence to be converted by video encoding software.
but yeah immediate goals that done have much emphasis are perspective transform ( and vector deformers) , copy and paste. and better stylesheet support ( maybe even offlinking so we can use defs from other documents )
this is more a wishlist in order of priority than a reccomendation for the roadmap but please take them into consideration if we are reorganising it.
Cheers
Andy
On 9/23/05, Bryce Harrington <bryce@...961...> wrote:
On Thu, Sep 22, 2005 at 10:39:32PM -0400, MenTaLguY wrote:
On Thu, 2005-09-22 at 17:53 -0700, Bryce Harrington wrote:
SVG Tiny is a good idea. I think previously we identified SVG Tiny compliance as our condition to releasing Inkscape 1.00.
What do others think? What if we restructured the roadmap to enable us to attack and achieve this objective?
I don't think it's sufficient for Inkscape 1.
Why's that?
However, I do think it is a very good idea for our next major goal.
Okay, great, if we can get a few more ayes, I'll look into how to restructure the roadmap to help us do this. I suppose we'd want to just identify what features need to be implemented, and sort them in some fashion, and plan to knock out one or two per release until we get there.
Bryce
SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Andy Fitzsimon wrote:
hey guys just my humble 2c about the roadmap and the priorities as i see them
- copy/paste with gimp & scribus
- perspective transform
- proper style implementation (stylesheets)
- enhanced vector deformation commands ( envelope, smear(nudge), etc )
- animation
If user requests as expressed in the feature tracker have any relevance when setting priorities, probably SVG filters is the most duplicated request (unfortunately, the tracker does not allow precise stats for duplicates). I know this is not easy to implement, but Andy was the first listing "blue sky" features... :p
On Fri, Sep 23, 2005 at 09:26:10AM +0300, Nicu Buculei wrote:
Andy Fitzsimon wrote:
hey guys just my humble 2c about the roadmap and the priorities as i see them
- copy/paste with gimp & scribus
- perspective transform
- proper style implementation (stylesheets)
- enhanced vector deformation commands ( envelope, smear(nudge), etc )
- animation
If user requests as expressed in the feature tracker have any relevance when setting priorities, probably SVG filters is the most duplicated request (unfortunately, the tracker does not allow precise stats for duplicates). I know this is not easy to implement, but Andy was the first listing "blue sky" features... :p
Well, for the purposes of the roadmap I think it'd be better to shoot for something a bit more broadly scoped than just a list of features. That's why I like the idea of shooting for SVG Tiny compliance; it's challenging, specific, easy to remember, and covers a range of features that fokls are interested in.
Bryce
- copy/paste with gimp & scribus
well, how should that work? at least, i guess, not with the existing "copy" function. It would be more like "export as bitmap and copy that to clipboard" for gimp. a bit more tricky for scribus...
- perspective transform
cool thing, right, and maybe less hard to implement than the first :)
On Thu, 2005-09-22 at 21:46 -0700, Bryce Harrington wrote:
I don't think it's sufficient for Inkscape 1.
Why's that?
Aside from my opinion and bulia's, read our reviews in the press. The universal expectation out there for a 1.0 release includes a lot more feature and UI work.
Just to pick one example: I wouldn't dare release a 1.0 without a proper layers dialog.
-mental
On Fri, 23 Sep 2005, MenTaLguY wrote:
Date: Fri, 23 Sep 2005 09:41:03 -0400 From: MenTaLguY <mental@...3...> To: Bryce Harrington <bryce@...961...> Cc: Alan Horkan <horkana@...44...>, inkscape-devel inkscape-devel@lists.sourceforge.net Subject: Re: New Inkscape Goals? (was Re: [Inkscape-devel] update of roadmap)
On Thu, 2005-09-22 at 21:46 -0700, Bryce Harrington wrote:
I don't think it's sufficient for Inkscape 1.
Why's that?
I think Inkscape could be ready for version 1.0.0 in a very short time if that is what developers considered a priority but I can see clearly developers would like to have something with much more features before stablising and tieing things down for a version 1.0.0 which would need to be properly supported for quite a while. I previously pointed out that despite warnings about Inkscape not being stable and effectively being a beta product many people are using and depening on it for series work and it is being "sold" in a way that gives users very high expectations and may lead to disappointment.
Different people have different ideas of what 1.0 is about but it is entirely reasonable that what the developers are interested in will decide. However it is important to realise many users have been so well conditioned by software vendors they simply will not use software which has not reached version 1.0 (and a certain major software company has a reputation for taking three versions to get things right, which only adds to user scepticism).
If you postpone and delay 1.0 it will be less likely to happen, however if solid goals are set it might encourage people (possibly various linux distributors) to help with testing and stablising.
Aside from my opinion and bulia's, read our reviews in the press. The universal expectation out there for a 1.0 release includes a lot more feature and UI work.
We have managed expectations before and we can do it again. I fear some users think 1.0 should somehow be able to stand toe to toe with whatever the latest version of Adobe Illustrator will be, but I believe Inkscape has already gone beyond what many programs have called 1.0 and it could happen sooner if developers actually wanted to make it happen sooner (which I accept they dont) and if things were tied down and stabalised and less polished features were perhaps omitted.
I think it would be better to think of 1.0 in terms of quality and stability more so than specific features (something Debian stable users could tolerate between releases). Otherwise we could very easily keep suggesting more features which developers feel really must be done and 1.0 could easily be postponed indefinately.
Just to pick one example: I wouldn't dare release a 1.0 without a proper layers dialog.
You right of course but as a hypothetical counter example this is as good an example as any of a feature most other vector drawing applications have and if we were making commercial product which absolutely had to be 1.0 and get out there we could hide the layers functionality and instead have only basic groups. That would probably suck, I know the developers don't want to do that (and most users would keep using the unstable versions) but it is just an example. I am only using it as an example of how features could be left out if and when it was decided it was necessary to get 1.0 out the door.
And to change the subject back around to animation (which could get in the way of full compliance to the SVG specs). I'm pretty sure given the current complexity of Inkscape already we really would need to split into a seperate application built around the same Inkscape core to do animation. You can almost think of Inkscape as a Suite already with Inkview and Inkboard, which I think will both get a lot of attention with the next release.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
Well as someone who uses Inkscape every day (albeit for pretty simple drawings and layouts), I would have to disagree for several reasons: 1) Inkscape is already pretty stable and worthy of 1.0 status compared to virtually all pre 1.0 programs I have seen. 2) Another reason to reach 1.0 naming asap is that many people are highly reluctant to use a less than 1.0 (even 1.1) product since even many commercial products don't achieve a good status until even version 3.0 (ie Windows itself). If one of my employees was basing our work on a program with less than a 1.0 version that I was unfamiliar with, I would be pretty upset and nervous. Yet, I'm quite comfortable using Inkscape at only a 0.42 version. 3) The longer you put off 1.0, the higher the user expectations become and then if there are problems with that version, the letdown is even bigger. 4) Who cares whether it matches some other commercial product - the commercial product ought to be better! Inkscape can stand on it's own. Turn it around and let the commercial vendors worry that their $$ product exceeds the free open source product.
Actually, I don't really care what version number it has - we'll keep using it anyway since it is a great program and easy to use.
Alan Horkan wrote:
On Fri, 23 Sep 2005, MenTaLguY wrote:
Date: Fri, 23 Sep 2005 09:41:03 -0400 From: MenTaLguY <mental@...3...> To: Bryce Harrington <bryce@...961...> Cc: Alan Horkan <horkana@...44...>, inkscape-devel inkscape-devel@lists.sourceforge.net Subject: Re: New Inkscape Goals? (was Re: [Inkscape-devel] update of roadmap)
On Thu, 2005-09-22 at 21:46 -0700, Bryce Harrington wrote:
I don't think it's sufficient for Inkscape 1.
Why's that?
I think Inkscape could be ready for version 1.0.0 in a very short time if that is what developers considered a priority but I can see clearly developers would like to have something with much more features before stablising and tieing things down for a version 1.0.0 which would need to be properly supported for quite a while. I previously pointed out that despite warnings about Inkscape not being stable and effectively being a beta product many people are using and depening on it for series work and it is being "sold" in a way that gives users very high expectations and may lead to disappointment.
Different people have different ideas of what 1.0 is about but it is entirely reasonable that what the developers are interested in will decide. However it is important to realise many users have been so well conditioned by software vendors they simply will not use software which has not reached version 1.0 (and a certain major software company has a reputation for taking three versions to get things right, which only adds to user scepticism).
If you postpone and delay 1.0 it will be less likely to happen, however if solid goals are set it might encourage people (possibly various linux distributors) to help with testing and stablising.
Aside from my opinion and bulia's, read our reviews in the press. The universal expectation out there for a 1.0 release includes a lot more feature and UI work.
We have managed expectations before and we can do it again. I fear some users think 1.0 should somehow be able to stand toe to toe with whatever the latest version of Adobe Illustrator will be, but I believe Inkscape has already gone beyond what many programs have called 1.0 and it could happen sooner if developers actually wanted to make it happen sooner (which I accept they dont) and if things were tied down and stabalised and less polished features were perhaps omitted.
I think it would be better to think of 1.0 in terms of quality and stability more so than specific features (something Debian stable users could tolerate between releases). Otherwise we could very easily keep suggesting more features which developers feel really must be done and 1.0 could easily be postponed indefinately.
Just to pick one example: I wouldn't dare release a 1.0 without a proper layers dialog.
You right of course but as a hypothetical counter example this is as good an example as any of a feature most other vector drawing applications have and if we were making commercial product which absolutely had to be 1.0 and get out there we could hide the layers functionality and instead have only basic groups. That would probably suck, I know the developers don't want to do that (and most users would keep using the unstable versions) but it is just an example. I am only using it as an example of how features could be left out if and when it was decided it was necessary to get 1.0 out the door.
And to change the subject back around to animation (which could get in the way of full compliance to the SVG specs). I'm pretty sure given the current complexity of Inkscape already we really would need to split into a seperate application built around the same Inkscape core to do animation. You can almost think of Inkscape as a Suite already with Inkview and Inkboard, which I think will both get a lot of attention with the next release.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sep 23, 2005, at 6:41 AM, MenTaLguY wrote:
On Thu, 2005-09-22 at 21:46 -0700, Bryce Harrington wrote:
I don't think it's sufficient for Inkscape 1.
Why's that?
Aside from my opinion and bulia's, read our reviews in the press. The universal expectation out there for a 1.0 release includes a lot more feature and UI work.
Just to pick one example: I wouldn't dare release a 1.0 without a proper layers dialog.
Then there are some other aspects.
One of which is API's/extensions, etc.
One thing people tend to expect is that extensions/plugins for some 1.0 product would stay compatible with 1.1, 1.2, etc. all the way up until 2.0. We've got a surprisingly functional API at the moment, however people have roughed out a much better long-term API. I'd personally say a stable and robust extensions API is one of the critical things needed for a "1.0".
On Fri, Sep 23, 2005 at 11:22:52PM -0700, Jon A. Cruz wrote:
On Sep 23, 2005, at 6:41 AM, MenTaLguY wrote:
Aside from my opinion and bulia's, read our reviews in the press. The universal expectation out there for a 1.0 release includes a lot more feature and UI work.
One thing people tend to expect is that extensions/plugins for some 1.0 product would stay compatible with 1.1, 1.2, etc. all the way up until 2.0. We've got a surprisingly functional API at the moment, however people have roughed out a much better long-term API. I'd personally say a stable and robust extensions API is one of the critical things needed for a "1.0".
I think if we get caught up in "perceived expectations" we may never reach 1.00. There are many, many, many features that we can expect that someone may expect to be there. In reality, no matter how hard we try, we will most certainly violate someone's expectations. The only thing we can really control is our _own_ expectations.
Thus, I'd like to suggest we completely ignore what we think external folks may or may not expect. Ignore all the reviewers and critics and what they think should or shouldn't go into Inkscape 1.00. We're the people devoting a portion of our lives to inkscape; our opinion is what matters. What do *we* expect to be in 1.00?
I've actually been pleasantly surprised at how viable our current extension API has been. The idea of using simple stdin/stdout filter programs has proven to be more robust and extensible than even I had imagined. We've gotten an incredible amount of mileage out of it. I would not be at all ashamed to release 1.00 with no more sophisticated of an extension API than what we've got now.
If by some chance of fate we *did* suddenly come up with a better extension API immediately after doing 1.00, I'd have no problem with bumping us up to 2.00. In practice, though, I bet we'd find a way to keep our current stdin/stdout extension API in addition to whatever clever scheme we come up with; the stdin/stdout approach is just proving to be too dang handy to drop. :-)
Bryce
On Sun, 2005-09-25 at 00:53 -0700, Bryce Harrington wrote:
Thus, I'd like to suggest we completely ignore what we think external folks may or may not expect. Ignore all the reviewers and critics and what they think should or shouldn't go into Inkscape 1.00.
The reason I mention the reviews is that the critics have been basically echoing my own opinion on the matter.
Off the top of my head (I'm sure I'm forgetting some things), some required things for 1.0 are:
* Full support for SVG Basic, excluding perhaps animation, interactivity/scripting and SVG fonts
* integrated PDF/PS/EPS/AI export/import (probably means hauling a subset of ghostscript in-tree, like Scribus has done)
* a proper layers dialog
* easily editable color swatches
* "paint" swatches (e.g. gradient, etc, not just solid colors)
* print-via-PDF (so we can do alpha etc directly)
* support for SVG profiles -- i.e. tracking the current set of SVG features in use, and being able to do things like (on request) force an SVG 1.2 Full document down to SVG 1.1 Tiny
bulia probably has some more UI-related must-dos.
If by some chance of fate we *did* suddenly come up with a better extension API immediately after doing 1.00, I'd have no problem with bumping us up to 2.00. In practice, though, I bet we'd find a way to keep our current stdin/stdout extension API in addition to whatever clever scheme we come up with; the stdin/stdout approach is just proving to be too dang handy to drop. :-)
Yeah.
-mental
On Sun, 2005-09-25 at 12:38 -0400, MenTaLguY wrote:
On Sun, 2005-09-25 at 00:53 -0700, Bryce Harrington wrote:
Thus, I'd like to suggest we completely ignore what we think external folks may or may not expect. Ignore all the reviewers and critics and what they think should or shouldn't go into Inkscape 1.00.
The reason I mention the reviews is that the critics have been basically echoing my own opinion on the matter.
Off the top of my head (I'm sure I'm forgetting some things), some required things for 1.0 are:
Full support for SVG Basic, excluding perhaps animation, interactivity/scripting and SVG fonts
integrated PDF/PS/EPS/AI export/import (probably means hauling a
subset of ghostscript in-tree, like Scribus has done)
a proper layers dialog
easily editable color swatches
"paint" swatches (e.g. gradient, etc, not just solid colors)
print-via-PDF (so we can do alpha etc directly)
support for SVG profiles -- i.e. tracking the current set of SVG features in use, and being able to do things like (on request) force an SVG 1.2 Full document down to SVG 1.1 Tiny
bulia probably has some more UI-related must-dos.
Text editing redo is top priority on this list for me.
If by some chance of fate we *did* suddenly come up with a better extension API immediately after doing 1.00, I'd have no problem with bumping us up to 2.00. In practice, though, I bet we'd find a way to keep our current stdin/stdout extension API in addition to whatever clever scheme we come up with; the stdin/stdout approach is just proving to be too dang handy to drop. :-)
Just about the list I'd suggest :) Also: find some CMYK-hack would be great for as long as SVG doesn't support it natively.
However I'm still buzzing around with joy because of the new curve editing. This has been such a great advancement!
David
On Sun, Sep 25, 2005 at 12:38:44PM -0400, MenTaLguY wrote:
Off the top of my head (I'm sure I'm forgetting some things), some required things for 1.0 are:
Alan started a section at the end of the Roadmap for listing our 1.0 goals. I'm adding your comments there.
- Full support for SVG Basic, excluding perhaps animation, interactivity/scripting and SVG fonts
How would you feel if we set the goal to be SVG Tiny rather than SVG Basic? SVG Tiny requires us to implement Animation, foreignObject extensibility, switch, hyperlinking, and so forth, so for us is going to be plenty ambitious, but achievable.
SVG Basic has all that, plus viewports, color profiles, masking, more advanced font stuff, scripting, and filters. Quite a bit to bite off... I'm worried we could get bogged down.
I would advocate that we set SVG Basic as our Inkscape 2.0 goal and SVG Tiny as the 1.0 goal. That gives us two really tangible and useful objectives to organize efforts towards.
- integrated PDF/PS/EPS/AI export/import (probably means hauling a
subset of ghostscript in-tree, like Scribus has done)
Yes, this is one of the areas where I think even if we didn't want to do it, we'd be strung up if we released 1.00 without it. ;-)
I think the ideal solution would be to find a way to share this functionality with scribus in some fashion or other.
- a proper layers dialog
This has been on the todo list for a while; is there a way we could break this work up into more digestible chunks?
easily editable color swatches
"paint" swatches (e.g. gradient, etc, not just solid colors)
print-via-PDF (so we can do alpha etc directly)
I've added the above. I know we're close on the editable swatches, not sure on paint swatches.
- support for SVG profiles -- i.e. tracking the current set of SVG features in use, and being able to do things like (on request) force an SVG 1.2 Full document down to SVG 1.1 Tiny
This sort of sounds like an extension sort of thing...?
Thanks for the list.
Bryce
On 9/25/05, Bryce Harrington <bryce@...961...> wrote:
- a proper layers dialog
This has been on the todo list for a while; is there a way we could break this work up into more digestible chunks?
Btw, are we talking about implementing it in gtk2 or in gtkmm2? What priority would gtmmfication have in the new roadmap? Gtkmmfication looks pretty much like the dark side of the moo^H^H^development process now.
Alexandre
On Sun, Sep 25, 2005 at 11:34:41PM +0400, Alexandre Prokoudine wrote:
On 9/25/05, Bryce Harrington <bryce@...961...> wrote:
- a proper layers dialog
This has been on the todo list for a while; is there a way we could break this work up into more digestible chunks?
Btw, are we talking about implementing it in gtk2 or in gtkmm2?
I would presume it would be worth doing in gtkmm but as long as users are happy with it, it probably doesn't matter.
What priority would gtmmfication have in the new roadmap? Gtkmmfication looks pretty much like the dark side of the moo^H^H^development process now.
I don't know. I'd like to see it have a place, but it's completely orthogonal to all the objectives folks have mentioned, and certainly it has no bearing on SVG Tiny/Basic compliance. I've moved it to the end for now; open to ideas on where it ought to go. Possibly it can be done just on the side.
Bryce
On Sun, 2005-09-25 at 12:45 -0700, Bryce Harrington wrote:
I would presume it would be worth doing in gtkmm but as long as users are happy with it, it probably doesn't matter.
Not doing it in gtkmm would be insane, IMO.
-mental
On Mon, Sep 26, 2005 at 09:36:52AM -0400, MenTaLguY wrote:
On Sun, 2005-09-25 at 12:45 -0700, Bryce Harrington wrote:
I would presume it would be worth doing in gtkmm but as long as users are happy with it, it probably doesn't matter.
Not doing it in gtkmm would be insane, IMO.
-mental
I looked into this a bit more yesterday. The gtkmm treeview control stuff is nice. There's some examples there too. It'd be a pretty good sized project to implement this, but it looks like the basic stuff is documented pretty well.
The way the treeview control is designed, it uses a "model" that represents the data you're trying to present in the tree.
We've talked about using treeview controls for the layer dialog, xml editor, extensions manager, preferences, and so forth. Do these things all have the same kind of underlying data structure? Is it going to be feasible to create an abstract model class for all of these?
Bryce
On Mon, 2005-09-26 at 11:25 -0700, Bryce Harrington wrote:
We've talked about using treeview controls for the layer dialog, xml editor, extensions manager, preferences, and so forth. Do these things all have the same kind of underlying data structure? Is it going to be feasible to create an abstract model class for all of these?
Let's do a few separately and see if there's something reasonable we can factor out of them.
There is, incidentally, an Attic'd treeview model class for XML nodes that I never finished. There are unfortunately some "black magic" aspects to bootstrapping a custom treeview model class, so it might be best to use that as a starting point if we get into custom treeview model classes. I'll see if I can dig it up again.
-mental
On Mon, 2005-09-26 at 11:25 -0700, Bryce Harrington wrote:
The way the treeview control is designed, it uses a "model" that represents the data you're trying to present in the tree.
We've talked about using treeview controls for the layer dialog, xml editor, extensions manager, preferences, and so forth. Do these things all have the same kind of underlying data structure? Is it going to be feasible to create an abstract model class for all of these?
I've been playing with this for the preferences dialogs, and I don't think anything is needed beyond the abstraction that GTKmm already provides. The one think that I haven't figured out how to do yet is to make a column a SPImage. I don't think that will be too hard once I dig into it though.
--Ted
On Tue, 2005-09-27 at 00:01 -0700, Ted Gould wrote:
On Mon, 2005-09-26 at 11:25 -0700, Bryce Harrington wrote: I've been playing with this for the preferences dialogs, and I don't think anything is needed beyond the abstraction that GTKmm already provides. The one think that I haven't figured out how to do yet is to make a column a SPImage. I don't think that will be too hard once I dig into it though.
You'd need to write a custom CellRenderer, which is not a Widget. Sort of a Widget-lite.
-mental
On Sep 27, 2005, at 10:10 PM, MenTaLguY wrote:
On Tue, 2005-09-27 at 00:01 -0700, Ted Gould wrote:
On Mon, 2005-09-26 at 11:25 -0700, Bryce Harrington wrote: I've been playing with this for the preferences dialogs, and I don't think anything is needed beyond the abstraction that GTKmm already provides. The one think that I haven't figured out how to do yet is to make a column a SPImage. I don't think that will be too hard once I dig into it though.
You'd need to write a custom CellRenderer, which is not a Widget. Sort of a Widget-lite.
When you look at that, try to keep swatches in the back of your mind.
Inkscape::UI::Previewable is intended to be a generic, placeable preview. At the moment it's only wrapping the colors in the color swatches dialog. However, it should be usable for many things, including layers. The need to make a column an SPImage could be one place to use this interface.
So... that could mean the interface itself needs to be tuned. Or perhaps just that we create some generic wrappers.
The trick here is to come up with some nice modular APIs so that we can abstract certain behavior.
The base concept goes along with that involved in not having a view class derive from Gtk::Window itself.
And plays a bit in parallel with http://wiki.inkscape.org/cgi-bin/ wiki.pl?DialogReplacement
On Sep 25, 2005, at 12:12 PM, Bryce Harrington wrote:
On Sun, Sep 25, 2005 at 12:38:44PM -0400, MenTaLguY wrote:
- support for SVG profiles -- i.e. tracking the current set of SVG features in use, and being able to do things like (on request) force an SVG 1.2 Full document down to SVG 1.1 Tiny
This sort of sounds like an extension sort of thing...?
Not really.
Though much of adding individual profiles could be done as extensions, some basic infrastructure needs to go in to allow that.
I'd view it almost like our translations. We need to get to the point to implement profiles correctly. Once we have things set to do two different profiles, it will be very easy for other people to come in and do n profiles very quickly.
Quoting "Jon A. Cruz" <jon@...18...>:
I'd view it almost like our translations. We need to get to the point to implement profiles correctly. Once we have things set to do two different profiles, it will be very easy for other people
to
come in and do n profiles very quickly.
Yes, exactly.
It wouldn't kill us to prototype it as an extension, but it won't be really useful to end-users without better integration.
The necessary support breaks down into:
A. determining the current document profile (e.g. for display in document preferences -- this should always be determined at load-time, never saved in the file)
B. restricting the document to a particular profile
1. disabling tools/features which aren't possible in the current document's selected profile
2. taking an existing document and stripping it down to meet a more restrictive profile (e.g. if the current profile is changed to a more restrictive one in document preferences)
All of these operations should probably be controlled by some sort of selection widget in document preferences.
There is an interesting twist -- more than one "minimal" profile can apply to a simple document at a time. I'm not sure how we should deal with that reality in the UI.
Someone want to capture this thread in an RFE? I'll not have time tonight...
-mental
On 9/26/05, mental@...3... <mental@...3...> wrote:
- disabling tools/features which aren't possible in the current document's selected profile
No, please never disable any tools. This will be a usability disaster. Automatically downgrade, warn the user on save, but never disable anything.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Sep 25, 2005, at 9:38 AM, MenTaLguY wrote:
- support for SVG profiles -- i.e. tracking the current set of SVG features in use, and being able to do things like (on request) force an SVG 1.2 Full document down to SVG 1.1 Tiny
I'd like to second that although this one might seem less important from a development point of view, it is likely to be among the 'killer' features from the end-user standpoints. Once it goes in, people will start saying "how did I ever get along without this", etc.
Much of my opinion on this comes from having worked in the multimedia field, and include workflow insight from having been in charge of coordinating artists with engineering in a few companies.
On 9/25/05, MenTaLguY <mental@...3...> wrote:
- easily editable color swatches
...in a palette docked at bottom of document window.
As well as: perspective envelope, variable-width and brushed strokes, blends, clip/mask tool, blur. That's the minimum.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Mon, Sep 26, 2005 at 04:41:26AM -0300, bulia byak wrote:
On 9/25/05, MenTaLguY <mental@...3...> wrote:
- easily editable color swatches
...in a palette docked at bottom of document window.
As well as: perspective envelope, variable-width and brushed strokes, blends, clip/mask tool, blur. That's the minimum.
I've added these. Can you give some additional details about what would need to be done for these? Possibly some of our new devs might be interested in working on one of these.
http://wiki.inkscape.org/cgi-bin/wiki.pl?Roadmap
Bryce
bulia byak wrote:
As well as: perspective envelope, variable-width and brushed strokes, blends, clip/mask tool, blur. That's the minimum.
I'm interested in working on perspective envelope and blends. They both fit the "path data manipulation" theme in which I am interested and with which I am somewhat familiar. They don't seem to me to be the really important things we need to push ourselves to get done, like SVGTiny compliance or huge and complicated codebase refactoring. But they are on the 1.0 wish list for at least one developer and numerous users.
I have done a minimal amount of research into both subjects while working on effects. I've got one completed blend effect (interp.py) and one completed envelope type effect (summer's night). Envelope objects have been scoped out on the wiki http://wiki.inkscape.org/cgi-bin/wiki.pl?PerspectiveObject.
I'm afraid, however, that I don't know enough to be successful enough at the outset to keep motivated enough to actually finish either of these projects, because they seem to be rather large projects for my competency level and are code creation rather than tweaking what already exists.
Would there be significant interest in gathering a few small teams of people to work on these features? Teams could consist of a couple of inexperienced coders like myself and one mentor who can assist in subdividing and prioritizing the task, and help out if we get stuck.
Aaron Spike
On 9/28/05, aaron@...749... <aaron@...749...> wrote:
I'm interested in working on perspective envelope and blends. They both fit the "path data manipulation" theme in which I am interested and with which I am somewhat familiar. They don't seem to me to be the really important things we need to push ourselves to get done, like SVGTiny compliance or huge and complicated codebase refactoring. But they are on the 1.0 wish list for at least one developer and numerous users.
From a vector artist viewpoint, they're much more important than Tiny
compliance, let alont codebase refactoring. With blends, you're no longer limited to gradients for doing things like shades, glows, complex-shaped color transitions etc. With perspective and curvilinear envelopes, we'll get into 3D and finally stop being shamefully behind Microsoft's "WordArt" :)
I have done a minimal amount of research into both subjects while working on effects. I've got one completed blend effect (interp.py) and one completed envelope type effect (summer's night). Envelope objects have been scoped out on the wiki http://wiki.inkscape.org/cgi-bin/wiki.pl?PerspectiveObject.
I wrote that. I'm still not happy that with this approach, we'll only be able to envelope paths (and not e.g. texts or rects without first converting to path), but I see no easy way to remove this limitation. Other than that, it should work fine and is (I think) not too difficult to implement. The problems with transforming/nodeediting objects within an envelope are there, but hey, for example Xara does not let you get into an envelope at all - you can only edit the objects inside by removing the envlope and then reapplying it. So I think this will work out nicely in the end.
For blends, the implementation will be similar: a <g> with two or more base paths as well as the phantom intermediate paths that are real from the SVG viewpoint but are not editable or even selectable from Inkscape viewpoint. These phantom paths are regenerated automatically, as each one remembers its two base paths and the interpolation parameter.
I'm afraid, however, that I don't know enough to be successful enough at the outset to keep motivated enough to actually finish either of these projects, because they seem to be rather large projects for my competency level and are code creation rather than tweaking what already exists.
This should not really be too difficult. I'll help you in any way I can. You can start with small steps and proceed gradually. Since your code will be limited to your own SPObject types, you won't risk breaking anything else :)
Would there be significant interest in gathering a few small teams of people to work on these features? Teams could consist of a couple of inexperienced coders like myself and one mentor who can assist in subdividing and prioritizing the task, and help out if we get stuck.
Yeah, I certainly volunteer :)
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 9/28/05, aaron@...749... <aaron@...749...> wrote:
I have done a minimal amount of research into both subjects while working on effects. I've got one completed blend effect (interp.py) and one completed envelope type effect (summer's night). Envelope objects have been scoped out on the wiki http://wiki.inkscape.org/cgi-bin/wiki.pl?PerspectiveObject.
I wrote that. I'm still not happy that with this approach, we'll only be able to envelope paths (and not e.g. texts or rects without first converting to path), but I see no easy way to remove this limitation. Other than that, it should work fine and is (I think) not too difficult to implement. The problems with transforming/nodeediting objects within an envelope are there, but hey, for example Xara does not let you get into an envelope at all - you can only edit the objects inside by removing the envlope and then reapplying it. So I think this will work out nicely in the end.
For blends, the implementation will be similar: a <g> with two or more base paths as well as the phantom intermediate paths that are real from the SVG viewpoint but are not editable or even selectable from Inkscape viewpoint. These phantom paths are regenerated automatically, as each one remembers its two base paths and the interpolation parameter.
I read the Perspective Object wiki page a long time ago and had no clue whatsoever what it meant. But lately I've been thinking about how envelopes would be accomplished and trying to relate the task to what I know about dynamic offsets and stars. When I read through the wiki page a second time, it makes perfect sense. This is exactly how I would envision it working.
The problem with text is one of those places where we are actually running up against the limits of what the SVG spec will allow us to do. I think you would agree that a working implementation will be majorly useful even if it has some blemishes.
I'm afraid, however, that I don't know enough to be successful enough at the outset to keep motivated enough to actually finish either of these projects, because they seem to be rather large projects for my competency level and are code creation rather than tweaking what already exists.
This should not really be too difficult. I'll help you in any way I can. You can start with small steps and proceed gradually. Since your code will be limited to your own SPObject types, you won't risk breaking anything else :)
Would there be significant interest in gathering a few small teams of people to work on these features? Teams could consist of a couple of inexperienced coders like myself and one mentor who can assist in subdividing and prioritizing the task, and help out if we get stuck.
Yeah, I certainly volunteer :)
Great. Where do we start? I guess we must first agree on markup and make inkscape render it properly. I didn't find http://wiki.inkscape.org/cgi-bin/wiki.pl?AddSPObject terribly enlightening at first glance. If you can help me sort out a progression of manageable tasks, perhaps we can pick up additional help along the way. Shall we start a todo list on the wiki?
Aaron Spike
Jon A. Cruz stimò:
One of which is API's/extensions, etc.
One thing people tend to expect is that extensions/plugins for some 1.0 product would stay compatible with 1.1, 1.2, etc. all the way up until 2.0. We've got a surprisingly functional API at the moment, however people have roughed out a much better long-term API. I'd personally say a stable and robust extensions API is one of the critical things needed for a "1.0".
I think that the best solution to this is to number the plugins API separately from the application version.
So, while in a stable branch (say 1.0.x, kernel old-style) the plugin API is kept the same, in a development branch (1.1.x) the API version is costantly incremented after each change.
On Fri, Sep 23, 2005 at 09:41:03AM -0400, MenTaLguY wrote:
On Thu, 2005-09-22 at 21:46 -0700, Bryce Harrington wrote:
[SVG Tiny support] I don't think it's sufficient for Inkscape 1.
Why's that?
Aside from my opinion and bulia's, read our reviews in the press. The universal expectation out there for a 1.0 release includes a lot more feature and UI work.
Actually for the purposes of deciding what goes into Inkscape 1.00, I would not put any weight at all into what the press thinks. They aren't putting their blood/sweat/tears into doing the work.
The opinion of you and Bulia is what matters here. You two have put in huge amounts of energy into the project so what you think should go into 1.00 counts for a lot.
Just to pick one example: I wouldn't dare release a 1.0 without a proper layers dialog.
*Nod* Judging from the number of RFE/Bug reports we've gotten related to this, it's clear that this is an extremely needed feature. This will be a great feature to get implemented.
From what I have seen of the SVG Tiny spec, it is not something that is
going to get implemented overnight. It requires a number of features that either aren't implemented or are being worked on but won't be implemented in the near term. I assume there is going to be _plenty_ of time to get a lot of other needed features (like the layer dialog) implemented. However, it sounds like there is clearly a list of features _in addition_ to SVG Tiny support, that the Inkscape development community would expect to be implemented prior to a 1.00 release.
It sounds like the question then becomes, "In addition to SVG Tiny compliance, what other features MUST be implemented prior to a 1.00 release?"
Perhaps it would be wisest to assemble a list of what we expect, and then aggressively triage the list so we can get 1.00 out without getting bogged down in unnecessary details too much.
Bryce
participants (17)
-
unknown＠example.com -
aaron＠...749... -
Adib Taraben -
Alan Horkan -
Alexandre Prokoudine -
Andy Fitzsimon -
Bryce Harrington -
bulia byak -
Daniel Stiefelmaier -
David Christian Berg -
Emanuele Aina -
John Taber -
Jon A. Cruz -
Joshua A. Andler -
MenTaLguY -
Nicu Buculei -
Ted Gould