- Inkscape Devel - Inkscape Mailman

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

Re: [Inkscape-devel] Proposal: Consider CVS Provider Change
by bulia byak 27 Jan '04

27 Jan '04

>I had an interesting experience trying to move a project off >sourceforge: they refused to take the project pages down. Maybe it's not so bad? Just schedule an automatic daily copy of your "real" CVS to the SF CVS, and you have a free backup copy... _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=dept/features&pgmarket=en-ca&RU=http%3a%2f%2fjoin…

1 0

RE: F1 => Help ? [was RE: [Inkscape-devel] RE: couple of functionality tweaks]
by bulia byak 27 Jan '04

27 Jan '04

>Windows users associate F1 with Help >and reaching for the Function keys is somewhat awkward, so I'd expect we >will need to change the keybinding. Oh please no!!! It's the key I use very often. I'm so spoiled by it that now I press it all the time when in Xara (and curse when it gives me help :) I don't know why but it's very convenient, maybe even more convenient than space (for me). And yes, it's non-standard, but it's borrowed from CorelDraw, and therefore has at least some legacy behind it. I'm against changing it in the default keybindings. _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoi…

1 0

Re: [Inkscape-devel] new preview?
by bulia byak 27 Jan '04

27 Jan '04

>the best I was able to do was to verify that Microsoft Visio 2000 uses > >Shift+Wheel for sideways >and >Ctrl+Wheel for Zoom > >which matches what I asked for the HIG to say >http://developer.gnome.org/projects/gup/hig/draft_hig_new/input.html#mouse-… Great, I committed the change to match this. Thanks! _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

Prep for releasing Inkscape 0.37
by Bryce Harrington 27 Jan '04

27 Jan '04

Sounds like it's time to start in on getting the Inkscape 0.37 release process underway. There's been a lot of great effort from many people going into this release, and we're all looking forward to delivering 0.37 to the community. I read over the latest version of the release notes yesterday and am amazed at how much has been acheved, well beyond the planned objectives. The steps we need to take to do this release are the same as before. 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. We need to finalize the code style guidelines, which basically means getting concensus on keeping tabs or converting tabs into 4-spaces. 2. Next we will declare feature freeze. Anyone working on features right now will need to either get them in by then, or delay/disable them until after the release, or move the work onto a branch. In addition to removing high priority bugs we need to ensure we haven't lost features (like grid snapping). 3. Once the tarball release is cut, I would like to see us take an organized approach to creating and testing the binary packages, so that they are consistently named and of high quality. I'll try to draw up a plan for this for us. 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. I think we can do it if we put some organized effort into it; we've got a good product and a lot of people will be thrilled to get word about it.

1 0