- Inkscape Devel - Inkscape Mailman

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