[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [gef-dev] GEF4 Layout refactoring - properties
|
Hi all,
my answers will be inline.
On 2014.07.07., at 18:11, Matthias Wienand <matthias.wienand@xxxxxxxxx> wrote:
> Hi all,
>
> I think it would be beneficial for the later adoption of KGraph-like
> structure to bring the GEF4 Layout interfaces closer to KGraph. As
> already discussed in our team call, KGraph does not define explicit
> properties, but a universal properties map. Our GEF4 Graph model already
> anticipates that, however, the layout interfaces still expose dedicated
> operations to set/get certain properties.
>
> I would like to remove those explicit properties from the GEF4 Layout
> interfaces and replace corresponding method calls with
> setProperty()/getProperty() as a first step. The object adapters for
> GEF4 Graph (defined in Zest.FX), which implement the layout interfaces,
> could forward any property access (obtained via the layout interface) to
> the adapted graph elements (while we still would have to make the
> properties in GEF4 Graph modifiable to support this).
+1 from me.
> One problem we have not discussed yet, is how to declare which
> properties are accessed by which algorithms (and how, i.e. read or
> write, or both). Having discussed this with Alexander already, we think
> it would probably be most transparent if each layout algorithm would
> explicitly specify its IN, OUT, and IN_OUT properties:
>
> - An IN property is accessed by the algorithm as an input parameter.
> - An OUT property is used by the algorithm as an output parameter.
> - An IN_OUT property is used by the algorithm as an input parameter and
> an output parameter, for example, location and size.
Sorry, but I am not sure whether this is needed and/or beneficial. In my understanding layout algorithms would only write back location and size (and for them, it could be either inout property - as in dynamic layouts, or in - as in static layouts), anything else would be either read-only for them, or not read at all. For these few properties, doing access control seems to be unnecessary.
However, I am not sure whether you have other use cases in mind, so feel free to share them.
Cheers,
Zoltán
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz
Fault Tolerant Systems Research Group
Budapest University of Technology and Economics