bug with gradient editing
by David Christian Berg
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
18 years, 8 months
Layer Merging, and Merging Groups of layers.
by Alan Horkan
[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
18 years, 8 months
Fix for Inkscape execstack marking
by Mike Hearn
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_i...
thanks -mike
18 years, 8 months
Open Clip Art Library Release 0.11 Announcement
by Jon Phillips
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.
18 years, 8 months
Re: [Inkscape-devel] gradient tool bug
by bulia byak
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.
18 years, 8 months
--new-gui
by Bryce Harrington
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
18 years, 8 months
icons breakage
by bulia byak
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.
18 years, 8 months
layer commands we need
by bulia byak
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
18 years, 8 months
NEW: gradient tool
by bulia byak
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.
18 years, 8 months
