- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] "Lock" vs "Sensitive"/"Insensitive"
by Joshua A. Andler 19 Nov '04

19 Nov '04

> On Wed, Nov 17, 2004 at 10:19:12PM -0500, MenTaLguY wrote: > > > We can investigate whether it makes sense to separate them in 0.41, > > but for now we need to fix the tools etc to treat such objects and > > layers as immutable, at least as far as the mouse tools are concerned. > > Brisgeek was saying that offhand he couldn't think of a situation where > he'd want to mark objects as read-only/immutable (other than having the > whole diagram be immutable, as in inkview). > > Brisgeek and other drawing people, can you think a bit more about this? My thought are that if I lock a layer, I shouldn't be able to do anything to that layers' objects until it is unlocked (other than change visibility, which is a layer level option). And my reasoning goes based on experience with other vector drawing apps... essentially it's the expected behavior. > To me (as a non-artist) it doesn't seem very useful to prevent > modification with the mouse tool of already-selected objects, as it's > easy to deselect them if you've just made them insensitve. Whereas it > does seem useful to be able to modify things that you've gone to the > trouble of selecting despite them being insensitive. To tell you the truth, more artists will end up using Inkscape than non-artists. And it is quite useful to be able to know that you can lock a layer, do a rubberband across the canvas to select all objects of my unlocked layers and not have to worry about anything in my locked layer getting selected as well. In Illustrator & Freehand (as well as others) that is the behavior. Also, as I just tested in Illustrator, if you have an object selected and lock the layer it's on, it is automatically deselected (as you can't modify something that is locked). That makes sense to me as well. If I click lock, it's because I'm don't want to edit that layer (or anything on it) and it saves me a click with the having to deselect manually (minor, but functionally it makes sense with how lock works in Illustrator). > I'd note that it's less work for it to mean merely insensitive rather > than insensitive and immutable from mouse tools. I'd suggest that at > least for 0.40, we keep it as meaning merely affecting > canvas-selectability. > > > Most drawing applications combine both behaviors (unselectable and > > immutable) into their notion of "lock". > > We'll keep that in mind, though Inkscape's general policy is that we > should find the most useful behaviour, and let other programs catch up. This, quite honestly, is where the other guys (Adobe, Macromedia, etc) set the standard and people coming over will expect certain things to function in the same way. I'm not saying it's necessarily right, but layers are very important and people will get turned off if they're "broken" in their view. If we separate unselectable and immutable into separate layer-level options it would make sense to all of us geeks. But most artists aren't really geeks and don't want separate functions, it just needs to do what they expect. I guess the best way to explain it, is that a lock is for protection. The best analogy I have for the lock doing both functions is that if you have your front door locked on your house, people shouldn't be able to A) come in and B) rearrange your furniture. But you unlock it and it's all fair game. Basically the object is a house (properties being furniture), and we're the random people. Just my .02 on the layer subject. -Josh

2 1

sp_repr_position() optimization
by MenTaLguY 19 Nov '04

19 Nov '04

I comitted a small optimization for SPReprs tonight; essentially sp_repr_position() and sp_repr_n_children() are now cached in SPReprs. The way it's actually accomplished is with SPRepr::_n_siblings, which is the number of siblings counting from that particular repr (inclusive) to the end of the sibling list. Looking at it from the parent's perspective, SPRepr::_n_siblings of a its first child will == sp_repr_n_children(), and the sp_repr_position() of a specific child will be: ( sp_repr_n_children(parent) - child->_n_siblings ) Normally, only the first child's SPRepr::_n_siblings will be kept up-to-date; there is a boolean flag (SPRepr::_child_counts_complete) in the parent indicating whether the remainder of its children also have up-to-date _n_siblings members. That flag is checked when sp_repr_position() is called, and the children scanned and updated "lazily" at that time if necessary. This permits node addition and removal to remain constant-time activities. The beneficial effect is that sp_repr_n_children() is always constant-time, and all calls but the first to sp_repr_position() are also constant-time. This will be important later for things like the "sort by overall z-order" facility that bulia asked for (we may need it for some finer points of the 0.40 release), as well as Gtk treeview models (which would necessarily heavily query sp_repr_position() to build GtkTreePaths) later. -mental p.s. Note that sp_repr_nth_child() isn't any faster, but I don't think it's necessary to further optimize at this time. p.p.s. _child_counts_complete sucks as a name. any better ideas?

3 4

pre3 needed, status
by bulia byak 19 Nov '04

19 Nov '04

I think we need a pre3 today. Several important fixes went in, and Mrdocs promised to (finally!) make static RPMs for it. Just a precious few things remain to be done before we can enter freeze: 1 add a dialog asking for a name of a new layer to create, with a couple of checkboxes "Make a sublayer" and "Move selection to the new layer" (I think Mental could use help on this one, it's a simple task for someone) 2 fix two crasher bugs: - 1056658 win98: crash on save (msvcrt error box) (JonCruz) - 1059059 crach autopackage 0.4, may be a dupe of 1064399 3 fix the several portability bugs (actually I think mental handled them already) That's the minimum, the more bugs we fix the better. But this minimum is minimal enough already, which is good news. Let's all make one final push.

4 4

Recent error messages
by Joshua A. Andler 19 Nov '04

19 Nov '04

First I've noticed that the log window has been popping up frequently with recent builds... unfortunately I've been really tied up the past week and a half and have only skimmed the lists (so I'm sorry if this has been discussed), anyway since this stuff started it says: ----- (inkscape.exe:2720): Gdk-CRITICAL **: file gdkdraw.c: line 1351 (gdk_drawable_re al_draw_pixbuf): assertion `width >= 0 && height >= 0' failed ----- And it seems to happen if I switch to a different program and then when I pull inkscape back up it spits that out. The really bad thing though is that Inkscape got caught in a loop here this morning. Using the most recent build in the Win32-snap dir, It just kept spewing the following into the log window: ----- (inkscape.exe:952): Gdk-WARNING **: gdkgc-win32.c:935: SaveDC failed: Not enough storage is available to process this command. (inkscape.exe:952): Gdk-WARNING **: gdkdrawable-win32.c:1493: CreateCompatibleDC failed: Not enough storage is available to process this command. (inkscape.exe:952): Gdk-WARNING **: gdkgc-win32.c:1074: RestoreDC failed: The pa rameter is incorrect. ----- Unfortunately I wasn't able to figure out what triggered it. And also I could not control inkscape whatsoever as it would just pull the log window ontop. Anyway, it just continually repeated those 3 lines non-stop until I finally killed it. Any ideas on either one? And on a side note I'll be posting the tracing quick-start in probably an hour or so for review.

5 12

rename layers dialog runtime error
by bulia byak 19 Nov '04

19 Nov '04

(inkscape:599): Gtk-WARNING **: Attempting to add a widget with type gtkmm__GtkHBox to a gtkmm__GtkDialog, but as a GtkBin subclass a gtkmm__GtkDialog can only contain one widget at a time; it already contains a widget of type GtkVBox and the dialog is empty, tiny sized, not modal, and jumps up in the corner of the screen...

1 0

fr.po error
by bulia byak 19 Nov '04

19 Nov '04

I get this when doing make: file=./`echo fr | sed 's,.*/,,'`.gmo \ && rm -f $file && /usr//bin/msgfmt -o $file fr.po fr.po:1:2: parse error fr.po:985:8: invalid multibyte sequence fr.po:1144:59: invalid multibyte sequence /usr//bin/msgfmt: found 3 fatal errors

2 1

Wiki
by Arpad Biro 18 Nov '04

18 Nov '04

Hi, The Wiki has been very badly spammed again. It seems sooner or later we will be forced to do something drastic about this... Arpad Biro __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

1 0

still no static binaries...
by bulia byak 18 Nov '04

18 Nov '04

All, We were without power for 4 days due to a snowstorm, and what's worse, my Linux partitions broke down when the power went out, so now I have to reinstall the system from scratch. There was no loss of my personal data (thanks to backups), but I lost all of my development environment and now I have to compile again all the latest glib, gtk, gtkmm, sigc++, boehm... So, as you can guess I was really disappointed to still not find a static package on SF. Right now I would be in an ideal situation to test it, being on a system with very limited libraries installed. I start to grow tired from repeating this, but WE NEED PACKAGES, and most importantly we need a static build. That's a prerequisite for the release. The longer we don't have it, the longer the release will be delayed. By not providing binaries now we not only get a poorly tested release, but the binaries _after_ the release will likely be slow to appear, even slower than for 0.39. That's because packagers need time and effort to set up the environment with all the new libraries. So, by doing some binaries now, we'll ensure prompt binary builds when 0.40 is out, which is important from the marketing point of view.

1 0

Rename Layer dialog
by Bryce Harrington 18 Nov '04

18 Nov '04

I've just committed a skeleton chunk of code that hooks up a Gtkmm-based dialog for layers. This is in dialogs/layer-properties.*. I won't have time to work on this for a couple days so if someone else would like a simple but important coding task, it'd be quite valued to fill it in. The dialog can be popped up via the Layers->Rename Layer item in the menu. As you'll see, the dialog's currently empty. The job is to hook up an entry box, make it display the name of the currently selected layer, and add a couple buttons to Apply/Close. In the handler for the apply() routine, make it take the text out of the entry box and set the layer name appropriately. Some resources: * debugdialog.* is a similar Gtkmm dialog you can look at for syntax and such. * The item-properties.cpp file includes code for renaming objects. Look at the sp_item_widget_label_changed(), for instance. You can probably adapt the renaming logic from this. * The gtkmm.org website has examples and reference info that will be of use if you're new to Gtkmm. I'll be happy to answer questions, and will be able to put in time on this this weekend if there's still work left to do. I think this is the last development task (aside from bug fixing) required before we can enter a hard freeze, so the sooner this can be done, the sooner we can get the release out. Bryce

2 1

RE: [Inkscape-devel] layer testing
by Gazal, Geraud (GE Healthcare) 18 Nov '04

18 Nov '04

What I find confusing is being able to select with Ctrl+Click or Rubberband... In fact, I thought the lock (or sensitive) state of a layer would be applied ( not necessarely propagated) to all the objects it contains. I'm not a graphics professional, I only try to draw basic maps as a hobby. I can easily understand that my needs don't match those of the majority. Layers are really useful for me, but the fact the the object they contain can be selected even when locked confuses me a lot. Let me explain : let's say I've got a reference layer with reference lines, and some bitmaps, and additional layers with text, buildings, water, streets... When working on a specific layer, i want to see the others but not modify anything in them. At the moment it's not ok (at least for me), as rubberband selection (my favourite one btw) can select ( and then modify) them. A workaround is to lock objects individually, but then, unlocking them one by one from the xml editor is a pain... regards, matiphas

2 1