Skip to main content

[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



Back to the top