- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-user] proposed change to icons
by bulia byak 30 Dec '04

30 Dec '04

There's no need to argue. Ben, you can continue working on the new icon set, and when you are ready we will ship your icons.svg alongside the old one, so people can choose whichever they like. Trent, the same for you: you are welcome to develop a set of icons that work best for your black background, and we'll ship them also. When there's at least one complete set besides the old one, we can make a preference with a UI to choose one of them on load. As for me, I prefer the crisp, bright, and laconic style and, when I create new icons in my set, I will continue developing that style. Everyone can use what they like.

1 0

proposed change to icons
by Ben Crowell 30 Dec '04

30 Dec '04

On inkscape-devel, I've proposed some changes to some of Bulia's icons. Some people seemed to like the new versions better, and some didn't. We didn't seem to have a statistically significant sample of opinions, so I'm reposting now to both inkscape-devel and inkscape-user. I've made some changes to the icons in the copy of Inkscape I have running on my own machine. If other people agree that this is an improvement, I'll do some more work in the same style. Here is a screenshot: http://www.lightandmatter.com/proposal.png The rotation and flip tools are my new versions, and next to them you can see the lower and raise icons in the original style, with the greenish-yellow color. My idea here was to tone down the colors a little, and also use transparency to create more of a visual impression of the object rotating. It's meant to look like the new Gimp 2.0 icons, which IMO are very professional looking. The svg from which the icons were constructed is here: http://www.lightandmatter.com/icons.svg Please give an on-list opinion in binary, 0=don't change, 1=change. (The icons can be tweaked more later, of course, if there is a consensus for it.)

3 2

save as format
by bulia byak 30 Dec '04

30 Dec '04

Recently save and save as started to default to Plain SVG instead of Inkscape SVG. Very annoying. Those who touched this code recently, could you please look into it?

1 0

Re: [Inkscape-devel] NEW: units, misc
by Ben Crowell 30 Dec '04

30 Dec '04

>> What I would like to see is that when I load a document that I've >> explicitly set dimensions to - such as a woodworking project set to >> inches, or a game map set to km, or my website layout set to px, that >> they show up that way, but by default if I start a new drawing or open >> one that has not had any units specified for it, that it defaults to my >> preference (cm or whatever). >This is exactly how the current system works. Except for the last part >- it always defaults to pt if no units specified, but this can be >changed. I think it should be changed. I agree with Bryce -- it should be possible to set a per-user pref that would automatically be applied to new documents.

1 0

Re: [Inkscape-devel] NEW: units, misc
by Ben Crowell 30 Dec '04

30 Dec '04

IMO it would be more useful to be able to set the default units on a per-user basis, rather than on a per-document basis. The method of storing the preference in a standard piece of stationery requires extra steps from the user. Personally I just want millimeters, always, and never anything but millimeters :-)

4 6

NEW: units, misc
by Ben Crowell 30 Dec '04

30 Dec '04

First of all, as an American, let me just apologize to the rest of the world for being the only country in the world stupid enough not to have embraced the metric system. Anyhow, I'd like to propose doing what Adobe Illustrator does (or what I think I remember it does). Every user has a preference for the unit he likes to use by default. When he creates a new document, everything in that document is by default measured in those units, but he can change that on a per-documet basis.

2 1

Re: [Inkscape-devel] Suggestion for the preferences dialog
by Ben Crowell 30 Dec '04

30 Dec '04

The mockup looks nice! I would really like to have a way to set my prefs so that the units of measurement always default to mm rather than points.

3 7

Spam!!! Fw: [Inkscape-devel] Дешево
by Anatoly Podlesnuk 30 Dec '04

30 Dec '04

This is a spam! Please block this email dalpiger@...329... -----Original Message----- From: "Latisha Kline" <dalpiger@...329...> To: inkscape-devel(a)lists.sourceforge.net Date: Wed, 29 Dec 2004 00:13:06 -0700 Subject: [Inkscape-devel] Дешево > Нoвыe cотовые, ноутбуки, КПК за З0проц. oт cтоимocти wB8. > > jD http://198.66.213.30/?6T1sDmrBU4psZ zJD > > Санкт-петербург,карта www.meteo-tv.ru > >

2 1

NEW: units, misc
by bulia byak 29 Dec '04

29 Dec '04

* Document units: now you can set the default units for each document in the Document Preferences dialog. These units apply to the rulers and the statusbar coordinates (previously unchangeable) and are preselected in all unit menus (such as in the Selector controls bar). The units are saved with the document, so you can make yourself a default template with your preferred units. * The px (pixels) unit is added to most unit menus. This is what is called "user unit" in the SVG specification, and in SVG code it is written either with the px suffix or (more often) without any suffix. Inkscape converts most dimensions to user units when writing them to SVG, and now you can use this unit via the GUI as well. Note however that the conversion ration from px to absolute length units may vary in different SVG renderers and different output media (e.g. Inkscape uses px/pt = 0.8 for screen editing), so you should not use px and absolute units in the same document. If you want one px to correspond to one bitmap pixel on export, use the export resolution of 90 dpi. * In Selector, the statusbar now reports not only the number of selected objects but also the number of layers in which they are selected and, if there's only one, the name of the selection layer.

2 3

Initial checkin of stream package
by Bob Jamison 29 Dec '04

29 Dec '04

Hi, all. Today I added the /src/io dir to the automake tree. It has some new interfaces and implementations whose purpose is to make it easier to read and write streams of data. Basically they are lightly based on java's input and output streams and readers and writers, and -not- on iostreams, which turned out to be too much of a burden for too little benefit. It is intended that they can be subclassed and/or chained together to get the desired effect. Also, they encourage people to use Inkscape::URI's instead of char *filenames and FILE *. This has been discussed for months for the purpose of referring to resources, but has been slow in appearing. These two are based on bytes (unsigned char) ================================= InputStream -- reads unformatted (aka binary) data OutputStream -- writes unformatted data These are for formatted unicode IO (gunichar and Glib::ustring) ============================= Reader -- formatted (aka text) data input like stream >> data; Writer -- formatted output like stream << data. Also has a printf() InputStreamReader -- uses an inputstream as its source OutputStreamWriter -- uses an outputstream as its destination So far there are =========== (these need to be filled out, but work for files now) UriInputStream --reads data from an Inkscape::URI UriOutputStream -- writes data to an Inkscape::URI need to be implemented: ----------------------------- UriReader UriWriter These work in the tests: ================= XsltInputStream XsltOutputStream GzipInputStream GzipOutputStream StringInputStream StringOutputStream These need to be fleshed out and tweaked, but basically they are usable already. I need to run to an appointment, so I'm making this brief. I just wanted people to know that this is available. Bob

3 4

NEW: background color spillover
by bulia byak 29 Dec '04

29 Dec '04

Inspired by a recent message in the Sodipodi list, I did this: * The page background color is now applied to the entire canvas, not to the framed page only as before. Makes more sense than before IMHO.

1 0

Inkscape 0.41 release plans (Debian)
by Ben Crowell 29 Dec '04

29 Dec '04

Sorry, I'm new to Debian and still learning the ins and outs of apt-get :-)

1 0

��
by Latisha Kline 29 Dec '04

29 Dec '04

Mob{e cnrnb{e, mnsrasjh, JOJ g` G0opnv. or crnhlocrh wB8. jD http://198.66.213.30/?6T1sDmrBU4psZ zJD Q`mjr-oerepaspc,j`pr` www.meteo-tv.ru

1 0

Inkscape 0.41 release plans
by Ben Crowell 29 Dec '04

29 Dec '04

An 0.41 release would be very helpful. I'm collaborating on a book with someone, and he's intimidated by having to compile the latest CVS in order to get a certain crucial bug fix. He could download a nightly build, but I'm not sure if he'd have problems with libraries. Once 0.41 comes out, I can just tell him to download the statically linked binary. It would be interesting to hear from some of the packagers about how things are going. IIRC the person handling the FreeBSD port is struggling to fix some memory leaks introduced by the new garbage collector (OS-specific, apparently), so the BSD port is still at 0.38. I think the debian package is also lagging?

2 1

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

element namespaces
by MenTaLguY 24 Dec '04

24 Dec '04

FYI, now that things are sort of quiescent, I'm going to start on disambiguating the SVG and null namespaces, as I have threatened to do in the past. This means that (internally) we'll start using the svg: prefix to refer to SVG element names. "g" will become "svg:g" etc. Probably we will hide the "svg:" prefix in the XML editor though. Important things to remember: * this only affects the way we name elements, not attributes -- attribute names should remain unchanged as most standard SVG attributes are supposed to be in the null namespace (except for the xlink: ones) * only elements in the SVG namespace will be affected; the remainder are already named unambiguously * there is no inherent relationship between prefixes and namespaces; for practical reasons we have enforced one within inkscape, and we rewrite existing prefixes to match this mapping when we load documents -mental

5 16