[Thuban-devel] Re: RfD: Support for layer specific resources

[Bernhard Herzog]

Martin Schulze <joey at infodrom.org> writes:

> What about this one instead?
>
> def get_layer_properties_dialog(layer):
>     for cls, func in _layer_dialogs['properties']:
>         if isinstance(layer, cls):
>             return func
>     return None

Yes, better.  But see below for some other, general remarks.

>> The logic that determines whether the dialog is already shown and either
>> raises the existing one or creates a new one should be left in the
>> mainwindow.  Actually, it should be moved into its own mainwindow method
>> as this logic has already been duplicated at least seven times in
>> mainwindow.py, but that's for another patch.
>
> That would require a global logic for naming windows/dialogs.

It would be local to the mainwindow.

> We may also need some sort of registration for calculation functions.

What exactly do you mean?  The Panels in Thuban/UI/classgen.py?


> Something like
>
>     def OpenOrRaiseDialog(self, type, layer, group=None):
>         # type one of [layer,properties,information]
> 	name = self.calculate_dialog_name(...)
>
> 	dialog = self.get_open_dialog(name)
>
> 	if dialog is None:
> 	    open_func = get_layer_properties_dialog(layer)
> 	    if open_func is None:
> 	        return None
> 	    dialog = open_func(self, layer, group)
> 	    parent.add_dialog(name, dialog)
> 	    dialog.Show(True)
> 	else:
> 	    dialog.Raise()

Well, it's still too get_layer_properties_dialog specific.  I was
thinking about something more like this:

    def OpenOrRaiseDialog(self, name, dialog_class, *args, *kw):
	dialog = self.get_open_dialog(name)

	if dialog is None:
	    dialog = dialog_class(self, name, *args, **kw)
	    parent.add_dialog(name, dialog)
	    dialog.Show(True)
	else:
	    dialog.Raise()

The raise-or-open logic should be completely separate from the logic
that determines which dialog to open.


> we will probably handle show_table
> and information similar to the properties dialog.

Why do we need layer specific dialogs for show table?  It may be
necessary to make the existing code more flexible, so that it works for
layers that are not sub-classes of Layer among others, but that
shouldn't require different dialogs.

> Apart from that, this method is executed quite often.  We would
> probably create a reasonable delay if it would be implemented that
> way.  In order to avoid this, I propose a hierarchical data structure
> for layer_dialogs.py (attached).

Well, the way you wrote the function, it returns the wrong results (see
below) in some cases and probably isn't all that much faster.  Anyway, I
don't think we need the hierarchical approach yet.  If the lookup is too
slow there are lots of ways in can be made faster.  E.g. instead of
doing a linear search each time, we could build a dictionary on demand
mapping layer classes to the appropriate dialog classes.


One problem that will probably bite us some day is that with the current
code (and the code in baserenderer.py for that matter) it can happen
that settings for a base class override that of one of its subclasses.
One way to solve it is to make sure the subclasses come before their
base classes in the list of layer classes, i.e. keep the list
topologically sorted, effectively.


> def has_layer_dialog(type, layer_class):
>     return (type in _layer_dialogs and layer_class in _layer_dialogs[type])

This is will return false if a base class of layer_class is in
layer_dialogs[type] but not layer_class itself.


  Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                http://sketch.sourceforge.net/
Thuban                                  http://thuban.intevation.org/