glade naming changed to icons
by Jonathan Phillips
Hello all,
I'm changing globally all references to glade, except in the logs of
course. I'm about to commit my changes, and am adding a big Changelog of
every file touched so that you can complain to me if something is wrong
and we can track it down without a rollback.
Thanks,
Jon
--
Jonathan Phillips <jon@...15...>
19 years, 1 month
RE: [Inkscape-devel] transforms
by bulia byak
>HOWEVER, please do not take the "auto-flattening" transforms behavior any
>further -- particularly, don't apply group transformations to group
>members instead. That way lies madness and severe numerical problems
>(errors will accumulate rapidly over time).
Think what will happen when we use groups as layers, and what is happening
already now that it's possible to select within group. For example:
- group some objetcs
- move and scale the group
- select an object within group
- copy
- paste
The transformation is lost. Also see this bug:
https://sourceforge.net/tracker/index.php?func=detail&aid=867521&group_id...
How do you propose to solve these problems without propagating transforms
within groups? Especially given that groups may nest arbitrarily deep?
>Also bear in mind the expectations of users who use Inkscape to make
>trivial edits to existing (possibly hand-structured) SVG files.
They will be able to work in the global "preserve" mode.
>I would prefer instead that transforms were _never_ flattened unless
>explicitly requested.
That's what "preserve" mode is for.
_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fj...
19 years, 1 month
RE: [Inkscape-devel] Prep for releasing Inkscape 0.37
by bulia byak
>1. First, there are a couple last code cleanup tasks that remain: We
> need to remove the #if 0 code, and we need volunteers for that.
I would prefer that this not be done in a hurry. You must thoroughly
understand the piece of code before removing anything, because it may be
actually very helpful. Just recently there were several occasions where I
reused the old #if0 code, revising and upgrading it, as I was hacking the
corresponding files. Without those #if0, my work would probably have been
more difficult. So I propose to not try to do all of this for the release,
but instead keep doing it as we go - once some part of code is significantly
touched by someone, remind him/her to clean up dead code there.
>4. Lastly is to get word out about this release. We have tasks
> identified in the roadmap for doing this. A suitable goal would be
> to match the Sodipodi 0.32 page view and download numbers.
Can you please post these numbers, just out of curiosity? As well as
probably SP 0.33 numbers and our 0.36 numbers? That would give us a sense of
competition, which is always good :)
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin....
19 years, 1 month
Proposal: Consider CVS Provider Change
by Bryce Harrington
As all SF-using developers know, SF CVS has been partly or totally
unavailable for much of the past week.
It is possible SF will overcome their current problems and things will
greatly stabilize and finally become highly reliable. However, past
experience coupled with knowledge of the company's uncertain financial
situation suggest this is unlikely to be the case and that we can expect
trouble to come.
I would like to propose that if when SF CVS returns, we do not have
adequate confidence that they'll be highly stable, that we then proceed
with a plan to shift to a different CVS provider.
There are many different alternatives to consider for CVS providers,
each with their own pros and cons. If we go this route I suggest we
assemble a set of requirements we would have for a provider, and then
judge various options against them.
Bryce
19 years, 1 month
RE: [Inkscape-devel] 'HACKING' file updated
by bulia byak
>Mmm, good thought. What if we replace the NEWS page with the latest
>Release Notes from the Wiki,
Yes - just add to the release algorithm: Take the latest release notes from
the wiki, format as text, and place as the NEWS file in the root.
Speaking of which, I've just rearranged the release notes a bit, and it
would be nice to add more stuff to Internals, Ports, and Infrastructure
sections. Can you think something up? We probably also need an intro
paragraph and a Known issues section.
>and remove the TODO list entirely (maybe
>moving relevant items into RFE's or the Roadmap?)
Most items there are "DONE", and those which are not are pretty obscure -
obviously Lauris was writing that for himself.
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2f...
19 years, 1 month
transforms
by MenTaLguY
bulia-
Please feel free to remove the "remove transform" verb. It's not normally
useful, and deleting the transform= attribute using the XML editor is
almost as easy.
HOWEVER, please do not take the "auto-flattening" transforms behavior any
further -- particularly, don't apply group transformations to group
members instead. That way lies madness and severe numerical problems
(errors will accumulate rapidly over time).
Also bear in mind the expectations of users who use Inkscape to make
trivial edits to existing (possibly hand-structured) SVG files.
I would prefer instead that transforms were _never_ flattened unless
explicitly requested.
I will explain my reasoning further when I get home tonight.
-mental
19 years, 1 month
Thank you
by Sebastian Stein
I like to thank Inkscape's developers for this great application. I first
tried sodipodi, but the user interface is a mess and it lacks such simple
things like drawing a circle.
Please go on with your great work!
Steinchen
19 years, 1 month
Re: [Inkscape-devel] remove/apply transformations?
by bulia byak
Thanks to everyone for responses! My summary:
I was _not_ proposing to remove support for transform=, of course. I
just want to make it more consistent and less confusing for new
users. So here's a more detailed proposal:
There's a switch in "tool options" for selector between "optimize"
and "preserve" transformations. The "preserve" option causes all
manual scales and drags in selector to add transform=, while
"optimize" (the default) writes transformations to the object
coordinates. I suspect that the "preserve" mode is buggy simply
because it's not the default, and anyway it seems to apply only to
manual operations in selector. What I want to do instead:
- Make this switch truly global, affecting all transform operations
no matter what caused them.
- Make sure the "optimize" mode is as complete as possible, i.e. all
commands write as much as possible to the object attributes in this
mode (absolute "optimization" is not possible, as some transforms
cannot be native for some objects and require a transform= anyway).
- Make sure the "preserve" mode is equally global and complete, and
thoroughly test it.
- Add "apply transform" command for those switching between these
two modes. Perhaps it might be combined with some other cleanup
operations and called simply "cleanup" or "optimize", because "apply
transform" is too confusing (I would expect it to call something
like the Transformation dialog, not make some invisible change to
XML).
- Remove the "remove transform" command - it's really just
confusing, and in any case it's easy to do the same by removing the
transform= attribute in the XML editor, if anyone ever needs this.
Jon:
>The transformations might be nice if we have a library of objects
>and make instances of the object, and rather than changing the
>original, transform the instance.
That's what SVG use element is for. There is some support for it but
it is incomplete. I'm seriously considering adding some simple UI
for it in the next version because having a "Clone" and "Define
symbol" command would be really cool and seems to not be excessively
difficult to add. And yes, of course svg:use requires transform=,
and it should still work in both modes - the "optimize" mode would
just not optimize an svg:use object, leaving its transform= in
place.
>saving each transformation and having a dialogue/palette with
>transformations or all transoforms: shape scaling, rotating,
>twisting, and so forth, would be useful, to go back in time to an
>earlier state on a shape.
Unfortunately no, transform= as currently implemented does not give
you a "history" of transformaions. It's always a single matrix and
you can just remove _all_ transformations if you remove it. SVG
allows you to write each transformation as a separate command to
this attribute, but I think Inkscape does not support this.
Robert:
>I actually have a need for both "transform = " and "apply
>transform" (I see no need for "remove transform"). I would prefer
>that when I transform an object, I get a "transform = " and then
>have the ability to apply that transform.
OK, you can just work in the "preserve" mode.
>Lets say I want to draw a regular hexagon. I will draw 3
>identical lines, rotate one 60, another -60, then apply the
>transformations. The endpoints of these paths will give me the
>control points to draw the hexagon.
>From this example, however, I don't see why you need preserving
transformations - if you apply them at once! This means you just
want the rotate command (in the Transformation dialog, I suppose) to
work in the "optimize" mode, i.e. apply the transformations for
you. Or am I missing something?
>In inkscape, currently, I combine paths to apply a transformation.
>I'd really like to see an apply transform button.
It's not difficult to add, however I think the first priority is to
make sure that _all_ transformation commands work correctly in both
optimize and preserve modes.
Bob:
>But if we ever get into the DOM scripting part of the SVG spec, we
>would likely want to keep the original object + each of its
>transformations. Like, say an object is rotated by angle theta,
>then translated to a point x,y. Say we want to to animate it by
>changing theta, thus rotating it, but leaving the translation
>alone.
Sure, this is where the preserve mode will be used. When we have
animation, it will be necessary indeed.
Herve:
>Well, in fact, i think that te transform= attribute dedicate to a
>group object or an object (instead of directly transforming the
>d=) may (my opinion) want to act like proto in vrml (3D xml) you
>import a proto from another file and transform it : that way when
>you change the original proto-file, all transformation will apply
>to that imported-proto-file-object. that transform possibility may
>add a 'abstrac-implemented-object-stuff' as 'new' in POO
>
>It is (i supposed) the way "use" should be implemented.
Yes, when you reference an external object as in svg:use, you can't
do without a transform=, and this cannot be optimized (see
above). Groups however are another matter. Currently Inkscape always
adds transform= to a group when you move it. I want it instead to
write it to each group member recursively (in optimize mode only, of
course). Any comments on this particular change?
_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fj...
19 years, 1 month
