- Inkscape Devel - Inkscape Mailman

Open Clip Art Library Release 0.11 Announcement
by Jon Phillips 08 Mar '05

08 Mar '05

Open Clip Art Library Release 0.11 Announcement March 8, 2005 UTC - Release 0.11 of the Open Clip Art Library (www.openclipart.org) is now available for download on-line as an individual package consisting of 2896 images submitted by over 200 artists from around the world. Some of the new clip art received this month includes more images of food, computer-related items and even a little boombox. In addition to the collected 0.11 package, each clip art file can now be found by keywords using developer Jonadab's new Keyword Search Tool. The Open Clip Art Library is growing rapidly because of increasing submissions from artists. Currently, the top five artists in terms of the amount of clip art submitted are: Danny Allen (951 images), Nicu Buculei (456), Jose Hevia (453), Andy Fitzsimon (250), and Alan Horkan (119). These Artist's and others contributions are the life blood of the Library. While the critical unit of contribution in traditional Open Source is code, it is a little different with the Open Clip Art Library project in that an actual clip art donation is just as helpful as the code supporting it. For March the Open Clip Art Library encourages submissions of clip art related to the concept of "Spring." In the coming months as the library grows in size, the project needs new developers to help build tools to process this growing repository. Upcoming planned features that the project needs assistance on include capturing and tracking of clip art requests, user account management, adding WebDAV support, and developing wizards to aid in composition. Use the following URLs to download the latest release of the Open Clip Art Library: http://www.openclipart.org/downloads/0.11/openclipart-0.11.tar.bz2 http://www.openclipart.org/downloads/0.11/openclipart-0.11.tar.gz http://www.openclipart.org/downloads/0.11/openclipart-0.11.zip http://www.openclipart.org/downloads/0.11/openclipart-tools.zip The Open Clip Art Library (http://www.openclipart.org/) aims to create an archive of clip art that can be used freely for any use. All graphics submitted to the project are placed into the Public Domain according to the Creative Commons Public Domain Declaration.

1 0

Re: [Inkscape-devel] gradient tool bug
by bulia byak 07 Mar '05

07 Mar '05

On Sun, 06 Mar 2005 23:19:26 +0100, Jakub Steiner <jimmac@...653...> wrote: > My question is exactly the other way around. If node editing tool is for > editing a shape, why have it define a gradient? In Sodipodi, you had to switch to node edit after having created a rectangle if you wanted to round corners. The rect tool could create a rect but not edit it. That was obviously crazy. I fixed that. Then we added on-canvas editing of pattern fills. It shows up whenever you have the shape handles or nodes (i.e. in node tool and all shape tools). This turned out to be quite convenient (at least for me). Now with gradients, I just followed the general trend, which is this: Each tool _creates_ objects of its type and allows for precise numerical control of them, but simple on-canvas _editing_ should be available everywhere for all objects. I think this is a good idea overall, though obviously in some cases it may lead to too much stuff on canvas. I don't think however that gradients are one of these cases. Does anyone else have an opinion? > sure about other artists, but I have a workflow where I first worry > about the shape and later on worry about the shading. I have no need to > be doing both at the same time. I often adjust shape and fill at the same time, and not having to switch tools is convenient for me. > > What about this: when no gradient handles are selected (all are > > white), it works as now. When a handle is selected (blue), the list > > will show (and let you change) the gradient definition for that > > handle's gradient. > > I fear this behavior isn't exactly obvious. Seeing that something is selected (blue) and assuming that the "Change" controls affect the selected thing is much more obvious IMHO than having some obscure "mode switch" in the toolbar. > What does showing both fill > and stroke gradients at the same time give you? It gives consistency and simplicity, above all. I select an object and I see _all_ of its gradients without having to think about modes and such. > The only thing obvious > to me is locking the vector of both gradients to be precisely the same. Yes, this is an advantage too. > Yet this is hardly an advantage even if it wasn't limited for both > having the same gradient applied (which is truly useless). It's not _thus_ limited. You can assign the different definitions to the gradients first and merge them after that. Even simpler, you can easily shift-drag one of the merged handles away, apply a different gradient to it, then merge it back. Then you will still be able to drag the merged gradients together, even though they will now have different gradient definitions. So it's not even a limitation, just a minor inconvenience. > I'm not > saying there isn't any. I just don't see it and I'm asking for a use > scenario. You said yourself (below) that merging gradients from different objects is useful. Now imagine that one of the objects is a fillless stroke and the other is a strokeless fill. I want to form a "virtual object" out of them by merging their gradient handles. With your proposal ("modes") this would be impossible - not just inconvenient but impossible. > I understand you have all this coded and you are motivated to justify > this design. In the end I will accept whatever there is, since I hardly > have any choice, but I strongly believe separating the two will lead to > a better interface that gives feedback on what's happening. I think it will just add a redundant control which will make the whole system less obvious and less discoverable by novices. I don't see what is the additional feedback that it will give you which my system would not give. > Snapping within multiple objects is useful for having a multiple object > form a "virtual" object. You may want to draw a car body structure and > keep the dashers separate. So the objects share the same shading. > > I don't see the need for having a precise snapping of stroke/fill > gradients if the gradient is supposed to be the same. In the end it just > gives the same result as having the object have no stroke. 1) Gradient definition does not have to be the same (see above) 2) Even if it's not useful for the same object's fill and stroke (I'm not sure why you think so, but OK), I think you can easily imagine wanting to form a "virtual object" from some objects without fill and others without stroke. > > Can you explain why would you need to switch a gradient from linear to > > radial, preserving the handle positions? This seems far-fetched to me. > > Why is this any better than simply drawing a new radial gradient for > > the same objects instead? > > See yourself adding the "New:" label? The interface doesn't speak on its > own, you had to describe its behavior because clicking on the button > doesn't give immediate feedback. You are right that in most cases I > continue to redesign the gradient placement, but the interface gave me > an immediate feedback on my actions as opposed to the current design. Even if I add a button to switch the selected gradient between linear and radial, this would be a separate button from the one which governs the newly created gradient. (Or are you proposing to always create linear and then, if needed, switch it to radial? That would be quite cumbersome.) And since the usefullness of the radial/linear switch for _existing_ gradients is not obvious to me, I think leaving only the control for _newly created_ gradients makes sense and reduces clutter. The fact that the "New:" part applies to newly created gradients is explained in the tooltips. Besides, this is consistent with the shape tools which, too, display "New:" when no objects of their type are selected, in which case adjusting the controls will affect newly created objects.

3 6

--new-gui
by Bryce Harrington 07 Mar '05

07 Mar '05

I've fussed around with the autoconf/automake stuff and in theory now you should be able to run `inkscape --new-gui` and see something other than a segfault. If so, great, if not, lemme know. I suspect due to a newly added share/ui directory, you will probably need to re-run autogen.sh and configure. Bryce

2 2

icons breakage
by bulia byak 07 Mar '05

07 Mar '05

Jon, in today's CVS: - There's a noticeable delay after the program window appears and before it shows icons in toolbars. It never happened before. - You removed the possibility for toolbars to be cut. Why? Now the window starts up wider than before, and if we add more controls to the selector toolbar it will have to be wider still. Moreover switching tools (e.g. switch to star) may resize the window, which is very annoying. Please fix this. Besides, you removed the only place where the "detach" flag was checked but did not remove its setting. This flag was added to make sure a detached toolbar is not cut while the attached one may be cut by the window. I think this must be restored.

2 5

layer commands we need
by bulia byak 07 Mar '05

07 Mar '05

Here's a list of layer commands that we need to implement, comments and additions welcome: Layers... // opens the Layers dialog ------------------- Move to Layer Above Shift+PgUp // move selection to the top of sibling layer above, or to the top of parent layer (but not root) if no siblings Move to Layer Below Shift+PgDn // move selection to the top of sibling layer below, or to the bottom of parent layer (but not root) if no siblings Move to Layer... // let me choose the layer name to move selection to ------------------- Unlock All Layers // unlock all layers in the document (or all siblings of the current layer?) Unhide All Layers ------------------- Unlock All in Layer // unlock all children of the current layer Unhide All in Layer ------------------- Group to Layer // convert group to layer Layer to Group

4 16

gradient bug? icons
by David Christian Berg 07 Mar '05

07 Mar '05

Hey guys, have a look at http://home.tu-clausthal.de/~dcb/gradients.png I've no clue, why that is... the one end is on top of the other, but instead of having just two plain areas it looks like in the screenshot. Anyways... icons: http://home.tu-clausthal.de/~dcb/icons.svg they still need some work, but... enjoy! David

3 9

NEW: gradient tool
by bulia byak 06 Mar '05

06 Mar '05

New in CVS: The Gradient tool (Ctrl+F1 or the g key) is a new convenient way to create, edit, and manage gradients: o Simply drag anywhere on canvas to create a gradient on selected objects. Existing gradients can be edited by dragging their handles (as in any tool that has on-canvas gradient editing enabled). o The tool's controls bar lets you choose the type of the newly created gradients (linear or radial) and whether they will be applied to the objects' fill or stroke. o For the gradient(s) of selected object(s), you can choose one of the gradient definitions in the document from the drop-down list in the controls bar. The Fork button creates a copy of the selected gradient definition and applies it to the selected objects, which is useful when you have several objects sharing one gradient definition but want to change that. The Edit... button opens the gradient dialog where you can edit the gradient definition (add/move/delete stops and change colors and opacities of stops). o The selected (blue) on-canvas gradient handle can be moved by arrow keys with all the regular modifiers (Alt ro move by 1 screen pixel, Shift to move by 10 times the distance). The Tab and Shift+Tab keys let you move selection from one handle to the next or previous. This functionality is largely equivalent to that of the Fill&Stroke dialog, but is much more convenient. Still TODO: - toggle buttons for spread (none/reflect/repeat) - button/dialog to rename selected gradient definition - X/Y spinbuttons for the position of the selected handle - the ability to assign color to the selected handle, so it's possible to edit at least two-stop gradients without opening the gradient editor - additional draggable handles for multi-stop gradients Also today I eliminated the old gradient position widget in Fill&Stroke as redundant. I'm thinking about removing the remaining gradient controls there too ("vector" list, Add/Edit, spread) because they are a duplication of what is available in the gradient tool, and have no added advantages in the dialog. All these changes were rather disruptive, so please test everything thoroughly. Of course any feedback on the usability, terminology (e.g. I had to invent the term "gradient definition" for that color strip with stops that can be applied to objects' gradients; Sodipodi termed them "vectors" which is incredibly misleading), or anything else is welcome.

5 6

mozilla futures
by Jon Phillips 06 Mar '05

06 Mar '05

You guys might have a look through these slides to see about mozilla + svg developments: http://www.mozilla.org/events/dev-day-feb-2004/mozilla-futures/ As you all know, mozilla svg is in the mozilla trunk now. Jon -- Jon Phillips USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)

1 0

Inkscape crash while drawing a gradient
by Jean-François Lemaire 06 Mar '05

06 Mar '05

I just made Inkscape CVS crash while "drawing" a gradient. Here is the output from the terminal: (inkscape:21590): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GObject' (inkscape:21590): GLib-GObject-CRITICAL **: file gobject.c: line 1642 (g_object_get_data): assertion `G_IS_OBJECT (object)' failed ** ERROR **: file desktop-handles.cpp: line 31 (SPSelection* sp_desktop_selection(SPDesktop*)): assertion failed: (desktop != NULL) aborting... Emergency save activated! Cheers, Jef

2 1

Hacking on icon stuff
by Jon A. Cruz 05 Mar '05

05 Mar '05

Just wanted to let people know I'm in the middle of hacking on icon loading. My immediate goal was to get rid of the ugly rescaling and blurring of the stock icons. But in doing that I should also be able to get rid of all hardcoding of sizes. So... all the SP_ICON_SIZE_* defines are about to dissapear, and their use should be replaced with the logical GTK_ICON_SIZE_* defines in many places. In many other places, hardcoded sizes should just dissappear.

9 24