- Inkscape Devel - Inkscape Mailman

Feature Freeze for Inkscape 0.40 Release
by Bryce Harrington 22 Nov '04

22 Nov '04

It's time to start making the final push towards getting the release out the door. Here's the plan: Feature Freeze Phase: * Starts at End of the Day, Sunday, 11/21 * All feature development work ceases * Last pass through bug tracker for show stopper bugs * Last chance to submit tutorials and translations Hard Freeze Day: * All codebase activity stops for one day * Conduct final QA testing * Unless a show stopper is found, establish Release Branch * If show stoppers are found by end of day, go back to Feature Freeze Release Branch: * Verify AUTHORS, version number, release notes, etc. * Only intended for last minute cleanup * Remember to merge bug fixes back to main branch too * Announce Inkscape-0.40 final tarball to packagers * Create packages and post to SourceForge Release PR: * Update Freshmeat page * Post announcement of release to news sites, blogs, etc. http://inkscape.org/cgi-bin/wiki.pl?AnnouncingReleases * Notify distro vendors of new release availability How's that sound? Bryce

3 4

Re: [Inkscape-devel] slower than sodipodi (fwd)
by MenTaLguY 22 Nov '04

22 Nov '04

On Wed, 2004-11-17 at 13:15, Carl Worth wrote: > > For a simple renderer, something like the SPObject/SPRepr split is likely > > to be severe overkill. > > A simple renderer, we have already in libsvg-cairo. > > Beyond that, people are interested in a standalone, cairo-based SVG > viewer with support for dynamic HTML. Libsvg-cairo is not up to that > task. What I don't know is if it makes sense to start trying to build it > up, or if we should instead extract the SVG guts from something else, > (such as sodipodi). Some of it is going to have to be built independently. Sodipodi has a lot of deep architectural issues that need fixing; I don't think you would find it a good choice. Inkscape, in turn, inherited the same deficiencies and we're far from getting them all fixed yet. It also uses C++ and has some additional dependencies that might be undesirable for a more general library. I think the biggest thing Inkscape can bring to the table up front is architectural "lessons learned". If you want dynamic HTML (by which I assume you mean DOM), my feeling is you'll need to do something similar to what Sodipodi and Inkscape do: we have a pre-chewed "semantic" layer a bit like librsvg's, and then a raw XML/CSS abstract syntax tree underneath it, with protocols for synchronizing changes between the two. I hate reinventing wheels, though. What I hope is that we can take designs prototyped and tested in Inkscape, contribute them to cairo/f.d.o as components of more portable C libraries, and adopt those libraries ourselves to the extent practical. Sort of peeling layers off the bottom as we go, I guess. > I'd like to see a good "standard" retained-mode API built on top of > cairo. It should be the kind of thing that might make it almost trivial > to write a dynamic SVG viewer as mentioned above. It could also make a > good replacement for libgnome-canvas, (something that Gnome seems to be > grappling about for right now). My impression from lurking on Rosegarden lists and those of other KDE projects is that the state of the generic QT canvas isn't much better. You know, actually, it's almost like there's a curse on general-purpose canvas libraries... It might be helpful to examine why such projects seem to keep failing. I have a feeling mistakes in that area are easy to repeat. > As for making this portable, (ie. for Gnome and KDE), I don't know if > it should talk to one of the existing event-loop integration projects, > or if it should export its own hooks for plugging in an event loop, > (ie. perhaps libevent compatible or something). Someone who better > knows the toolkits and integration projects should be consulted there. Based on my experiences with Inkscape and Sodipodi, trying to treat every node in the display graph as a "mini-widget" with event dispatching is a mistake for broad and deep graphs like those that would correspond to many complex SVG documents. The important primitives to have in a retained-mode graphics API for graphical interactivity seem to be: * find the first descendant of a specified node matching a predicate (given as a closure), maybe with a choice of traversal strategies * primitives for determining whether a node overlaps with a given shape, maybe with optimized versions for testing against a point+tolerance radius, and against a bounding rectangle And then you can readily build "mini-widgets" on top of that if need be (potentially as a higher-level library), but you aren't forced to deal with the whole display graph that way. > In the meantime, has anyone played with cairo-based rendering for > inkscape? It shouldn't be too hard to get going, (for example, the > Scribus guys said they got something working in just one weekend last > week). Me, kind of. I've been experimenting with it a bit offline, and plan to work on it more earnestly during the 0.41 development cycle. One of the big hurdles is that it would need to work on Win32. As far as I know there is no Win32 GDI surface type, and it's not obvious how to get at the in-memory buffer of a Cairo image surface. Maybe some of the Win32 Inkscape developers could help with that, though (anyone interested?). -mental

3 4

fake small caps
by David Christian Berg 21 Nov '04

21 Nov '04

When a font doesn't have real small caps, they are the normal capitals scaled to 70% of the original hight or the such. Now this way they are too thin and don't look all that good. I wonder what the result would be like, if you trace a letter with an outline that varies it's thickness with the slope of the outline. Ranging from 0 thicknes for horizontal to 100% thickness (how many pts that are is adjustable) for vertical lines. I have no clue, it that works, but I think it might look quite OK. It's properbly not svg complient at all :( I'll propose this to the scribus list as well. David

2 3

NEW: changes keyboard selection commands
by bulia byak 20 Nov '04

20 Nov '04

I don't really know how the keyboard selection commands should best behave with respect to layers/lockedness/hiddenness, so I decided to make this configurable. Now there's a "Selecting" tab in Preferences which has three checkboxes that affect "Select all" (Ctrl+Shift+A) as well as selecting by Tab/Shift+Tab: - select only in current layer - ignore hidden objects - ignore locked objects By default all three are on, which is the most natural setting, but it's different from the behavior in the past and may not be the most convenient. Experiement and report which works best for you. Now only the Find dialog remains to be made layer/lock/hide-aware.

2 2

Layers dialog
by Bryce Harrington 20 Nov '04

20 Nov '04

Mental, I've got most of the layer rename dialog thingee set up. Could you put the code needed to rename a layer into the apply() routine in layer-properties.cpp? Bryce

1 0

assert in xml editor
by bulia byak 20 Nov '04

20 Nov '04

Every time I select a node in XML editor, I get (inkscape:14979): GLib-GObject-CRITICAL **: g_value_get_uint: assertion `G_VALUE_HOLDS_UINT (value)' failed Anyone else seeing this?

3 5

test ignore
by vellum 19 Nov '04

19 Nov '04

1 0

slow rendering when zoomed in
by David Christian Berg 19 Nov '04

19 Nov '04

I'm kinda confused, that rendering takes a lot longer, when I zoomed in to a place, while when zoomed out moving objects was quite fast, but well, is not a accurate of course. Any explanation for the really annoying slow down when zoomed in? David

3 4

layer testing
by Gazal, Geraud (GE Healthcare) 19 Nov '04

19 Nov '04

tested with 17-nov-2004 build on win2k, here is a sum up some feedback ? preliminary In Layer1, draw a rectangle Then lock the layer chapter 1 a) toggle to selector tool, try to select the rectangle by clicking on it -> impossible (cool) b) try to select object with click-drag ctrl-click or shift-click -> possible (don't know if it is cool or not...) and try to modify then -> possible (not cool) c) open the XML editor, select the rectangle, go back to canvas, the rectangle is selected and can be modified scaled, filed, transformed... (cool) d) toggle to rectangle tool, try to select the rectangle -> possible (not cool), and the rectangle can be modified toggle again to selector tool -> the rectangle is selected (not cool) and can be modified chapter 2 in the same (locked) layer toggle to any shape tool and try to draw another shape -> possible (don't know if it is cool or not) then toggle to selector tool and try to select them -> same as in chapter 1 -> objects can be selected by click-drag ctrl-click or shift-click, but not by click They can then be modified (transformed, filled, ...) or aligned.... regards, matiphas

5 8

layers and locking
by MenTaLguY 19 Nov '04

19 Nov '04

FWIW, what most people expect from layer locking is just "make this layer safe so I don't accidentally change it (or the objects on it)". After some thought, I think the best set of behaviors are these: * tools capable of selection only select objects if they are visible, unlocked, and all of their parents are unlocked * drawing tools can only draw if the current layer and all its ancestors are visible and unlocked * locking a layer unselects all selected descendants of that layer, but locking an object does not unselect that object Per Peter's suggestion, "locked" may not be the most appropriate label for the per-object locking (since it doesn't render the object immutable, really), although I think "insensitive" is marginally too jargony. Inverting the meaning and labeling it "selectable" might be most appropriate. Layer locking ought to remain called "locking", though, since that is the common and expected term. -mental

3 2