- Inkscape Devel - Inkscape Mailman

pre4 requested
by bulia byak 23 Nov '04

23 Nov '04

The absolutely last feature, the "new layer" dialog, has been just checked in. Drawing on locked or invisible layers is disabled. So we are good to go into freeze as soon as pre4 is made (source and static binary). There are two layer bugs which I hope are easy to fix: - when renaming layer, the widget at the bottom is not updated until you move mouse over it - when creating new layer, if you press Enter in the dialog, the layer is created twice (clicking on "create" does it once as expected)

1 0

Freeze question & updated spanish po
by Lucas Vieites 23 Nov '04

23 Nov '04

Hi, I'm attaching an updated spanish po. Is the "feature freeze" is also a "string freeze"? If no new strings are added, I would like to do a full revision of the correctness of the strings in their context. For this I must agree with bulia in insisting on the creation of static builds. I'm having continuous failures trying to compile gtkmm on my system, which I can't afford to have unstable. Cheers, -- Lucas Vieites Fariña Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

5 9

OPB: Linux Brings Oregon International Attention
by Bryce Harrington 23 Nov '04

23 Nov '04

This is terribly off topic but I thought it was cool - our local PBS station is running a piece about Open Source here in Oregon... http://www.publicbroadcasting.net/opb/news.newsmain?action=article&ARTICLE_… Bryce

1 0

SVG Linking
by NAGY Endre 23 Nov '04

23 Nov '04

Greeetings I attempted to invoke the example in S17.1 of the SVG 1.1 specification in inkscape. This deals with "Linking out" of SVG content.The relevent part of this is <a xlink:href="http://www.w3.org"> <ellipse cx="2.5" cy="1.5" rx="2" ry="1" fill="red" /> </a> When invoking the example in InternetExplorer, the affect of clicking on the ellipse is to bring up W3's web page. I have not found a way of achieving this in inkscape. The relevent parts of the spec are 1. "SVG 1.0 only requires that user agents support XLink's notion of simple links." 2. "By activating these links (by clicking with the mouse, through keyboard input, voice commands, etc.), users may visit these resources." 3. "If the above SVG file is viewed by a user agent that supports both SVG and HTML, then clicking on the ellipse will cause the current window or frame to be replaced by the W3C home page." WRT 1, does inkscape meet this requirement WRT 2, MouseClicking events in inkscape are trapped for the puposes of the selector tool (I dont know how to turn of all tools). How can I activate the link WRT 3, My purposes are not the rendering of HTML but rather the invocation of a program. Does inkscape support this and how. Regards Endre IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient.

2 1

caption for Layer - not readable
by Taraben, Adib 22 Nov '04

22 Nov '04

Hi, I extracted the last win32 snapshoot on my win2000 box. My problem I cann not read the caption on the layer-combo-box on the statusbar. The Font is to small or hiroglyphic ?? attached screenshot. HTH, Adib.

4 4

Spam again
by Gazal, Geraud (GE Healthcare) 22 Nov '04

22 Nov '04

Hi The wiki has been spammed once more. The spammer is registered as Durik... ( see revisions of spammed pages for more info) Regards, Matiphas

2 1

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

patch tracker > text in shape
by john cliff 19 Nov '04

19 Nov '04

Hi all, Theres a patch in the tracker I'd really like to get in the codebase before 0.40, its a pretty simple bit of code, just wasn't sure on sunday if we were meant to have been in freeze or not so rather than commit it I put it in the tracker (its also pretty much the first thing I've done with the codebase since july, so was feeling a bit rusty, thought a second set of eyes going over it wouldnt hurt) Its a simple right click menu entry for "add text to shape" which creates a flowRoot structure containing clones of the selection. The text itself still erquires editing with the XML editor, but it takes the pain out of trying to create the structure. Just seemed a waste to have the rendering for a feature thats requested so much, but to make it so hard to actually use. Patch number is 1066358. Cheers John

2 1

RE: [Inkscape-devel] layer testing
by Gazal, Geraud (GE Healthcare) 19 Nov '04

19 Nov '04

OK, thanks a lot for the quick reaction and code update. I plan to test again this WE on WinXP, win2k, mdk10.1 (if i manage to build) and debian (ubuntu) Regards, Matiphas > -----Original Message----- > From: MenTaLguY [mailto:mental@...3...] > Sent: vendredi 19 novembre 2004 07:35 > To: bulia byak > Cc: Gazal, Geraud (GE Healthcare); Inkscape ML > Subject: Re: [Inkscape-devel] layer testing > > > On Thu, 2004-11-18 at 23:30, bulia byak wrote: > > > Mental: I now fixed that by traversing the chain of all parents in > > SPItem::isLocked(). Please review this fix. It works but may not be > > optimal. > > I can't think of a better approach. When I realized the > problem earlier > today I was going to do that myself. > > > Perhaps better if you can make it inherited in the setter, > > not getter. > > I wouldn't try that unless the getter was unacceptably slow. > > Currently, the setter is O(1), and the getter (with inheritance) is > O(log n). Doing it the other way around would make the > getter O(1), at > the expense of making the setter O(n), which would suck much worse for > large trees. > > It might not be such a big disadvantage if SVG trees were > typically deep > and narrow, but shallow and broad is the normal case: it's not too > unusual to have e.g. 200 children of a single parent, but > nesting deeper > than 3 or 4 levels is unusual. > > Under those circumstances, traversing upwards (even multiple times) is > much cheaper than recursively visiting all descendants. > > > > 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) > > > > I think it's not cool but it needs fixing in many places, > so unlikely > > to be ready for the release. > > Hmm. I'd still like to look into it if we could. It's a > pretty visible > bug. > > -mental >

1 0

Re: [Inkscape-devel] "Lock" vs "Sensitive"/"Insensitive"
by Joshua A. Andler 19 Nov '04

19 Nov '04

> On Wed, Nov 17, 2004 at 10:19:12PM -0500, MenTaLguY wrote: > > > We can investigate whether it makes sense to separate them in 0.41, > > but for now we need to fix the tools etc to treat such objects and > > layers as immutable, at least as far as the mouse tools are concerned. > > Brisgeek was saying that offhand he couldn't think of a situation where > he'd want to mark objects as read-only/immutable (other than having the > whole diagram be immutable, as in inkview). > > Brisgeek and other drawing people, can you think a bit more about this? My thought are that if I lock a layer, I shouldn't be able to do anything to that layers' objects until it is unlocked (other than change visibility, which is a layer level option). And my reasoning goes based on experience with other vector drawing apps... essentially it's the expected behavior. > To me (as a non-artist) it doesn't seem very useful to prevent > modification with the mouse tool of already-selected objects, as it's > easy to deselect them if you've just made them insensitve. Whereas it > does seem useful to be able to modify things that you've gone to the > trouble of selecting despite them being insensitive. To tell you the truth, more artists will end up using Inkscape than non-artists. And it is quite useful to be able to know that you can lock a layer, do a rubberband across the canvas to select all objects of my unlocked layers and not have to worry about anything in my locked layer getting selected as well. In Illustrator & Freehand (as well as others) that is the behavior. Also, as I just tested in Illustrator, if you have an object selected and lock the layer it's on, it is automatically deselected (as you can't modify something that is locked). That makes sense to me as well. If I click lock, it's because I'm don't want to edit that layer (or anything on it) and it saves me a click with the having to deselect manually (minor, but functionally it makes sense with how lock works in Illustrator). > I'd note that it's less work for it to mean merely insensitive rather > than insensitive and immutable from mouse tools. I'd suggest that at > least for 0.40, we keep it as meaning merely affecting > canvas-selectability. > > > Most drawing applications combine both behaviors (unselectable and > > immutable) into their notion of "lock". > > We'll keep that in mind, though Inkscape's general policy is that we > should find the most useful behaviour, and let other programs catch up. This, quite honestly, is where the other guys (Adobe, Macromedia, etc) set the standard and people coming over will expect certain things to function in the same way. I'm not saying it's necessarily right, but layers are very important and people will get turned off if they're "broken" in their view. If we separate unselectable and immutable into separate layer-level options it would make sense to all of us geeks. But most artists aren't really geeks and don't want separate functions, it just needs to do what they expect. I guess the best way to explain it, is that a lock is for protection. The best analogy I have for the lock doing both functions is that if you have your front door locked on your house, people shouldn't be able to A) come in and B) rearrange your furniture. But you unlock it and it's all fair game. Basically the object is a house (properties being furniture), and we're the random people. Just my .02 on the layer subject. -Josh

2 1

sp_repr_position() optimization
by MenTaLguY 19 Nov '04

19 Nov '04

I comitted a small optimization for SPReprs tonight; essentially sp_repr_position() and sp_repr_n_children() are now cached in SPReprs. The way it's actually accomplished is with SPRepr::_n_siblings, which is the number of siblings counting from that particular repr (inclusive) to the end of the sibling list. Looking at it from the parent's perspective, SPRepr::_n_siblings of a its first child will == sp_repr_n_children(), and the sp_repr_position() of a specific child will be: ( sp_repr_n_children(parent) - child->_n_siblings ) Normally, only the first child's SPRepr::_n_siblings will be kept up-to-date; there is a boolean flag (SPRepr::_child_counts_complete) in the parent indicating whether the remainder of its children also have up-to-date _n_siblings members. That flag is checked when sp_repr_position() is called, and the children scanned and updated "lazily" at that time if necessary. This permits node addition and removal to remain constant-time activities. The beneficial effect is that sp_repr_n_children() is always constant-time, and all calls but the first to sp_repr_position() are also constant-time. This will be important later for things like the "sort by overall z-order" facility that bulia asked for (we may need it for some finer points of the 0.40 release), as well as Gtk treeview models (which would necessarily heavily query sp_repr_position() to build GtkTreePaths) later. -mental p.s. Note that sp_repr_nth_child() isn't any faster, but I don't think it's necessary to further optimize at this time. p.p.s. _child_counts_complete sucks as a name. any better ideas?

3 4

pre3 needed, status
by bulia byak 19 Nov '04

19 Nov '04

I think we need a pre3 today. Several important fixes went in, and Mrdocs promised to (finally!) make static RPMs for it. Just a precious few things remain to be done before we can enter freeze: 1 add a dialog asking for a name of a new layer to create, with a couple of checkboxes "Make a sublayer" and "Move selection to the new layer" (I think Mental could use help on this one, it's a simple task for someone) 2 fix two crasher bugs: - 1056658 win98: crash on save (msvcrt error box) (JonCruz) - 1059059 crach autopackage 0.4, may be a dupe of 1064399 3 fix the several portability bugs (actually I think mental handled them already) That's the minimum, the more bugs we fix the better. But this minimum is minimal enough already, which is good news. Let's all make one final push.

4 4

Recent error messages
by Joshua A. Andler 19 Nov '04

19 Nov '04

First I've noticed that the log window has been popping up frequently with recent builds... unfortunately I've been really tied up the past week and a half and have only skimmed the lists (so I'm sorry if this has been discussed), anyway since this stuff started it says: ----- (inkscape.exe:2720): Gdk-CRITICAL **: file gdkdraw.c: line 1351 (gdk_drawable_re al_draw_pixbuf): assertion `width >= 0 && height >= 0' failed ----- And it seems to happen if I switch to a different program and then when I pull inkscape back up it spits that out. The really bad thing though is that Inkscape got caught in a loop here this morning. Using the most recent build in the Win32-snap dir, It just kept spewing the following into the log window: ----- (inkscape.exe:952): Gdk-WARNING **: gdkgc-win32.c:935: SaveDC failed: Not enough storage is available to process this command. (inkscape.exe:952): Gdk-WARNING **: gdkdrawable-win32.c:1493: CreateCompatibleDC failed: Not enough storage is available to process this command. (inkscape.exe:952): Gdk-WARNING **: gdkgc-win32.c:1074: RestoreDC failed: The pa rameter is incorrect. ----- Unfortunately I wasn't able to figure out what triggered it. And also I could not control inkscape whatsoever as it would just pull the log window ontop. Anyway, it just continually repeated those 3 lines non-stop until I finally killed it. Any ideas on either one? And on a side note I'll be posting the tracing quick-start in probably an hour or so for review.

5 12

rename layers dialog runtime error
by bulia byak 19 Nov '04

19 Nov '04

(inkscape:599): Gtk-WARNING **: Attempting to add a widget with type gtkmm__GtkHBox to a gtkmm__GtkDialog, but as a GtkBin subclass a gtkmm__GtkDialog can only contain one widget at a time; it already contains a widget of type GtkVBox and the dialog is empty, tiny sized, not modal, and jumps up in the corner of the screen...

1 0

fr.po error
by bulia byak 19 Nov '04

19 Nov '04

I get this when doing make: file=./`echo fr | sed 's,.*/,,'`.gmo \ && rm -f $file && /usr//bin/msgfmt -o $file fr.po fr.po:1:2: parse error fr.po:985:8: invalid multibyte sequence fr.po:1144:59: invalid multibyte sequence /usr//bin/msgfmt: found 3 fatal errors

2 1

Wiki
by Arpad Biro 18 Nov '04

18 Nov '04

Hi, The Wiki has been very badly spammed again. It seems sooner or later we will be forced to do something drastic about this... Arpad Biro __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

1 0