3:34 p.m.
FYI: I'm in the middle of listening, but there is a comparison of Xara
and Inkscape. http://www.linuxactionshow.com/?p=77
-Josh
10:11 p.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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
10:38 p.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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.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
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
--
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...
11:34 p.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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
11:48 p.m.
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
11:57 p.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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."
12:17 a.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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
Inkscape. Draw Freely.
http://www.inkscape.org
2:07 a.m.
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
2:46 a.m.
New subject: Cairo plan? (was Re: Xara and Inkscape comparison on Linux Action Show)
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
2:58 a.m.
New subject: Cairo plan? (was Re: Xara and Inkscape comparison on Linux Action Show)
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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
3:13 a.m.
New subject: Cairo plan? (was Re: Xara and Inkscape comparison on Linux Action Show)
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
4:20 a.m.
New subject: Cairo plan? (was Re: Xara and Inkscape comparison on Linux Action Show)
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
--
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...
7:35 p.m.
New subject: Cairo plan? (was Re: Xara and Inkscape comparison on Linux Action Show)
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
11:46 p.m.
New subject: Cairo plan? (was Re: Xara and Inkscape comparison on Linux Action Show)
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
--
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...
4:23 a.m.
New subject: Cairo plan? (was Re: Xara and Inkscape comparison on Linux Action Show)
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&CI...
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
--
http://www.zensui.org
12:42 a.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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
11:56 p.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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&...
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
11:59 p.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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,
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&...
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
-------------------------------------------------------------------------
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&CI...
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
--
http://www.zensui.org
12:38 a.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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,
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&...
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.
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
12:50 a.m.
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/
1:51 a.m.
New subject: Xara and Inkscape comparison on Linux Action Show
On Mon, 2007-01-22 at 15:34 -0800, Bryce Harrington wrote:
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.
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
7:04 p.m.
New subject: 0.46 development goals
On Mon, Jan 22, 2007 at 08:51:53PM -0500, MenTaLguY wrote:
On Mon, 2007-01-22 at 15:34 -0800, Bryce Harrington wrote:
> 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.
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
7:18 p.m.
New subject: 0.46 development goals
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
7:32 p.m.
New subject: 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.
* 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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
8:30 p.m.
New subject: 0.46 development goals
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
9:42 p.m.
New subject: 0.46 development goals
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
1. 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.
2. 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)
3. definitions of the aforementioned rules and value domains
All string-valued properties already have their accepted values listed
in enums.
4. 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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
10:57 p.m.
New subject: 0.46 development goals
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
11:26 p.m.
New subject: 0.46 development goals
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(a)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
2:25 a.m.
New subject: 0.46 development goals
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(a)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
5:04 a.m.
New subject: 0.46 development goals
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.
--
Alan
2:25 a.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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...
2:22 a.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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):
>
> 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&CI...
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
--
http://www.zensui.org
2:57 a.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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&CI...
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
--
http://www.zensui.org
--
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...
2:50 a.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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
3:49 a.m.
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(a)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).
--
Alan
2:02 p.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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
8:56 p.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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 :)
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
3:57 a.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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.
10:49 p.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
11:14 p.m.
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.
11:28 p.m.
New subject: Xara and Inkscape comparison on Linux Action Show
is this a merge of FOSS projects?! I will gladly beta-test this "monster" on
my Mac... far... awaaay in the future...
11:35 p.m.
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
11:43 p.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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
--
http://www.zensui.org
11:38 p.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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
6:40 p.m.
New subject: Xara and Inkscape comparison on Linux Action Show
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:
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.
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?
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
7:03 p.m.
New subject: Xara and Inkscape comparison on Linux ActionShow
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
7:11 p.m.
New subject: Xara and Inkscape comparison on Linux ActionShow
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
6136
days inactive
6157
days old
inkscape-devel@lists.inkscape.org
47 comments
11 participants
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