June 2004 - Inkscape Devel - Inkscape Mailman

RE: [Inkscape-devel] layers
by bulia byak 10 Jun '04

10 Jun '04

>You're describing groups; this is something different. OK. But then I need our groups to be significantly expanded in functionality: I need a "current group" to which I can by default add newly created objects, and I need a dialog that would show me only these top-level groups so that I can get an idea of what I have in the document, and to set visibility/editability of such groups easily. See? You may call them "groups," but then we'll simply end up adding a lot of the standard layer functionality to these groups, because your "slices" do not support it. >I guess using the term "layers" sets up wrong expectations of behavior >for people coming from Illustrator/graphic design backgrounds (because >Illustrator calls its top-level groups "layers" and limits the >functionality of child groups), so we will need to find a better term. OK, let's call your idea "slices". Or "aspects". >What I'm describing is fundamentally different (we will still have >groups, so top-level groups will necessarily act like "Illustrator >layers") -- think of my "layers" being like search keywords, where one >can say "hide all objects not matching this set of keywords". We already have Find which is pretty close to what you describe. And we can make it behave almost exactly as you describe, by adding some sort of a combo box to Object properties that would allow you to set inkscape:keywords attribute by editing it or by selecting from a pool of other keywords in the document, and adding one more field to Find for searching by these keywords. It's not difficult, I just don't see much use in it if, as you say, we still need "traditional" groups as well. _________________________________________________________________ Check out the coupons and bargains on MSN Offers! http://youroffers.msn.com >From MAILER-DAEMON Thu Jun 10 01:59:18 2004 Date: Thu, 10 Jun 2004 10:58:33 +0200 From: Thorsten Wilms <t_w_@...123...> To: inkscape-devel(a)lists.sourceforge.net Subject: Re: [Inkscape-devel] layers Message-ID: <20040610085833.GA5599@...124...> Reply-To: tw@...125... References: <1086842330.709.7207.camel@...4...> Mime-Version: 1.0 In-Reply-To: <1086842330.709.7207.camel@...4...> Priority: normal X-Mailer: Mutt User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 Sender: inkscape-devel-admin(a)lists.sourceforge.net Errors-To: inkscape-devel-admin(a)lists.sourceforge.net X-BeenThere: inkscape-devel(a)lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/inkscape-devel>, <mailto:inkscape-devel-request@lists.sourceforge.net?subject=unsubscribe> List-Id: <inkscape-devel.lists.sourceforge.net> List-Post: <mailto:inkscape-devel@lists.sourceforge.net> List-Help: <mailto:inkscape-devel-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/inkscape-devel>, <mailto:inkscape-devel-request@lists.sourceforge.net?subject=subscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=inkscape-devel> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Content-Disposition: inline On Thu, Jun 10, 2004 at 12:38:51AM -0400, MenTaLguY wrote: > > 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. But most the well known vector and bitmap apps all couple layers to z-order. And the whole metaphor doesn't make sense if you take that aspect away. So whatever you go for: don't call any concept that doesn't create z-order compartments layers And a z-order management facility just like illustrator/freehand layers is needed anyway. > * an object can be in zero or more layers Such concepts are better called groups or sets. Can what you aim at be described as saved selections? Going with the set name: Objects could be explicitly added to sets, or sets could be like live queries (allthough I wonder if that wouldn't be overkill). Just an idea: How about inheritance of properties from sets/groups to members? > * 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 Oh, saved selections wouldn't have visibility of their own, but allow to change all members state at once. --- Thorsten Wilms

1 0

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