- Inkscape Devel - Inkscape Mailman

Article about Cairo
by Bob Jamison 04 Feb '05

04 Feb '05

Here is another item of interest: http://www.osnews.com/story.php?news_id=9609 Bob

1 0

input "preedit" handling disabled
by Kees Cook 04 Feb '05

04 Feb '05

While investigating bug 1086769, I discovered that inkscape's on-canvas text editing does not handle (some?) multi-byte character entry. Here's what I did... I installed "scim-chinese" and "scim-gtk2-immodule" which gives me an "SCIM" input module (right-click on text-entry widget to select SCIM). Then, you can hit ctrl-space to switch to chinese-char-entry mode, which lets you type a letter (say, "a") and then select (with numbers) which character you want. In the text widgets, this works great. On the canvas, inkscape would do VERY weird things: it would add the "preedit" character to the _end_ of the string instead of at the cursor position, and then when the final char was selected, it would overwrite the char AT the cursor position. Basically, the SPTextContext is attempting to handle the "preedit" character events itself, but it doesn't do it right. Since "preedit" handling doesn't seem to be _required_ for input to be processed, I've disabled it. This just means that the "predit" char isn't visible until you're done typing it in. What's weird is that other Input Modules (like, say "IPA") will show their preedit letters and inkscape seems to handle it correctly (type "a" "e" with the IPA IM, to see a merged "ae" character). Even with preedit disabled, this works on the canvas. So... I'm not sure why preediting is there at all, and I've disabled it. Can anyone find any reduced functionality as a result of this? Currently this _fixes_ chinese input (at least with SCIM), so I'd like to leave it like this until I can better understand the IM system. -- Kees Cook @outflux.net

3 3

Re: [Inkscape-devel] Some suggestions for the fill and stroke dialog
by bulia byak 04 Feb '05

04 Feb '05

On Fri, 04 Feb 2005 12:11:06 +0100, David Christian Berg <david@...407...> wrote: > > - a current color indicator (like the one in the "color selector" in > > your mockup), except that it must not be in any dialog, but at the > > bottom of the main toolbar, on on the left of the horizontal palette > > Hmm, from Adobe I'm used to having it under the main toolbar, an it's > make sense to be there, but with the current layout it would be too > small. It doesn't need to be that big. Just a square with a border. Our main toolbar is wide enough for it I think. > So maybe I'd just put two buttons in front of the color-selection > bar/palette at the bottom.I think that would make a lot of sense. Possible, too. > > With these, 90% of reasons to open fill&stroke will be eliminated, and > > its size won't matter much anymore. > > Well, you'll still have to have a dialog to change the colors (opening > via double click) If our default palette has some common colors, changing them will be unfrequent. > and you'll have to have a dialog for stroke stuff. Also unfrequent with the exception of stroke width. > Concerning the CMYK vs RGB argument, Andreas gave: I think it should be > a drop down, because you've gotta be able to define RGB colors, even > when you're in a CMYK document, but the standard of the drop down has to > be set by document prefs. I don't care "what kind of document is this". Inkscape is a design tool, not prepress tool. I want the color mode which is the most convenient for me to THINK IN, and most often this is either HSV or wheel. If after I create my design I need to convert it to CMYK for some reason, I can use other tools for that. The CMYKness of a document must not affect my design process. The fact that in Adobe products it DOES affect it, is one of the main problems I have with those products. > > With palette, you click to change fill, shift+click to change stroke > > (same as the dropper tool now). Again, using fill&stroke for this will > > be much less frequent, so there's no need to break it up. > > (There also should always be one empty color field to add new colors Not empty, but a "duplicate color" command in the right-click menu of the swatches. > and > you'll have to be able to drag colors within the pallete. Yes > Furthermore: > have a Inkscape setting to have _no_ colors in the palette at startup. > That's the way I'm working, predefined colors (other than black and > white) are unnecessary for me and hinder the workflow, while other > people might want to have them.) Yes, though new users should see a complete enough palette by default > Point is that maybe this should be a document setting, Right now it is more of an Inkscape setting, because the color selector remembers the tab you used last. And I like it this way. It's not like length units which indeed may be different per document; colors are just colors everywhere. > Hmm, disagreed. Put the other stroke stuff into an expander like in the > mock-up, so that you can hide and show it easily, when you need it. In > general I don't like the idea being able to do the same thing at > multiple places. Exactly, this is what we need - one "quick" way to do something and one "complete" way to do the same. Like the quick layer selector and the layer dialog. I see absolutely no problem with this. Changing stroke width is such a common operation that it MUST be in the window interface somewhere. > I'm not yet sure, how the selector in the mock-up is supposed to work. > Wouldn't it make sense if it had tabs at the top for switching between > start, join and end markers? Yeah, probably, details need to be worked out, what I like however is the two-dimensional table instead of drop-down menu. > Or maybe you should just have a Markers > dialogue without any lines shown in the preview and you drag them and > drop them into the stroke-style dialogue as start, join or end > marker.... I think that would make a lot of sense, because that way you > can easily use any marker anywhere. As opposed to what? Can't you now use them anywhere? > > SVGs version 1.1 documents cannot use CMYK at all, so this is > > irrelevant. The CMYK selector is just a convenience. And then, even if > > I have a CMYK document of some kind, why on earth can't I use HSV or > > RGB to find a color I want, and have it converted to CMYK by the > > program? > > It's true, but for some reason graphic programs usually distinguish a > little stronger between the color spaces. I really hate that. I think the reason is that most of those programs are just old, and were initially paper-oriented, and thus keep sticking to their old superstitions even though they are mostly irrelevant today. > > Separating markers does make sense, though maybe not into a dialog but > > into a new tab in fill&stroke. > > hmm, that make me think of something. why not put everything in separate > tabs? Like [stroke weight], [caps and joins] (including miter limit -- > miter limit needs a spinbox!), [pattern] (this might as well get more > options like in Corel, where you can define your own pattern styles) and > [markers]. Possible too, but only if we use icons only, not words, for tab headers, otherwise they won't fit. > Hmmpff, the quick layer selection?? Maybe it's a good idea, once there > is another layer/objects dialogue, but as is right now, I haven't yet > managed to make layers part of my workflow. I only notice them, when for > some strange reason I can't move one object behind another. I use layers all the time and I really cannot imagine how I lived without them. Yes, there are some operations that are difficult and clumsy with the quick layer selector, but for many simple common operations it is very convenient and natural, indeed more natural than the layer dialogs in other apps.

2 2

versioning consensus
by unknown＠example.com 04 Feb '05

04 Feb '05

Incidentally, had we ever reached a consensus on calling this release 0.41.0 rather than 0.41? A _LOT_ of people seem to be reading 0.40 as 0.4.0, so making the .0 explicit would remove the ambiguity... -mental

4 3

Another Inkscape mention
by Bob Jamison 04 Feb '05

04 Feb '05

Hi, all, Saw an article mentioning Inkscape on Newsforge today: http://software.newsforge.com/software/05/02/02/215259.shtml Bob

1 0

win32 compile problem
by Adib Taraben 04 Feb '05

04 Feb '05

I get following error in the current CVS: in the current MinGW compiler there is no such io/sys.h file HTH, Adib. dialogs/export.cpp:53:20: io/sys.h: No such file or directory dialogs/export.cpp: In function `void sp_export_export_clicked(GtkButton*, GtkOb ject*)': dialogs/export.cpp:972: error: `file_test' is not a member of `Inkscape::IO' dialogs/export.cpp:974: error: `sanitizeString' is not a member of `Inkscape::IO ' dialogs/export.cpp:1022: error: `sanitizeString' is not a member of `Inkscape::I O' mingw32-make[1]: *** [dialogs/export.o] Error 1 mingw32-make[1]: Leaving directory `E:/projekte/inkscape/src' mingw32-make: *** [all] Error 2

3 3

Object Rotation
by Aaron Spike 04 Feb '05

04 Feb '05

I have a few questions/comments about rotation. First a confession: for the last week I thought the "snap to angle with ctrl" function was broken. It wasn't. I had the snapping set at 2 degrees and the angle indicator in the status bar follows pointer. So I didn't notice that the bbox actually was snapping and I convinced myself it wasn't snapping because of the numbers didn't snap. The point is I'm wrong a lot. But would it make sense if the number in the status bar snapped with ctrl too? Or what if the number followed the object instead of the mouse? Would that make more sense or is the current behavior what one would expect? Second, what would be the pros and cons of allowing a user to choose arbitrary degrees for snapping? I was just working on a pentagonal design. I though "Hey, this will be easy. I'll just set the snapping to 72 degrees. 72 is a nice even number, right." But it wasn't a choice. I suppose you can't have every factor of 360 in the list. In the end I was saved by the tile-clones dialog which doesn't have a list. Aaron Spike

4 3

Status needed for ReleaseNotes
by Bryce Harrington 04 Feb '05

04 Feb '05

One other task needed before we get too much further is to update the Roadmap. Mental, Ted, Ishmal, and others, can you give us some quick status on the following items? [Perl, Python scripting; XSLT] [embed/outbed, gamma scripts] [Effects menu] [extensions warning and logging] [Namespace changes] [Making reprs private] Also, Arpad, can you give us a list of the translations that were updated from 0.40 to 0.41? Thanks, Bryce

9 17

Fwd: [Inkscape-user] Line marker colour
by bulia byak 04 Feb '05

04 Feb '05

forwarding to devel too.. ---------- Forwarded message ---------- From: bulia byak <buliabyak@...400...> Date: Fri, 4 Feb 2005 08:51:14 -0400 Subject: Re: [Inkscape-user] Line marker colour To: inkscape-user(a)lists.sourceforge.net On Fri, 04 Feb 2005 13:45:17 +0100, Arnout Standaert <arnout.standaert@...687...> wrote: > is there any intention of fixing bug #995815 for the 0.41 release? It's > the bug where line markers (for instance, arrowheads) don't follow the > colour of the line they're attached to. Not for 0.41 for sure, it's almost out. In fact it's not really a bug, it's just a limitation of SVG which needs to be worked around. This workaround has to be quite complex, though doable. We just need a coder who would be motivated enough to dive into it. My comments in that bug give a rough plan for attacking it. To All: Note that the people in that bug started offering real monetary awards for whoever will do this first. So, if you want to make some money, here's a good task for you! :)

1 0

embed/outbed, gamma scripts ??
by Bryce Harrington 04 Feb '05

04 Feb '05

What is "embed/outbed" and "gamma scripts" ? I see these mentioned in the release notes, but with no elaboration... This is also the first I've heard of them. Bryce

2 1