- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] handling statusbar messages
by bulia byak 13 Dec '03

13 Dec '03

>The way the class hierarchy works is: > > SPView - base class for all views of an SPDocument > ^ > SPSVGView - rendered graphical view > ^ > SPDesktop - editable rendered graphical view > >SPViews are the 'model' side of the MVC equation, with various widgets >(SPDesktopWidget is the one normally used with SPDesktops) acting as >view/controllers. It's actually the SPDesktopWidget, not the SPView >(SPDesktop) which is subscribing to the status message signal. I still don't see why SPView is involved in statusbar handling... but anyway, if you say this is right, let it be. What ails me is that I want to provide a richer and more convenient interface for statusbar messages. For example, I want a function for temporary displays that are pushed and then popped after some timeout. This means the statusbar signal must be split in two, or at least given extra arguments. Is this the right approach? >Btw, I do not want us to introduce more global state as far as "finding >the current desktop automatically" -- eventually I want all signal >handlers and SPActions bound to specific views, so they "know" their >associated view rather than having to look at a global variable to know >which is 'current'. Right, but what is to be done now? As I wrote, now all calls to sp_view_set_status start from the desktop and figure out its view. If this is wrong, what is right? Starting from some object on the canvas that logically "issues" the message, ascending to its SPView, and then sending a message from SPView to the associated desktop widget? That seems overly complicated to me, but I'm OK with it if its implemented and if I'm given a convenient interface to it. In other words, what is the minimum of arguments that a statusbar-setting function (callable from anywhere) must have? Now it accepts a message and an SPView, but I don't like having to figure out the SPView every time I call it. Can there be a function that accepts only the message and if yes, how to program it properly? _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1

black magic
by bulia byak 13 Dec '03

13 Dec '03

I found a bug that is likely triggered by the new NR high resolution. It's here: https://sourceforge.net/tracker/index.php?func=detail&aid=859364&group_id=9… Could anyone please confirm that bug with the latest CVS? I'm asking because the fix that I found for this bug is really very weird. I don't understand how it can fix anything. Pure black magic. Namely, add an empty g_print("") to line 204 of libnrtype/nr-rasterfont.c: NRRectF * nr_rasterfont_generic_glyph_area_get (NRRasterFont *rf, unsigned int glyph, NRRectF *area) { NRRFGlyphSlot *slot; glyph = CLAMP (glyph, 0, rf->nglyphs); g_print(""); slot = nr_rasterfont_ensure_glyph_slot (rf, glyph, NR_RASTERFONT_BBOX_FLAG | NR_RASTERFONT_GMAP_FLAG); On my computer, this fixes the crash. I would really appreciate if anyone can confirm both the bug and the "fix", and especially give any insight on how this fix could affect anything (and maybe even on how to fix this properly). I spent several hours trying to debug this but this g_print was the best I could find :) _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

doc?
by bulia byak 13 Dec '03

13 Dec '03

The 0.36 source tarball contains no /doc. What's up? _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

3 4

Re: [Inkscape-devel] printf
by bulia byak 13 Dec '03

13 Dec '03

> > > If not for this problem, does printf satisfy our requirements or are >there > > > any other problems with it? If it's OK, maybe we could just include >the > > > "standard" printf right into our codebase, instead of linking to a >library? > > > Just an idea. > > > > Possibly, but if we do one ourselves we can be more clever with e.g. > > rounding behavior. Anyway, Bryce said he alraedy had some code > > somewhere, as I recall... > > > >Yes, I do. I've added a task for myself to add this to the codebase. The reason I ask this questions is because I see how Lauris is handling this in 0.33. Now instead of a single printf call, he declares a char[] buffer for each value, calls a custom conversion function, and then assembles these buffers into a string. That is extremely bulky and hard to read, and I would like to avoid this if possible, preserving the format string approach of printf. So, how close is your code to being a drop-in replacement for printf with its format strings? _________________________________________________________________ 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…

3 2

printf
by bulia byak 13 Dec '03

13 Dec '03

>*printf() exhibits locale-dependent behavior on win32; we >need to replace it with our own code for generating correct >SVG measurements regardless of locale. If not for this problem, does printf satisfy our requirements or are there any other problems with it? If it's OK, maybe we could just include the "standard" printf right into our codebase, instead of linking to a library? Just an idea. _________________________________________________________________ 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…

3 2

handling statusbar messages
by bulia byak 13 Dec '03

13 Dec '03

Currently, whoever needs to update statusbar calls sp_view_set_status() giving it the message and a pointer to a SPView object. This function emits a signal from that SPView object, and this signal is caught by the desktop object which does actual update to the statusbar (using gtk_statusbar_push()). This seems strange. Why is SPView involved at all? In ALL cases when sp_view_set_status() is called, the caller code has (or finds out) the current desktop and then finds its SPView by saying SP_VIEW(desktop), only to pass this to the sp_view_set_status(). Given that the message ends up being handled by the desktop anyway, the entire mess with SPView and emitting/catching signals seems unnecessary to me. The code needing to update statusbar could call a function in desktop.c directly, either giving it some desktop pointer, or even letting it find out the current desktop automatically. The signal and the statusbar-setting functions in view.c could then be eliminated. I think the code would be simpler and more logical this way. Any comments? _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1

zoom and precision
by bulia byak 12 Dec '03

12 Dec '03

I've augmented my libnr precision and 256x zoom patch with a fix to store SVG paths with 8 digits instead of 6 (changing %g to %.8g in printfs in svg/svg-path.c). Since I've been using this patch for some time and have not seen any problems, so I decided to commit it now. This is code that is in use literally every second, so by putting it in early in the release cycle we'll be able to catch more bugs with it. Please work and play at higher resolutions than you usually do and submit any bugs to the tracker. Note that you'll need to rerun configure after updating because I patched libnr/gen_nr_config.c which is recompiled and rerun on configure (I think). _________________________________________________________________ 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…

1 0

Open Source myths
by Jon A.Cruz 12 Dec '03

12 Dec '03

Here's a nice little article on software development http://www.onlamp.com/pub/a/onlamp/2003/12/11/myths.html Of all the issues raised, the ones I've thought about I'm in agreement with. The few I hadn't consciously considered before seem to be right on track also. In all, it seems that these are things that those in the Inkscape community are doing, however it's always good to explicitly state what's good and why. Among other things it might help us improve and also just keep us on track. (so at the very least, read the article and keep things in mind)

1 0

C++-ification
by Bryce Harrington 12 Dec '03

12 Dec '03

Just a quick head's up, we're about to proceed with the renaming of all .c files to .cpp. Nathan is working on updating Makefiles &tc. presently and if it works out, he'll be committing the changes soon. The expected near-term effects to be aware of: * Change histories on code files will be reset * Potential build issues on some platforms * Everyone will need to cvs update -Pd, make distclean, and rebuild * Compilation with gcc will cease to work as support for gcc is ended * If you are working on a branch or out of sync with CVS HEAD, your next merge may be more complicated than usual due to the file rename These issues should be transitory, but please expect some turbulence for a bit. Thanks, Bryce

2 2

Re: [Sodipodi-list] Re: 0.8 multiplier
by MenTaLguY 12 Dec '03

12 Dec '03

On Thu, 2003-12-11 at 13:06, Lauris Kaplinski wrote: > SVG spec is resolution agnostic. Yes, but I finally read this part of the SVG spec... > All its units are just > defined as certain ratios of undefined base unit (pixel), that > may or may not be related to some real-world unit. For the initial coordinate system, the SVG specification refers to CSS2's definition of length units, which broadly specifies two classes of units: 1. relative units which do NOT have fixed relationships with real-world units * em and ex: determined by the current font size * px: determined by the user agent, generally some multiple of device pixels 2. absolute units which _are real-world units_ (subject to the user-agent's ability and desire to match them) * mm: real-world mm * cm: 10 mm * in: 2.54 cm * pt: 1/72 in * pc: 12 pt > Sodipodi document has real-world dimensions. > To map resolution agnostic SVG onto real-world paper, it uses > mapping: > 1 SVG point == 1 typographic point (To be totally pedantic, typographic points are 0.0138 in, which is not _quite_ the same as Postscript/SVG points [1/72 = 0.01388888...]; I think everyone uses the Postscript definition nowadays though.) > As 1SVG point == 1.25 SVG pixels, and pixels are SVG base units, > SVG base unit == 0.8 typographic points on all sodipodi documents. Unless a viewBox is set, the relationship between user-space base units (pixels) and the absolute units is totally user-agent dependent. (this is why all examples in the SVG spec specify a viewBox) Thinking about this, if Sodipodi intends to be completely interoperable, it needs to always write a default viewBox according to the base units/points mapping it imposes. e.g. for a document 100ptx100pt, the viewBox should be "0 0 125 125". -mental

1 0

menu reorg
by bulia byak 12 Dec '03

12 Dec '03

I propose to break Edit menu into two, Edit and Object. Otherwise it's pretty long already, and will be still longer when we add boolean ops. I think everyrhing up to and including Clear All/Select All should remain in Edit, and the remainder of items should go to Object. If there are no objections, I will commit (it's a cosmetic patch so it's unlikely to break anything). _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoi…

2 1

0.37 plan
by Bryce Harrington 12 Dec '03

12 Dec '03

It's very cool to have 0.36 out the door after so much work! It's being well received by the community, and the feedback is that we've definitely made notable improvement over the baseline. So what's next? First, as we talked about, we're going to keep things low key the rest of the month, and enjoy the holidays. This next release is going to be a bit different than this past one. For 0.36 our goal was to strive to get some new features in and revamp the look and feel, to prove that this project brings new value to the community and to gain experience working as a project. For the 0.37 release our focus is going to change. We want to make the codebase itself better, so that it is easier and more enjoyable for us to work on in the future. Doing this will require undertaking several sizeable endeavors: * Convert the codebase to C++ * Change from function prefixing to true C++ namespaces * Adopt a new code style * Remove all obsolete code * Organize all of our documentation The above work will touch pretty much all the files in the codebase, and since that could be a significant amount of work, I think we should use a divide-and-conquer approach to it. A way to achieve this is to divide the codebase into several distinct "subsystems"; this way the size of the commitment each of us must make will be tractible, and so that we can work together as a team to achieve them. I'll establish a list of these subsystems shortly; there is a diagram on the Documentation page of the website to give some hints as to what this list will be. In addition, there are several features we'd like to pursue, such as reorganizing the dialogs, Fred's new booleans work, and Nathan's grid code. There are also a number of bugs we decided to leave to this release, that should receive attention. We can look forward to seeing these features and bug fixes folded in, as we proceed with the principle objective of the code conversion and cleanup. Bryce

1 0

Plugins - first cut at requirements list
by Bryce Harrington 12 Dec '03

12 Dec '03

I've posted my first stab at a list of requirements for a plugin/extension/module system here: http://www.inkscape.org/cgi-bin/wiki.pl?PlugIns Ted's done a good bit of work on implementing support for a module system, so hopefully this list can be made to mesh with that work. The intent of making a requirements list is to firmly identify what we want out of this system, so that as folks work on implementing it, it is clear what it needs to do. Please look it over and add your thoughts of what should be in there. Bryce

1 0

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

0.36 release candidate tagged in CVS
by Bryce Harrington 11 Dec '03

11 Dec '03

The one priority-9 bug that was identified in testing was fixed by Bulia, thus closing the last task required for the Inkscape 0.36 release. It builds with both gcc and g++. Folks are itching to get into dev mode for 0.37. We're ready to cut the release. RELEASE_0_36_0 is now tagged in CVS. Unless we discover any major issues during packaging, this should be considered the official release source. If there are issues that require fixing for this release, we can create a branch from this tag point to work on them, and allow the main branch to return to development. This tagged version can be checked out via the command: cvs co -r RELEASE_0_36_0 -d inkscape_0_36_0 inkscape Ted, can you finalize and post the official tarball at your earliest convenience? Nathan and Mael, once this tarball is available, please proceed with creating the Debian and Windows binary packages, and I'll do the same for RPM. Once all of these packages have been created, then we will put out an announce to Freshmeat, et al. Hopefully we can achieve this within a day or two. Meanwhile, everyone should consider CVS HEAD to be unfrozen and available for open development once again. Thanks, Bryce

3 4

last changes pleease
by bulia byak 11 Dec '03

11 Dec '03

Hoping it's not too late, could you guys please take the latest CVS for the release? Just a couple last-minute cosmetic changes: h and v shortcuts for flipping, and the Edit menu is split into Edit and Object. This is important for making a good first impression, as the old Edit menu was way too big. _________________________________________________________________ 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