Now in CVS:
Gradient editing on canvas is now available, much more convenient and powerful than the old way of dragging gradient knots in the Fill&Stroke dialog.
o Any number of selected objects can simultaneously display handles and direction lines for their linear and radial gradients (in the objects' fills or strokes). You can drag these handles directly in the drawing, to interactively adjust gradient positions.
o Gradient handles can be enabled in the Node tool, shape tools, Text tool, and Dropper tool (on by default), as well as in Selector and Zoom tools (off by default). Use the Inkscape Preferences dialog to change this.
o Any gradient handle, if dragged close to a handle of another gradient, will merge with that handle (drag with Shift to prevent merging). Dragging such a merged handle will adjust any number of gradients attached to it. To separate merged handles, drag them away one by one with Shift.
o Radial gradients display handles in the center and at the ends of two radii, which allows you to move, rotate, squeeze, or stretch the gradient to form an arbitrary ellipse. Also, you can independently adjust the focus of the gradient; drag the central handle with Shift to separate the focus handle.
o When dragged, handles will snap to the edges and the central axes of the bounding boxes of all selected objects (drag with Shift to prevent snapping).
o Dragging with Ctrl will snap the angle of the linear or radial gradient to the user-settable angle increments (default is 15 degrees). The center of a radial gradient, dragged with Ctrl, will be constrained to horizontal and vertical movement relative to its previous position. When dragged with Ctrl+Alt, a handle moves along the gradient direction or its perpendiculars, allowing you e.g. to stretch or squeeze a linear gradient without disturbing its angle.
Overall, this is a major usability milestone, something I dreamed to do since Sodipodi times. Gradients are one of the most widely used features in Inkscape, and now they are finally made usable (well, almost - see below).
The old gradient position widget in Fill&stroke remains for now (and still works), but I plan to remove it as soon as the new on-canvas editing is sufficiently tested. I would welcome any feedback on the new feature.
Next in my plans: A Gradient tool, which will allow you to actually create new gradients by dragging (at the moment you still need to open Fill&stroke to switch an object to gradient) as well as adjust most gradient settings in its controls bar at the top of the window. In that tool, the selected gradient handle will be moveable by arrow keys (with all the usual modifiers), and setting any color via Fill&stroke, palette, dropper, or Paste style will be applied to the selected handle's gradient stop (instead of the entire selected object).
Sounds brilliant Bulia. Perhaps you could put a screenshot on the site?
Cheers Jon
bulia byak wrote:
Now in CVS:
Gradient editing on canvas is now available, much more convenient and powerful than the old way of dragging gradient knots in the Fill&Stroke dialog.
o Any number of selected objects can simultaneously displayhandles and direction lines for their linear and radial gradients (in the objects' fills or strokes). You can drag these handles directly in the drawing, to interactively adjust gradient positions.
o Gradient handles can be enabled in the Node tool, shapetools, Text tool, and Dropper tool (on by default), as well as in Selector and Zoom tools (off by default). Use the Inkscape Preferences dialog to change this.
o Any gradient handle, if dragged close to a handle ofanother gradient, will merge with that handle (drag with Shift to prevent merging). Dragging such a merged handle will adjust any number of gradients attached to it. To separate merged handles, drag them away one by one with Shift.
o Radial gradients display handles in the center and at theends of two radii, which allows you to move, rotate, squeeze, or stretch the gradient to form an arbitrary ellipse. Also, you can independently adjust the focus of the gradient; drag the central handle with Shift to separate the focus handle.
o When dragged, handles will snap to the edges and thecentral axes of the bounding boxes of all selected objects (drag with Shift to prevent snapping).
o Dragging with Ctrl will snap the angle of the linear orradial gradient to the user-settable angle increments (default is 15 degrees). The center of a radial gradient, dragged with Ctrl, will be constrained to horizontal and vertical movement relative to its previous position. When dragged with Ctrl+Alt, a handle moves along the gradient direction or its perpendiculars, allowing you e.g. to stretch or squeeze a linear gradient without disturbing its angle.
Overall, this is a major usability milestone, something I dreamed to do since Sodipodi times. Gradients are one of the most widely used features in Inkscape, and now they are finally made usable (well, almost - see below).
The old gradient position widget in Fill&stroke remains for now (and still works), but I plan to remove it as soon as the new on-canvas editing is sufficiently tested. I would welcome any feedback on the new feature.
Next in my plans: A Gradient tool, which will allow you to actually create new gradients by dragging (at the moment you still need to open Fill&stroke to switch an object to gradient) as well as adjust most gradient settings in its controls bar at the top of the window. In that tool, the selected gradient handle will be moveable by arrow keys (with all the usual modifiers), and setting any color via Fill&stroke, palette, dropper, or Paste style will be applied to the selected handle's gradient stop (instead of the entire selected object).
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
FANTASTIC!!
but of course I've to remark some things :) It would maybe be nice if the nodes had the color that is applied, but that's not importand, since you see it anyways. More importantly: The stops inbetween the end nodes should be configurable as well imho... Also: the snapping of the nodes is real cool, but i think they should snap, when you press shift and not the other way around.
There's probably a lot more, but I'm still to facinated by the new feature :)
Thank you!
David
On Sat, 19 Feb 2005 17:26:13 +0100, David Christian Berg <david@...407...> wrote:
but of course I've to remark some things :) It would maybe be nice if the nodes had the color that is applied, but that's not importand, since you see it anyways.
I think the gradient handles should always use the same color, to easily differentiate them from path nodes, shape handles etc. I haven't yet decided which.
More importantly: The stops inbetween the end nodes should be configurable as well imho...
Eventually yes, that would make the gradient editor dialog mostly unnecessary.
Also: the snapping of the nodes is real cool, but i think they should snap, when you press shift and not the other way around.
With the grid, you press Shift to not snap. I'd like to keep it if only for consistency.
Hi bulia,
that sounds very nice, but I have problems to compile CVS.
Tobias
-------------------------------------------------------------------
make all-recursive make[1]: Entering directory `/home/tobias/cvs/inkscape' Making all in src make[2]: Entering directory `/home/tobias/cvs/inkscape/src' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/freetype2 -I/usr/include/freetype2 -I/usr/X11R6/include -DPOTRACE="potrace" -DXTHREADS -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/sigc ++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT gradient-chemistry.o -MD -MP -MF ".deps/gradient-chemistry.Tpo" \ -c -o gradient-chemistry.o `test -f 'gradient-chemistry.cpp' || echo './'`gradient-chemistry.cpp; \ then mv -f ".deps/gradient-chemistry.Tpo" ".deps/gradient-chemistry.Po"; \ else rm -f ".deps/gradient-chemistry.Tpo"; exit 1; \ fi gradient-chemistry.cpp: In function `void sp_gradient_set_coords(SPGradient*, unsigned int, NR::Point, bool, NR::Matrix)': gradient-chemistry.cpp:487: error: parse error before `*' token gradient-chemistry.cpp:494: error: no match for 'operator*' in ' NR::operator*(const NR::Matrix&, const NR::Matrix&)((&i2d)) * move' libnr/nr-matrix-ops.h:51: error: candidates are: NR::Matrix NR::operator*(const NR::Matrix&, const NRMatrix&) libnr/nr-matrix-ops.h:48: error: NR::Matrix NR::operator*(const NR::Matrix&, const NR::Matrix&) libnr/nr-matrix-ops.h:26: error: NR::Point NR::operator*(const NR::Point&, const NR::Matrix&) libnr/nr-point-ops.h:45: error: NR::Point NR::operator*(double, const NR::Point&) gradient-chemistry.cpp:484: warning: unused variable `double move_angle' gradient-chemistry.cpp:485: warning: unused variable `double move_stretch' gradient-chemistry.cpp:506: error: parse error before `*' token gradient-chemistry.cpp:513: error: no match for 'operator*' in ' NR::operator*(const NR::Matrix&, const NR::Matrix&)((&i2d)) * move' libnr/nr-matrix-ops.h:51: error: candidates are: NR::Matrix NR::operator*(const NR::Matrix&, const NRMatrix&) libnr/nr-matrix-ops.h:48: error: NR::Matrix NR::operator*(const NR::Matrix&, const NR::Matrix&) libnr/nr-matrix-ops.h:26: error: NR::Point NR::operator*(const NR::Point&, const NR::Matrix&) libnr/nr-point-ops.h:45: error: NR::Point NR::operator*(double, const NR::Point&) gradient-chemistry.cpp:503: warning: unused variable `double move_angle' gradient-chemistry.cpp:504: warning: unused variable `double move_stretch' make[2]: *** [gradient-chemistry.o] Error 1 make[2]: Leaving directory `/home/tobias/cvs/inkscape/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/tobias/cvs/inkscape' make: *** [all] Error 2
On Sat, 19 Feb 2005 09:22:21 +0100, Tobias Jakobs <tobias.jakobs@...128...> wrote:
Hi bulia,
that sounds very nice, but I have problems to compile CVS.
That seems to be a problem with gcc 3.3. With Kees' help I fixed it yesterday night. Please update your CVS and report the results.
Hi,
Le Sat, 19 Feb 2005 12:39:48 -0400, bulia byak a écrit :
On Sat, 19 Feb 2005 09:22:21 +0100, Tobias Jakobs <tobias.jakobs@...128...> wrote:
Hi bulia,
that sounds very nice, but I have problems to compile CVS.
That seems to be a problem with gcc 3.3. With Kees' help I fixed it yesterday night. Please update your CVS and report the results.
I had the same problem yesterday, and now inkscape compiles fine.
Emmanuel.
On Fri, 18 Feb 2005 20:57:30 -0400, bulia byak <buliabyak@...400...> wrote:
Now in CVS:
Gradient editing on canvas is now available, much more convenient and powerful than the old way of dragging gradient knots in the Fill&Stroke dialog.
<snip/>
Very cool! Can't wait to test it :)
All I can dream about now is that thrice daily snapshots will be back again.
Alexandre
On Sat, Feb 19, 2005 at 05:46:57PM +0300, Alexandre Prokoudine wrote:
All I can dream about now is that thrice daily snapshots will be back again.
Eep. If you notice a significant lag on the daily win32 snaps, please email the devel list. I'll check on them.
On Sat, 19 Feb 2005 09:16:14 -0800, Kees Cook <inkscape@...62...> wrote:
On Sat, Feb 19, 2005 at 05:46:57PM +0300, Alexandre Prokoudine wrote:
All I can dream about now is that thrice daily snapshots will be back again.
Eep. If you notice a significant lag on the daily win32 snaps, please email the devel list. I'll check on them.
Well, I'm talking about
LATEST.tar.gz 12-Feb-2005 18:02 6.1M
at http://cortijodelrio.net/~inkscape/
Alexandre
Alexandre Prokoudine wrote:
On Sat, 19 Feb 2005 09:16:14 -0800, Kees Cook <inkscape@...62...> wrote:
On Sat, Feb 19, 2005 at 05:46:57PM +0300, Alexandre Prokoudine wrote:
All I can dream about now is that thrice daily snapshots will be back again.
Eep. If you notice a significant lag on the daily win32 snaps, please email the devel list. I'll check on them.
Well, I'm talking about
LATEST.tar.gz 12-Feb-2005 18:02 6.1M
at http://cortijodelrio.net/~inkscape/
Alexandre
I have been generating builds on an almost daily basis again here: http://troi.hous.es3.titan.com/inkscape/builds/
Here is today's: http://troi.hous.es3.titan.com/inkscape/builds/Inkscape0502190935.zip
Bob
On Sat, 19 Feb 2005 22:33:41 -0600, Bob Jamison <rwjj@...127...> wrote:
I have been generating builds on an almost daily basis again here: http://troi.hous.es3.titan.com/inkscape/builds/
Here is today's: http://troi.hous.es3.titan.com/inkscape/builds/Inkscape0502190935.zip
Uhm, 17 MBytes? This must be windows binary build :) I was talking about sources :)
Well, nevermind, I can wait.
Alexandre
Bob
On Fri, 18 Feb 2005, bulia byak wrote:
Date: Fri, 18 Feb 2005 20:57:30 -0400 From: bulia byak <buliabyak@...400...> To: Inkscape Devel List inkscape-devel@lists.sourceforge.net, Inkscape users list inkscape-user@lists.sourceforge.net Subject: [Inkscape-devel] NEW: on-canvas gradient editing
Now in CVS:
Gradient editing on canvas is now available, much more convenient and powerful than the old way of dragging gradient knots in the Fill&Stroke dialog.
That is very cool. There is a bit of lag between the spot/handle and when the axis/spokes move which makes it feel a bit sluggish but otherwise this is great. It is particularly trippy if you wave your mouse around while using repeating gradient.
The old gradient position widget in Fill&stroke remains for now (and still works), but I plan to remove it as soon as the new on-canvas editing is sufficiently tested. I would welcome any feedback on the new feature.
I expect you can safely remove most of it but it might be useful to have a more controlled way to adjust gradients in addition to the interactive editing...
Next in my plans: A Gradient tool, which will allow you to actually
... but it sounds like the tool you have planned will provide for most of those issues.
While I'm taking a few minutes to try out the latest and greatest test build I have noticed a few unrelated oddities: There definately should not be ((parenthesis)) used in menu labels. Singular or plural, pick one (one or more can be implied).
Document Preferences could be labelled as "Document Properties" or simply Properties (it is in the file menu so it is implied that it is the Properties of the current file). It would help disambiguate it from the standard Preferences (and allow a more terse label). Looking at it more closely it is actually a combination of what other applications would call "Page Setup" and Metadata corresponds to what most applications simply refer to as Properties.
There are other things I find disconcerting about Inkscape and rough edges here and there but I'd be just repeating myself to bring them up again now so I'll leave it at that.
The new interactive gradient functionality is great and I'm sure it will draw even more people to Inkscape (no pun intended).
Sincerely
Alan Horkan
Inkscape, Draw Freely http://inkscape.org Abiword is Awesome http://abisource.com
On Sat, 19 Feb 2005 20:00:49 +0000 (GMT), Alan Horkan <horkana@...44...> wrote:
That is very cool. There is a bit of lag between the spot/handle and when the axis/spokes move which makes it feel a bit sluggish
Yeah, I know. I hope to fix this today, I think I now know how.
The old gradient position widget in Fill&stroke remains for now (and still works), but I plan to remove it as soon as the new on-canvas editing is sufficiently tested. I would welcome any feedback on the new feature.
I expect you can safely remove most of it but it might be useful to have a more controlled way to adjust gradients in addition to the interactive editing...
Hmm. What is "more controlled" about it? It's significanly less precise and much harder to control, in all aspects. (I will only remove the position control, of course, not the gradient list.)
By the way, not only is the old gradient position widget outrageously inconvenient, it was also significuntly less straightforward to program and therefore more prone to nasty surprises. I consider it a prime example of how NOT to borrow ideas from commercial software, because apparently the only reason for its existence was the fact that CorelDraw edits gradients the same way. Such an awful amount of programmer's effort and users' frustration went into it, it's mindboggling... even though better interfaces (Xara) already existed when Sodipodi started.
My version of on-screen editing is vaguely similar to Xara, but already improves on it in some ways (e.g. Xara cannot merge gradient handles).
While I'm taking a few minutes to try out the latest and greatest test build I have noticed a few unrelated oddities: There definately should not be ((parenthesis)) used in menu labels. Singular or plural, pick one (one or more can be implied).
Is there a style rule for this somewhere, or is it your opinion?
Document Preferences could be labelled as "Document Properties" or simply Properties (it is in the file menu so it is implied that it is the Properties of the current file). It would help disambiguate it from the standard Preferences (and allow a more terse label).
I disagree. "Preferences" and "properties" sound like synonyms. Having them side-by-side is very confusing. "Inkscape preferences" and "Document preferences" explain exactly what they are, stress both their similarity and their difference, and are totally unambiguous.
On Saturday 19 February 2005 21:20, bulia byak wrote:
On Sat, 19 Feb 2005 20:00:49 +0000 (GMT), Alan Horkan
<horkana@...44...> wrote:
That is very cool. There is a bit of lag between the spot/handle and when the axis/spokes move which makes it feel a bit sluggish
Yeah, I know. I hope to fix this today, I think I now know how.
The old gradient position widget in Fill&stroke remains for now (and still works), but I plan to remove it as soon as the new on-canvas editing is sufficiently tested. I would welcome any feedback on the new feature.
I expect you can safely remove most of it but it might be useful to have a more controlled way to adjust gradients in addition to the interactive editing...
Hmm. What is "more controlled" about it? It's significanly less precise and much harder to control, in all aspects. (I will only remove the position control, of course, not the gradient list.)
By the way, not only is the old gradient position widget outrageously inconvenient, it was also significuntly less straightforward to program and therefore more prone to nasty surprises. I consider it a prime example of how NOT to borrow ideas from commercial software, because apparently the only reason for its existence was the fact that CorelDraw edits gradients the same way. Such an awful amount of programmer's effort and users' frustration went into it, it's mindboggling... even though better interfaces (Xara) already existed when Sodipodi started.
My version of on-screen editing is vaguely similar to Xara, but already improves on it in some ways (e.g. Xara cannot merge gradient handles).
Can I ask a Q here at this point? Sorry, I need to get into building Inkscape CVS so I havent seen it yet.
IE, how have you handled large gradient "lengths" where the item its applied to is much smaller than the gradient vector? This is one thing we have had trouble with importing SVGs into Scribus where the vector is much larger than the item. Currently a limitation of Scribus gradients is that the end points of the vector must be within the boundaries of the object, which was never the case before in Inkscape IIRC. We can edit the gradient vector on the canvas in 1.3 though. Hopefully to achieve this you wont have to zoom right out. Of course, theres argument for just changing the end points colours but that will become inaccurate if applying the same gradient to multiple objects.
Craig
On Sat, 19 Feb 2005 21:34:55 +0100, Craig Bradney <cbradney@...242...> wrote:
IE, how have you handled large gradient "lengths" where the item its applied to is much smaller than the gradient vector? This is one thing we have had trouble with importing SVGs into Scribus where the vector is much larger than the item. Currently a limitation of Scribus gradients is that the end points of the vector must be within the boundaries of the object, which was never the case before in Inkscape IIRC.
It was always possible to extend a gradient beyond the object. However it was rather inconvenient before, because you had to drag a handle beyond the edges of the dialog. Now it is much easier to do: you just drag your gradient points anywhere on the canvas, be it inside the object or outside it.
SVG has no limitations on where the gradient ends may be, and it is very useful in many situations to have them outside of the object. For example, I often need several objects to have exactly the same gradient vector, which for some of them will lie outside and for some inside. I would even say that in a typical artwork, the _majority_ of gradients have their controls somewhere outside of their objects.
So, please, remove this limitation in Scribus, it's a major roadblock for importing SVG artwork into it.
We can edit the gradient vector on the canvas in 1.3 though.
Cool, I hope you'll find it useful to examine Inkscape's way of doing it, and maybe suggest something for us, or borrow something from us, or both :)
Of course, theres argument for just changing the end points colours but that will become inaccurate if applying the same gradient to multiple objects.
No, of course, changing colors is a very clumsy workaround for true out-of-object handles. Besides it won't help at all with radial gradients or even with non-horizontal-and-non-vertical linear ones.
On Sat, 19 Feb 2005, bulia byak wrote:
Date: Sat, 19 Feb 2005 16:20:39 -0400 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: on-canvas gradient editing
On Sat, 19 Feb 2005 20:00:49 +0000 (GMT), Alan Horkan <horkana@...44...> wrote:
That is very cool. There is a bit of lag between the spot/handle and when the axis/spokes move which makes it feel a bit sluggish
Yeah, I know. I hope to fix this today, I think I now know how.
Great.
The old gradient position widget in Fill&stroke remains for now (and still works), but I plan to remove it as soon as the new on-canvas editing is sufficiently tested. I would welcome any feedback on the new feature.
I expect you can safely remove most of it but it might be useful to have a more controlled way to adjust gradients in addition to the interactive editing...
Hmm. What is "more controlled" about it? It's significanly less
The current gradient system isn't very controlled but I mean that in general a dialog with input widgets like spinners/sliders allow users to specify exactly what they want with much greater precision. Even with a very steady hand it is not always possible to get exactly what you want using a more interactive tool. (Sorry for not being clearer.)
While I'm taking a few minutes to try out the latest and greatest test build I have noticed a few unrelated oddities: There definately should not be ((parenthesis)) used in menu labels. Singular or plural, pick one (one or more can be implied).
Is there a style rule for this somewhere, or is it your opinion?
I cannot believe you are asking me to verify that.
Inkscape has an Object menu that applies to one or more objects. It is not labelled Object(s).
Have you ever seen a popular application with Parenthesis in the menus before?
Do I also need to explain why abbreviations in menu labels are not a good idea?
If I was willing to spend a considerable amount of time I could probably find some to find suitable reference in the the Gnome HIG or Gnome Documentation Style Guide but it such a simple thing it will be dificult to find anything specifically telling you not to do it. (I know all too well that it is poor writing style to use parenthesis exactly because I do it all the time and it isn't very aesthetically pleasing either to have excessive punctuation.)
Document Preferences could be labelled as "Document Properties" or simply Properties (it is in the file menu so it is implied that it is the Properties of the current file). It would help disambiguate it from the standard Preferences (and allow a more terse label).
I disagree. "Preferences" and "properties" sound like synonyms. Having them side-by-side is very confusing. "Inkscape preferences" and "Document preferences" explain exactly what they are, stress both their similarity and their difference, and are totally unambiguous.
You are looking at this one in isolation thinking only of Inkscape. I'm looking at it in terms of Gnome and a variety of other applications and I'm thinking of consistancy and many applications have an item for "Page Setup" grouped with Print and Print Preview (some apps like OpenOffice put this elsewhere like under formatting) and a Properties item (metadata is still a technical term even if you and I might be using it all the time).
While writing my previous mail I was going to say that if Inkscape were following the Gnome Human Interface Guidelines then Preferences would be in the Edit menu but the Edit menu in Inkscape is very crowded at the moment and I'm fairly sure I've already pointed that out so I was going to leave it for another day.
Seeing Inkscape in the menu label for anything other than "About Inkscape" (and even there it is redundant) just seems wrong to me.
I've done my bit, I've provided feedback as best I can. Make of it what you will.
Sincerely
Alan Horkan
Free SVG Clip Art http://OpenClipArt.org Inkscape, Draw Freely http://inkscape.org Abiword is Awesome http://abisource.com
On Sat, 2005-02-19 at 16:20 -0400, bulia byak wrote: Hi Bulia!
First of all, thanks for the on-canvas effort. While my Inkscape is still compiling for me to test it, I have to reply to the bits I have something to say ;)
Document Preferences could be labelled as "Document Properties" or simply Properties (it is in the file menu so it is implied that it is the Properties of the current file). It would help disambiguate it from the standard Preferences (and allow a more terse label).
I disagree. "Preferences" and "properties" sound like synonyms. Having them side-by-side is very confusing. "Inkscape preferences" and "Document preferences" explain exactly what they are, stress both their similarity and their difference, and are totally unambiguous.
In fact I find having the items Inkscape Preferences and Document Preferences next to each other bleed my eyes every time I enter the file menu. I don't think I've seen object *preferences* in an application before. Preferences to my knowledge are always linked to *behavior*.
There's been some discussions wrt settings versus preferences where the difference isn't that obvious, however preferences and properties are definitely not synonyms. Preference is subject to change user by user. A user changes application preferences to better suit his/her workflow.
I had to look up property in a dictionary to get a clear definition since I ended up in tautologies ;)
"That which is proper to anything; a peculiar quality of a thing; that which is inherent in a subject, or naturally essential to it; an attribute; as, sweetness is a property of sugar."
You want to change document properties to change its measurable attributes, not how it should behave if you poke it. "I like them big" does sound like a preference rather than a property but let's just stop confusing you ;)
I very much agree with Alan File>Inkscape Preferences and File>Document Preferences are very alien both when it comes to menu placement and the label itself. Since you already use File then File>Properties makes so much more sense especially when you already have Object>Properties (well it's object>object properties :/).
Edit>Preferences is the proper thing to do if you want Gnome users to be familiar with Inkscape's interface, but doing that requires to do a radical thing restructure the menus completely which is quite a thing, but definitely worth doing if you compare GIMP1.2 and 2.0.
I hope this sparks up some interest in making the menus easier to navigate and natural. I sure hope I can bloody detach from the day-to-day work to actually contribute something :/
Anyway thanks for the non-stopping hacking effort!
On Sun, 20 Feb 2005 02:22:19 +0100, Jakub Steiner <jimmac@...659...> wrote:
Edit>Preferences is the proper thing to do if you want Gnome users to be familiar with Inkscape's interface,
It always struck me as something extremely odd that the global preferences of a program are in "Edit", just below Copy and Paste. What's the connection? I fail to see it. Yeah, I know, everyone does that. But it does not make it less stupid in my opinion. And in other programs, it's in Tools instead, which isn't any better. I always swear when I'm trying to find it on one of these menus while it's (of course!) in another.
In my experience, most users of most programs have very vague idea of what are the various kinds of properties and preferences. In many cases they are surprised to find that some of those thingies they changed are saved with the document and some are with the program itself. And most programs don't make it easier for them to figure this out.
A typical user goes like this, "I think it must be settable somewhere... OK, let's try Properties... Nope... Maybe Configuration... No. Where did I see it last time? Ah! It also has this Preferences thing, dammit. Yeah, there it is. OK, let's hope it will now remember it and I won't have to set it again." It's more trial-and-error than anything else. And it's frustrating.
So, in an attempt to fix this, I put the two configuration commands next to each other so that: 1) the user is instantly aware that there are two similar-but-different commands for setting various things; 2) the user is given an idea of how they are different (the statusbar tips explain that document preferences are saved with the document); 3) the user does not need to hunt these commands down in different menus. So, I think it's much easier to understand and remember it this way.
I don't want to start a flamewar, so if the consensus is that we must change that, let it be. I just wanted to explain my reasoning.
BULIA THIS IS AWESOME!!!!! no really.. this is HUGE!!!!!! it will be so much easier to create artwork with technically complex gradient compositions !!
now that its easy to change bends in gradients... im going to play with some chrome... chrome... chrome....
/me does a little dance and runs out the door to tell friends
bulia byak wrote:
On Sun, 20 Feb 2005 02:22:19 +0100, Jakub Steiner <jimmac@...659...> wrote:
Edit>Preferences is the proper thing to do if you want Gnome users to be familiar with Inkscape's interface,
It always struck me as something extremely odd that the global preferences of a program are in "Edit", just below Copy and Paste. What's the connection? I fail to see it. Yeah, I know, everyone does that. But it does not make it less stupid in my opinion. And in other programs, it's in Tools instead, which isn't any better. I always swear when I'm trying to find it on one of these menus while it's (of course!) in another.
i think we can learn form other projects. Mozilla people had a similar dilemma in Firefox: traditionally, Netscape and Mozilla Suite used Edit>Preferences (which is consistent with Gnome). in the desire to attract Windows people, they copied the Internet Explorer layout and moved to Tools>Options. the old user base and Linux people was outraged and a bad compromise was reached: now Firefox has two different menu layouts, one for Windows, with Tools>Options and another for Linux, with Edit>Preferences (don't know about Mac).
and as a personal opinion, i think it make sense, because you Edit the Preferences
Nicu Buculei wrote:
bulia byak wrote:
On Sun, 20 Feb 2005 02:22:19 +0100, Jakub Steiner <jimmac@...659...> wrote:
Edit>Preferences is the proper thing to do if you want Gnome users to be familiar with Inkscape's interface,
It always struck me as something extremely odd that the global preferences of a program are in "Edit", just below Copy and Paste. What's the connection? I fail to see it. Yeah, I know, everyone does that. But it does not make it less stupid in my opinion. And in other programs, it's in Tools instead, which isn't any better. I always swear when I'm trying to find it on one of these menus while it's (of course!) in another.
i think we can learn form other projects. Mozilla people had a similar dilemma in Firefox: traditionally, Netscape and Mozilla Suite used Edit>Preferences (which is consistent with Gnome). in the desire to attract Windows people, they copied the Internet Explorer layout and moved to Tools>Options. the old user base and Linux people was outraged and a bad compromise was reached: now Firefox has two different menu layouts, one for Windows, with Tools>Options and another for Linux, with Edit>Preferences (don't know about Mac).
and as a personal opinion, i think it make sense, because you Edit the Preferences
This is what the HIG says about the edit menu: ------------
The Edit menu contains items relating to editing both the document (clipboard handling, search and replace, and inserting special objects) and the user's preferences. Preferences are edited here rather than on a Settings menu, because:
*
most applications' preferences windows are accessed via a single menu tem, and single-item menus offer poor usability
*
most applications already contain a suitable Edit menu.
----------- http://developer.gnome.org/projects/gup/hig/2.0/menus-standard.html#menu-sta...
I think it would be natural to find preferences in the edit menu, just as my other apps. I might be wrong on this, but I think the ongoing gimp menu reorganisation puts edit in preferences too. Doing it the firefox way sound like a good solution. - Andreas Nilsson
On Sun, 20 Feb 2005 11:52:38 +0100, Andreas Nilsson <nisses.mail@...563...> wrote:
The Edit menu contains items relating to editing both the document (clipboard handling, search and replace, and inserting special objects) and the user's preferences. Preferences are edited here rather than on a Settings menu, because:
Wow, I love this reasoning. It basically says, put it on Edit because Edit exists and because you can't put it in a menu of its own. Clever.
Now, putting it to File is of course not much better, but at least it is compliant with the idea that File has items that control the application as a whole (such as Exit), which seems more relevant for global preferences.
On Sun, Feb 20, 2005 at 11:52:38AM +0100, Andreas Nilsson wrote:
This is what the HIG says about the edit menu:
The Edit menu contains items relating to editing both the document (clipboard handling, search and replace, and inserting special objects) and the user's preferences.
I think it would be natural to find preferences in the edit menu, just as my other apps. I might be wrong on this, but I think the ongoing gimp menu reorganisation puts edit in preferences too. Doing it the firefox way sound like a good solution.
I tended to agree with Bulia about it's placement under the File menu. I've always felt that all the application-level stuff should go there.
However, the fact that Edit>Preferences is a standard and appears to be becoming more of a standard trumps that. Particularly with the HIG specifying the position. I think that since we emphasize compliance to the HIG, and since it's listed in it, it seems fairly clear cut. If GIMP and Scribus will also be placing it under Edit, then I think that too is a compelling reason for placing it there.
It's also an excellent point that we have both Document and Application preferences (or properties), and having them in two separate menus could be confusing. However, I think other applications like OpenOffice, etc. also have this dichotomy; we could do well to follow their approach, since at least it'll be consistent across open source apps.
Bryce
On Sunday 20 February 2005 19:11, Bryce Harrington wrote:
On Sun, Feb 20, 2005 at 11:52:38AM +0100, Andreas Nilsson wrote:
This is what the HIG says about the edit menu:
The Edit menu contains items relating to editing both the document (clipboard handling, search and replace, and inserting special objects) and the user's preferences.
I think it would be natural to find preferences in the edit menu, just as my other apps. I might be wrong on this, but I think the ongoing gimp menu reorganisation puts edit in preferences too. Doing it the firefox way sound like a good solution.
I tended to agree with Bulia about it's placement under the File menu. I've always felt that all the application-level stuff should go there.
However, the fact that Edit>Preferences is a standard and appears to be becoming more of a standard trumps that. Particularly with the HIG specifying the position. I think that since we emphasize compliance to the HIG, and since it's listed in it, it seems fairly clear cut. If GIMP and Scribus will also be placing it under Edit, then I think that too is a compelling reason for placing it there.
Yes, we used to have it under Edit, and then we cleaned up the GUI for 1.2 and made a Setitngs menu as we had 5 settings areas (shortcuts, fonts etc). Now in 1.3 its back under Edit, Preferences as we have an all in one preferences dialog for the application. We have File->Document Setup for the document preferences.
Craig
Bryce Harrington wrote:
On Sun, Feb 20, 2005 at 11:52:38AM +0100, Andreas Nilsson wrote:
This is what the HIG says about the edit menu:
The Edit menu contains items relating to editing both the document (clipboard handling, search and replace, and inserting special objects) and the user's preferences.
I think it would be natural to find preferences in the edit menu, just as my other apps. I might be wrong on this, but I think the ongoing gimp menu reorganisation puts edit in preferences too. Doing it the firefox way sound like a good solution.
It's also an excellent point that we have both Document and Application preferences (or properties), and having them in two separate menus could be confusing. However, I think other applications like OpenOffice, etc. also have this dichotomy; we could do well to follow their approach, since at least it'll be consistent across open source apps.
Bryce
I don't think it is that confusing actually, because they adress two different things. Preferences how the program behave and Page Setup (or whatever it's called) properties for the current document. Having document properties close to the printing stuff in the file menu is also nice, because often when you print stuff, the document is a bit to big, or has to small margins and stuff like that so having it close to eachother feels natural. - Andreas Nilsson
On Sun, 20 Feb 2005, Bryce Harrington wrote:
Date: Sun, 20 Feb 2005 10:11:52 -0800 From: Bryce Harrington <bryce@...260...> To: Andreas Nilsson <nisses.mail@...563...> Cc: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: on-canvas gradient editing
On Sun, Feb 20, 2005 at 11:52:38AM +0100, Andreas Nilsson wrote:
This is what the HIG says about the edit menu:
The Edit menu contains items relating to editing both the document (clipboard handling, search and replace, and inserting special objects) and the user's preferences.
I think it would be natural to find preferences in the edit menu, just as my other apps. I might be wrong on this, but I think the ongoing gimp menu reorganisation puts edit in preferences too. Doing it the firefox way sound like a good solution.
I tended to agree with Bulia about it's placement under the File menu. I've always felt that all the application-level stuff should go there.
However, the fact that Edit>Preferences is a standard and appears to be becoming more of a standard trumps that. Particularly with the HIG specifying the position. I think that since we emphasize compliance to the HIG, and since it's listed in it, it seems fairly clear cut. If GIMP and Scribus will also be placing it under Edit, then I think that too is a compelling reason for placing it there.
Here is the bug report for the GIMP suggesting Edit, Preferences http://bugzilla.gnome.org/show_bug.cgi?id=157613
Maybe it was because it was me suggesting it or maybe it is because he saw straight through me and knew greater design implications of where I was trying to go with the idea.
Essentially in a CSDI app like the GIMP I want to duplicate most of the Toolbox items are also in the Diagram window so that I'm not forced to switch context to the Toolbox if I dont want to (something I already experimented with in Dia by getting the Help menu in both places). Duplication of menu items is generally not a good idea but The GIMP already duplicates most of the File menus, and a fair few of the Xtns items could be moved entirely to the image window. (So I may be on crack and Svens scepticism is probably well warranted.)
It's also an excellent point that we have both Document and Application preferences (or properties), and having them in two separate menus could be confusing. However, I think other applications like OpenOffice, etc. also have this dichotomy; we could do well to follow their approach, since at least it'll be consistent across open source apps.
As usual my bias is for consistency because I spend small amounts of time using lots of different applications whereas Bulia is an expert user who I'm sure knows just about everything there is to know about Inkscape inside and out.
I dont personally like the idea of putting preferences in differnt places on different platforms like firefox does but I'm still using Mozilla. The trade off is that you make windows users a little happier and do things they way they expect (consistency with windows) at the expense of consistency with Inkscape itself and the Gnome platform. Again I know where my bias lies and I'm trying to move away from the Microsoft way and I can understand the Firefox has different priorities and that I'm not really their target user.
So the question is who are the target users of Inkscape and what are the Inkscape priorities? (I'll leave that as a rhetorical question.)
Sincerely
Alan Horkan
Free SVG Clip Art http://OpenClipArt.org Dia is for Diagrams http://gnome.org/projects/dia/ Inkscape, Draw Freely http://inkscape.org Abiword is Awesome http://abisource.com
On Sat, 2005-02-19 at 21:48 -0400, bulia byak wrote:
A typical user goes like this, "I think it must be settable somewhere... OK, let's try Properties... Nope... Maybe Configuration... No. Where did I see it last time? Ah! It also has this Preferences thing, dammit. Yeah, there it is. OK, let's hope it will now remember it and I won't have to set it again." It's more trial-and-error than anything else. And it's frustrating.
That is exactly why such things need to be standardized. Since Inkscape is a multiplatform application, ideally it should follow Firefox' example and structure the menus depending on the platform specifications and usanses. Mac users will be looking for an "Inkscape" menu and "Preferences". Windows and GNOME users are used to "Edit>Preferences" even though it uses a wrong pattern of action>object instead of object>action. These issues have to be tackled globally for the whole platform and not application by application even though I see it's a lot harder change things.
There is so many ways a structure could make sense. To really have a user in mind, have *consistency with the rest of the platform* in mind.
And since I already mentioned Firefox, I have to express my utter amazement by the design of it. The application is stripped down to solve a basic set of tasks, keeping the complexity down as much as possible. Then it has means to extend its functionality with extensions. Specific functionality that is very useful to a group of people doesn't pollute the interface for everybody while making it easy for users to install an extension providing the functionality. Also it lowers the maintenance for the core application. I am hoping to see you guys invest in making a sane API for scriptability since an illustrator app is just screaming for people to write custom scrpits that automa so many tiring tasks.
And last but not least, as mentioned above, while sharing the core, each platform has a specific interface making it feel native on its host system. Users will find it easy to learn to use the application because it will feel "natural" to them.
Adding features surely is a noble goal. Looking back at why the Inkscape project started I hope the interest in usability isn't just marginal.
cheers
Jakub Steiner wrote:
That is exactly why such things need to be standardized. Since Inkscape is a multiplatform application, ideally it should follow Firefox' example and structure the menus depending on the platform specifications and usanses. Mac users will be looking for an "Inkscape" menu and "Preferences". Windows and GNOME users are used to "Edit>Preferences" even though it uses a wrong pattern of action>object instead of object>action. These issues have to be tackled globally for the whole platform and not application by application even though I see it's a lot harder change things.
There is so many ways a structure could make sense. To really have a user in mind, have *consistency with the rest of the platform* in mind.
i'm not thrilled by the Firefox approach, it makes the support difficult, one should ask the user what OS is using before directing him to the correct place in menu. the same for documentation: it should mention all possible locations for every supported OS.
On Sun, 2005-02-20 at 19:39 +0200, Nicu Buculei wrote:
Jakub Steiner wrote:
That is exactly why such things need to be standardized. Since Inkscape is a multiplatform application, ideally it should follow Firefox' example and structure the menus depending on the platform specifications and usanses. Mac users will be looking for an "Inkscape" menu and "Preferences". Windows and GNOME users are used to "Edit>Preferences" even though it uses a wrong pattern of action>object instead of object>action. These issues have to be tackled globally for the whole platform and not application by application even though I see it's a lot harder change things.
There is so many ways a structure could make sense. To really have a user in mind, have *consistency with the rest of the platform* in mind.
i'm not thrilled by the Firefox approach, it makes the support difficult, one should ask the user what OS is using before directing him to the correct place in menu. the same for documentation: it should mention all possible locations for every supported OS.
Well maintaining so many language versions sucks in a similar manner. The question is if it's worth it. I'm saying yes, that interface consistency is worth it.
The number of items that would be different is not too big. As far as I know the documentation now is XML that's processed with an XSLT stylesheet, so creating platform dependent version isn't all that complex really.
Let me reply to Bulia's comment on having some more sane structure than what the HIG suggests (or generally the Mac/... HIG, not sure if Windows have interface guidelines).
It may sound like a good idea to play on your own field if you think you can design a better structure. But look at MS Internet Explorer, they do the same -- the box model in CSS specifies the width and height doesn't include the padding of the box, so you need to be careful about using % units since padding is added to that. MS didn't like that idea and have width and height be defined so that padding is subtracted from this amount. While it may sound like it's making the % units more useful, the fact that only IE has this behavior makes all web designers cry.
Similarly Inkscape doesn't try to interpret SVG differently from what the SVG spec says. It does uses its own namespace to extend it, but whatever you save as SVG will be interpreted by a standard SVG renderer. You don't have circles defined differently than in SVG because it's more efficient (yes t would rock if I actualy knew enough to give a better example). Unfortunately there is no single standard, interface guidelines for all platforms, which makes this a little worse of a situation.
cheers
On Sun, 20 Feb 2005 18:57:21 +0100, Jakub Steiner <jimmac@...659...> wrote:
Let me reply to Bulia's comment on having some more sane structure than what the HIG suggests (or generally the Mac/... HIG, not sure if Windows have interface guidelines).
It may sound like a good idea to play on your own field if you think you can design a better structure. But look at MS Internet Explorer, they do the same -- the box model in CSS specifies the width and height doesn't include the padding of the box, so you need to be careful about using % units since padding is added to that. MS didn't like that idea and have width and height be defined so that padding is subtracted from this amount. While it may sound like it's making the % units more useful, the fact that only IE has this behavior makes all web designers cry.
This analogy does not work. Moving a command to a different menu is not the same as breaking HTML or SVG rules. I was just trying to make Inkscape more intuitive to work with.
Anyway, like I said, I'm not going to fight for it. I'm OK with placing the command into any menu with any name.
On Sun, 20 Feb 2005 18:09:07 +0100, Jakub Steiner <jimmac@...653...> wrote:
And since I already mentioned Firefox, I have to express my utter amazement by the design of it.
This analogy doesn't work either. Firefox must be transparent and simple, because it's used by millions, and used for a simple task of viewing pages. A vector editor is a very different thing with a very different audience. Editing a vector drawing is all about tweaking things. Why should we be afraid of letting people tweak things in preferences - if at the same time we allow and encourage them to tweak things on canvas in new and unexpected ways?
On Sunday 20 February 2005 19:38, bulia byak wrote:
On Sun, 20 Feb 2005 18:09:07 +0100, Jakub Steiner <jimmac@...653...> wrote:
And since I already mentioned Firefox, I have to express my utter amazement by the design of it.
This analogy doesn't work either. Firefox must be transparent and simple, because it's used by millions, and used for a simple task of viewing pages. A vector editor is a very different thing with a very different audience. Editing a vector drawing is all about tweaking things. Why should we be afraid of letting people tweak things in preferences - if at the same time we allow and encourage them to tweak things on canvas in new and unexpected ways?
Yeah, I think this is a very valid point. You have a target audience, you have to fit to that and not necessarily some HIG. Eg DTP is typically a very complicated area as can be vector or pixmap based graphics, and the users expect certain features from the GUI. Getting the balance right IS hard. Many have said the InDesign PDF export GUI is hard to manage, but love the Scribus one. This will be hard to keep as simple as we add more PDF 1.5 and 1.6 features in the future though.
That Firefox thing annoys me as I switch from my PCs to others' a lot, but having given them a better browser, its much less of an annoyance than spending hours removing spyware from friends and families and customers PCs.
Craig
On Sun, 2005-02-20 at 14:38 -0400, bulia byak wrote:
On Sun, 20 Feb 2005 18:09:07 +0100, Jakub Steiner <jimmac@...653...> wrote:
And since I already mentioned Firefox, I have to express my utter amazement by the design of it.
This analogy doesn't work either. Firefox must be transparent and simple, because it's used by millions, and used for a simple task of viewing pages. A vector editor is a very different thing with a very different audience. Editing a vector drawing is all about tweaking things. Why should we be afraid of letting people tweak things in preferences - if at the same time we allow and encourage them to tweak things on canvas in new and unexpected ways?
Sure, but I'm not sure you picked up the core of my message.
With a vector editor you have a very diverse user base. People will draw icons, create diagrams, draw schemas, blueprints. If you provide an easy way to extend the core functionality, you will make Inkscape a nice *platform* for people to focus on a very niche market/area without affecting people who don't give a heck about it.
cheers
On Sun, 20 Feb 2005, Jakub Steiner wrote:
Date: Sun, 20 Feb 2005 18:09:07 +0100 From: Jakub Steiner <jimmac@...653...> To: bulia byak <buliabyak@...400...> Cc: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: on-canvas gradient editing
On Sat, 2005-02-19 at 21:48 -0400, bulia byak wrote:
A typical user goes like this, "I think it must be settable somewhere... OK, let's try Properties... Nope... Maybe Configuration... No. Where did I see it last time? Ah! It also has this Preferences thing, dammit. Yeah, there it is. OK, let's hope it will now remember it and I won't have to set it again." It's more trial-and-error than anything else. And it's frustrating.
That is exactly why such things need to be standardized.
So many stantards to choose from ...
Since Inkscape is a multiplatform application, ideally it should follow Firefox' example and structure the menus depending on the platform specifications and usanses.
(nuances?)
Given the nature of Open Source someone will almost inevitably want to make these kind of platform specific changes so I suppose it makes sense to put in place the infrastructure that allows devlepers to manage it in a clean and maitainable way.
menu and "Preferences". Windows and GNOME users are used to "Edit>Preferences" even though it uses a wrong pattern of action>object instead of object>action. These issues have to be tackled globally for the whole platform and not application by application even though I see it's a lot harder change things.
There is so many ways a structure could make sense. To really have a user in mind, have *consistency with the rest of the platform* in mind.
Which platform do the Inkscape developers really want to promote?
Does following the microsoft way really benift the Firefox platform? It seems like it might or is that incidental to the success of firefox?
And since I already mentioned Firefox, I have to express my utter amazement by the design of it. The application is stripped down to solve a basic set of tasks, keeping the complexity down as much as possible.
Unfortunately I think they managed this poorly and threw the baby out with the bathwater. Years of experience were lost, and features are getting reimplmented badly and inconsistently several times over as extension. Ideally they would have devovled pieces in an organised manner and had more official plugins. There are plenty of people dragging their heels and sticking with Mozilla.
extension providing the functionality. Also it lowers the maintenance for the core application. I am hoping to see you guys invest in making a
Modularisation and orthogonal seperation shouldn't necessarily require getting rid of thing. I think the real benfits were laid long before with the seperation of the core Gecko rendering engine.
The Firefox developers didn't really save themselves all that much maintaince work. Mozilla isn't going away and it still requires maintainance. If anything I think they made more work for themselves.
Adding features surely is a noble goal. Looking back at why the Inkscape project started I hope the interest in usability isn't just marginal.
Inkscape is a differnt beast entirely and the Inkscape plugin system looks very promising. Although I seem to keep butting heads with Bulia it is great that there is so much interest in usability surrounding Inkscape and although difficult these discussions ensure decisions are well thought out and the Inkscape developers can justify them with conviction.
Sincerely
Alan Horkan
Inkscape, Draw Freely http://inkscape.org Abiword is Awesome http://abisource.com
On Sun, Feb 20, 2005 at 07:02:14PM +0000, Alan Horkan wrote:
Which platform do the Inkscape developers really want to promote?
This may be rhetorical, but if not the answer should hopefully be pretty obvious that we give priority to Linux. But that doesn't mean we want to exclude other platforms.
The view I tend to take (and I think others agree), is that we're not fighting so much for a _platform_ oriented mindshare as much as a _philosophical_ mindshare. I.e., the fight is not Linux-vs-Windows so much as Open Source -vs- Closed.
For those who do want to think in terms of platforms, the presence of Inkscape on Windows is not meant to imply we're embracing Microsoft. A better analogy might be a Viking invasion type thing... Note that we're not adopting native widgets, not using the native compiler, etc. but are bringing the open source versions (gtk, gcc) along with us.
The grand strategy is that Inkscape's presence (along with Firefox, OpenOffice, Gimp, etc.) on other operating systems will flatten the playing field. Once Windows users are comfortably using all-OSS on top of Windows, they become very easy to shift to another platform.
When I first switched to Linux, it was pretty extreme. I had to leave behind all the tools, processes, etc. I had grown accustomed to on Windows and devote several unproductive months to training myself in what was available on Linux. Having these apps on Windows helps reduce the cost of change, so when the user does finally pull up Linux, they'll be able to return to their normal productivity reasonably quickly.
So the question is who are the target users of Inkscape and what are the Inkscape priorities? (I'll leave that as a rhetorical question.)
I can't resist answering rhetorical questions like that, with a big long dissertation. ;-)
In any product, it is worthwhile to know where you get your value, so you can make appropriate decisions and direct resources accordingly.
For commercial software, value comes in the form of money paid by corporations and individuals who purchase the software (presumably to use it). Thus you focus your energies towards efforts that will result in good magazine reviews, prime shelf-space location, etc. If you also put out an actually good and useful product, then you'll also benefit from word of mouth. The name of the game is to get as many people to buy each release of the software. You probably don't care if the user buys the software but never uses it - still counts as a sale. The value allows you to build up the organization, fund support, administration and marketing, and maybe also develop new versions of the software with what cash remains.
Essentially:
1. User spends their time on a job 2. Job pays user some money in exchange for the time spent 3. User pays money for new copy of software 4. Some large portion of money goes to profit, overhead, administration, paying off debt, etc. 5. Some small portion is allocated to improve product 6. Development occurs (out of user's visibility) 7. A new version is packaged and released 8. User learns that a new copy is available, possibly with some features they want 9. Repeat
For open source software, on the other hand, value doesn't come from money paid by users (except maybe for donations, but that tends to be for secondary purposes). Instead it comes in the form of voluntary contributions from people, in the form of patches, articles, bug reports / fixes, translations, packaging, etc. This value results in direct improvements to the software and the organization around it.
Thus, our target users are those that provide value in some fashion back to the project. By focusing on their needs, we can increase the amount of contributions to the project, which accelerates the development, pulls in more users, and improves the software and the community organization that surrounds it.
Essentially:
1. User gets copy of the software, and spends their time improving it 2. Improvements are incorporated into product 3. A new version is released including the changes they wanted 4. Repeat
Inkscape's priorities should focus first on helping existing users that are contributing actively to the project, and to gaining new users that will become contributors in the future. Thus, it is important not only to provide new features and fix bugs but also to make it easier for others to add changes to the software, and to develop good relations such that the community organization improves and grows.
One of the best ways to ensure that actively contributing users are getting their needs met is to encourage those users to work specifically on fulfilling their needs themselves, where they have the skills to do so. By 'scratching their own itch' they can directly ensure things are done according to how they need them. Our strength, though, is in our ability to coordinate and work as a team; each can then do things that leverage their strong skills to do things that maximize the project's gains.
Windows as a platform is important because there are people who will work on improving Inkscape if they can use it there. Similarly for OSX. However, I think we'll get the most bang for the buck from Linux, since Linux users tend to be more active with development communities in general, and because there are so many programmers using Linux.
Bryce
Here's a quick SVG example of how cool it is to have a more accurate on-canvas gradient editor..
IMO this is a big step.. just like when we got multi-stop gradients. boolean ops & colour raster-vector tracing
On Mon, 21 Feb 2005 12:56:24 +1000, Andy Fitzsimon <andyfitz@...400...> wrote:
Here's a quick SVG example of how cool it is to have a more accurate on-canvas gradient editor..
Very cool, thanks :) It's a good starting point for a 0.42 about box, don't you think? :)
On Mon, 21 Feb 2005, Andy Fitzsimon wrote:
Date: Mon, 21 Feb 2005 12:56:24 +1000 From: Andy Fitzsimon <andyfitz@...400...> To: Bryce Harrington <bryce@...260...> Cc: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [OT] Re: [Inkscape-devel] NEW: on-canvas gradient editing
Here's a quick SVG example of how cool it is to have a more accurate on-canvas gradient editor..
Phenomenal! I'm in awe.
I almost dont believe that was created using only Vector Graphics.
Sincerely
Alan Horkan
Bryce Harrington wrote:
I can't resist answering rhetorical questions like that, with a big long dissertation. ;-)
you are pretty good at those dissertations, you should send them more often to osnews or such or even publish a blog
Hi Bulia, One think that isn't addressed in the interface at the moment is creating a gradient across a large number of objects (eg. when you have a lot of lines where you want to fade the stroke to transparency).
Currently it works well to tweak the gradient in the old floating window since it applies the gradient on the whole selection rather than merging the gradient handles one by one on the canvas.
One possible interface on canvas would be in the yet-to-be-created gradient tool where a drag outside the handles would (re)define the gradient for the whole selection.
cheers
On Mon, 21 Feb 2005 13:47:24 +0100, Jakub Steiner <jimmac@...659...> wrote:
Currently it works well to tweak the gradient in the old floating window since it applies the gradient on the whole selection rather than merging the gradient handles one by one on the canvas.
IMHO much more convenient is to snap together the vectors of several objects on canvas (of course unless there are too many of them) and then adjust the common snapped vector. It will remain snapped even if you deselect and then reselect the objects.
One possible interface on canvas would be in the yet-to-be-created gradient tool where a drag outside the handles would (re)define the gradient for the whole selection.
Of course, that was the plan.
participants (15)
-
Alan Horkan -
Alexandre Prokoudine -
Andreas Nilsson -
Andy Fitzsimon -
Bob Jamison -
Bryce Harrington -
bulia byak -
Craig Bradney -
David Christian Berg -
Emmanuel Pacaud -
Jakub Steiner -
Jonathan Leighton -
Kees Cook -
Nicu Buculei -
Tobias Jakobs