January 2004 - Inkscape Devel

glade naming changed to icons
by Jonathan Phillips 28 Jan '04

28 Jan '04

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...>

1 0

RE: [Inkscape-devel] Inkscape on Windows
by bulia byak 28 Jan '04

28 Jan '04

>I have GTK 2.2.4-2 (from the Gimp web site) installed, which is the >official version for Windows. However, when I try to install Inkscape, it >quits the installer, asking me to install GTK2. Are you using 0.36 installer? If so wait for 0.37, or grab a recent build here: http://troi.lincom-asg.com/~rjamison/inkscape/ These new builds do not require any external libraries. Just unzip and run. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

4 4

RE: [Inkscape-devel] transforms
by bulia byak 28 Jan '04

28 Jan '04

>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=9… 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%2fjoi…

2 1

RE: [Inkscape-devel] Prep for releasing Inkscape 0.37
by bulia byak 28 Jan '04

28 Jan '04

>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.ms…

2 2

Proposal: Consider CVS Provider Change
by Bryce Harrington 27 Jan '04

27 Jan '04

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

5 8

RE: [Inkscape-devel] 'HACKING' file updated
by bulia byak 27 Jan '04

27 Jan '04

>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%2fjo…

1 0

RE: [Inkscape-devel] 'HACKING' file updated
by bulia byak 27 Jan '04

27 Jan '04

>I've rewritten the old (Sodipodi) HACKING file to make it shorter and to >briefly outline our development philosophy for those wanting to get >involved in the future. I've enclosed it below for review. Good work, thanks! Now it would be great to revise (or remove?) the old NEWS and TODO files... _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

3 2

transforms
by MenTaLguY 27 Jan '04

27 Jan '04

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

1 0

Thank you
by Sebastian Stein 27 Jan '04

27 Jan '04

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

1 0

Re: [Inkscape-devel] remove/apply transformations?
by bulia byak 27 Jan '04

27 Jan '04

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%2fjoi…

2 1