March 2005 - Inkscape Devel - Inkscape Mailman

Icon preview
by Jon A. Cruz 09 Mar '05

09 Mar '05

It's a little buggy, but go ahead and check out the initial cut of "Icon Preview" under the View menu. I mainly just put stuff I needed for debugging into a dialog. Just hit "refresh" and it will render the top desktop's selected item as icons in different stock sizes.

2 2

bug with gradient editing
by David Christian Berg 09 Mar '05

09 Mar '05

Hey Bulia, just found a bug with gradient editing. Steps to reproduce: 1. Create a Text 2. Apply a gradient to the text 3. Delete the text 4. Undo deleting the text 5. Try to edit the gradient or switch to a solid fill. It won't work If you can't fix it right away, I'll file a bug report against it. Take care! David

5 8

Layer Merging, and Merging Groups of layers.
by Alan Horkan 08 Mar '05

08 Mar '05

[sorry, deleted old posts had to start a new thread] I said I'd take a look at how Adobe Photoshop handles groups of Layers and I was able to check Adobe Photoshop 7 and to be honest I wasn't impressed. Adobe Photoshop allows you to have lots of seperate layers and it also allows you to create what looks like a folder in the Layer Palette so that you can put Layers inside the folder and group them together. What I'm unimpressed by is that they depending on what you have selected - a Layer or a Layer Group Folder - the menu entries for "Layer, Merge Down" (and the other one) dynamically change lables and offer to Merge Layer Set. (I'm not sure about the specific wording, I only have very limited access to proprietary multimedia software so I'm describing this from memory). If you are usign the Merge Down function and you hit a Layer Group in the stack you are stopped dead. No attempt is made to move into the group and merge the next layer, no prompt is given offering to merge the whole group or just the next layer. The workflow stops, dead end. Inkscape cannot copy the dynamically changing menu behaviour because dynamically changing menu items almost always make for a bad user interface and even worse accessibility. However I do think this could be done better, my initial suggestion would be if "Merge Down" hits a Layer Group there would be a prompt offering to "Merge Next Only" or "Merge Group" but it is only a suggestion as I'm fairly sure Bulia has some implementation ideas of his own Hope that helps. If you want me to get screenshots or try to better describe how Adobe Photoshop behaves please do ask. Sincerely Alan Horkan Inkscape, Draw Freely http://inkscape.org Abiword is Awesome http://www.abisource.com

2 1

Fix for Inkscape execstack marking
by Mike Hearn 08 Mar '05

08 Mar '05

Hi, I have fixed the problem reported by Ivan Gyurdiev. As the MMX assembly does not appear to require an executable stack, the attached patch provides a .GNU-stack section allowing it to be protected. As you can see the stack is marked RW not RWE: mike@...646... src $ readelf -aW inkscape|grep GNU_STACK GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4 This patch will take effect in the autopackage nightly builds immediately (because that tree is where I wrote it). It's been put in the bug tracker here: https://sourceforge.net/tracker/index.php?func=detail&aid=1157714&group_id=… thanks -mike

2 1

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