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

[Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>]

Hi,

I guess, layering information should not be stored in the GEF Graph. It is some internal stuff of the Sugiyama (and possibly other tree-visualizer algorithms); the only thing it could use from the GEF Graph are some "hints" related to that (e.g. consider a selected node as root node or similar ideas). Finally, this layering information will not directly written back to the GEF Graph but only translated into position/size information.

Maybe this difference comes from how we understand the role of the GEF Graphs. In my head, GEF Graph is the user-provided data to be visualized; while Zest provides (1) a visualizer that writes the information out, and (2) layout algorithms that can create and/or update position and size information in this graph. If this is in conflict what you are understanding here, we should come to an understanding.

Cheers,
Zoltán

PS.: I can still imagine other layouts reusing this information, but it is the internal ideas of layouts, that reuse the same kind of translation internally.
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

On 2014.07.08., at 10:22, Alexander Nyßen <alexander.nyssen@xxxxxxxxx> 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