- Inkscape Devel - Inkscape Mailman

layers
by MenTaLguY 10 Jun '04

10 Jun '04

Been thinking a bit about layers today, especially in light of the RFE that Jonathan put in, and Thorsten's comments earlier. I realized that I'm still wayy too stuck in the Illustrator mindset. They've got the right idea. Illustrator layers really are just glorified groups. We can do better, and different. It's helpful to look at other tools, and what layers look like in their generalized form. In many tools, layers are entirely are decoupled from grouping and z-ordering. They basically just let you take slices through "aspects" of the document and work on them in isolation. For 2d apps, think of GIS databases or KiSS dolls. For 3d apps, Blender or Unigraphics. I think that's the direction we should go with layers, too. It gives us some really useful functionality we'd otherwise not have. So, here's the deal, I think: * we keep the document tree dialog we had been planning, but we don't call it "layers" anymore, and don't try to shoehorn Illustrator-style pseudo-layers on top of it (we'll still have some easy facility for drawing/editing "inside" groups though) * inkscape:groupmode goes away (bulia has already rendered it obsolete anyway) * the "layers" dialog is just a list of layers with visibility toggles and buttons to add/remove layers * an object can be in zero or more layers * this is determined by the inkscape:layers attribute, which holds a whitespace-separated list of layer IDs (NMTOKENS) * we'll probably have <inkscape:layer> elements too, somewhere, to hang per-layer attributes (like descriptive names) on, but layers will fundamentally exist just by virtue of being referenced * in absence of this attribute, an object is considered to be in the same layer(s), if any, as its parent (this is the default for new objects) * layer visibility is an Inkscape-specific thing, separate from CSS visibility of individual objects * objects are visible in the editor iff: 1. their CSS visibility is "visible" 2. at least one layer they're in is visible, or they aren't in any layers 3. their parents are visible by these criteria * there should be a {select,unselect}-by-layer feature * there should also be an {add,remove}-selected-objects-to-layer feature I think that should cover all the bases, and shouldn't require much work to implement. Personal life allowing, I'll take a stab at getting this hammered out by next week. (no, I've not forgotten about pangoification ... my contribution to that this week will be getting the C++ification stuff documented, time permitting) -mental -----Forwarded Message----- From: SourceForge.net <noreply@...34...> To: noreply@...34... Subject: [ inkscape-Feature Requests-857357 ] LAYERS: Various ideas combined Date: Mon, 07 Jun 2004 22:17:17 -0700 Feature Requests item #857357, was opened at 2003-12-10 05:47 Message generated for change (Settings changed) made by bryce You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=604309&aid=857357&group_i… Category: None Group: None Status: Open Priority: 9 Submitted By: Jonathan Phillips (kidproto) >Assigned to: MenTaLguY (mental) Summary: LAYERS: Various ideas combined Initial Comment: Something which I really missed in SVG is the ability to work with layers. Layers should allow to show and hide all objects in them and it should be possible to change some attribute in all objects of a layer (for example, the line color). Alternatively, it should be possible to select objects by layer - then this can be done manually. Note that layers are not groups: Objects from different groups can be in the same layer so they move with the other objects in the same group but whether they are visible or not depends on the setting of the layer. Layers can be used to depth-arrange objects (so when I move a layer in front of some other layer, the objects in the different groups must be reordered accordingly). When a group is in a layer, then all objects in that group are in the same layer. I'm not sure if it would be a good idea to allow one object to be in different groups (it's visible when at least one of them is visible). For the implementation: When I did this, I added a x:layer attribute to the elements plus a x:layer-style element to the SVG. Then my XSLT script would select drop all elements of invisible layers and sort the layers according to the depth attribute of the x:layer-style elements. ( NOTE: originally in sodipodi bug tracker as bug(s) # 616232 ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=604309&aid=857357&group_i…

1 0

Help needed setting up good Nightly Snapshot system
by Bryce Harrington 09 Jun '04

09 Jun '04

Hi all, As Bob mentioned, the visit from Slashdot cratered our nightly Win32 snapshot server, and we need some help coming up with a better solution. No Inkscape experience needed, just need to be familiar with SourceForge, scripting, and compiling apps. The snapshots have proven useful in letting users test out and report on recently implemented features without having to compile it themselves. So this is a pretty highly valued service for the community. What we need going forward is a script or set of scripts that: * Checks out from CVS once a day and compiles for Win/Lin/Mac both debug and optimized. (e.g. via SF compile farm?) * If compilation is successful, post the packages to mirrors (e.g. SourceForge). * Allows users a place on the web to go to to get the latest version * Creates and provides autopackage versions (the AP folks are doing this for us currently, so this may not be necessary but is worth considering if it's not hard to do.) * Doesn't place the administrative responsibility on a single specific person * Code is checked into a subdir of inkscape_project/ * Has a README and/or wiki page explaining install & usage If you'd like to work on this or a piece of it, let me know and we can work out the details. Bryce

10 20

Re: your patch
by bulia byak 09 Jun '04

09 Jun '04

>and be more concious of this sort of thing. (comes >from being self taught too, no one ever corrects you >:) ) One more comment: try to modularize more, instead of copy&paste. You may want to check out how I reworked your "copy gradients to gradients clipboard" code in selection-chemistry some time ago. >this was the plan, as i put pattern support in >get_stock when i wrote it. Again could do with a >"table of previews" type widget tho, should look into >if the GIMP or similar has something we can lift. Yes, and I think that widget will resolve the speed problem as well. Namely, it will need to generate previews on the fly when you open it, and show incrementally those that are already generated (the way images are shown as the are downloaded in a browser). This will remove the delay from fill&stroke. 2 remaining problems with patterns in fill&stroke: - it does not apply a pattern to multiple selected objects - I will need to create a function that, for any pattern, returns its visible ancestor, i.e. the first pattern up the chain of hrefs that has any children. Then we need to use this function everywhere you access a pattern, so that (1) auto-generated adjustment (childless) patterns linked to some other patterns are never shown in the menu and cannot be applied (you can only apply "root" patterns) and (2) for any selected object, you see its "root" pattern highlighted in the menu, instead of the real adjustment pattern it is assigned in SVG. This way it'll make much more sense. I will tackle the second problem later today. If you know how to easily fix the first one, that would be great. _________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Different idea for 'running' a file
by Bob Jamison 09 Jun '04

09 Jun '04

Hi all, I had this idea last night at the pub, and I think that it might be a cleaner and easier way to enable scripting interactivity than a "runmode". I'd like to toss this idea to the group and see what you all think. How about this: we consider "running" a file to be something like a "Preview" window. Instead of modifiying the behaviour of the Inkscape editor, we clone the repr tree, make an instance of an Inkview viewer, and display that. If we can just regard Inkscape as being "edit mode", and Inkview as "run mode", it might make for a cleaner separation, and obviate the need for things like if (runmode) { } in Inkscape source. Then, any of us working with interactivity need only hack on the player code, and can leave the editor stuff untouched. How does that sound? Anyone have an opinion? Bob

3 2

your patch
by bulia byak 09 Jun '04

09 Jun '04

I have applied and committed your patch after some cleanup. Comments: - Please get yourself an editor that can do auto indent. Now you seem to indent manually which is a pain both for you and for those who read your code :) - Always generate diffs ignoring whitespace differences (diff -b). That would make your patch much smaller and easier to read. - It's "Pattern fill", not just "Bitmap fill" - No need to set "sodipodi:fill-pattern". You seem to have copied it from "sodipodi:fill-cmyk" but that is entirely different story (and we plan to eliminate it btw). - Be more defensive in coding. You write e.g. pat = SP_PATTERN(g_object_get_data (G_OBJECT(gtk_menu_get_active (GTK_MENU(gtk_option_menu_get_menu (GTK_OPTION_MENU(patmnu))))), "pattern")); Not only is this ugly, but it's very easy to break. Instead, separate it into sequential assignments and do proper checks between them ("Did I get what I think I get?" "Is there an active item?" "Is this really a pattern?" etc). For example now your code will break if I add a separator to the menu (which is an item but has no pattern data). - Eventually it would be the best to treat patterns the same as markers. That is, add previews to the menu, and add a patterns.svg document that would contain some nice predefined patterns for users. That should be easy because we already have all the code in place. However this has to wait until we sort out the speed problem with marker previews first. _________________________________________________________________ MSN Premium: Up to 11 personalized e-mail addresses and 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

WG: [Inkscape-devel] ecma -- my last spam for the day
by Taraben, Adib 09 Jun '04

09 Jun '04

Scipting is great, but this needs some kind of modeswitching in between runmode and editmode. Is it? Adib. ________________________________ Von: inkscape-devel-admin(a)lists.sourceforge.net im Auftrag von Bob Jamison Gesendet: Mo 07.06.2004 21:00 An: inkscape-devel(a)lists.sourceforge.net Betreff: [Inkscape-devel] ecma -- my last spam for the day Ok. I promise that this is my last post to the list today. I am finally caught up from last week, and now I can start adding the real code and not bother this list. I added one file: /src/ecma/script01.svg ...which is the example scripted svg file from the spec: http://www.w3.org/TR/SVG11/script.html#ScriptElement I would like to consider the current goal for scripting to be to make this file work correctly in Inkscape and/or Inkview. Does that sound reasonable? Bob ------------------------------------------------------- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

3 3

question regarding use of inkscape for my own project
by Julien Keable 09 Jun '04

09 Jun '04

hello happy community, I'm new-to/mixed-up-with SVG, and I'm starting my own SVG-friendly application. I need to load SVG files, modify/generate objects and their properties via API calls and render it in a buffer. While looking at cairo and librsvg to render SVG graphics, I realized (correct me if I'm wrong) their API didn't provide calls to access individual objects or their properties. Then I figured out using some existant app would be much smarter, as open source is starting to kick some serious mellons. Then I saw inkscape and got very excited, because as a bonus, we get SVG extensions and automatic rendering technology updates and so on.. So my plan is to strip inkscape from its GUI part, or simply link the relevant CVS dirs to my own CVS, but this seems a bit harcodre to me and I'd like to hear your wisdom speak about this. (ex : which dirs/classes ? ) another thing I'd like is a table that looks like this : loads SVG renders SVG has API to modify objects ksvg cairo libart librsvg Just to make things as clear as possible, I need to : - load svg files - access/transform individual objects through API (not GUI, I don't have one) ex : rotate(MyCube, 123) - render it in some 32 bit pixel buffer (RGBA) BTW, why is everyone is moving away from libart (inkscape, sodipodi)? thanks, Julien Keable

5 8

ecma -- my last spam for the day
by Bob Jamison 09 Jun '04

09 Jun '04

Ok. I promise that this is my last post to the list today. I am finally caught up from last week, and now I can start adding the real code and not bother this list. I added one file: /src/ecma/script01.svg ...which is the example scripted svg file from the spec: http://www.w3.org/TR/SVG11/script.html#ScriptElement I would like to consider the current goal for scripting to be to make this file work correctly in Inkscape and/or Inkview. Does that sound reasonable? Bob

4 4

Pango
by Bryce Harrington 09 Jun '04

09 Jun '04

Hi all, Last weekend I read through the libnrtype code and put some comments to document what each of the routines do. Probably didn't get 100% correct though, and I wrote in a lot of questions. Could someone scan through the code for the 'Q:'s and see if they can fill in what I couldn't? Also, I reviewed the Pango API's last night and tried to sort out which groups of API calls would need to be implemented in each of the libnrtype files. I put these as steps in the Roadmap in Wiki. Again, I don't know how accurate I was so would appreciate it if someone could check it over and clarify what I missed. My goal was to drill down far into the details of each step. I feel like I came close, but not close enough, so any help specifying that more precisely would be appreciated. >From what I understand, most of libnrtype consists of functions to look up typeface names, font family names, metrics, attributes, etc. In effect, it implements a big 'dictionary' of this info, with various functions to get/set the data, initialize structs containing typeface info on the fly as needed (with reference counting), and so forth. For all this stuff, Pango has routines which do exactly the same thing. So these can be switched over pretty directly, I'd guess. It also has functions for getting outlines of fonts, which I don't totally grok yet, but it looks like there are similar routines in Pango. I can't tell if these would be as straightforward to switch over, since different kinds of structs are involved, so this may be the hard portion of the project. Beyond the above two things, the vast bulk of the rest of the code seems to be there to implement a class hierarchy. I.e., constructors, init, destructors, virtual functions, yada yada. Pretty straightforward and won't need to be fiddled with this go-around. I don't think C++-ifying it would buy us anything, since we'll probably want to majorly restructure all of this code anyway once we're fully converted over to Pango. By the way, Pango looks *very* cool - it handles a much wider degree of font styles, types, etc. than we do. Stuff like lower caps, strike-out, etc. I don't think we support these kinds of fonts at all, so we'll be gaining it all. Also, in Fred's pango_test we were able to get an arabic font to display, that didn't work for me at all in Inkscape. So potentially we may be picking up support for a much wider range of fonts, which would be quite cool. Bryce

2 2

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