insensitive, xml editor
I've been bugged by this all day... Anyway, here we go. When turning an object to insensitive via the item properties menu, there's a line added in the xml:
sodipodi:insensitive = "true" formally that was sodipodi:insensitive = "1" it seems, since I have a few objects I created with inkscape not long ago, that have that tag. Anyway, setting the value to either "false" or "0" in the xml editor doesn't do anything. Checking sensitive in the item properties dialog again, deletes the whole line. This can of course be done in the xml editor as well, but it's a wierd behaviour, that the value setting doesn't do anything. It also brings me to another point. When you select an attribute and press [del] the whole object is deleted. Rather than that the specific attribute should be deleted, I think. And when selecting a undeletable item, the "delete attribute" should be insensitive.
What I also found to be very surprising, is, that I can select items within a insensitive group via ctrl+click, but am not able to select the insensitive item via shift+click or alt+click and then change it back to sensitive via the right-click menu, but as it seems to me have to use the xml editor to select it, and then either directly delete the insensitive attribute or use the item properties dialog to do so.
David
On Fri, 2004-04-09 at 09:24, David Christian Berg wrote:
I've been bugged by this all day... Anyway, here we go. When turning an object to insensitive via the item properties menu, there's a line added in the xml:
sodipodi:insensitive = "true" formally that was sodipodi:insensitive = "1" it seems, since I have a few objects I created with inkscape not long ago, that have that tag.
Strange ... looking at the CVS history, it's been "true" since the fork from Sodipodi.
Anyway, setting the value to either "false" or "0" in the xml editor doesn't do anything.
The code only checks whether the attribute exists or not, not what it is set to.
I don't think we can change that behavior without breaking compatability (at least in principle ... it may not matter much in practical terms) with Sodipodi.
-mental
Strange ... looking at the CVS history, it's been "true" since the fork from Sodipodi.
Then I must have opened the document in sodipodi in the mean while and saved it, for some reason, dunno and this doesn't matter, really.
Anyway, setting the value to either "false" or "0" in the xml editor doesn't do anything.
The code only checks whether the attribute exists or not, not what it is set to.
I don't think we can change that behavior without breaking compatability (at least in principle ... it may not matter much in practical terms) with Sodipodi.
But isn't it on the otherhand inconsistent to have an attribute that can't be set to "false"? And isn't it more like that sodipodi should change that aswell?
David
On Fri, 2004-04-09 at 10:43, David Christian Berg wrote:
I don't think we can change that behavior without breaking compatability (at least in principle ... it may not matter much in practical terms) with Sodipodi.
But isn't it on the otherhand inconsistent to have an attribute that can't be set to "false"? And isn't it more like that sodipodi should change that aswell?
Maybe; you should probably verify Sodipodi's current behavior and submit an RFE to them.
The most we can do is match Sodipodi's behavior. If we want our own behavior we would need to introduce an attribute in the inkscape namespace.
-mental
MenTaLguY wrote:
On Fri, 2004-04-09 at 10:43, David Christian Berg wrote:
I don't think we can change that behavior without breaking compatability (at least in principle ... it may not matter much in practical terms) with Sodipodi.
But isn't it on the otherhand inconsistent to have an attribute that can't be set to "false"? And isn't it more like that sodipodi should change that aswell?
Maybe; you should probably verify Sodipodi's current behavior and submit an RFE to them.
The most we can do is match Sodipodi's behavior. If we want our own behavior we would need to introduce an attribute in the inkscape namespace.
I don't understand why there is a problem: attr exists and equals "true" or "1" then true, false otherwise.
njh
On Fri, 2004-04-09 at 20:21, Nathan Hurst wrote:
I don't understand why there is a problem: attr exists and equals "true" or "1" then true, false otherwise.
Sodipodi (at least as of the fork) treats "false" as true also. The only false case is absence of the attribute.
You can see the interoperability problems that would arise if at some point we start producing documents with sodipodi:insensitive="false", yes?
The ground rule is that for attributes in the Sodipodi namespace, we use Sodipodi behavior. If we want different behavior, we use our own namespace.
-mental
participants (3)
-
David Christian Berg -
MenTaLguY -
Nathan Hurst