- Inkscape Devel - Inkscape Mailman

ATTENTION: libgc dependency
by MenTaLguY 19 Jul '04

19 Jul '04

Please note that sometime in the next few weeks we'll be introducing a dependency on the Boehm garbage collector (libgc), and that said library must be compiled with C++ support enabled. I'd encourage all packagers/autobuilders to investigate whether there will be any problems for them. -mental

2 1

Report for 2004-07-18 18:00 GMT-0500
by unknown＠example.com 19 Jul '04

19 Jul '04

Hi. I have some bad news. Unfortunately, the last build attempt at compiling Inkscape CVS was very unsuccesful. I'm sorry, I really tried hard. Really. Here is the LOG file, and I hope that helps.

6 5

AW: [Inkscape-devel] Plain svg format?
by Taraben, Adib 19 Jul '04

19 Jul '04

>On Sun, 2004-07-18 at 20:01, bulia byak wrote: >> Yes, and I'm thinking about _why_ this may be needed, and can only >> think of the two reasons above. > >IMO, the most fundamental (if not most common) reason is to yield an SVG >document which will validate against the SVG DTD. > >Having elements in any non-SVG namespaces would (afaiK) prevent that. > >Of course, I'm not really sure most folks care about DTDs much anymore, >given they don't play well with namespaces in general. > >-mental I care. In my special purpose inkscape is not only a drawing program but a (_THE_) svg-editor. Adib.

2 1

ATTENTION: gtkmm upgrade
by MenTaLguY 19 Jul '04

19 Jul '04

I've just comitted Aubanel's gtkmm upgrade patch. You will need to rerun autogen.sh. >From now on, libgtk+ >= 2.4, libsigc++ >= 2.0 and libgtkmm >= 2.4 are required for Inkscape. I have tried to carefully test and build, but this did require some autofoo changes I do not fully understand. So be aware, and if you have any problems please help me track them down and fix them. -mental

5 9

Plain svg format?
by Øyvind Hvamstad 19 Jul '04

19 Jul '04

Hi, I just dig this app. Good work. However, I have some problems with the new rdf metadata tags when storing plain svg in 0.39. It seems that no namespace declarations are present for rdf, dc and cc. Adding them to the top fixes the problem, but it's really a hazzle when you have some 30 figures in a thesis. :) I added these: xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" You probably know this already, but if not.. Well.. Jimi needs valid xml! Inkscape rocks! (more than sodipodi :)) -- Øyvind Hvamstad <oyvind@...457...>

5 6

All tasks for 0.39 Milestone Completed
by Bryce Harrington 18 Jul '04

18 Jul '04

All of the tasks for milestone 5 "Inkscape 0.39" are now complete (the extension proposal was the last, oft-procrastinated item). I've moved all the completed Milestone 5 tasks to the PastMilestones page. Bryce

1 0

Proposal for Hard Freeze Process
by Bryce Harrington 18 Jul '04

18 Jul '04

As mentioned in the freeze process proposal for this release, we will have a new 'Hard Freeze' step to give us better quality control for the run-up to the Release Phase. During the Hard Freeze, we all refrain from committing to CVS. Instead, necessary changes should be posted to the patch tracker. A couple people -- the "Change Control Team" -- have the responsibility to vet and apply patches if they're absolutely necessary. For this release, I'd like to propose Mental and Bulia as the Change Control Team, and that we rotate who is on this team in future releases. Because the Inkscape developers are trustworthy, I think we can rely on the honor system, rather than turning off everyone's access. If there happened to be any abuse, it can be handled on a case-by-case basis. Here's how the process would work: === Hard Freeze Phase === 0. The Hard Freeze will be announced once all of the Must Fix bugs have been addressed and the codebase passes its distcheck and tests. Nobody except Change Control commits into the release tree after this point - only to the patch tracker. 1. The Change Control Team reviews the status of the application and of recent bug fixes. They request patches for abnormalities found. 2. Only patches for key bug fixes, documentation, packaging, and translations will be taken at this point. 3. Once the Change Control Team is satisfied, they announce that the codebase is Good For Release, and branch the release candidate. (See CreatingDists.) This marks the end of the Hard Freeze phase. === Release Phase === 4. The Release Team creates the distribution source tarball package, and posts the GPG-signed tarball(s). 5. Packagers begin creating the 0.XX.0-1 packages of this release for their platforms. 6. The Release Phase should be treated like a Feature Freeze; everyone can resume committing to CVS, but should limit themselves to bug fixing, in case there are serious issues that will require making a new point release. 7. If issues are discovered during this packaging process, the Change Control Team will review the changes and their fixes and choose: a) Ignore the issue for this release. b) Put up an optional package for packagers to use as needed. The packagers increment their patch-number (i.e. 0.XX.0-1) c) Declare a minor-rev increase (i.e. 0.XX.1). All packages must be regenerated in this case. 8. Once a suitable number of working, tested packages have been posted to the file tracker, the Release Team announces that the codebase is Released. 9. Finally, announcements about the release are made. This also marks the end of the Release Freeze. 10. Normal development resumes. Bryce

3 5

tab -> 4 spaces
by Kees Cook 18 Jul '04

18 Jul '04

Is anyone interested it doing this to the source code? I made a test CVS tree to see how much would be changed. The file count is 565. :) I only processed files in /src, but it would be a giant commit. I personally find in valuable, but worry it would really disrupt other folks. On the other hand, doing it after a release seems like the best time to do it. Thoughts? -- Kees Cook @outflux.net

2 3

Re: [Inkscape-devel] Re: [Inkscape-devel] BUG and solution in align dialog
by bulia byak 18 Jul '04

18 Jul '04

> My SF name is o__b Done, you can commit your code now. Welcome to the team! :) > > One idea I had is this: Imagine you have a path consisting of strict > > horizontal and vertical segments, and you want to distribute (some of > > the) vertical segments (not nodes!) equi-spacely. I think it's a > > pretty common situation, but distributing _nodes_ will break the > > verticality of segments. So I propose to add a (perhaps optional) > > rule: If two or more nodes are aligned vertically (within some > > tolerance), consider them one node and move them as a whole during > > horizontal distributions, and the same for horizontal > > alignment/vertical distributions. Makes sense? > > > Looks weird to me, and could be surprising for the user. But I understand the > need for such a functionality. If we generalize a bit, this would be > distributing groups of nodes. But this is hard in terms of UI. Yes, what I propose is a subset of "distribute groups", and yes, fully generalized "distribute groups" is difficult to implement and may be overcomplex in terms of UI. Which is why I propose this special case - I think it's very common in practice and pretty intuitive once you get used to it. Just think of it as nodes "snapping together" when they're on one horizontal or vertical, so that distribution buttons treat them as a whole. This may be switched off by a checkbox in the align dialog (on by default, with the state remembered across sessions in a preference value). > > Another thing I always wanted to have is Random distribution. Maybe > > you can add it while you're working on that dialog, I think it should > > be easy enough? > > > > I'm not sure to understand what it means. Just throw each node on an random > position, or keeping the order and randomize the step size, or even > distribute against a distribution function (gaussian, poisson, etc.) ? In fact there may be many various approaches to randomization, but for practice, what I think will be the most useful is two buttons: Shake and Shuffle. 1. Shake: Each selected object moves by some small random distance from its current position. Here a Gaussian distribution would be appropriate, so that small displacements are more frequent than large ones. The default radius might be 0.05 of the total span (span == the distance between the outermost selected object), with this value ("the force of the shake") settable in preferences. Shake may sometimes change the order of objects if they're close together, but normally it will not. If you need a stronger shake, just keep pressing the Shake button. 2. Shuffle: All objects are placed at random points within the entire span between the outer objects. This does not preserve the order of the objects, but shuffles them like cards in the pack. For example, if you have a row of equispaced objects and you want to change their positions randomly but keep the equispaced distribution, you press Shuffle and then Distribute equispaced to space them evenly again. Note: it is obvious that the overall span of the objects will keep getting narrower if you press Shuffle repeatedly. I'm not sure if this is a problem that we have to live with, or it makes sense to try to compensate for it by artificially expanding the span before shuffling so that, _on average_, the span stays the same across many subsequent shuffles (it's an interesting mathematical problem, by the way - how much we need to expand the span for this condition to satisfy). Also note: in the above, "objects" may be nodes (in node tool) or object centers (otherwise); I don't think we need separate shake/shuffle buttons for left/right edges. However, when calculating the span, it makes sense to measure it between the outer edges of the bboxes of the outer objects, not between their centers. Let me know what you think of this plan. > Done. I'm just wondering why so many enums are anonymous and you pass plain > ints as parameters ? No idea, maybe just Sodipodi legacy... > > > Yes. But as we will refactor all the dialogs, that should be > > > the right time to do it. The only thing needed is to make > > > each dialog inherit from a class. > > > > That's a good idea, as currently there's much shared code that can be > > moved to the parent class (delete/destroy handlers, etc.). Some of the > > shared code is already factored out into dialog-events but not all. > > > OK, I'll look at this. Obviously what needs to go into that class is all the standard global variables in all dialog files (x, y, w, h, dlg, etc.).

2 1

gtkmm 2.4
by MenTaLguY 18 Jul '04

18 Jul '04

Now that we've branched for the release, HEAD is unfrozen. I think my first bit of work will be to merge Aubanel's gtkmm 2.4 patch sometime in the next few days. If this will cause undue problems for anyone, please scream now. -mental

4 6