Re: [gef-dev] GEF4 Layout refactoring - properties

[Alexander Nyßen <alexander.nyssen@xxxxxxxxx>]

Hi Zoltán,

actually we were less concerned about access control, but more about making visible which algorithm actually needs which input properties (and produces which output, which may in addition to location and size  for instance a layer assignment in the Sugiyama case), which may otherwise be somehow implicit.

Cheers 
Alexander

Von meinem iPhone gesendet

> Am 08.07.2014 um 09:55 schrieb Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>:
> 
> 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
> 
> _______________________________________________
> gef-dev mailing list
> gef-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/gef-dev