=?UTF-8?Q?Re:_Bug_60331_=EF=BF=BD_Object_propertie?= =?UTF-8?Q?s_should_handle_multiple_objects?=

On 11/22/08, Hans Breuer <hans breuer org> wrote:

I tried out newgroup. From the look of it, it has nothing to do with
the multiple selection bug! As far as I could see, the newgroup is a
very special beast that keeps track of objects within it. What I need
is just a very very simple collection ... it is ephemeral, since it
changes every time a mouse-click results in selecting one or more
objects. The solution for bug 60331 basically amounts to replacing the
glist of selected objects with proper DiaObject that can be passed

Why do you want to change this on the object interface level? Wouldn't a
dedicated "multiple selected objects" properties dialog give you a better

No, I don't intend to change the object interface in any way. Also,
the current properties dialog itself handles multiple objects very
well ... the only problem is that when the user clicks on
"Properties", all the selected objects are not passed through to the
dialog, only the head of the list is passed.

Such a dialog could listen to the current diagram selection and extract all
the required properties to show from this. On apply it would simply iterate
over all selected properties and call their set_props() method.

Like I said, the current dialog does the second part very well. But
the first part about getting the current selection is handled from
outside the dialog. The dialog interface accepts a single DiaObject,
instead of a set.

Now one option is to change the dialog interface to accept a list of
objects. The other option is to have a first class "Selection" object
that tracks the currently selected objects. This replaces the current
g_list in DiagramData. The second option is better because it allows
us to fix the following bug:

Selection needs to be in the undo list

And also it represents a very small step in fixing this bug:

print selection / export selection

Otherwise you would have to constantly rebuild your "virtual group object"
when the selection changes, wouldn't you?

No problem with that! We are already constantly rebuilding the g_list
of selected objects. We replace that code with functions like
selection_add_object() and all that.

Finally, I appeal to aesthetics. "current selection" is a very
prominent concept in the application. It should in principle have a
proper representation. Once it is abstracted out, who knows, other
ideas might start popping up because now it is easy to think about


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]