- Inkscape Devel - Inkscape Mailman

Interesting things in Xara land
by Joshua A. Andler 01 Feb '07

01 Feb '07

Apparently they got acquired by another company... http://xara.com/press/magix.asp

5 5

Re: [Inkscape-devel] [Inkscape-user] Baffling UI
by Joshua A. Andler 01 Feb '07

01 Feb '07

bulia byak wrote: > On 1/30/07, Alan Horkan <horkana@...44...> wrote: > http://www.maths.tcd.ie/~horkana/inkscape/illustrator/Adobe-Illustrator-CS/… >> (found a better link) >> >From the middle to the left, see warp tool, and twirl >> http://www.coe.fau.edu/abinder/handouts/Itools.htm >> >> These are taken from Adobe Illustrator CS verison 1 > > OK, I admit I wasn't aware of this - it wasn't available in my older > version which I used until recently. It's indeed a good feature. > Different from ours but having its own strengths (and limitations). We > need to catch up, not by copying but by thinking how we can do the > same better and more flexible. > I fired up my copy of AI10 and played with them. Here are some thoughts: They have separate tools for warp, twirl, pucker, bloat, scallop, crystallize, and wrinkle... none of which you can configure (at least not that I could find in my version). I don't have my tablet at the office so I don't know if pressure makes a difference either. It seems like overkill (in typical AI fashion) to have SEVEN tools to accomplish these various (but somewhat similar) tasks. My first question is, do we add this functionality to an existing tool or create a new "distortion" tool? Either way, I propose a bunch of modifiable parameters (including size of affected area, as it seems AI can't do that... at least not with the mouse). Oh and can't forget that if we could enable pressure and tilt interaction for tablets that would totally rock. Anyway, if we go the parameter route, it also seems like a good time to perhaps look experimenting with a "preset" system. So people can save and load presets. If we make it very flexible we could ship with a bunch of presets and also have community contributed presets on the website that people could download. I guess I look at this distortion/modification stuff in the way I'd love to see our brush capabilities go (when we can directly paint with objects/patterns/etc). I believe (easily) loadable sets of options, presets, and brushes will really help foster more community contribution. Some people may not know how to contribute, but, they may be very artistic and willing to give back. This seems to be the case for every other program with loadable brushes and such. I'm not married to any of the above ideas or even believe that this is the best way to go, for the most part I'm just throwing a bunch of ideas out there to stimulate more conversation about this. :) Also, is it my imagination or does this seem like a prime candidate for the live path effects? I will add items from the discussion to a wiki page once the conversation has built up a little more (and other thoughts/ideas are out there). -Josh

3 3

Inkscape roadmap for 0.46 and beyond
by Bryce Harrington 31 Jan '07

31 Jan '07

Hi all, I think I've mostly finished with the reworking of the roadmap. Thank you to everyone who has provided ideas or critique: http://wiki.inkscape.org:8080/wiki/index.php/Roadmap This shouldn't be taken as gospel, of course. It's likely that tasks will need to be resorted as we move forward, but I think this gives us a starting point to plan around. Two factors I've tried to account for in the prioritization are first, that we have a goal to achieve SVG Mobile (aka SVG Tiny) support by version 0.50, and second that developers are going to want to work on separate aspects of Inkscape in parallel, rather than everyone focusing on one area for one release. Thus I've added categories in each section to roughly define what these different areas are, and have attempted to avoid putting too many tasks in any one area. Please feel free to re-prioritize or elaborate on any of the items here. It would especially be nice if we could more distinctly call out lower level tasks for some of the higher level task descriptions, so that new developers can more easily find things defined well enough for them to work on. Also, linking to mail archives or wiki pages with more info about the tasks would be quite helpful! If you adjust priorities, it would probably be better to move things *later* than earlier. There's no problem with planning to do things far in the future but actually getting them done early! But if we put too many things into 0.46, it could get a bit overwhelming. One of the things that's gotten really clear is that if we really do want to get SVG Mobile support by 0.50, then we're going to need to start thinking about cutting ground on Animation. Fortunately the spec only requires "Basic Animation support", with a subset of the features, so it sounds pretty doable if we give ourselves plenty of time and do some really good brain storming on it. For 0.46, we could focus on conceptual definition - what we want, how it should work, and so forth. I know a lot of people have good ideas on this, so it's probably going to be mostly a matter of getting those ideas recorded and organized, so future prototypers have something to inspire and guide their work. Bryce

2 1

Mac OSX package status
by Aaron Spike 31 Jan '07

31 Jan '07

Have we made any progress toward Mac packages for this release? Aaron Spike

4 7

Re: [Inkscape-devel] [Inkscape-user] Layers dropdown
by bulia byak 31 Jan '07

31 Jan '07

On 1/31/07, jiho <jo.irisson@...400...> wrote: > Inkscape could benefit from a similar approach, but it surely needs a > lot of thinking first. My humble opinion is that beginner vs. > advanced profiles won't work because one can be quite advanced in > some areas (eg node editing) and beginning in others (eg. color > management). Furthermore, a beginner and an advanced users > essentially have the same goals, it's just that the beginner does not > know how to achieve them and restraining them in a limited or a less > accessible functionality mode won't help them. In addition, as > someone already mentioned: how can one know when he is ready to > switch to advanced mode? Exactly my thoughts. > On the contrary, CAD/technical, diagramming, GIS, artistic, child > modes could be very efficient in exposing only the "right" features > to the user or exposing the same features differently. Indeed, > depending on which kind of work you do, your _goal_ is different and > the application can help you achieve it. Agreed. And as a first step towards this, let's make it easier for the user to make such "profiles" for himself. We really need a "Save as template" command which should be very easy to program based on the "Save a copy". All it has to do is just go to the templates directory in the save dialog, to save the user from wading there on his own (which is confusing and different on different platforms). Any takers? -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

pre2: drop-down lists in extensions on windows broken
by bulia byak 30 Jan '07

30 Jan '07

I cleared all previous installs and reinstalled pre2 on this winXP machine, but it does not help: in Effects > Generate from path > Pattern along path, the two drop-down lists are empty and cannot be opened. When I run the effect, I get Traceback (most recent call last): File "share\extensions\pathalongpath.py", line 264, in ? e.affect() File "C:\inkscape\share\extensions\inkex.py", line 157, in affect self.effect() File "share\extensions\pathalongpath.py", line 233, in effect if self.options.repeat: AttributeError: Values instance has no attribute 'repeat' Can anyone else confirm this? If it's real, it should be fixed before the release, since this is one of the major new features in 0.45. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 2

Re: [Inkscape-devel] Using Inkscape Canvas for your project
by Jon Phillips 30 Jan '07

30 Jan '07

<topPost /> Thanks for the reply Damon. I'm cc'ing the Inkscape development list, Bryce Harrington and Mental, two core developers working on this issue. More below... On Tue, 2007-01-30 at 16:07 +0000, Damon Chaplin wrote: > On Mon, 2007-01-29 at 15:37 -0800, Jon Phillips wrote: > > Message body follows: > > > > Hi, have you considered using Inkscape's canvas for your > > project (http://inkscape.org). We are trying to modularize > > our code more so that we can help other projects and get > > more contributors. Plus, we want the benefits of Cairo on > > our app. > > I wanted to create a new cairo-based canvas widget for GTK+ so > Inkscape's canvas wasn't really an option. > > Do you have a list of features of your canvas somewhere? Unfortunately not...plus, it is not modularized well-enough yet...hence we are seeking out if it could be of use to others, and to try and combine efforts on various parts of Inkscape. > Here's the list of GooCanvas Features: > > o Optional model/view split. > o Uses interfaces for items & views. > o Basic items - rect/ellipse/polyline/text/image/group. > o Path item, using SVG path specification strings. > o Embedded GTK+ widgets. > o Layers/stacking order with raise/lower functions. > o Cascading styles - line width/style/dashes, colors, fill patterns. > o Affine transformations for all items - rotations/scales/skews. > o Event handling - button/motion events, "pointer-events" property > like SVG. > o Grabs - support for pointer & keyboard grabs. > o Keyboard focus traversal. > o Accessibility (item title & description properties and hierarchy > stuff). > o Printing (output to a given cairo_t). > o Scrolling. > o Zooming. > o Item visibility setting - on/off/above zoom threshold. > o Simple animation. > o Scalable - support for thousands of items over a large canvas area. > o Support for different units - pixels/points/inches/millimeters. > o API docs. > o GooCanvasTable for layout of items (though this isn't in cvs yet). > > It is already pretty stable and mature (better than > GnomeCanvas/FooCanvas). Though the API is likely to change a little bit > more in future before stabilizing. > > I'd be interested to hear what things are needed for apps like Inkscape > that GooCanvas doesn't have. > > Damon This is quite impressive Damon. Bryce and Mental, what are your thoughts? Regardless if a collaboration happens or not, it is great to connect and get to know each other. Perhaps you would be interested in the upcoming libre graphics meeting conference in may 2007: http://lgm.scribus.net (temp site). 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...

1 0

Illustrator Warp tools
by Aaron Spike 30 Jan '07

30 Jan '07

Alan Horkan wrote: >> I'd just like to point out, for the sake of others who might get a >> wrong idea from you, that Illustrator has no "warping nodes". > > Unfortunately your are not correct. > > The best I can manage at the moment is to show you this screenshot and try > to direct your attention to the very hard to find feature (see the hand > with a finger pointing down and beside it a box with a twirl coming out > the corner) > http://www.maths.tcd.ie/~horkana/inkscape/illustrator/Adobe-Illustrator-CS/… > > (found a better link) >>From the middle to the left, see warp tool, and twirl > http://www.coe.fau.edu/abinder/handouts/Itools.htm > > These are taken from Adobe Illustrator CS verison 1 I just went out and fired up a copy of CS2 here at work. Alan, thank you for pointing this out! Finally something neat from illustrator. :-) This is a bit different than node sculpting. It doesn't require a node selection. There is a cursor with a center mark and an area delimited by a larger circle. As the user clicks and drags the paths are updated in real time. only the area within the larger circle is updated. And the amount of update seems to taper off toward the edge. There are various effects which can be applied to the current path. My take: we could do something like this by partially applying our non existent live effects to a path within an adjustable sphere of influence. Aaron Spike

1 0

Re: [Inkscape-devel] Using Inkscape's canvas code
by Jon Phillips 30 Jan '07

30 Jan '07

This is great Rick and libpapyrus-devel ppl. I'm cc'ing the Inkscape-devel list, Bryce Harrington and Mental, both core developers on Inkscape, as they can more adequately ask/answer questions. More below... On Mon, 2007-01-29 at 22:51 -0700, Rick L Vinyard Jr wrote: > Jon Phillips wrote: > > Message body follows: > > > > Hi, have you considered using Inkscape's canvas for your > > project (http://inkscape.org). > When I thought about restructuring glcanvasmm (an OpenGL based canvas) > as the cairo based (and then later cairomm based) papyrus I looked all > over for a library that would make it easy to do research in > diagrammatic reasoning... more specifically visual programming languages > (not Visual C++)... and even more specifically rule-based visual languages. > > I looked at GnomeCanvas, GnomeCanvasmm, Evas, DiaCanvas, Zinc, FooCanvas > (GooCanvas didn't exist then), et. al with the thought of just using the > library or writing a wrapper for the non-C++ libraries. I also looked at > several apps such as Dia, Inkscape, Sodipodi, et. al. with the thought > of extracting the drawing canvas. I even looked at pure vector drawing > libraries as well as 3D scenegraph libraries (such as Ogre and > OpenSceneGraph) that also had decent support for 2D primitives. > > Specifically, several things I was looking for: > * A standalone object-oriented C++ library with a minimalist set of > dependencies... to paraphrase Einstein... as few dependencies as > possible, but no fewer. > > * Easy to extend the canvas items either through inheritance or > through new drawing primitives > > * Easy to modify the behavior of objects in the canvas, either through > external controllers and events or through user interaction > > * Because of the above reasons, I really wanted something that > returned to Smalltalk's concept of a Model-View-Controller as separate > concepts > > So, I suppose to bring a long answer to your question to a conclusion... > yes, I did consider Inkscape's canvas but I really wanted something that > didn't tie the geometrical structure (model) to Gtk or the display (view > and controller), and at the time it looked like more work to extract the > canvas from Inkscape (or any of the other apps) and rewrite it as a > cairo based canvas, as opposed to rewriting glcanvasmm as a cairo based > canvas. > > But, I'm always open to either: > (1) Using sp_canvas if it makes sense > (2) Looking to sp_canvas as a model for improving the papyrus canvas Great! Ok, I hope we can work towards a model of collaboration. > With respect to (2), I know there are many aspects of the papyrus canvas > that are ripe for improvement. In particular, I've been looking for an > easy to use API first and speed second. That doesn't mean I'm not > concerned about speed... just that it is currently second in priority. This seems to be the same strategy for cairo. > > We are trying to modularize > > our code more so that we can help other projects and get > > more contributors. > That sounds great. I think there are many pieces of Inkscape that could > be reused all over the place if they were structured into libraries. Yes, we are working towards this. Maybe you could recommend pieces you would like that we could work to box up :) > > Plus, we want the benefits of Cairo on > > our app. > > > Which is a huge benefit. That's another reason for the separation > between papyrus and papyrusmm. Papyrus renderables only require a cairo > context to draw into, and thus only has a dependency on cairomm. Wow, cool! > Also, just browsing through the Inkscape repository, it looks like there > is a lot of duplicative effort between the Inkscape codebase and cairo. > For example: > > 88 void sp_curve_reset(SPCurve *curve); > 89 > 90 void sp_curve_moveto(SPCurve *curve, NR::Point const &p); > 91 void sp_curve_moveto(SPCurve *curve, gdouble x, gdouble y); > 92 void sp_curve_lineto(SPCurve *curve, NR::Point const &p); > 93 void sp_curve_lineto(SPCurve *curve, gdouble x, gdouble y); > 94 void sp_curve_lineto_moving(SPCurve *curve, gdouble x, gdouble y); > 95 void sp_curve_curveto(SPCurve *curve, NR::Point const &p0, NR::Point const &p1, NR::Point const &p2); > 96 void sp_curve_curveto(SPCurve *curve, gdouble x0, gdouble y0, gdouble x1, gdouble y1, gdouble x2, gdouble y2); > 97 void sp_curve_closepath(SPCurve *curve); > 98 void sp_curve_closepath_current(SPCurve *curve); > > From a cursory scan it looks like these and other methods could be > eliminated by moving to cairo. And, if there is some optimization you > have that cairo doesn't, I'm sure Carl would gladly accept patches. Yes, agree. He sits in our channel all the time, so we are all buddies :) > > If you get a chance, please check out sp-canvas.cpp which is > > our main canvas code. It works really well: > > > > http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/disp… > > > I have... along with many of the canvas items as well. There are some > great things there. > > > Also, please forward this onto your project list so others > > can see. > Not a problem. Great Rick, lets keep the dialogue happening and hopefully great collaboration we can aim towards :) Jon > --- > > Rick > -- 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...

1 0

Re: [Inkscape-devel] [Inkscape-user] Baffling UI
by Bryce Harrington 29 Jan '07

29 Jan '07

On Sun, Jan 28, 2007 at 11:52:09PM +0100, Olivier Lefevre wrote: > Thanks for the explanations. So if I create the rectangle and > immediately switch to the select tool yes I get to see its properties > and change them. It did not occur to me to try the selector because the > object seemed to have disappeared as soon as I clicked elsewhere. I'll > be damned if I know why it was white: I have _viewed_ some SVG documents > in Inkscape before but this is my first stab at creating one. > > In the status bar I would suggest not using F and S but spelling out > Fill and Stroke in full: there is enough space for that and if you are a > newcomer and both F and S say "N/A" it is not obvious what they refer > to. Besides it seems weird for the stroke to be N/A: I can understand Would it perhaps be clearer to get rid of the labels entirely and just show a rectangle or other shape in the fill color, with a border in the stroke color (if any)? Then we could eliminate the need to localize at all, which could be beneficial in languages where the translation for 'fill' or 'stroke' may end up being a longer word. Bryce > having no fill but how can an object have neither fill nor stroke yet > still somehow exist? As per your own message, shouldn't the stroke have > been white or transparent and not N/A? White is definitely a color and > in most editing tools transparent _is_ a color, too, albeit obviously a > peculiar one. > > > Inkscape is not a viewer. Its primary function is editing. Therefore, > > plain arrow keys are reserved for the most basic editing action: > > OK. > > -- O.L.

2 1