Xara and Inkscape comparison on Linux Action Show
FYI: I'm in the middle of listening, but there is a comparison of Xara and Inkscape. http://www.linuxactionshow.com/?p=77
-Josh
On Mon, Jan 22, 2007 at 08:34:27AM -0700, Joshua A. Andler wrote:
FYI: I'm in the middle of listening, but there is a comparison of Xara and Inkscape. http://www.linuxactionshow.com/?p=77
Here's a direct link to the mp3 of it:
http://www.linuxactionshow.com/episodes/LinuxActionShowEP031.mp3
Offset is about 33 minutes in, where they start talking about them.
Some of the points the reviewers have:
* They like the name "Xara Xtreme" better than "Xara LX", but they like the name "Inkscape" all the more - "it just drops off the tongue, it's beautiful"
* File format support is critically important. "In this case Inkscape takes the cake by a pretty wide margin." 20-some formats, including SVG.
* Xara easier to pick up and run with from a new user perspective. Applying transparent gradients can be done entirely on-screen with click and drag. Same for adding shadows, etc.
* Both have good rendering, but felt Xara rendering output looked slightly better.
* Speed of Xara is where it really shined - it's very fast. Can make lots and lots of layers, transparencies, etc. "Smooth as silk" "Same sort of project on Inkscape lags a bit."
* Inkscape has a lot more effects
The reviewer felt the speed and ease of picking it up gave Xara an edge, unless you're a professional graphics guy.
Bryce
On Mon, 2007-01-22 at 14:11 -0800, Bryce Harrington wrote:
On Mon, Jan 22, 2007 at 08:34:27AM -0700, Joshua A. Andler wrote:
FYI: I'm in the middle of listening, but there is a comparison of Xara and Inkscape. http://www.linuxactionshow.com/?p=77
Here's a direct link to the mp3 of it:
http://www.linuxactionshow.com/episodes/LinuxActionShowEP031.mp3Offset is about 33 minutes in, where they start talking about them.
Some of the points the reviewers have:
They like the name "Xara Xtreme" better than "Xara LX", but they like the name "Inkscape" all the more - "it just drops off the tongue, it's beautiful"
File format support is critically important. "In this case Inkscape takes the cake by a pretty wide margin." 20-some formats, including SVG.
Xara easier to pick up and run with from a new user perspective. Applying transparent gradients can be done entirely on-screen with click and drag. Same for adding shadows, etc.
Both have good rendering, but felt Xara rendering output looked slightly better.
Speed of Xara is where it really shined - it's very fast. Can make lots and lots of layers, transparencies, etc. "Smooth as silk" "Same sort of project on Inkscape lags a bit."
Inkscape has a lot more effects
The reviewer felt the speed and ease of picking it up gave Xara an edge, unless you're a professional graphics guy.
Bryce
What about the community aspect of the projects? Did you all see the article about how Xara dev. has dropped off and people are not happy that they aren't committing patches or aren't that helpful to possible community members?
http://applications.linux.com/article.pl?sid=06/12/19/2032224&tid=39
Jon
On Mon, Jan 22, 2007 at 02:38:22PM -0800, Jon Phillips wrote:
On Mon, 2007-01-22 at 14:11 -0800, Bryce Harrington wrote:
The reviewer felt the speed and ease of picking it up gave Xara an edge, unless you're a professional graphics guy.
What about the community aspect of the projects? Did you all see the article about how Xara dev. has dropped off and people are not happy that they aren't committing patches or aren't that helpful to possible community members?
http://applications.linux.com/article.pl?sid=06/12/19/2032224&tid=39
Yes, this is a hidden strength of Inkscape. It's also amazing how deeply we've penetrated the Open Source community. Being 100% open source down to the renderer has helped us here, as has our goal of working closely with other community projects.
But this presents a question worth discussing:
"What should Inkscape's next set of goals and objectives be?"
In the period from 0.44 to 0.45 it feels like we've achieved a lot of key goals we'd set out for ourselves from the start of the project. We are seeing many 3rd-party extensions created for Inkscape. Distros include Inkscape as a vital component. We've got ports to all major computing platforms, and to a heap-load of languages.
Certainly, there's still much left to be done and many features to go before we fully support the SVG specification. We also know of a number of key features (Cairoification, PDF, DOM-based scripting) that are still high priorities on our todo list. But I think now would be a good time to get our RoadMap reorganized and into proper shape, to allow us to better focus on the specific objectives that will enable us to meet our own goals. A common risk of community-oriented projects like ours is loss of focus; while I think we've done well at staying on track, it couldn't hurt to re-evaluate our existing goals and identify new ones to adopt.
What do you think of these as goals?
* SVG editing (compliant and efficient) * Professional graphic art drawing (powerful and beautiful) * Technical drawing (flexible and reliable) * Amateur artist drawing (fun and easy) * Inspires community participation in FLOSS
I don't think any of these mark a serious shift from the directions we've been on already, but it helps to spell them out explicitly. Anything else missing?
As far as near-term objectives, I don't see a reason to change our objectives necessarily, but it could help to itemize them a bit more clearly. Some thoughts (ordered by importance, not milestone):
1. SVG Tiny Support: This has been our ultimate objective for a while now, and I think it should remain a primary objective. With filter support we're now a nice step closer.
2. PDF Import/Export: We made a fairly good shot at this for 0.45 but ultimately missed the mark. I bet we could nail it on a second shot.
3. Fonts: While we've considered font support to be a "done" objective, based on the number of bug reports, clearly this needs a lot more focus than we've given it.
4. Codebase refactoring and documentation: With as many contributions as we've received, it's no surprise things have gotten cluttery, but for future maintainability it would be beneficial to spend a focused amount of time finishing various refactoring projects, excising old code, documenting stuff, and simplifying our build process.
5. Extension/DOM/scripting architecture: We have a lot of the necessary bits in place, they just need muscle to get them from the 70% mark up towards the 90% mark. My feeling is that this is extremely important - if done extremely well, this could enable a LOT more people to help us meet a much more aggressive set of goals.
6. Performance: This is a key area where we compare poorly against with Xara.
7. Cairoification: Big project, but still important. We need a cairo canvas layer before we can start this. There's a few options out there to consider.
More thoughts?
Bryce
Bryce Harrington wrote:
On Mon, Jan 22, 2007 at 02:38:22PM -0800, Jon Phillips wrote:
On Mon, 2007-01-22 at 14:11 -0800, Bryce Harrington wrote:
The reviewer felt the speed and ease of picking it up gave Xara an edge, unless you're a professional graphics guy.
What about the community aspect of the projects? Did you all see the article about how Xara dev. has dropped off and people are not happy that they aren't committing patches or aren't that helpful to possible community members?
http://applications.linux.com/article.pl?sid=06/12/19/2032224&tid=39
Yes, this is a hidden strength of Inkscape. It's also amazing how deeply we've penetrated the Open Source community. Being 100% open source down to the renderer has helped us here, as has our goal of working closely with other community projects.
But this presents a question worth discussing:
"What should Inkscape's next set of goals and objectives be?"
-----SNIP-----
More thoughts?
2geom integration. It seems to me that 2geom will open a lot of doors for potential new features and editing abilities (not to mention bug fixes for things that currently aren't optimal such as the boolean ops). I personally think this should be be added to the roadmap at this point as well as a discussion on how to go about achieving this.
With this refactoring/integration, it's also a good time for us to really reorganize code and do some janitorial work. It also presents an optimal time to look into what will be necessary for cairofication.
-Josh
I concur with this:
"2geom integration. It seems to me that 2geom will open a lot of doors for potential new features and editing abilities (not to mention bug fixes for things that currently aren't optimal such as the boolean ops). I personally think this should be be added to the roadmap at this point as well as a discussion on how to go about achieving this.
With this refactoring/integration, it's also a good time for us to really reorganize code and do some janitorial work. It also presents an optimal time to look into what will be necessary for cairofication."
On 1/22/07, Joshua A. Andler <joshua@...533...> wrote:
With this refactoring/integration, it's also a good time for us to really reorganize code and do some janitorial work. It also presents an optimal time to look into what will be necessary for cairofication.
I read complaints about cairo from sK1 people - after switching to cairo display they claim it's not too fast (even with glitz) and breaks down on paths with 1000+ nodes. So perhaps we should not hurry with cairofication.
bulia byak wrote:
On 1/22/07, Joshua A. Andler <joshua@...533...> wrote:
With this refactoring/integration, it's also a good time for us to really reorganize code and do some janitorial work. It also presents an optimal time to look into what will be necessary for cairofication.
I read complaints about cairo from sK1 people - after switching to cairo display they claim it's not too fast (even with glitz) and breaks down on paths with 1000+ nodes. So perhaps we should not hurry with cairofication.
No one will disagree about Cairo's current speed. If we are doing other refactoring though, it wouldn't hurt for us to look into what needs to be done for an eventual renderer replacement. Do we really want to solely maintain a renderer forever when we can get other improvements for free with a shared library?
I know that the main goal of the current dev cycle of Cairo is performance improvement (last time I checked there was major work going on for tessellation). Additionally, given that our renderer is faster, perhaps our devs could help improve the speed of Cairo (as we're pitching in for PDF improvement).
I'm not advocating a switch anytime soon, I'm just thinking it would smart to develop a plan at the time other things are being refactored. This way if the Cairo guys figure out some super-speed voodoo and we really want to switch, it will be that much easier (and potentially faster).
-Josh
On Mon, Jan 22, 2007 at 07:07:10PM -0700, Joshua A. Andler wrote:
No one will disagree about Cairo's current speed.
Although, it'd help to have some tangible benchmarks to go by. But in general I don't think there's disagreement on this point.
If we are doing other refactoring though, it wouldn't hurt for us to look into what needs to be done for an eventual renderer replacement. Do we really want to solely maintain a renderer forever when we can get other improvements for free with a shared library?
As I understand things, Cairo in and of itself isn't enough - it just renders stuff. What we need in addition to Cairo is a Gtk canvas layer, that provides an interactive way of interfacing to the renderer.
Presently there are a couple Gtk+ Cairo canvas libs - Papyrus and GooCanvas. I've only briefly looked at them and neither seems particularly mature. I couldn't say whether they are developing in a direction that will eventually support what we need, nor is it clear which of the two would be the better option to adopt. But I think it would be worthwhile for someone to give them a deeper evaluation.
I know that the main goal of the current dev cycle of Cairo is performance improvement (last time I checked there was major work going on for tessellation). Additionally, given that our renderer is faster, perhaps our devs could help improve the speed of Cairo (as we're pitching in for PDF improvement).
Fred did much of the coding for our renderer, and it's been a long time since we've seen him. Mental is active on the Cairo list already. njh always was focused more on the algorithmic aspects, that he's now encapsulating into 2geom. pjrm has been busy with family stuff. So, we're currently a bit shy on active renderer-level expertise ourselves.
I'm not advocating a switch anytime soon, I'm just thinking it would smart to develop a plan at the time other things are being refactored. This way if the Cairo guys figure out some super-speed voodoo and we really want to switch, it will be that much easier (and potentially faster).
Agreed.
Well like Mental says, the refactoring work is going to be a major prerequisite; without it, any sort of architectural change like this is going to be much more painful than it'd be with it.
Aside from that, I think a canvas analysis may be the next major step. Perhaps this could even be done in parallel. Basically, we'd need to decide if we want to:
a) Go with goocanvas or papyrus or some other 3rd party lib b) Adapt our existing canvas layer to work with Cairo c) Create a new canvas layer d) Some combination of the above e) Stick with what we have
However, it's not likely we'll be able to get all the refactoring work done quickly, so it may be premature to make canvas decisions right yet.
Bryce
On 1/22/07, Bryce Harrington <bryce@...961...> wrote:
As I understand things, Cairo in and of itself isn't enough - it just renders stuff. What we need in addition to Cairo is a Gtk canvas layer, that provides an interactive way of interfacing to the renderer.
What's wrong with sp-canvas? It's well tested and is being increasingly optimized, and its overhead is minimal anyway compared to the renderer. Yet replacing the canvas will be much more difficult than the renderer, because the canvas and SPCanvasItems are the foundation of a lot of our codebase. So I'm not in favor of replacing it, unless some very good reasons are given. We just need a much faster way to convert shapes into pixels, but from that point on we can handle it just fine.
On Mon, Jan 22, 2007 at 10:58:21PM -0400, bulia byak wrote:
On 1/22/07, Bryce Harrington <bryce@...961...> wrote:
As I understand things, Cairo in and of itself isn't enough - it just renders stuff. What we need in addition to Cairo is a Gtk canvas layer, that provides an interactive way of interfacing to the renderer.
What's wrong with sp-canvas? It's well tested and is being increasingly optimized, and its overhead is minimal anyway compared to the renderer. Yet replacing the canvas will be much more difficult than the renderer, because the canvas and SPCanvasItems are the foundation of a lot of our codebase. So I'm not in favor of replacing it, unless some very good reasons are given. We just need a much faster way to convert shapes into pixels, but from that point on we can handle it just fine.
You removed too much of my original email. One of the options (e) is indeed to retain our existing canvas and update it to work with Cairo.
Aside from that, I think a canvas analysis may be the next major step. Perhaps this could even be done in parallel. Basically, we'd need to decide if we want to:
a) Go with goocanvas or papyrus or some other 3rd party lib b) Adapt our existing canvas layer to work with Cairo c) Create a new canvas layer d) Some combination of the above e) Stick with what we have
If we do stick with what we have, another option to consider is breaking it out into a stand-alone library atop Cairo, that others can use independently of Inkscape. We've had many RFE's opened requesting this.
Bryce
On Mon, 2007-01-22 at 19:13 -0800, Bryce Harrington wrote:
On Mon, Jan 22, 2007 at 10:58:21PM -0400, bulia byak wrote:
On 1/22/07, Bryce Harrington <bryce@...961...> wrote:
As I understand things, Cairo in and of itself isn't enough - it just renders stuff. What we need in addition to Cairo is a Gtk canvas layer, that provides an interactive way of interfacing to the renderer.
What's wrong with sp-canvas? It's well tested and is being increasingly optimized, and its overhead is minimal anyway compared to the renderer. Yet replacing the canvas will be much more difficult than the renderer, because the canvas and SPCanvasItems are the foundation of a lot of our codebase. So I'm not in favor of replacing it, unless some very good reasons are given. We just need a much faster way to convert shapes into pixels, but from that point on we can handle it just fine.
You removed too much of my original email. One of the options (e) is indeed to retain our existing canvas and update it to work with Cairo.
Aside from that, I think a canvas analysis may be the next major step. Perhaps this could even be done in parallel. Basically, we'd need to decide if we want to:
a) Go with goocanvas or papyrus or some other 3rd party lib b) Adapt our existing canvas layer to work with Cairo c) Create a new canvas layer d) Some combination of the above e) Stick with what we have
If we do stick with what we have, another option to consider is breaking it out into a stand-alone library atop Cairo, that others can use independently of Inkscape. We've had many RFE's opened requesting this.
Bryce
I think this is a wise strategy that will win us even more points in the larger community and will help out inkcore concept. Who is the right person to help outline this strategy and what is next IYO bryce?
Jon
On Mon, Jan 22, 2007 at 08:20:48PM -0800, Jon Phillips wrote:
On Mon, 2007-01-22 at 19:13 -0800, Bryce Harrington wrote:
On Mon, Jan 22, 2007 at 10:58:21PM -0400, bulia byak wrote:
On 1/22/07, Bryce Harrington <bryce@...961...> wrote:
Aside from that, I think a canvas analysis may be the next major step. Perhaps this could even be done in parallel. Basically, we'd need to decide if we want to:
a) Go with goocanvas or papyrus or some other 3rd party lib b) Adapt our existing canvas layer to work with Cairo c) Create a new canvas layer d) Some combination of the above e) Stick with what we have
If we do stick with what we have, another option to consider is breaking it out into a stand-alone library atop Cairo, that others can use independently of Inkscape. We've had many RFE's opened requesting this.
Bryce
I think this is a wise strategy that will win us even more points in the larger community and will help out inkcore concept. Who is the right person to help outline this strategy and what is next IYO bryce?
Jon, one thing you could do is to touch base with the goocanvas and/or papyrus developers and ask if they've considered Inkscape's canvas and if they'd had a chance to look at Inkscape's sp_canvas.
Bryce
On Tue, 2007-01-23 at 11:35 -0800, Bryce Harrington wrote:
On Mon, Jan 22, 2007 at 08:20:48PM -0800, Jon Phillips wrote:
On Mon, 2007-01-22 at 19:13 -0800, Bryce Harrington wrote:
On Mon, Jan 22, 2007 at 10:58:21PM -0400, bulia byak wrote:
On 1/22/07, Bryce Harrington <bryce@...961...> wrote:
<snip />
hing you could do is to touch base with the goocanvas and/or papyrus developers and ask if they've considered Inkscape's canvas and if they'd had a chance to look at Inkscape's sp_canvas.
Bryce
Ok, I contacted the lead developers. Hopefully they will reply and then I'll put them in touch on the list...I think papyrus looks the most promising :)
Jon
About renders? Didn't a 3D object is equal to an OpenGL object? Why complicate things... use modules...
2007/1/22, Bryce Harrington <bryce@...961...>:
On Mon, Jan 22, 2007 at 07:07:10PM -0700, Joshua A. Andler wrote:
No one will disagree about Cairo's current speed.
Although, it'd help to have some tangible benchmarks to go by. But in general I don't think there's disagreement on this point.
If we are doing other refactoring though, it wouldn't hurt for us to look into what needs to be done for an eventual renderer replacement. Do we really want to solely maintain a renderer forever when we can get other improvements for free with a shared library?
As I understand things, Cairo in and of itself isn't enough - it just renders stuff. What we need in addition to Cairo is a Gtk canvas layer, that provides an interactive way of interfacing to the renderer.
Presently there are a couple Gtk+ Cairo canvas libs - Papyrus and GooCanvas. I've only briefly looked at them and neither seems particularly mature. I couldn't say whether they are developing in a direction that will eventually support what we need, nor is it clear which of the two would be the better option to adopt. But I think it would be worthwhile for someone to give them a deeper evaluation.
I know that the main goal of the current dev cycle of Cairo is performance improvement (last time I checked there was major work going on for tessellation). Additionally, given that our renderer is faster, perhaps our devs could help improve the speed of Cairo (as we're pitching in for PDF improvement).
Fred did much of the coding for our renderer, and it's been a long time since we've seen him. Mental is active on the Cairo list already. njh always was focused more on the algorithmic aspects, that he's now encapsulating into 2geom. pjrm has been busy with family stuff. So, we're currently a bit shy on active renderer-level expertise ourselves.
I'm not advocating a switch anytime soon, I'm just thinking it would smart to develop a plan at the time other things are being refactored. This way if the Cairo guys figure out some super-speed voodoo and we really want to switch, it will be that much easier (and potentially
faster).
Agreed.
Well like Mental says, the refactoring work is going to be a major prerequisite; without it, any sort of architectural change like this is going to be much more painful than it'd be with it.
Aside from that, I think a canvas analysis may be the next major step. Perhaps this could even be done in parallel. Basically, we'd need to decide if we want to:
a) Go with goocanvas or papyrus or some other 3rd party lib b) Adapt our existing canvas layer to work with Cairo c) Create a new canvas layer d) Some combination of the above e) Stick with what we have
However, it's not likely we'll be able to get all the refactoring work done quickly, so it may be premature to make canvas decisions right yet.
Bryce
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, Jan 22, 2007 at 04:48:36PM -0700, Joshua A. Andler wrote:
2geom integration. It seems to me that 2geom will open a lot of doors for potential new features and editing abilities (not to mention bug fixes for things that currently aren't optimal such as the boolean ops). I personally think this should be be added to the roadmap at this point as well as a discussion on how to go about achieving this.
With this refactoring/integration, it's also a good time for us to really reorganize code and do some janitorial work. It also presents an optimal time to look into what will be necessary for cairofication.
Thanks, I've added this to the roadmap. I too would like to get more details about what would be involved in undertaking this. I'd also like to have a better feel for how ready 2geom is in terms of stability and featurefulness.
I also agree that it's high time that we all pitch in chunks of time towards various refactoring needs. Lots of things are needed, and we definitely have the manpower to get them taken care of. Maybe during the 0.46 development cycle we can arrange some refactoring sessions on weekends. It'd take some planning ahead of time, but it'd be fun, and a good way to get new coders up and running on the codebase.
Bryce
On 1/23/07, Bryce Harrington wrote:
More thoughts?
Regarding technical drawing,
1) there is an interesting RFE, that could grow to a functional spec (read the topmost comment):
http://sourceforge.net/tracker/index.php?func=detail&aid=1630896&gro...
2) Having spent a reasonable time with Visio, I would say that being able to add new tags/arguments and edit existing ones in Inkscape's XML editor similar to the way it's done in Visio's "sheets" would improve Inkscape a lot. I guess I could even provide a thorough description of what I have in my mind, in case anyone's interested.
Alexandre
I use paper>InkScape as my only cross-platform "free-style" prototyping tool... InkScape is "BirdOfFeathers".
2007/1/22, Alexandre Prokoudine <alexandre.prokoudine@...400...>:
On 1/23/07, Bryce Harrington wrote:
More thoughts?
Regarding technical drawing,
- there is an interesting RFE, that could grow to a functional spec
(read the topmost comment):
http://sourceforge.net/tracker/index.php?func=detail&aid=1630896&gro...
- Having spent a reasonable time with Visio, I would say that being
able to add new tags/arguments and edit existing ones in Inkscape's XML editor similar to the way it's done in Visio's "sheets" would improve Inkscape a lot. I guess I could even provide a thorough description of what I have in my mind, in case anyone's interested.
Alexandre
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Jan 23, 2007 at 02:56:01AM +0300, Alexandre Prokoudine wrote:
On 1/23/07, Bryce Harrington wrote:
More thoughts?
Regarding technical drawing,
- there is an interesting RFE, that could grow to a functional spec
(read the topmost comment):
http://sourceforge.net/tracker/index.php?func=detail&aid=1630896&gro...
- Having spent a reasonable time with Visio, I would say that being
able to add new tags/arguments and edit existing ones in Inkscape's XML editor similar to the way it's done in Visio's "sheets" would improve Inkscape a lot. I guess I could even provide a thorough description of what I have in my mind, in case anyone's interested.
Thanks, some good ideas! I've added them to the roadmap. Technical drawing is definitely an area I want to work on for the next few releases, and I hope others will be able to contribute new features for this area as well. :-)
Bryce
On Mon, 22 Jan 2007, Bryce Harrington wrote:
On Mon, Jan 22, 2007 at 02:38:22PM -0800, Jon Phillips wrote:
On Mon, 2007-01-22 at 14:11 -0800, Bryce Harrington wrote:
The reviewer felt the speed and ease of picking it up gave Xara an edge, unless you're a professional graphics guy.
Inkscape has improved in leaps and bound since the days of Sodipodi but the interface is definately still a little weird especially for those used to commercial apps like Xara, but Inkscape isn't anyowhere near as old as Xara.
What about the community aspect of the projects? Did you all see the article about how Xara dev. has dropped off and people are not happy that they aren't committing patches
failing to commit patches (or at least politey review them in a timely manner) is tantamoutn to turning contributors away, and a fine example of the value of a good maintainer as opposed to a talented developer. encouraging contributors is one of the best things Inkscape has done.
But this presents a question worth discussing:
"What should Inkscape's next set of goals and objectives be?"
In the period from 0.44 to 0.45 it feels like we've achieved a lot of key goals we'd set out for ourselves from the start of the project.
Certainly, there's still much left to be done and many features to go before we fully support the SVG specification. We also know of a number of key features (Cairoification, PDF, DOM-based scripting) that are still high priorities on our todo list.
What do you think of these as goals?
- SVG editing (compliant and efficient)
I think SVG has been a core goal which really helps keep inkscape on track and makes it much clearer that supporting a million vector and raster file formats is not a priority.
In any case these other file formats tend to make great projects for third party filters and extensions, or ideally shared libraries. It seems like SVG is at the core of Inkscape, PDF essential for printing, and and PNG covers most raster graphics needs. A small push to use gdkpixbuf and gain JPEG support for use withi SVGs would be a big improvement would cover the other raster essentials. After that any other formats are a bonus, especially if they have individual maintainers or are based off of libraries get occasional maintaince (I remain concerned about the ongoing helath of DXF suppport in Inkscape).
- Professional graphic art drawing (powerful and beautiful)
- Amateur artist drawing (fun and easy)
It should be possible to do the lattter without alienating the former but bulia might disagree with me. It is certainly a reasonable enough approach to make things work first and make them easy later (KDE tends towards this) at the risk of confusing less advanced users in the short term (which Gnome tends to avoid, and it is so much easier to support users with less risk of getting confused or shooting themselves in the foot). We've seen before that rushing some features to release helps get the flaws hammered out but other features result in many questions to which we can only reply "known issue, workin progress" despite warnings in the release notes.
- Technical drawing (flexible and reliable)
Looking at the request tracker many users want AutoCAD. Others want Visio.
Inkscape is almost a victim of its own success that users want to do so much through Inkscape rather than using more "suitable" CAD or Diagramming tools.
Again if these were seperate third party plugins it would all be gravey but adding a lot more technical drawing features inevitably makes things more techincal and daunting for begginers and fun artists (probably not making too much of a differnce to pro artists though).
- Inspires community participation in FLOSS
The old long term plan to create a canvas other projects can use might help spread that inspiration and reduce some of the desire for Inkscape to be so many differnt things all at once.
I don't think any of these mark a serious shift from the directions we've been on already, but it helps to spell them out explicitly. Anything else missing?
Just had to get a word in about JPEG support but continuing on the same direction sounds pretty good.
More thoughts?
Rock on .
Sincerely
Alan Horkan
http://advogato.org/person/AlanHorkan/ http://www.linkedin.com/in/alanhorkan http://alanhorkan.livejournal.com/
On Mon, 2007-01-22 at 15:34 -0800, Bryce Harrington wrote:
- Codebase refactoring and documentation: With as many contributions as we've received, it's no surprise things have gotten cluttery, but for future maintainability it would be beneficial to spend a focused amount of time finishing various refactoring projects, excising old code, documenting stuff, and simplifying our build process.
I think cleaning up the codebase is probably the single most important task right now, and it will make all the others significantly easier to accomplish.
-mental
On Mon, Jan 22, 2007 at 08:51:53PM -0500, MenTaLguY wrote:
On Mon, 2007-01-22 at 15:34 -0800, Bryce Harrington wrote:
- Codebase refactoring and documentation: With as many contributions as we've received, it's no surprise things have gotten cluttery, but for future maintainability it would be beneficial to spend a focused amount of time finishing various refactoring projects, excising old code, documenting stuff, and simplifying our build process.
I think cleaning up the codebase is probably the single most important task right now, and it will make all the others significantly easier to accomplish.
Here are the refactoring tasks currently in our roadmap.
Could you review this and see if there's additional stuff we should have listed, or if some of these should be postponed for now?
Architectural Refactoring Effort:
(For 0.46:) * Eliminate all use of sp_repr_new in favor of XML::Document::* classes (see [1] * Migrate SPObject to native C++ classes * Implement gradient UI "release" handler to deal with gradient garbage collection (see bug 984854) * Create an SPObject API for tracking references and avoiding id clashes on import and interdocument copy/paste. What we need are a void SPDocument::importCopies([set of SPObjects]), and an [set of SPObjects] SPObject::dependencies() method. * What else?
(Maybe 0.46?) * Eliminate use of the style.h types in as much of codebase as possible, particularly display/*. * Replace style.cpp entirely, with a clearer and cleaner version. * 2geom Integration
(Definitely post-0.46) * Cairo Adoption Effort: o Prereq: Is renderer immune to the same kinds of numerical problems we see with our new renderer, libnr, or libart? o Will the new renderer improve performance for most users? o Integrate a Cairo-based SVG Canvas library
Also, I'm trying to also spell out the 'janitorial' type tasks that may be easier for novices to tackle. Here's a start at this list; let me know if there's other things we could include in this list:
Codebase Cleanup Effort:
* Convert use of gboolean to bool where feasible * Switch from use of TRUE/FALSE to true/false * Change to use of GQuarks instead of #defines where feasible * Learn and use autoscan and autoreconf to find out which configure tests are still needed. * Clean up configure.in * (PARTIALLY DONE) DirectoryReorgProposal * Convert all tabs into spaces (convert tabs to 4 spaces) * Rename all 'SPFooBar' routines to 'FooBar' and put into namespaces o (DONE) dialogs folder
Bryce Harrington wrote:
Architectural Refactoring Effort: [...] * What else?
Convert GTK dialog code to GTKMM: "copy"/convert the dialog code in src/dialogs/ to src/ui/dialog/. It is a pretty straightforward task for most dialogs I think.
- Convert all tabs into spaces (convert tabs to 4 spaces)
See [1]. What was the result of this discussion? Moreover, Jon Cruz wrote [2]: "Trailing whitespace is also a non-visible but diff-confusing issue, and should also eventually tracked down and removed." I can set my editor to automatically remove trailing whitespace; but I cannot do this in batch mode. However, this might create a lot of SVN diffs if it is done separate from 'de-tabbing'. Aren't there pretty-printing programs out there somewhere that can help us automize? (I have never seen or used such a program, only heard of them)
Regards, Johan
[1] = http://sourceforge.net/mailarchive/message.php?msg_id=7164324 [2] = http://wiki.inkscape.org/wiki/index.php/InkscapeJanitors#Cleanup:_Whitespace
On 1/23/07, Bryce Harrington <bryce@...961...> wrote:
* Implement gradient UI "release" handler to deal with gradient garbage collection (see bug 984854)
Looks like that bug concerns the gradient editor dialog which, with the current advances in on-canvas editing, is planned for removal. If anyone can think up a good reason to still have that dialog after we can add/move/remove/recolor intermediate gradient stops on canvas, please speak up.
* Replace style.cpp entirely, with a clearer and cleaner version.
Mental or anyone, can you please elaborate on what is fundamentally wrong with style.cpp? Yes, it's huge and messy, but so is CSS specification. Megatons of work went into testing and debugging this piece of code over the years. Is there no chance it could be improved gradually rather than replaced wholesale?
One problem I'm very aware of is that SPStyle does not use URIReferences for tracking stuff in defs. A lot of documented bugs stem from this. However I don't think it would be such an unsurmountable task to fix this within SPStyle. And yet I'm not doing this - mostly because of this plan to "replace style.cpp altogether" which seems to be in our TODOs since forever: why spend time on code which will be replaced? So, I'd like to discuss this now to make sure we know what we're going to do.
* Convert use of gboolean to bool where feasible * Switch from use of TRUE/FALSE to true/false
I think it's mostly done by now. The remaining gbooleans cannot be changed because they are used for GTK APIs.
On Wed, 2007-01-24 at 15:32 -0400, bulia byak wrote:
* Replace style.cpp entirely, with a clearer and cleaner version.Mental or anyone, can you please elaborate on what is fundamentally wrong with style.cpp? Yes, it's huge and messy, but so is CSS specification. Megatons of work went into testing and debugging this piece of code over the years. Is there no chance it could be improved gradually rather than replaced wholesale?
I think it's only practical to conduct the process incrementally, but when it's complete I don't expect any of the original code to be left.
There are a lot of serious individual problems, but the fundamental problem really is that it's huge and messy -- far more than the CSS specification calls for -- and that the mess keeps those individual problems from getting fixed.
On the outside, it should present a simple set of accessor methods for getting/setting properties by name, and propagating to/from repr.
On the inside, it should consist of (in code, in no particular order):
1. a concise list of property names with the expected domain of values in CSS and the associated Inkscape data type
2. a concise list of property aliases which represent one or more properties combined, each with the rule used to combine
3. definitions of the aforementioned rules and value domains
4. some generic code (not tied to any one property) implementing the needed behavior
In some respects, we're already not too far away from the ideal (there's already a bit of #3 evident), but in others we've got a long way to go (#4, for instance -- a lot of stuff that should be identical is currently implemented redundantly and inconsistently, once for each property).
-mental
On 1/24/07, MenTaLguY <mental@...3...> wrote:
I think it's only practical to conduct the process incrementally, but when it's complete I don't expect any of the original code to be left.
I very much doubt that. Your goals are good, but I don't see how they could lead to replacing _all_ of the current code. Refactoring and simplifying, probably. But there's a lot of code there which cannot and should not be replaced. Take sp_style_merge_from_dying_parent and its helpers, for example. It's a huge piece of code which painstakingly implements (and documents!) the merging of all supported properties. You cannot make it much simpler than it is, because there is in fact a lot of variants of doing merging depending on whether a property is inherited, whether it accumulates (as opacity), whether it allows relative specification, whether it's numeric, etc. etc. It's still incomplete and may be buggy, but I see no other way to approach this. Please let's not try to fix what isn't broken.
On the outside, it should present a simple set of accessor methods for getting/setting properties by name, and propagating to/from repr.
Agreed
- a concise list of property names with the expected domain of values
in CSS and the associated Inkscape data type
This is pretty much how it's done already. We have types for lengths, paint, filters, etc.
- a concise list of property aliases which represent one or more
properties combined, each with the rule used to combine
This is perhaps where some refactoring is indeed necessary (though I haven't looked at it closely)
- definitions of the aforementioned rules and value domains
All string-valued properties already have their accepted values listed in enums.
- some generic code (not tied to any one property) implementing the
needed behavior
We already have a lot of generic code there - for reading/writing paint properties, for example. Perhaps more functions like this can be added, and existing ones can be streamlined, but I don't think it's going to be something too drastic.
Just an example, when Peter Moulder added support for libcroco and document-wide style specifications, it was a solid piece of new code, but it didn't require rewriting any significant portion of style.cpp. It was reasonably neatly slapped on top of it and works fine. Which shows that for all its incompleteness, style.cpp is not so really bad by itself.
So, per above, I propose that we stop talking about "replacing style.cpp" and remove that phrase from the roadmap. "Refactoring/streamlining style.cpp" sounds much closer to what we really need and, unlike "replacing", will not have the chilling effect on developers who might want to hack on that file.
On Wed, 2007-01-24 at 17:42 -0400, bulia byak wrote:
You cannot make [sp_style_merge_from_dying_parent] much simpler than it is, because there is in fact a lot of variants of doing merging depending on whether a property is inherited, whether it accumulates (as opacity), whether it allows relative specification, whether it's numeric, etc. etc.
I disagree; it's not as bad as it could be, but with refactoring of the surrounding code it could be written significantly more concisely.
Most of the variants can be accounted for by composition of simpler rules, and most of the information about which rules apply (inherited? numeric?) should be shared rather than hard-coded into the bodies of the various functions which must consider them (of which sp_style_merge_from_dying_parent is only one).
So, per above, I propose that we stop talking about "replacing style.cpp" and remove that phrase from the roadmap. "Refactoring/streamlining style.cpp" sounds much closer to what we really need and, unlike "replacing", will not have the chilling effect on developers who might want to hack on that file.
That makes sense.
-mental
On Wed, 24 Jan 2007, bulia byak wrote:
Date: Wed, 24 Jan 2007 15:32:08 -0400 From: bulia byak <buliabyak@...400...> To: Bryce Harrington <bryce@...961...> Cc: Jon Phillips <jon@...235...>, Joshua A. Andler <joshua@...533...>, MenTaLguY <mental@...3...>, Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] 0.46 development goals
On 1/23/07, Bryce Harrington <bryce@...961...> wrote:
* Implement gradient UI "release" handler to deal with gradient garbage collection (see bug 984854)Looks like that bug concerns the gradient editor dialog which, with the current advances in on-canvas editing, is planned for removal. If anyone can think up a good reason to still have that dialog after we can add/move/remove/recolor intermediate gradient stops on canvas, please speak up.
I would need more time to think about it but you may want to hold on to the dialog for keyboard accessibility rather than interactive mouse control. You might also want it for precision values so that users could specify exactly angles. Having said that if you really want to remove the dialog you can probably do other things to mitigate these kinds of issues.
Alan Horkan wrote:
On Wed, 24 Jan 2007, bulia byak wrote:
Date: Wed, 24 Jan 2007 15:32:08 -0400 From: bulia byak <buliabyak@...400...> To: Bryce Harrington <bryce@...961...> Cc: Jon Phillips <jon@...235...>, Joshua A. Andler <joshua@...533...>, MenTaLguY <mental@...3...>, Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] 0.46 development goals
On 1/23/07, Bryce Harrington <bryce@...961...> wrote:
* Implement gradient UI "release" handler to deal with gradient garbage collection (see bug 984854)Looks like that bug concerns the gradient editor dialog which, with the current advances in on-canvas editing, is planned for removal. If anyone can think up a good reason to still have that dialog after we can add/move/remove/recolor intermediate gradient stops on canvas, please speak up.
I would need more time to think about it but you may want to hold on to the dialog for keyboard accessibility rather than interactive mouse control. You might also want it for precision values so that users could specify exactly angles. Having said that if you really want to remove the dialog you can probably do other things to mitigate these kinds of issues.
With the current plans, everything you can do with the dialog will be accessible either on-canvas or in the controls bar. It's actually a little more keyboard friendly in it's current state than it used to be (and will be more so by the time 0.46 comes out). This is one of those times where I personally say good riddance to the dialog as these changes are making the gradient tool much easier and more user-friendly.
If you drop in Jabber or IRC tomorrow we can talk more about it. :)
-Josh
On Wed, 24 Jan 2007, Joshua A. Andler wrote:
On 1/23/07, Bryce Harrington <bryce@...961...> wrote:
* Implement gradient UI "release" handler to deal with gradient garbage collection (see bug 984854)
Looks like that bug concerns the gradient editor dialog which, with the current advances in on-canvas editing, is planned for removal. If anyone can think up a good reason to still have that dialog after we can add/move/remove/recolor intermediate gradient stops on canvas, please speak up.
I would need more time to think about it but you may want to hold on to the dialog for keyboard accessibility rather than interactive mouse control. You might also want it for precision values so that users could specify exactly angles. Having said that if you really want to remove the dialog you can probably do other things to mitigate these kinds of issues.
With the current plans, everything you can do with the dialog will be accessible either on-canvas or in the controls bar. It's actually a
You're probably right but now was the time to mention it. It does seem like it will be good riddance to the gradient dialog. (Getting rid of the Font dialog however would not be a good idea, there is just too much Font related functionality users will want that cannot reasonably be accomodated in a toolbar.)
If you drop in Jabber or IRC tomorrow we can talk more about it. :)
Thanks but I dont think that will be necessary.
On Mon, 2007-01-22 at 15:34 -0800, Bryce Harrington wrote:
On Mon, Jan 22, 2007 at 02:38:22PM -0800, Jon Phillips wrote:
On Mon, 2007-01-22 at 14:11 -0800, Bryce Harrington wrote:
The reviewer felt the speed and ease of picking it up gave Xara an edge, unless you're a professional graphics guy.
What about the community aspect of the projects? Did you all see the article about how Xara dev. has dropped off and people are not happy that they aren't committing patches or aren't that helpful to possible community members?
http://applications.linux.com/article.pl?sid=06/12/19/2032224&tid=39
Yes, this is a hidden strength of Inkscape. It's also amazing how deeply we've penetrated the Open Source community. Being 100% open source down to the renderer has helped us here, as has our goal of working closely with other community projects.
But this presents a question worth discussing:
"What should Inkscape's next set of goals and objectives be?"
In the period from 0.44 to 0.45 it feels like we've achieved a lot of key goals we'd set out for ourselves from the start of the project. We are seeing many 3rd-party extensions created for Inkscape. Distros include Inkscape as a vital component. We've got ports to all major computing platforms, and to a heap-load of languages.
Certainly, there's still much left to be done and many features to go before we fully support the SVG specification. We also know of a number of key features (Cairoification, PDF, DOM-based scripting) that are still high priorities on our todo list. But I think now would be a good time to get our RoadMap reorganized and into proper shape, to allow us to better focus on the specific objectives that will enable us to meet our own goals. A common risk of community-oriented projects like ours is loss of focus; while I think we've done well at staying on track, it couldn't hurt to re-evaluate our existing goals and identify new ones to adopt.
What do you think of these as goals?
- SVG editing (compliant and efficient)
- Professional graphic art drawing (powerful and beautiful)
- Technical drawing (flexible and reliable)
- Amateur artist drawing (fun and easy)
- Inspires community participation in FLOSS
My only issue with this is possible bloat because of too many goals. Before we discussed working towards and Inkcore strategy, where the core of inkscape could be a library/set of libraries and inkscape uses this core. Thus, other projects could sprout that focus on using this core. I'm thinking inkview, inkpresent, inkbrowse, etc. Check my blog post-lite on this:
http://rejon.org/2007/01/02/the-open-source-raster-core-gegl-004-released/
Anyway, as concrete goals, I think SVG editing is still the key goal to promote. I think professional drawing and amateur drawing might compete a bit, but obviously, by supporting SVG profiles, we get both amateur (SVG Tiny) and professional (SVG 1.1/1.2), right? Jon Cruz, what do you think?
I don't think any of these mark a serious shift from the directions we've been on already, but it helps to spell them out explicitly. Anything else missing?
As far as near-term objectives, I don't see a reason to change our objectives necessarily, but it could help to itemize them a bit more clearly. Some thoughts (ordered by importance, not milestone):
SVG Tiny Support: This has been our ultimate objective for a while now, and I think it should remain a primary objective. With filter support we're now a nice step closer.
PDF Import/Export: We made a fairly good shot at this for 0.45 but ultimately missed the mark. I bet we could nail it on a second shot.
Fonts: While we've considered font support to be a "done" objective, based on the number of bug reports, clearly this needs a lot more focus than we've given it.
Codebase refactoring and documentation: With as many contributions as we've received, it's no surprise things have gotten cluttery, but for future maintainability it would be beneficial to spend a focused amount of time finishing various refactoring projects, excising old code, documenting stuff, and simplifying our build process.
Extension/DOM/scripting architecture: We have a lot of the necessary bits in place, they just need muscle to get them from the 70% mark up towards the 90% mark. My feeling is that this is extremely important - if done extremely well, this could enable a LOT more people to help us meet a much more aggressive set of goals.
Performance: This is a key area where we compare poorly against with Xara.
Cairoification: Big project, but still important. We need a cairo canvas layer before we can start this. There's a few options out there to consider.
More thoughts?
Bryce
I think we need to be clear that 0.50 is SVG Tiny (which is now called SVG Mobile) and 1.0 of Inkscape is full SVG 1.1 support.
Could these be added to the roadmap. I think that having clear short-term, SVG Mobile, and longe term, SVG 1.1 is vital to our incremental strategy.
Inkscape's strength is the community. We rock :) I'm also curious if anyone out there would be interested in either A.) funding inkscape development B.) working for funders of Inkscape development
While we are good at scratching our itches, I wonder what we could get done that we aren't doing by commercial dev. Of course, they would have to follow the community guidelines, etc, and ideally would be inkscape devs.
Jon
Can I design the Interface of InkScape... on my free time.
2007/1/22, Jon Phillips <jon@...235...>:
On Mon, 2007-01-22 at 15:34 -0800, Bryce Harrington wrote:
On Mon, Jan 22, 2007 at 02:38:22PM -0800, Jon Phillips wrote:
On Mon, 2007-01-22 at 14:11 -0800, Bryce Harrington wrote:
The reviewer felt the speed and ease of picking it up gave Xara an edge, unless you're a professional graphics guy.
What about the community aspect of the projects? Did you all see the article about how Xara dev. has dropped off and people are not happy that they aren't committing patches or aren't that helpful to possible community members?
http://applications.linux.com/article.pl?sid=06/12/19/2032224&tid=39
Yes, this is a hidden strength of Inkscape. It's also amazing how deeply we've penetrated the Open Source community. Being 100% open source down to the renderer has helped us here, as has our goal of working closely with other community projects.
But this presents a question worth discussing:
"What should Inkscape's next set of goals and objectives be?"
In the period from 0.44 to 0.45 it feels like we've achieved a lot of key goals we'd set out for ourselves from the start of the project. We are seeing many 3rd-party extensions created for Inkscape. Distros include Inkscape as a vital component. We've got ports to all major computing platforms, and to a heap-load of languages.
Certainly, there's still much left to be done and many features to go before we fully support the SVG specification. We also know of a number of key features (Cairoification, PDF, DOM-based scripting) that are still high priorities on our todo list. But I think now would be a good time to get our RoadMap reorganized and into proper shape, to allow us to better focus on the specific objectives that will enable us to meet our own goals. A common risk of community-oriented projects like ours is loss of focus; while I think we've done well at staying on track, it couldn't hurt to re-evaluate our existing goals and identify new ones to adopt.
What do you think of these as goals?
- SVG editing (compliant and efficient)
- Professional graphic art drawing (powerful and beautiful)
- Technical drawing (flexible and reliable)
- Amateur artist drawing (fun and easy)
- Inspires community participation in FLOSS
My only issue with this is possible bloat because of too many goals. Before we discussed working towards and Inkcore strategy, where the core of inkscape could be a library/set of libraries and inkscape uses this core. Thus, other projects could sprout that focus on using this core. I'm thinking inkview, inkpresent, inkbrowse, etc. Check my blog post-lite on this:
http://rejon.org/2007/01/02/the-open-source-raster-core-gegl-004-released/
Anyway, as concrete goals, I think SVG editing is still the key goal to promote. I think professional drawing and amateur drawing might compete a bit, but obviously, by supporting SVG profiles, we get both amateur (SVG Tiny) and professional (SVG 1.1/1.2), right? Jon Cruz, what do you think?
I don't think any of these mark a serious shift from the directions we've been on already, but it helps to spell them out explicitly. Anything else missing?
As far as near-term objectives, I don't see a reason to change our objectives necessarily, but it could help to itemize them a bit more clearly. Some thoughts (ordered by importance, not milestone):
SVG Tiny Support: This has been our ultimate objective for a while now, and I think it should remain a primary objective. With filter support we're now a nice step closer.
PDF Import/Export: We made a fairly good shot at this for 0.45 but ultimately missed the mark. I bet we could nail it on a second shot.
Fonts: While we've considered font support to be a "done" objective, based on the number of bug reports, clearly this needs a lot more focus than we've given it.
Codebase refactoring and documentation: With as many contributions as we've received, it's no surprise things have gotten cluttery, but for future maintainability it would be beneficial to spend a focused amount of time finishing various refactoring projects, excising old code, documenting stuff, and simplifying our build process.
Extension/DOM/scripting architecture: We have a lot of the necessary bits in place, they just need muscle to get them from the 70% mark up towards the 90% mark. My feeling is that this is extremely important - if done extremely well, this could enable a LOT more people to help us meet a much more aggressive set of goals.
Performance: This is a key area where we compare poorly against with Xara.
Cairoification: Big project, but still important. We need a cairo canvas layer before we can start this. There's a few options out there to consider.
More thoughts?
Bryce
I think we need to be clear that 0.50 is SVG Tiny (which is now called SVG Mobile) and 1.0 of Inkscape is full SVG 1.1 support.
Could these be added to the roadmap. I think that having clear short-term, SVG Mobile, and longe term, SVG 1.1 is vital to our incremental strategy.
Inkscape's strength is the community. We rock :) I'm also curious if anyone out there would be interested in either A.) funding inkscape development B.) working for funders of Inkscape development
While we are good at scratching our itches, I wonder what we could get done that we aren't doing by commercial dev. Of course, they would have to follow the community guidelines, etc, and ideally would be inkscape devs.
Jon
-- Jon Phillips
San Francisco, CA USA PH 510.499.0894 jon@...235... http://www.rejon.org
MSN, AIM, Yahoo Chat: kidproto Jabber Chat: rejon@...896... IRC: rejon@...897...
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, 2007-01-22 at 20:22 -0600, Esteban Barahona wrote:
Can I design the Interface of InkScape... on my free time.
Sure, you can always create mockups and create patches to be considered. I would suggest creating svg-based mockups and posting here about them, however, patches go a long way towards getting things done :)
Jon
2007/1/22, Jon Phillips <jon@...235...>: On Mon, 2007-01-22 at 15:34 -0800, Bryce Harrington wrote: > On Mon, Jan 22, 2007 at 02:38:22PM -0800, Jon Phillips wrote: > > On Mon, 2007-01-22 at 14:11 -0800, Bryce Harrington wrote: > > > The reviewer felt the speed and ease of picking it up gave Xara an > > > edge, unless you're a professional graphics guy. > > > > What about the community aspect of the projects? Did you all see the > > article about how Xara dev. has dropped off and people are not happy > > that they aren't committing patches or aren't that helpful to possible > > community members? > > > > http://applications.linux.com/article.pl?sid=06/12/19/2032224&tid=39 > > Yes, this is a hidden strength of Inkscape. It's also amazing how > deeply we've penetrated the Open Source community. Being 100% open > source down to the renderer has helped us here, as has our goal of > working closely with other community projects. > > But this presents a question worth discussing: > > "What should Inkscape's next set of goals and objectives be?" > > In the period from 0.44 to 0.45 it feels like we've achieved a lot of > key goals we'd set out for ourselves from the start of the project. We > are seeing many 3rd-party extensions created for Inkscape. Distros > include Inkscape as a vital component. We've got ports to all major > computing platforms, and to a heap-load of languages. > > Certainly, there's still much left to be done and many features to go > before we fully support the SVG specification. We also know of a number > of key features (Cairoification, PDF, DOM-based scripting) that are > still high priorities on our todo list. But I think now would be a good > time to get our RoadMap reorganized and into proper shape, to allow us > to better focus on the specific objectives that will enable us to meet > our own goals. A common risk of community-oriented projects like ours > is loss of focus; while I think we've done well at staying on track, it > couldn't hurt to re-evaluate our existing goals and identify new ones to > adopt. > > What do you think of these as goals? > > * SVG editing (compliant and efficient) > * Professional graphic art drawing (powerful and beautiful) > * Technical drawing (flexible and reliable) > * Amateur artist drawing (fun and easy) > * Inspires community participation in FLOSS
My only issue with this is possible bloat because of too many goals. Before we discussed working towards and Inkcore strategy, where the core of inkscape could be a library/set of libraries and inkscape uses this core. Thus, other projects could sprout that focus on using this core. I'm thinking inkview, inkpresent, inkbrowse, etc. Check my blog post-lite on this: http://rejon.org/2007/01/02/the-open-source-raster-core-gegl-004-released/ Anyway, as concrete goals, I think SVG editing is still the key goal to promote. I think professional drawing and amateur drawing might compete a bit, but obviously, by supporting SVG profiles, we get both amateur (SVG Tiny) and professional (SVG 1.1/1.2), right? Jon Cruz, what do you think? > I don't think any of these mark a serious shift from the directions > we've been on already, but it helps to spell them out explicitly. > Anything else missing? > > As far as near-term objectives, I don't see a reason to change our > objectives necessarily, but it could help to itemize them a bit more > clearly. Some thoughts (ordered by importance, not milestone): > > 1. SVG Tiny Support: This has been our ultimate objective for a while > now, and I think it should remain a primary objective. With filter > support we're now a nice step closer. > > 2. PDF Import/Export: We made a fairly good shot at this for 0.45 but > ultimately missed the mark. I bet we could nail it on a second > shot. > > 3. Fonts: While we've considered font support to be a "done" > objective, based on the number of bug reports, clearly this needs a > lot more focus than we've given it. > > 4. Codebase refactoring and documentation: With as many contributions > as we've received, it's no surprise things have gotten cluttery, but > for future maintainability it would be beneficial to spend a focused > amount of time finishing various refactoring projects, excising old > code, documenting stuff, and simplifying our build process. > > 5. Extension/DOM/scripting architecture: We have a lot of the > necessary bits in place, they just need muscle to get them from the > 70% mark up towards the 90% mark. My feeling is that this is > extremely important - if done extremely well, this could enable a > LOT more people to help us meet a much more aggressive set of goals. > > 6. Performance: This is a key area where we compare poorly against > with Xara. > > 7. Cairoification: Big project, but still important. We need a cairo > canvas layer before we can start this. There's a few options out > there to consider. > > More thoughts? > > Bryce I think we need to be clear that 0.50 is SVG Tiny (which is now called SVG Mobile) and 1.0 of Inkscape is full SVG 1.1 support. Could these be added to the roadmap. I think that having clear short-term, SVG Mobile, and longe term, SVG 1.1 is vital to our incremental strategy. Inkscape's strength is the community. We rock :) I'm also curious if anyone out there would be interested in either A.) funding inkscape development B.) working for funders of Inkscape development While we are good at scratching our itches, I wonder what we could get done that we aren't doing by commercial dev. Of course, they would have to follow the community guidelines, etc, and ideally would be inkscape devs. Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 jon@...235... http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: rejon@...896... IRC: rejon@...897... ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, Jan 22, 2007 at 06:25:39PM -0800, Jon Phillips wrote:
I think we need to be clear that 0.50 is SVG Tiny (which is now called SVG Mobile) and 1.0 of Inkscape is full SVG 1.1 support.
Could these be added to the roadmap. I think that having clear short-term, SVG Mobile, and longe term, SVG 1.1 is vital to our incremental strategy.
I've added these to the roadmap. Jon, would you mind itemizing what's required for SVG Mobile that we don't have right now? That'd give us something to base objectives on for the next few releases.
Bryce
On Mon, 22 Jan 2007, Jon Phillips wrote:
Date: Mon, 22 Jan 2007 18:25:39 -0800 From: Jon Phillips <jon@...235...> To: Bryce Harrington <bryce@...961...> Cc: Joshua A. Andler <joshua@...533...>, Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Xara and Inkscape comparison on Linux Action Show
I think we need to be clear that 0.50 is SVG Tiny (which is now called SVG Mobile) and 1.0 of Inkscape is full SVG 1.1 support.
The conservatism when it comes to version numbers is a missed opportunity. There are plenty more users out there phobic about using anthing less that 1.0 than there are developers who similiar fear the big One Point Zero (and in the case of Microsoft products you have so many people who wont even touch it until after the first service pack or make claims that Microsoft only really start to get things right after 3 major releases.) Inkscape with fully SVG Tiny support would rock and with a little stablisatoin be well worth of the 1.0 tagline. The specification is only relatively tiny because of the mobile devices it targets, it even includes basic animation feeatures and getting all that in Inkscape would be a major step well worthy of a major version number (not to mention all the other improvements inkscape would sure accumulate by then).
On Tue, 2007-01-23 at 03:49 +0000, Alan Horkan wrote:
The conservatism when it comes to version numbers is a missed opportunity.
I think it's honest, though. Setting aside SVG features for the moment, we've still got some really major architectural and functionality issues to sort through. One of the most glaring is printing, and that's going to take a long time to get right.
(Let's not even think about some of the grave usability issues that still linger...)
-mental
On 1/24/07, MenTaLguY <mental@...3...> wrote:
(Let's not even think about some of the grave usability issues that still linger...)
Hey, there's a company called Adobe which has published a version 12.0 of their vector editor product - still without proper on-canvas editing of gradients. And somehow they can get away with that :)
On Jan 22, 2007, at 6:25 PM, Jon Phillips wrote:
Anyway, as concrete goals, I think SVG editing is still the key goal to promote. I think professional drawing and amateur drawing might compete a bit, but obviously, by supporting SVG profiles, we get both amateur (SVG Tiny) and professional (SVG 1.1/1.2), right? Jon Cruz, what do you think?
I probably wouldn't break those down that way.
SVG Tiny would probably be used by professionals targeting the mobile market.
I'd say the profiles would support things, but that 1.1/1.2 and amateur/professional are orthogonal aspects. I'd easily see professional+1.1 and amateur+1.2, etc.
On 1/22/07, Bryce Harrington <bryce@...961...> wrote:
- Xara easier to pick up and run with from a new user perspective. Applying transparent gradients can be done entirely on-screen with click and drag.
I.e. he didn't find our Gradient tool? or didn't guess it does transparency, "entirely on-screen with click and drag"?
Actually, we do need a Mask tool with a UI similar to Gradient tool but applying a gradient to the object's mask. Just one of the million things we still miss.
Just so you guys know, I did write an email to both of the hosts when I had finished listening to it this morning. ;)
As with you Bulia, I made the "transparent gradient" observation and I had to tell them about the gradient tool. If you need something like the example (and description of steps) they gave, it's definitely no more difficult nor confusing in Inkscape.
I pointed out a few things to them that rock about our usability as well. Such as double clicking on any object with the selector to automatically change the tool. In general I tried to tell them things about Inkscape they probably didn't know. On top of that I did point out the (apparent) issues w/ Xara development temporarily stalling and the community not being too happy with the lack of applied patches.
Bulia, as for the Mask tool... what is involved in that? Should we throw the info up on the wiki? My (overly simplified) guess is as follows:
1) It duplicates current selection and applies back to the selection as a mask. 2) The tool works like gradient tool to apply transparency, basically editing a gradient on the mask object.
I assume we'd just have a button on the toolbar to "remove transparency" or something to get rid of it too.
Bulia, I know time estimates are kinda difficult, but could you guess roughly how big of a task this is? Is this something people without a good knowledge of our codebase could try to implement?
-Josh
bulia byak wrote:
On 1/22/07, Bryce Harrington <bryce@...961...> wrote:
- Xara easier to pick up and run with from a new user perspective. Applying transparent gradients can be done entirely on-screen with click and drag.
I.e. he didn't find our Gradient tool? or didn't guess it does transparency, "entirely on-screen with click and drag"?
Actually, we do need a Mask tool with a UI similar to Gradient tool but applying a gradient to the object's mask. Just one of the million things we still miss.
is this a merge of FOSS projects?! I will gladly beta-test this "monster" on my Mac... far... awaaay in the future...
Esteban Barahona wrote:
is this a merge of FOSS projects?! I will gladly beta-test this "monster" on my Mac... far... awaaay in the future...
There are no plans to merge Inkscape and Xara. We have general plans for refactoring Inkscape (with lib2geom and potentially Cairo when it has rockin performance), but as far as I know, Xara is not a part of any plans.
There was light discussion when Xara announced it was going OSS, but, I think the two projects have different goals, so a merger wouldn't make much sense for us.
-Josh
Sorry, I don't mind details...
lib.2D.InkScape
lib.3D.Xara
perhaps? and using both as modules of something... other software?
2007/1/22, Joshua A. Andler <joshua@...533...>:
Esteban Barahona wrote:
is this a merge of FOSS projects?! I will gladly beta-test this "monster" on my Mac... far... awaaay in the future...
There are no plans to merge Inkscape and Xara. We have general plans for refactoring Inkscape (with lib2geom and potentially Cairo when it has rockin performance), but as far as I know, Xara is not a part of any plans.
There was light discussion when Xara announced it was going OSS, but, I think the two projects have different goals, so a merger wouldn't make much sense for us.
-Josh
On Mon, Jan 22, 2007 at 05:28:28PM -0600, Esteban Barahona wrote:
is this a merge of FOSS projects?! I will gladly beta-test this "monster" on my Mac... far... awaaay in the future...
No, no, no... We *had* discussed merging with the Xara folks last year, but nothing came of it. While Inkscape and Xara appear very similar from a practical user viewpoint, there are serious technical differences that made it pretty clear that merging would be very hard. Just to name a few examples: Different widgetsets, different coding licensing, different internal document structures, different core file format (XAR vs. SVG). Then on top of the technical issues are the cultural ones of community vs. corporate.
Bryce
On 1/22/07, Joshua A. Andler <joshua@...533...> wrote:
Bulia, as for the Mask tool... what is involved in that? Should we throw the info up on the wiki? My (overly simplified) guess is as follows:
- It duplicates current selection and applies back to the selection as
a mask. 2) The tool works like gradient tool to apply transparency, basically editing a gradient on the mask object.
I assume we'd just have a button on the toolbar to "remove transparency" or something to get rid of it too.
On reflection, I don't think we can rightfully call it "mask tool" if it can only do a special kind of mask - a gradient mask. So it would be more consistent - and easier to implement - to enable the existing Gradient tool to edit mask gradients too. Now it displays and can create two kinds of gradients - those on fill and stroke. Let's just add a third type: gradient on mask. They would add a third "on" button in the toolbar and would be displayed with a different color of nodes and/or gradient lines. All three kinds of gradients will be displayed at the same time (as they are now for fill and stroke) and can be snapped together. It should be also possible to have several mask gradients on the same object. When a new mask gradient is created, the tool would add a new white rectangle covering the whole object (perhaps even with some margins) to its mask and create/display gradient from white to transparent on it.
In a similar vein, we should enable the Node tool to edit both the object itself and its clipping path at the same time, probably displaying the clippath with a different color/shape of nodes. However, for this to happen, we first need to enable this tool to edit more than one nodepath at the same time. While cubmersome, this is not really so difficult, and it is in fact near the top of my TODO.
Thoughts?
On Thu, 25 Jan 2007 14:40:45 -0400, "bulia byak" <buliabyak@...400...> wrote:
In a similar vein, we should enable the Node tool to edit both the object itself and its clipping path at the same time, probably displaying the clippath with a different color/shape of nodes.
I really like this idea. We should probably also draw the outline of the clipping path shape when editing.
-mental
MenTaLguY wrote:
On Thu, 25 Jan 2007 14:40:45 -0400, "bulia byak" <buliabyak@...400...> wrote:
In a similar vein, we should enable the Node tool to edit both the object itself and its clipping path at the same time, probably displaying the clippath with a different color/shape of nodes.
I really like this idea. We should probably also draw the outline of the clipping path shape when editing.
The ability to draw those outlines will also be useful for blurred objects and objects that have live path effects applied. :-)
Aaron Spike
participants (11)
-
unknown＠example.com -
Aaron Spike -
Alan Horkan -
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
Esteban Barahona -
Jon A. Cruz -
Jon Phillips -
Joshua A. Andler -
MenTaLguY