June 2004 - Inkscape Devel - Inkscape Mailman

pattern news
by bulia byak 09 Jun '04

09 Jun '04

- Now there's a Tile command (Alt+T) that creates a rect with pattern fill out of the selection. Lots of fun. - The Fill&Stroke dialog lets you select any of the patterns defined in the document for any object (done by Sim). - I changed the default back to import bitmaps as <image>s. Those who prefer it to be bitmaps however can change the setting in Preferences (Misc tab). Also you can select any <image> and Tile it for the same result. - Preferences>Transforms tab: there's now a setting to transform or not transform the pattern fill with the object. When it's off, you transform objects but their pattern stays unmoved; when on, they're transformed as a whole. Works the same in both Optimize and Preserve modes. Still todo: - The "transform pattern" switch will be moved to the selector top panel, alongside the "scale stroke" and "scale rounded corners in rects" switches. Also the same switch needs to be created for gradients. - An Untile command to convert a pattern fill to the original container object plus the object(s) that were in the pattern. - The pattern fills will get knots on the canvas that will let you arbitrarily transform patterns inside objects by dragging the knots (Sim is working on that). _________________________________________________________________ MSN Premium with Virus Guard and Firewall* from McAfee� Security : 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

change to Make for ecma
by Bob Jamison 08 Jun '04

08 Jun '04

I worked libjs.a and /ecma into the Mingw build files. It all builds/links with the new stuff. I will look into adding them to the Unix files later, when I am back from the office. I will try to get on jabber://inkscape@...132... later. Bob

1 0

RE: [Inkscape-devel] L10n questions
by bulia byak 08 Jun '04

08 Jun '04

>>#: src/verbs.cpp:962 >>"Ru_lers" >> >>#: src/verbs.cpp:962 >>"Show or hide rulers" >> >>#: src/verbs.cpp:963 >>"Show or hide scrollbars" > >Not used now, replaced by texts in interface.cpp. But it would be better to >rework sp_ui_menu_append_check_item_from_verb so that when verb is >non-null, it takes the label and tooltip from it as well (now it only takes >shortcut). And I just did this. _________________________________________________________________ Add photos to your e-mail with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

5 5

Revisiting ECMA. Seriously, folks. :)
by Bob Jamison 07 Jun '04

07 Jun '04

By the way, I am finally starting again to work on the ECMAScript/SVG binding (not Inkscape scripting). I checked in a cleaned-up directory of Mozilla's Javascript C engine. It is in /src/extension/script/js so that it can be convenient to both the SVG binding and IS scripting guys. I also started checking in a few files in /src/ecma for testing. Hopefully in a few days we can start seeing some progress. Bryce shamed me out of my lethargy with his article. ;-) Off topic: You might be interested in this mail list thread from another OS project (probably -the- OS project), gcc: http://gcc.gnu.org/ml/gcc/2004-06/msg00014.html This shows the kind of interaction among the members of a very large project. Some of the threads in that list can be fascinating. Bob

3 5

Re: [Inkscape-devel] Re: Inkscape Layers
by Bob Jamison 07 Jun '04

07 Jun '04

Yes, the intent -is- to provide layers just like in other applications. When we talk about using <g> nodes to group them, what we are talking about is merely how to store layer information in the SVG format. Thorsten Wilms wrote: >I didn't catch the whole discussion about layers, I just hope I'm not >totaly off here. >However, layers can be seen as serialized selections and are in this aspect >just like groups. But in vector graphics apps layers usualy establish >z-order 'compartments'. There is z order inside each layer, but the general >z-order of each member of a layer is higher than those of members of layers >below and lower than those of members of layers above. > >Grouping is used to lock relative position of items and for scaling them >all together. Layers are about organizing z-order, toggling visibility >and locking. Visibilty and locking can of course work the same way for >groups, it's just they are usualy not listed in vector apps. > >It would be interesting to implement/express layers as special case of >groups, but I have no idea how to go about toggable z-order compartment >behaviour. > > >--- >Thorsten Wilms > > >------------------------------------------------------- >This SF.Net email is sponsored by the new InstallShield X. >>From Windows to Linux, servers to mobile, InstallShield X is the one >installation-authoring solution that does it all. Learn more and >evaluate today! http://www.installshield.com/Dev2Dev/0504 >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > >

1 0

Article followup
by Bryce Harrington 07 Jun '04

07 Jun '04

Hi all, I wanted to follow up with a few comments on the reception of the article. I was mortified when I saw that the Slashdot blurb said Inkscape was my "brainchild" and that I was _the_ founder of Inkscape rather than _a_ founder. I hope no-one took offense at that. I suppose its unusual for open source projects to be true team efforts, but that is really one of Inkscape's strengths and one of the things that makes it so fun. I also want to apologize to Bob for cratering his server! Hope that didn't cause problems beyond just the loss of the machine. Hopefully with Artemio's help, that problem will be stimulating us to gain a better solution in general for the future. Despite the problems, I think it went quite well. The main goal had been to raise awareness of Inkscape and what we got exceeded what I'd been hoping for. Also, I noticed that a number of the points I wanted to make were conveyed and received by the audience. A couple of the points sparked some interesting discussions; I think our "patch first, ask questions later" policy got people thinking. Big thank-you to mental or whomever suggested emphasizing we don't _blindly_ accept patches, but do check licenses, etc. I again want to thank everyone that helped with editing the article and rejon for giving me a deadline to get it done by; as much as I grumble about deadlines, it was useful motivation. Nathan - it turned out we missed one of the erroneous "it's", as several readers pointed out to me. :-) I'd also like to return the favor. I think with this general "What's Inkscape" piece out of the way, there is an audience for more focused articles, and if anyone is interested in writing one I would be more than happy to lend a hand. For example, I'd bet an article giving advice about usability would be well received. An article about Inkscape internals as they relate to SVG rendering would as well. I also think a usage-oriented "secrets of Inkscape" article would be appropriate. So if anyone is interested in authoring an article on any of those subjects, I would be happy to help in any capacity. Bryce

4 4

orphan collection
by MenTaLguY 07 Jun '04

07 Jun '04

Just a quick heads-up: I've comitted my orphan collection code to CVS. Among other things, this means that leftover gradients/markers/patterns will get automatically cleaned up when the objects that use them are deleted. Caveats: * this only applies to such objects created with a build of Inkscape which post-dates this commit * not all automatically-created objects will necessarily be collected; the code that creates them needs to be updated to set the correct collection policy * paint objects won't get collected until another editing operation takes place, since NRArenaShape currently holds onto an SPStyle for too long Technical details: Assuming its collection policy permits it, an object will be collected if neither it nor its descendants have any outstanding inter-document URI references (nonzero SPObject::hrefcount). There are two "policies" for collecting orphans: * "with-parent" - the object will only be collected if one of its ancestors is collected * "always" - the object is always collected if unused (a third policy might be "never", which would necessarily also prevent that object's ancestors from ever being collected; I do not plan on implementing it) The policy in effect is determined by the inkscape:collect attribute. Be careful with the "always" policy; it really only makes sense for "private" objects that are indirectly created behind the scenes (e.g. by selecting a fill or marker option in the GUI). -mental

1 0

Proposal for scoping the Pango work for 0.39
by Bryce Harrington 07 Jun '04

07 Jun '04

We've been discussing what needs to be done for the Pangoification work that we identified as required for 0.39, and what scope of work we should pursue for this release. One of the key factors driving the consideration is that we've got a lot of (cool but non-Pango) things implemented in the codebase right now that we'd like to get released to users soon. Unfortunately, the quantity of work to do the full conversion over to Pango 100% is daunting, especially considering the wide number of platform bugs we're certain will crop up. Thus, we are floating this idea for how to scope the Pango work for this release: 0. Document all of the routines in libnrtype 1. Create a copy of libnrtype in the codebase called libnrtype_pango 2. Go through all of the nr-*.cpp routines in libnrtype_pango and rewrite them to use Pango calls. This is the bulk of the work, but I figure this could be done by a couple developers in a week or so. 3. Cleanup and remove whatever files and code become obsolete from libnrtype_pango in the process. 4. Create a compile-time option --with-libnrtype-pango that controls whether inkscape is built with the existing type renderer, or our new Pango-based one. 5. Get Inkscape able to compile and run with the new libnrtype_pango code; if it misses a lot of existing features or has a lot of new quirks, that's perfectly fine - we'll fix them later. 6. Finish up all the non-Pango development work and finalize the release. 7. Generate two sets of packages for Windows, Linux, and Mac: One compiled with libnrtype_pango for testing, the other compiled with the existing type renderer for regular usage. We then will adjust the Roadmap by moving the 0.40 milestone and all subsequent ones forward one release and introducing a new 0.40 milestone that focuses on the second phase of the Pango conversion. The advantage of this change to the Roadmap is that it buys us additional development and testing time for Pango but still gets the current work out and available for users to start taking advantage of and testing out. Another advantage is that it will enable us (including users) to test out the feasibility of switching to Pango without having to take the full plunge all at once. Previously, we had not scoped out precisely what would be done for this release for Pango, so had assumed we'd try to get 100% finished with it; this may be doable but appears to be unrealistic to achieve within an acceptable amount of time. Please let us know if this plan sounds suitable, or if not, what adjustments to it that you would suggest. Thanks, Bryce

3 3

Fill and Stroke Dialog
by Michael Wheeler 07 Jun '04

07 Jun '04

Hi Everyone, I was playing around with the June 4th Win32 build and I noticed that the Fill and Stroke dialog is slow to come up. I haven't been using all of the daily builds, so I don't know where the problem started, but the dialog is snappy for me in 0.38. Also, changing the colors in the dialog is less smooth. The other dialogs seem just fine. By the way, the working eyedropper is great. I like that it keeps things real simple. How would people feel if it used a crosshair rather than the white arrow. Maybe this is silly, but I am always feel a little unsure what specific point I am aiming at with the arrow. Thanks, Michael Wheeler http://www.planet-zero.net

6 14

Re: [Inkscape-devel] Re: Inkscape Layers
by MenTaLguY 07 Jun '04

07 Jun '04

On Sun, 2004-06-06 at 05:44, Thorsten Wilms wrote: > However, layers can be seen as serialized selections and are in this aspect > just like groups. But in vector graphics apps layers usualy establish > z-order 'compartments'. There is z order inside each layer, but the general > z-order of each member of a layer is higher than those of members of layers > below and lower than those of members of layers above. In SVG, groups establish "compartments" as well. Because our model is based on SVG, to us layers and groups are essentially the same thing. -mental

1 0