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,

ok, in this sense, it is fine by me. Having interfaces does not hurt, just it does not solve the entire problem in itself. But again, we are discussing options right now.

I am also in favor of removing the LayoutInterfaces before Mars comes out, as it would clean up our code and make our work more similar to the Kieler algorithms, thus allowing a more seamless integration between the two.

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

On 2014.07.08., at 15:36, Alexander Nyßen <alexander.nyssen@xxxxxxxxx> wrote:

> Hi Zoltan,
> 
> I think our understanding about the role of GEF4 Graph is probably pretty much the same. My point was simply that if we split GEF4 Graph into a set of interfaces and related implementation classes and use only the interfaces to realize (1) visualization by Zest.FX and (2) allow layout algorithms to consume input data (whatever attributes seem necessary) from it and write output data to it (position and size), we would not force our users to always transform their data into the Graph data structure (while they could of corse use GEF4 Graph exactly in this way). Instead, they could also create adapters that implements the GEF4 Graph interfaces and delegate to their model.
> 
> What Matthias and I were referring to w.r.t. to bringing the layout-interfaces closer to GEF4 Graph was actually meant to open a migration path for (2), i.e. that the layout algorithms could actually use GEF4 Graph (or the interface layer of it - if we split it apart - to be more precise) directly rather than via an additional set of layout-related interfaces (which we currently have in terms of NodeLayout, etc.).
> 
> Hope that clarifies any misunderstandings...
> 
> Cheers
> Alexander
> 
> Am 08.07.2014 um 10:31 schrieb 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
>> 
>> _______________________________________________
>> 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
> 
> --
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Software-Engineer
> 
> Telefon: +49 (0) 231 / 98 60-210
> Telefax: +49 (0) 231 / 98 60-211
> Mobil: +49 (0) 151 /  17396743
> 
> http://www.itemis.de 
> alexander.nyssen@xxxxxxxxx 
> 
> itemis AG
> Am Brambusch 15-24
> 44536 Lünen
> 
> Rechtlicher Hinweis:
> 
> Amtsgericht Dortmund, HRB 20621
> 
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
> 
> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
> 
> 
> _______________________________________________
> 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

Back to the top