- Inkscape Devel - Inkscape Mailman

Spiro / Raph Levien
by Bryce Harrington 28 Dec '04

28 Dec '04

---------- Forwarded message ---------- Date: Wed, 29 Dec 2004 00:17:07 +0100 (CET) From: Jose Hevia <100026838@...625...> To: clipart@...330... Subject: Re: [Clipart] OCAL identified by IBM as resource for Linux migrations >From http://www.advogato.org/person/raph/ 16 Nov 2004 » Spiro I've tentatively chosen a name for my curve editor: Spiro. I posted a "code escape" here and on the Typophile forums. So far, I've gotten little or no response from my posting here, but lots of people checking it out and sending feedback on the Typophile board. Interestingly, many of the commenters are encouraging me to patent the idea and/or otherwise try to make money off it. I'll have a new code snapshot soon. In the meantime I've been tracing the miniscules from 72pt metal Centaur (see screenshot). There's nothing like trying to use the thing for real to point out what needs improving :) There's no rush, as I'm still tweaking the core algorithms, but obviously this is something that should go into other free software applications, most especially Inkscape. What I'm most inclined to do is release all the core code as GPL, package up nice Win32 and MacOS versions with refined GUI's (especially cut'n'paste with the dominant apps on those platforms) as commercial apps, and also try to license the code for inclusion in proprietary apps. We'll see how all that plays out. ->I'd been reading his diary for long 17 Oct 2004 » [...]If I go this route, I'll need to factor the code into UI dependent and UI independent parts. That's probably good discipline in any case, especially if I'm hoping for the code to be adapted into other apps that need curve editing (Gimp paths, inkscape, etc.).[...] Jose Hevia _______________________________________________ clipart mailing list clipart@...626... http://lists.freedesktop.org/mailman/listinfo/clipart

1 0

Changing helper/sp-intl.h refs to glibmm/i18n.h
by Bob Jamison 28 Dec '04

28 Dec '04

It was discovered by one of the guys in the Jabber room last night that sp-intl.h's wrapping of gettext() in the _() macro is redundant. It is already defined by glib/g18n.h, or more proper for us, glibmm/i18n.h. After getting the concensus that making the change was ok, I went ahead and did a mass search/replace, followed by a build to test it. I removed helper/sp-intl.h, and removed its entry in helper/Makefile_insert. I changed all of the #includes from helper/sp-intl.h to glibmm/i18n.h in the 169 files listed below. Sorry about the big commit, but anything that can remove unnecessary legacy code must be helpful. The build seems to be fine, but if anyone sees any problems, please tweak it. Bob ./arc-context.cpp ./desktop.cpp ./desktop-events.cpp ./dialogs/align.cpp ./dialogs/clonetiler.cpp ./dialogs/debugdialog.cpp ./dialogs/desktop-properties.cpp ./dialogs/display-settings.cpp ./dialogs/docker.h ./dialogs/export.cpp ./dialogs/filedialog.cpp ./dialogs/fill-style.cpp ./dialogs/find.cpp ./dialogs/item-properties.cpp ./dialogs/layer-properties.cpp ./dialogs/object-attributes.cpp ./dialogs/object-properties.cpp ./dialogs/rdf.h ./dialogs/scriptdialog.cpp ./dialogs/sp-attribute-widget.cpp ./dialogs/stroke-style.cpp ./dialogs/text-edit.cpp ./dialogs/tracedialog.cpp ./dialogs/transformation.cpp ./dialogs/xml-tree.cpp ./document.cpp ./draw-anchor.cpp ./draw-context.cpp ./dropper-context.cpp ./dyna-draw-context.cpp ./event-context.cpp ./extension/db.cpp ./extension/extension.cpp ./extension/init.cpp ./extension/internal/eps-out.cpp ./extension/internal/gnome.cpp ./extension/internal/ps.cpp ./extension/internal/svg.cpp ./extension/system.cpp ./file.cpp ./help.cpp ./helper/units.cpp ./helper/units-test.cpp ./inkscape.cpp ./inkview.cpp ./interface.cpp ./knot.cpp ./main.cpp ./node-context.cpp ./nodepath.cpp ./object-edit.cpp ./object-ui.cpp ./path-chemistry.cpp ./pencil-context.cpp ./pen-context.cpp ./print.cpp ./rect-context.cpp ./select-context.cpp ./selection-chemistry.cpp ./selection.cpp ./selection-describer.cpp ./select-toolbar.cpp ./seltrans.cpp ./slideshow.cpp ./sp-anchor.cpp ./sp-ellipse.cpp ./sp-guide.cpp ./sp-image.cpp ./spiral-context.cpp ./sp-item.cpp ./sp-item-group.cpp ./sp-line.cpp ./splivarot.cpp ./sp-offset.cpp ./sp-path.cpp ./sp-polygon.cpp ./sp-polyline.cpp ./sp-rect.cpp ./sp-shape.cpp ./sp-spiral.cpp ./sp-star.cpp ./sp-text.cpp ./sp-tspan.cpp ./sp-use.cpp ./star-context.cpp ./text-chemistry.cpp ./text-context.cpp ./text-editing.cpp ./toolbox.cpp ./tools-switch.cpp ./trace/trace.cpp ./verbs.cpp ./widgets/dash-selector.cpp ./widgets/font-selector.cpp ./widgets/gradient-position.cpp ./widgets/gradient-selector.cpp ./widgets/gradient-vector.cpp ./widgets/layer-selector.cpp ./widgets/paint-selector.cpp ./widgets/sp-color-gtkselector.cpp ./widgets/sp-color-notebook.cpp ./widgets/sp-color-scales.cpp ./widgets/sp-color-selector.cpp ./widgets/sp-color-wheel-selector.cpp ./widgets/spw-utilities.cpp ./widgets/sp-xmlview-attr-list.cpp

1 0

Suggestion for the preferences dialog
by Andreas Nilsson 28 Dec '04

28 Dec '04

(This might have been fixed in 0.40, but since I run Debian testing I still use 0.39. If that is the case, ignore this mail.) I currently find the preferences dialog a bit hard to navigate, partly because it feels a bit crowded, but mostly because it presents the usability problem of tabs in tabs. See for example the Interface Hall of Shame: http://digilander.libero.it/chiediloapippo/Engineering/iarchitect/tabs.htm The tools/shapes creates the most trouble of navigation. (see http://ramnet.se/~nisse/diverse/temp/inkscape_tabsintabs.png) So, I did a little gimping and came up with a new preferences dialog similar to the one beep-media-player uses. http://ramnet.se/~nisse/diverse/temp/inkscape_new_prefs_mockup.png The icons are ones that I found on jimmacs site and thought somewhat fitted, or ones I drew very quickly. What do you think? - Andreas Nilsson

5 7

Inkscape 0.41 release plans
by Bryce Harrington 27 Dec '04

27 Dec '04

Hi all, After chatting with Ishmal, Mental, Bulia, and others, it sounds like we ought to shoot for cutting a near-term release, in the mid- to late-January timeframe. The reasoning for this is that we already have some noteworthy new features that would be worth getting out to users, and because the Gtkmm work, while progressing along well, won't be finished that quickly. If no-one has any serious objections to this proposal, we would go back into a feature freeze within the first week or so of January, focus on bug fixing for a couple weeks, and try to push out the 0.41 release by the end of the month. (As a side PR benefit, there are a number of conferences and symposia in the Feb/Mar period, so this would give fresh bits for folks to play with.) In parallel to the above release effort, the focus on the Gtkmm work will continue (and hopefully intensify), with the objective of merging immediately after the 0.41 release. The code won't be finished at that point, and won't be used for the primary UI (you'll have to use a special flag to activate the Gtkmm), but we'll finally have the code in the main codebase proper, which will hopefully enable the remainder of the work to get done swiftly. Bryce

4 5

possible bug
by Makurin Roman 26 Dec '04

26 Dec '04

When I trying to export my *.svg into *.png and path contains white spaces I`ve got an error. -- JID: drolyk@...189... ICQ: 105266647

1 0

SVG prefix commit
by MenTaLguY 25 Dec '04

25 Dec '04

Okay, I've comitted the change; from now on, name SVG elements in Inkscape like "svg:g" rather than "g". Important note: attribute naming has not changed, it's just elements I was pretty careful not to break anything, but I can't guarantee it; it was a pretty wide-ranging change. Let me know if anything broke. -mental

2 5

brief history of namespace support in Inkscape
by MenTaLguY 25 Dec '04

25 Dec '04

Just as a bit of background... Originally, in Sodipodi, namespaces were ignored entirely. Any element without a prefix was assumed to be SVG, xlink: was always assumed to be XLink, and sodipodi: always Sodipodi stuff. We did add xmlns declarations just to keep parsers happy, but that was it. Obviously that was deeply wrong to do. It was difficult for me to get buy-in for a sweeping change, however. What I did finally did get accepted was a simple hack -- I remapped the prefixes on load to what Sodipodi expected. So, at that point, if you loaded a document where the SVG namespace was bound to the blah: prefix, "blah:g" would become "g" in memory. Similarly, if ook: were bound to the Sodipodi namespace, "ook:namedview" would become "sodipodi:namedview" in memory. This is the code we inherited from Sodipodi, and the approach I refer to as "normalized qnames". Now, there were a couple shortcomings that remained: One, this was only done on load. The serialization code still didn't know anything about namespaces and we simply relied on stuffing a bunch of xmlns attributes in the document and hoping that covered everything. Not a simple thing to fix, unfortunately. Two, non-namespaced elements would appear to be in the svg namespace. This means that some non-SVG elements would get interpreted (and saved) as SVG elements. Thankfully, that was trivially fixable by normalizing svg elements to use the prefix svg: instead of none. As I noted on the Sodipodi list at that time, I did want to go back and address those two shortcomings, but Things Happened, and a year or two later I'm writing this. We did inherit both shortcomings, so it's high time I did something about them. I just knocked out the second one, and I'm hoping I can spend some time on the first one soon. The serializer improvements shouild actually afford a lot of opportunity to make our XML output prettier, including using shorter prefixes (e.g. maybe just i: for inkscape's namespace) in serialized files. And of course using SVG as the default namespace again, where practical to do so. -mental

1 0

I'm leaving a debug message in
by Ted Gould 25 Dec '04

25 Dec '04

Hey, I know that this is annoying, but I think it is important for a short while. The message that I'm leaving is a notice that an extension is being unloaded. This is because now extensions are getting unloaded if they aren't used for a while -- and this code has never been used before. But, since it happens seemingly randomly, I don't want people to start debugging something that is actually a bug in these unload routines. Now, I think that I've tested all the cases, but I'd like to keep it in for a while to make sure. -- Ted

1 0

Problems with XML Editor
by Valentin Cristescu 24 Dec '04

24 Dec '04

Hi, I can't start the XML Editor. The message is: Inskcape encountered an internal error and will close now. I'm using Fedora Core 3.

2 1

Non-coder tasks
by Bryce Harrington 24 Dec '04

24 Dec '04

Today a question came up regarding how non-coders can help improve Inkscape. This info has been added to the Inkscape FAQ, under 'Are there non-coding ways to help?': http://www.inkscape.org/faq.php Let me know if you have other ideas we could list there. Bryce

2 2