I notice the Object Properties dialog has changed. Questions:
Why are Title and Description always disabled?
What is Label? It's made from the id obviously but pressing Update informs me that it is "invalid". Hey, I did not put it there! Why Inkscape gives me something which he (Inkscape) knows to be invalid?
Most importantly, where did the id= field go? We must keep a way to edit id, even if we add more stuff to this dialog.
On Sun, 31 Oct 2004, bulia byak wrote:
I notice the Object Properties dialog has changed. Questions:
Why are Title and Description always disabled?
Mental said that full implementation of these would have to wait until after the release since they appeared more complicated than had been assumed.
What is Label? It's made from the id obviously but pressing Update informs me that it is "invalid". Hey, I did not put it there! Why Inkscape gives me something which he (Inkscape) knows to be invalid?
A task was put into the roadmap to add a way to edit a inkscape:layer property.
Most importantly, where did the id= field go? We must keep a way to edit id, even if we add more stuff to this dialog.
One of the tasks mental put into the roadmap was to remove the id= field. Perhaps he can explain the reasoning.
Bryce
Most importantly, where did the id= field go? We must keep a way to edit id, even if we add more stuff to this dialog.
One of the tasks mental put into the roadmap was to remove the id= field. Perhaps he can explain the reasoning.
I'm against removing it. It may be true that it's bad to use id for anything except refs, but the fact is that they _are_ used for lots of things both in Inkscape and elsewhere. We must retain a way to edit it.
On Sun, 31 Oct 2004, bulia byak wrote:
Most importantly, where did the id= field go? We must keep a way to edit id, even if we add more stuff to this dialog.
One of the tasks mental put into the roadmap was to remove the id= field. Perhaps he can explain the reasoning.
I'm against removing it. It may be true that it's bad to use id for anything except refs, but the fact is that they _are_ used for lots of things both in Inkscape and elsewhere. We must retain a way to edit it.
The roadmap was clear about removing this, and since the other tasks show both your name and mental's name listed, it is logical to assume you are in consensus on the tasks.
You and mental have specified that layer implementation work must be done prior to the release, so I have volunteered time to help work on this. I don't have any particular stake in *why* these changes must or must not be done, except that I wouldn't want to think I'm wasting my time by helping.
Bryce
The roadmap was clear about removing this, and since the other tasks show both your name and mental's name listed, it is logical to assume you are in consensus on the tasks.
We did discuss the problems caused by id used for metadata, and how this can be fixed by providing true metadata (label & description), but I don't remember that removing the id editability was ever mentioned.
Bryce Harrington wrote:
I wouldn't want to think I'm wasting my time by helping.
Actually, ...... it was probably good to get that off of the dialog, if only so that there are not 2 different OK buttons on the dialog, that do different things. Maybe a separate small dialog only for ID's could separate out that function, and put it into a clear and proper context.
OOdraw has a simple separate dialog just for naming a drawing object, like this:
http://troi.hous.es3.titan.com/~rjamison/inkscape/files/oonameobject.png
....which only does that one thing. Maybe that would be good enough to allow users to still set the ID field, but not clutter up the properties dialog with two attributes that look similar and confusing to the user. This could be whipped together in Gtkmm in an hour or so, and I would be glad to do it.
Bob
....which only does that one thing. Maybe that would be good enough to allow users to still set the ID field, but not clutter up the properties dialog with two attributes that look similar and confusing to the user.
I think that EXACTLY because ID looks similar to other metadata and may be confusing, we should keep it in the same dialog. The user will then be able to compare tooltips for different fields and actually understand their difference and uses, as opposed to different dialogs which will forever leave him in a state of undecision: "did I change this one the last time? or was it the other one?"
Not to mention that any additional dialogs add clutter. And not to mention that Object Properties already has a keyboard shortcut, while I doubt we can afford a new shortcut for the ID dialog.
bulia byak wrote:
Most importantly, where did the id= field go? We must keep a way to edit id, even if we add more stuff to this dialog.
One of the tasks mental put into the roadmap was to remove the id= field. Perhaps he can explain the reasoning.
I'm against removing it. It may be true that it's bad to use id for anything except refs, but the fact is that they _are_ used for lots of things both in Inkscape and elsewhere. We must retain a way to edit it.
I agree; maybe the goal was to provide another way to edit it (besides the xml editor).
Heh. Adding the ID field was my very first contribution to Inkscape. The reason then was the same as now: apps external to the SVG file need to be able to reference objects in the DOM tree. I use this field every day at work. Scripting will need this, too.
Bob
bulia byak wrote:
I'm against removing it. It may be true that it's bad to use id for anything except refs, but the fact is that they _are_ used for lots of things both in Inkscape and elsewhere. We must retain a way to edit it.
Funny.. just got back to the office, and I needed to use the ID field again. This is one of the most basic requirements for referring to an object uniquely from outside the SVG file.
Both libsvg-cairo and Batik have a method like getElementById(), which implies that there is an ID that I can set.
Please don't cripple me.
Bob
On Mon, 2004-11-01 at 08:27, Bob Jamison wrote:
Funny.. just got back to the office, and I needed to use the ID field again. This is one of the most basic requirements for referring to an object uniquely from outside the SVG file.
To be clear: removing the id field was my idea alone, and a stupid one. I wound up needing it pretty quickly too.
Somebody please put it back when you have a chance.
-mental
MenTaLguY wrote:
To be clear: removing the id field was my idea alone, and a stupid one. I wound up needing it pretty quickly too.
Somebody please put it back when you have a chance.
Well... I don't think it's that stupid.
Especially having done lots of different stuff with different flavors of XML over many years. We should probably take a little time with that stewing in our brains to see if there's a nice UI change way of hiding id from novices, yet making it accessible for the more advanced users.
participants (5)
-
Bob Jamison -
Bryce Harrington -
bulia byak -
Jon A. Cruz -
MenTaLguY