- Inkscape Devel - Inkscape Mailman

window focus confusions
by Johan Forsberg 11 Jun '04

11 Jun '04

Hello, I've been using Inkscape fairly often lately and there's one thing in particular that has been annoying me a bit. If I keep more than one image-window open, and want to use e.g. the fill/stroke-dialog, there's always a chance that my wm changes focus to the wrong image-window while my pointer travels between the windows. This happens naturally if the windows overlap so that the wrong window is between the right window and the dialog. If this happens, whatever I do in the dialog will affect the wrong window/object. I realise that maybe I'm in the minority who swear by the "sun mouse" behaviour, but I'm not prepared to part with it on the account of one program :) So, I wonder if there could be an intuitive way to either 1. make it visually obvious (perhaps the selection could change colour) which window my dialog actions will affect, or 2. to lock the "active" window (maybe the last one actually edited?) to consequent dialog actions. Or maybe there's another, more obvious way to solve it. But I think as it works now, it's potentially confusing to new users. I can get around it by organizing my windows, but it's still easy to slip. Thanks! -- Johan Forsberg

1 0

RE: pango again
by bulia byak 11 Jun '04

11 Jun '04

Hi Fred, your patch is fantastic! Most everything works out of the box and the text looks really smooth with subpixel positioning. (No more autohinting, yay!) Even letterspacing works as before. I posted your patch to the tracker, please attach updated versions there. Here are the issues (all of the below is on Linux; I'll try to build it on Windows later today and report results in a separate message): 1. Convert to path distorts lettershapes. I attached a sample to the patch tracker. Compare the red "a" (path) with underlying black "a" (glyph). Looks like all bezier control points became closer to the nodes. 2. Some fonts are badly distorted. I attach (also in the tracker) one such font that is used in the same lettershape-distortions.svg. When converted to path, however, these distortions disappear, although the resulting path is still wrong as described in 1. above. 3. I see you disabled all the fuzzy font matching and name parsing code in nr-type-fontdirectory. Do you think it will be difficult to reenable it with your code? I have written a good deal of that file so I could now try to reenable it. Any hints you might give are welcome. 4. Kerning pairs in fonts still don't work. I thought Pango would provide that automatically - or is some additional support needed? 5. Symbol fonts still don't work. When I select Symbol font in the list, I get ** (inkscape:25358): WARNING **: Unable to load unicode charmap from font file /home/d/.fonts/SYMBOL.TTF ** (inkscape:25358): WARNING **: Unable to open font file /home/d/.fonts/SYMBOL.TTF for font Symbol 512, falling back to /usr/share/fonts/console8x8.pcf.gz ** (inkscape:25358): WARNING **: Error in FT_Set_Char_Size: 23 Haven't yet checked Hebrew or Arabic. Is right-to-left supposed to work now? If not what is needed to make it work? _________________________________________________________________ http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Re: [Inkscape-devel] layers
by bulia byak 11 Jun '04

11 Jun '04

> > * 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? Yes! I think it's exactly what it is - named selections. And from this viewpoint, the idea is useful, but it should NOT be coupled with visibility any more than it's coupled with z-order. It should be only concerned with saving and restoring selections (that possibly span layers or groups). And after you call it "named selection" and remove any attempts to tie it in with layer-like behavior, the idea of an object belonging to more than one named selection is perfectly legitimate. The UI might be simple: a "Name selection" command and an extra drop-down list in Find that lists all named selections in document. Or, even simpler, a single combo box on the selector top panel where you can type in the new name of your current selection, or select one of the defined names from a drop-down to reselect them. And the more I think about it, the more I like this idea. Saved selections can indeed be very useful. Mental, what do you think? _________________________________________________________________ MSN Premium helps eliminate e-mail viruses. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

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

11 Jun '04

The idea is attractively simple, but I see some problems: > * layer visibility is an Inkscape-specific thing, separate from CSS >visibility of individual objects That's problem #1. Remember that our SVG must render the same anywhere. If I hide a layer and save, I must not see that layer in Batik either. I don't see how you can achieve this, other than by manually adding SVG invisibility to all objects that are in an invisible layer (messy). Also: - I disagree that layers should not be related to z-order. A very useful operation (in a traditional vector editor) is re-z-ordering layers, which is not possible with your scheme - except if you select all objects in a layer and group them and move them up or down... which brings us back to the original scheme. - The notion of current layer is possible (just add the name of the current layer to all newly created objects), but again this disregards z-order which may be very inconvenient. For example if I work in a layer which is on top of "background" layer but under the "shades" layer, I expect all new objects to be created in between these layers as well. In your scheme, they're still added on top of all objects, which makes the entire layer thing less than useful. - The idea of an object belonging to more than one layer is cool, but the more I think of it the less I like it. I think it's just unclean and will give users lots of headaches (such as "Why hasn't this object disappeared when I hide its layer? Why do some objects in X disappear when I delete everything in Y?" etc) without significant advantages (or at least I don't see such advantages). When I want object X to be visible both with layer Y and with layer Z, I just put it in a third layer and name it accordingly and manipulate it as needed. I think it's saner that way. Or am I missing something? _________________________________________________________________ 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…

3 3

Re: [Inkscape-devel] layers
by Bob Jamison 10 Jun '04

10 Jun '04

Thorsten Wilms wrote: >Such concepts are better called groups or sets. >Can what you aim at be described as saved selections? > > > That might be a good model. The reason people keep saying "groups" is merely because the <g> tag is the mechanism that the SVG format gives us for things like this. Actually, z-layered groups was what I thought people were asking for when this idea was first mentioned. Just like Illustrator, Corel, even OpenOffice. Check out OO Draw, and see how they do it. A bit clumsy, but it works. It is definitely necessary at times in a drawing program to affix an image or other drawing in the background, sometimes ghosted, to provide a guide for drawing or tracing. This is something I could use myself, actually. Ok, back to my 4-day weekend. Bob

1 0

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