- Inkscape Devel - Inkscape Mailman

new booleans patch
by bulia byak 12 Dec '03

12 Dec '03

I've been sent a new patch that implements boolean operations, offset/inset path, and path outline. The license is public domain. It's been uploaded to the tracker. I've just compiled it and it seems to work as advertised, although I did not test it much yet. I will now incorporate it properly (creating commands for all functions) and test as much as I can. If there are no problems, I think we must get this into CVS right now, before the release. Rationale: 1) it's a killer feature, 2) it's orthogonal to everything else, so even if something is broken in the new functions, this will not affect the rest of Inkscape. Everyone is welcome to download and test the patch too (or at least review the code). Big thanks to the author! _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2fjo…

3 3

status bar discussion
by bulia byak 11 Dec '03

11 Dec '03

Please review and contribute: http://inkscape.org/cgi-bin/wiki.pl?StatusBar _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

1 0

RE: [Inkscape-devel] New guide prototype
by bulia byak 11 Dec '03

11 Dec '03

>G'Day! >Peter and I have been working on a new grids and guides idea which extends >the control handle idea of Dia and Visio 'correctly' (We can justify this >claim quite strongly). There is a test bed version of it at: Thanks, I really enjoyed it! The ability to move a guide so that all objects aligned to it would move too was something I always dreamed of. But I'm not sure I fully understand the difference between the two tools. Is it correct that the first tool behaves exactly as the current selector, i.e. scales and moves regardless of snaps (but keeps the snaps where breaking them is not required for moving), while the second one attempts to scale or move preserving snaps if possible? Note that currently in selector, the edge of the object is not the same as the resize handle, as the handle is always at some distance from the edge. When you implement the "snap marks" you will need to attach them to the object's bounding box, not the handles. And the center of an object can now be moved to any point, so snapping the center onto something must take into account (this is particularly important with text objets, where I often need to align e.g. the baseline of a letter, which is neither the center nor the edge). _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2fjo…

1 0

Re: [Inkscape-devel] color selector changes
by bulia byak 11 Dec '03

11 Dec '03

>>- The GTK+ selector is shakey: when you move the small circle inside the >>triangle, the triangle shakes and jitters. I think this is because the >>color itself produces HSV, but its position is determined by the RGB, and >>the conversion/rounding errors when the color goes to RGB and back make it >>unsteady. Can you ensure that the color wheen is connected to the HSV >>value? Also, when you move the circle to the black or white corners, the >>triangle snaps to the red, i.e. loses its current hue value. I think this >>will also be fixed if you make it reflect the HSV value, not RGB. >> > >Guess what? Don't bug me about this one. ;-) > >Actually... it is just the standard GTK+ color selector. My code only >creates one and then listens for changes. All those details are handled by >the GTK+ version you're running. > >Although it could be a bit of feed-back loop. I'll check to make sure >that's minimized. Yes, that seems to be a feedback problem. I commented out the last gtk_signal_emit (GTK_OBJECT (csel), cs_signals[CHANGED]); in sp_color_gtkselector_gtk_changed(), and jittering is gone, although the object color is not updated. So you just need to make sure this signal you emit is caught by the right listeners (i.e. the canvas objects) and not the color widget itself. Maybe encosing the emit into a pair of block/unblock functions might help. >Actually "color palettes" were something I was going to add. For the GTK+ >wheel, I just need to feed an array of colors for the palettes. Of course we need a separate color palette widget, ideally dockable to the document window, but for now a small palette inside the picker would be nice too. >So we might need "color palettes", "color schemes" and "swatches". I think >details of this would be best hashed out on jabber and on the Wiki. Yes, and a current color widget too (see wiki). >True... but it's built into the GTK+ widget. It does not have alpha (the >one difference). Of course, a simple work-around is to just hide the bottom >entry area when the color picker has one. Would that work better or be >distracting? I don't like that option too. Would be ideal to find a way to tweak the standard GTK widget. >I've split the second notion off into the notebook with tabs. Thus the >"Mode" switch should change to only determine the colorspace to use. I was >planing on "RGB", "CMYK" and "Any", with "Any" being the default. Later we >might also add "Spot". Then it must be named more descriptively, e.g. "Store color as:", but then "Any" sounds kind of funny. >But... I was just thinking the other day that another approach might help. >If we did named "color picker sets" then the user could change the set >named "full" and the set named "brief". They could also create new sets and >use them per location, or just stay with the default sets. I was thinking >that this has the benefit of being simple for beginning/normal users, yet >allow full customization for power users. And the coding would not be too >different than for a two-state enum'ed or boolean'ed set. Maybe, although I don't feel a need for this. Maybe just me. I think the GTK color wheel can be the default picker most people use, and the others are just "for completeness" and for special purposes. The wheel makes it possible to enter RGB values anyway, and it's not that you'll want to move RGB sliders very often, because HSV is much more natural to an artist. >In either case, hooking the color selections up to the new overall >preferences setting dialog would be handy. Yes, that's where it belongs IMHO, without cluttering the actual picker interface. Please add that to the PreferencesDialog wiki page. _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

1 0

Re: inkscape helping
by Jonathan Phillips 11 Dec '03

11 Dec '03

Although I'm new to the project and everything (congrats to ourselves on the new release), it is important for me to tell everyone I'm involved with about some personal things. My sister, Charis Gohil, passed away today at 3 AM CST. It was an amazing peaceful moment here as it was the first snow, and we (family and my sister) had our last words before the end of her time on earth. I started a journal about my sister, but it is not really that relevant anymore, but has pictures of her and myself. http://protofunk.org/?page=bio/charis/index I loved my sister very much and am happy that she is in a better place :) jon On Wed, 2003-12-10 at 21:46, Bryce Harrington wrote: > On Wed, 10 Dec 2003, Jonathan Phillips wrote: > > > stuff... > > > > Bryce, I'd be on top of all these changes but my sister's state has > > worsened in the last two days. She is probably going to pass away in the > > next day or two. I will get back as soon as possible. Sorry I can't help > > get this release out the gate. I'll be on board and running at 200% > > soon. I'm going to be offline here for a bit. > > > > This is not all doom and gloom here, it is actually been one of the best > > times with my sister ever...fyi... > > Thanks for the note; don't worry about Inkscape, family comes first. > We've got things well in hand. > > Btw, what's your sister's name? > > Bryce -- Jonathan Phillips <jon@...15...>

2 1

RE: [Inkscape-devel] color selector changes
by bulia byak 11 Dec '03

11 Dec '03

>Well... I just checked in some changes for the color selector. It needs a >little more polish (mode, CMYK types, and the popup to select subsets of >possible pickers) but should be ready for some initial testing and use. Thanks! My initial impressions: - Do the slider strips have to be so wide (i.e. tall)? I'd like to see them take less vertical space. - Before, the slider strips expanded horizontally when you resized the fill&stroke dialog. This was nice as it allowed to get a better resolution at the expense of screen space. Now they stay the same length no matter how you resize the window. - RGB, CMYK, and HSV are all familiar abbreviations to a designer. But "GTK+" is confusing. Is this a new color model? Better call it by what it shows, e.g. "Wheel". - The sliders are always black and therefore are invisible on dark areas of the strip (this was the problem with the old picker too). They need to be made either e.g. black interior with white outline, or some pseudo 3D, or (as in Gimp) pairs of black triangle at top and white at bottom, or automatically inverting when going from light to dark and back (as is the pointer on the GTK+ wheel). - The GTK+ selector is shakey: when you move the small circle inside the triangle, the triangle shakes and jitters. I think this is because the color itself produces HSV, but its position is determined by the RGB, and the conversion/rounding errors when the color goes to RGB and back make it unsteady. Can you ensure that the color wheen is connected to the HSV value? Also, when you move the circle to the black or white corners, the triangle snaps to the red, i.e. loses its current hue value. I think this will also be fixed if you make it reflect the HSV value, not RGB. - BTW when you resize the window, it's the color wheen in the GTK+ tab that must be made larger so you can pick colors with better precision. - When the fill&stroke dialog has focus, the GTK+ triangle has some ugly non-antialiased one-pixel black border. Without focus, it looks OK, no border. - In Gimp, a similar GTK+ color wheel also has a small palette where you can remember colors (in the bottom right area). Can we have it, too? - "Color name" should really be "Hex" or something like that. Besides, it's redundant as we have the RGBA field below. - The "previously selected color" in the GTK selector is always black. It must reflect the color we got from the program or from preferences; i.e. for "apply to selected objects", when I select a new object, both halves of the color swatch must show the same color, and then the left side should stay the same while the right one is changing. - The "Mode" switch at the top seems redundant (and incomplete), now that we have the multi-tab interface for different pickers. - The bottom right button that allows you to select which pickers are shown is also redundant, IMHO. Instead, the color selector must remember (both within and across sessions) the last picker used and show it when activated. With this, removing pickers is not necessary and frees no extra space. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1

New guide prototype
by Nathan Hurst 11 Dec '03

11 Dec '03

G'Day! Peter and I have been working on a new grids and guides idea which extends the control handle idea of Dia and Visio 'correctly' (We can justify this claim quite strongly). There is a test bed version of it at: http://bowman.csse.monash.edu.au/~pmoulder/guides-LATEST.tar.gz To run it you will need python-gtk2 and python-numeric (also called numpy). Please run it and tell us if the behaviour feels right - it is easier to try variations whilst the code is python, rather than C++ (although it is easier to know whether the behaviour feels right once we implement it in inkscape proper) Feel free to ask questions about our intentions, and suggest extensions that would be helpful. Clearly the prototype is but a taste of what can be done with this new approach (We have several whiteboards worth of ideas to implement :), but it is important to work out the basic interface now. In particular, what do people think about the two tools behaviour? Should this be folded into a modifier key on the selection tool? Can it be done well with only one tool? Is the breaking of constraint behaviour (which control point disconnects when you move something) reasonable, or can you suggest a better heuristic? (Currently the rule that is broken is chosen arbitrarily, perhaps it would be better to break the oldest created relationship, or perhaps the least recently moved?) What do people think of the indicators for how control points are connected to guide lines and guide points? Suggestions? In case you're wondering, our intent is to provide Dia level diagraming support, as well as strong CAD type design elements. Some things which we know how to do, but haven't added include: adjustable spacers, enforced alignment and distribution, clipart with programable control handles (like visio), and many other goodies :) Thanks, njh

2 3

Inkscape 0.36 - "See, even a 5 year old can use it."
by Ted Gould 11 Dec '03

11 Dec '03

Inkscape Release 0.36 "See, even a 5 year old can use it." This is the second release of Inkscape and there has been a tremendous amount of work that has been done on the project. Many patches and ideas that had been 'waiting in the wings' have now been applied to the codebase. Now Inkscape is easier to use for users as the interface is less complex and more intuitive. In Brief: * Main GUI has been significantly redesigned * Usability of dialogs, keyboard shortcuts, and mouse is improved * Preliminary support for layer grouping, path markers, and extension modules * Much more user and developer documentation - doxygen, docbook, man page, wiki, diagrams, & more * Many bugfixes, minor enhancements, and usability tweaks What is Inkscape? The Inkscape application is an open source SVG editor with capabilities similar to Illustrator, CorelDraw, Visio, etc. Supported SVG features include basic shapes, paths, text, alpha blending, transforms, gradients, node editing, svg-to-png export, grouping, and more. Enhancements * CSDI interface has been traded for an SDI one: Now each document window has its own menubar at the top and its own detachable toolbar at left. This increases Inkscape's compliance with the GNOME HIG and decreases confusion for the majority of users. * A secondary (horizontal) detachable toolbar is introduced for operations and controls specific to each tool. At the moment this toolbar is mostly empty but we have big plans on how to fill it with all kinds of useful things for convenient access. * Dialogs now always stay on top of the document window (even if you have several document windows open). They are easy to open or activate (using shortcuts displayed in their title bars), close (Ctrl+w), or defocus (Esc). Moreover, dialogs remember their size and position across sessions. * New commands: Paste style (apply the style of the copied object to the current selection), Fit page width to window. * Introductory layers support. There is now code in the code base to start handling layers. GUI elements to follow - watch this slot! * Arrowhead and marker support. A much requested feature which increases the usability of Inkscape for everyday tasks. * Using mouse is now less painful thanks to the increased mouse tolerance (you don't have to be exactly over an object to grab it) and introduced drag tolerance (very small drags, which are usually accidental, are now considered clicks and do not move anything). * Undo is now unlimited (that is, limited only by available memory). * Lots of new keyboard shortcuts. Notably, Esc now consistently deselects, cancels selection, and cancels drag or transformation of any kind (so far only in selector and node edit). Arrows, Ctrl+a, and Tab/Shift?+Tab act on nodes in node editor exactly as they do on objects in Selector. There are at least two ways to activate each tool, one with an F<number> key (Corel Draw style) and another with a single letter (Adobe Illustrator style). Space toggles between Selector and your current tool. Dialogs are consistently activated by Ctrl-Shift-<letter> combinations. * There's no lower limit on the size of exported PNGs anymore. You can use Inkscape to create even 1x1 PNG images. * The standard xml:space attribute on text objects is now honored. For newly created objects it has the value of "preserve" which means all whitespace characters are shown exactly as typed. * Enhanced modules system. Now modules can be defined using external files so no C coding is required for an extension. * Mac OS X and Windows build fixes. These builds are getting more mature and working better. * Increased code documentation. Come check it out, the Inkscape codebase is getting more readable every day. * Numerous bugfixes and usability improvements. Infrastructure * The web presence of Inkscape is dramatically different than with the last release. If you haven't already, you should check it out at: http://www.inkscape.org. * Many people have been contributing to the Wiki, which has a sizable amount of content today: http://www.inkscape.org/cgi-bin/wiki.pl. * Doxygen documentation builds are now happening on HEAD nightly: http://www.inkscape.org/doc/doxygen/html. * CVS snapshots are taken on a nightly basis: http://www.inkscape.org/cvs-snap/. What lies ahead * More useful stuff in the secondary toolbar - all kinds of controls that are relevant to a specific tool will be put into that toolbar for convenient access. * A new, extensive Preferences dialog. Lots of settings that are now hard-coded will be settable. * Dialogs reorganization: less dialogs overall, with their functions more logically grouped. * More precision, maximum zoom of 256x or more. * Complete keyboard control for node editing, including editing control handles of a node. * GUI selection of arrowheads for path start/end/mid markers. Known problems * At least on KDE, floating dialogs may not stay on top when you switch between maximized document windows. You may need to click on the window's title bar to bring the dialogs to top. (See src/dialogs/dialog.events for a possible workaround and comments, feel free to suggest a patch.) * Also on KDE, detached toolbars do not stay on top. (This is a KDE problem.) * On Windows, dialogs do not stay on top of document in this version. * Some keyboard shortcuts (e.g. arrow keys for nudge) do not work if your mouse pointer is not over the document window. * When using Copy/Paste? (or Paste style) commands, you cannot copy gradients or arrowheads from one document to another. Workaround: use the XML editor to copy the content of the <defs> element from the source document to the target document, then copying gradients and arrowheads will work. * Pasting text directly into a text object on the canvas does not work. Workaround: open the Text dialog (Ctrl+Shift+t) and paste into the text editing area there, then click Apply. * 'warning: failed to load external entity "glade/icons.svg" - This is not a fatal problem, but merely an indication that Inkscape could not locate its icon images. This problem can also be detected when some of the button icons show up as random noise. The usual fix is to go through the 'make install' process so that the icons.svg file gets copied to the expected location. * 'colinear!' - This is a libart warning. The original libart intersector has all kinds of numerical problems, and it is believed that this warning is emitted if it tries to find intersection of two almost parallel lines. Robert Crosbie recently noticed this still occurs when using the Calligraphic tool. More information at: http://www.inkscape.org/

1 0

New Jabber server
by Bryce Harrington 11 Dec '03

11 Dec '03

Hi all, dmandell has graciously set up a permanent Jabber room for Inkscape on his server, and I'd like to propose we transition to that instead of the one on jabber.org. The reasons for this are: * Fewer users on it so probably not so laggy * We've got the ear of the admin (useful in case of problems) * Forewarning in case of server software changes * Fewer random visitors We're going to test it a bit this evening, and assuming things go well, and no one identifies any issues with transitioning, we will update the website docs to point there instead of jabber.org. Bryce

1 0

color selector changes
by Jon A. Cruz 11 Dec '03

11 Dec '03

Well... I just checked in some changes for the color selector. It needs a little more polish (mode, CMYK types, and the popup to select subsets of possible pickers) but should be ready for some initial testing and use. As part of it, I was simplifying the pickers to juse use SPColor objects instead of all the overloaded different component primitive types. This might be a good thing to continue... as it could facilitate moving to better color, custom spot color, etc. Oh, and the 'API' (as it were) for creating new pickers will probably undergo a little revision. At the moment the gtkcolorselector might be an interesting place to start.

2 1