Re: Bug 60331 ï Object properties should handle multiple objects

[Hans Breuer <hans breuer org>]

At 28.11.2008 07:02, Sameer Sahasrabuddhe wrote:
> On 11/28/08, Hans Breuer <hans breuer org> wrote:
>
> > > > 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?
>
> Ok. Rather than dissecting each others emails, let me summarise:
>
> We both agree that changing the programming interface to the dialog
> object is bad, and I have no intention to do it. 
Where did you draw that conclusion from? I'm against changing the *object* 
interface to take multiple objects. Changing the signature of one app/-only 
interface looks much less invasive.
Why can't we just change properties_show() to take either an object or a 
selection? Thus it would be possible to have all the one-or-multiple object 
specific code in app/properties.c, wouldn't it?

> The current dialog
> does very well at setting properties of multiple objects, but the
> problem is that we can't pass multiple objects to it through the
> current programming interface. Now solutions proposed:
>
> 1) Promote the current selection to a DiaObject.
>
> This does not need a change in the interface in any manner. But if the
> selection object is not a DiaObject, it can't be passed to the dialog.
Selection as DiaObject still does not pass the "duck test" [1] for me. When 
I look at your other mail, there seem to be only three functions where 
Selection behaves like a _specific_ DiaObject: Group.
All the other methods (select, destroy, create, draw, copy, move_handle) 
are not behaving like a DiaObject usually does.

> 2) Create a new dialog!
>
> The current dialog is perfectly well suited to do the required job.
> Creating a new dialog just to make a distinction between a single
> selected object and multiple selected objects is ugly. How does it get
> invoked? The current dialog is invoked through the selected object's
> vtable. 
Really? The container dialog is invoked in app/properties.c and it is 
filled with properties got form the "current object". It should be 
relatively simple to extend that to accumulate properties from from 
multiple objects and show these instead.
Most objects implement GetPropetiesFunc by delegating to 
object_create_props_dialog() which in turn delegates to prop_dialog_new()
[ Both slightly misnomed because they do not create a dialog, but just 
return a widget which includes all the needed property widgets. The dialog, 
it's apply (anf other) button(s) are still outside of that. ]

> We would need more code just to check if multiple objects are
> selected, and then invoke the special dialog.
Yes. But that code would be resticted to the place where the specific 
propblem is to be solved ;)

> Instead if the current selection is itself a DiaObject, then it's own
> vtable points to the appropriate action, ie, a call for the current
> dialog. We might still need to check whether one or more objects are
> selected in some places, but if that becomes necessary, the check is
> now neatly placed inside the behaviour of the selection object, where
> it's relevant.
When I look at the use of data->selected I see almost no place, where the 
selection could/should be treated as a single object (align, copy, find, 
...). With Selection being a DiaObject all the place still need to know 
implementation details from Selection. At least I can not imagine a benefit 
in these places when the list got replaced by a single object containing 
the list.

> 3) An invisible layer.
>
> I am not aware of how this works. Would appreciate a pointer in the
> general direction of what this means. 
If you look at samples/Self/dia-core.dia [2] (or maybe PyDiaObjects.dia, 
because that contains the connections between the dia objects) you'll see 
that a Layer is between the Diagram and the DiaObject. Basically the Layer 
is a container of objects with some extra properties. None of it's methods 
seems to be inappropriate for the Selection object.

> This solution is useful only if it allows us to invoke the current 
> dialog without changing its interface.
>
I think you are bit too focused to the selection properties solution ;-)
If we invent an on class to deal with the selection concept it should be 
useable for much more than changing multiple properties at once.

> > > http://bugzilla.gnome.org/show_bug.cgi?id=110393
> > > Selection needs to be in the undo list
If the selection would be a "floating layer" the undo could be derived from 
 "layer delete". Only problem to solve would be object ownership.

> > > http://bugzilla.gnome.org/show_bug.cgi?id=171074
> > > print selection / export selection
If al the other layers are hidden (and Layer interfacing would be properly 
abstracted) this should be just a matter of layer visibility.

> Now that the intentions are clear, let's ignore these bugs. I
> shouldn't have dragged them here in the first place.
No, I think these bugs are very helpful to analyze what we should expect 
from a Selection object.

> > Of course showing some code addressing all my objections above may convince
> > me that I'm wrong ;-)
>
> Would love to do that! I already have the SelectionObject, but need to
> be careful about its vtable. That will take some time. Till then, two
> things would be highly appreciated:
>
> 1) Anything that could possibly go wrong by making SelectionObject a
> DiaObject. Like code that might have to make a special exception, for
> example. 
Search for data->selected and try to fit that to your Selection object.

> I would hate to be suprised by something unexpected ... if
> anyone can see something right away, please let me know since that can
> save a lot of effort.
Hope the above helps.

> 2) A general idea about what invisible layers are, and their place in
> the rest of the world.
I think playing a bit with layers (see Edit/Layers...) should help.

Thanks,
        Hans

[1] http://en.wikipedia.org/wiki/Duck_test
[2] svn://svn.gnome.org/svn/dia/trunk/samples/Self/dia-core.dia

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