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

[Miro Spoenemann <msp@xxxxxxxxxxxxxxxxxxxxxx>]

Hi all,

in KIELER we have solved this problem using an extension point where

 * layout options, i.e. parameters of layout algorithms, can be declared
with some meta data such as identifier, name, and data type;
 * layout algorithms can be declared together with a list of supported
layout options.

These meta data are gathered in a singleton service class. As a result,
we could implement a generic "Layout" view, very similar to the
"Properties" view, where a layout algorithm can be selected and the list
of supported layout options is then updated automatically, so the user
can access all parameters of the algorithm.

Usually layout options are used as input of the algorithms. There are
some rare cases where properties are used as output, e.g. to mark edges
that have been routed with spline control points, but we don't
distinguish explicitly between input and output properties. Whether a
property is input or output is documented in the source code where the
property constant is declared.

We'll present our proposal on the graph interface this afternoon or so.

Regards
  Miro


On 07/08/2014 10:22 AM, Alexander Nyßen wrote:
> 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
> _______________________________________________
> 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
> 
> 
>