Re: Bug 60331 ï Object properties should handle multiple objects

[Hans Breuer <hans breuer org>]

At 23.11.2008 05:25, Sameer Sahasrabuddhe wrote:
> 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
> > > around.
>
> > 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
> > solution?
>
> 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.
We are talking of app/properties.c's call to apply_properties_from_dialog, 
aren't we?

> > 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.
Again apply_properties_from_dialog() ?

> Now one option is to change the dialog interface to accept a list of
> objects. 
This would be an object interface change if my above assumptions are right.

> 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. 
For me it still feels wrong to have a selection object - on te same level 
as all the other objects?

> The second option is better because it allows
> us to fix the following bug:
>
> http://bugzilla.gnome.org/show_bug.cgi?id=110393
> Selection needs to be in the undo list
I think fixing this bug is independent of a DiaObject representing 
selections, of course we would need some object to represent selections.
But e.g. a (floating) layer feels more natural to me than letting 
everything be a DiaObject.

> And also it represents a very small step in fixing this bug:
>
> http://bugzilla.gnome.org/show_bug.cgi?id=171074
> print selection / export selection
Here a layer would definitely be more useful. Otherwise your special object 
needs to be known (special cases) in all the rendering code whicj already 
is aware of (invisible) layers.

> > 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.
Ok, agreed.

> Finally, I appeal to aesthetics. "current selection" is a very
> prominent concept in the application. It should in principle have a
> proper representation. 
Yes ...

> Once it is abstracted out, who knows, other
> ideas might start popping up because now it is easy to think about
> selections.
... but IMO not as DiaObject.

Of course showing some code addressing all my objections above may convince 
me that I'm wrong ;-)

Thanks,
        Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert