Re: [gef-dev] Zest FX UI contribution

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

Hi,

I'm not yet at a point where I thought about this feature. What I
changed just today (while commuting) was the content provider which
instead of returning a list now looks like this:

> public interface ContentProvider<O,I> {
> 	public void setInput(I input);
> 	public O getRootElement(int index);
> 	public int getSize();
> }

> public interface TreeContentProvider<O,I> extends ContentProvider<O, I> {
> 	public O getChild(O parent, int index);
> 	public O getParent(O element);
> 	public int getChildSize(O parent);
> 	public boolean hasChildren(O element);
> }


which should support loading data lazy a lot better because it does not
require you to load things into memory all at once but requests data on
demand.

As stated things are very much in the flux - I'm not sure that this
mailing list is the correct area for this discussion.

I currently lean towards not having add/remove/... methods on the viewer
but more lean toward requiring an observer pattern if your viewer
content is dynamic ;-)

I've opened a bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=440425
where people can attach themselves if they are interested in such an API

Tom

On 25.07.14 11:42, Ujhelyi Zoltán wrote:
> Hi Tom,
> 
> thanks for revisiting this issue. It looks really promising; I have some ideas how to extend it to support additional properties (e.g. containment relations for trees; or further attributes for tables), but I am looking forward to how do you imagine this.
> 
> However I have a question. I don't see how this API could be extended to handle model changes: if the internal model changes, I would like to update the viewer contents as required. I know, this was quite cumbersome in the original JFace API, as for model changes I had to call the add/remove methods of the Viewer from the content provider, but the functionality was there. In this API, I don't see how this could be achieved.
> 
> 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.25., at 0:38, Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx> wrote:
> 
>> Hi,
>>
>> Today I had some time to putting together a first API Design for Viewer 2.0.
>>
>> You can read about it at
>> http://tomsondev.bestsolution.at/2014/07/24/jface-viewers-in-a-java8-world-part-1-listviewer/
>>
>> I'm in the very early design stages and are trying out things so the
>> final design might look completely different.
>>
>> Tom
>>
>> On 08.07.14 11:22, Tom Schindl wrote:
>>> Hi,
>>>
>>> Yeah the paradigm is ok and I have already thought about different APIs
>>> multiple times (even implemented for customers).
>>>
>>> I'm in the process to define such an API as part of e(fx)clipse although
>>> there's no source yet available in the repo. Once I have something I'll
>>> post an update so that you can get an idea ;-)
>>>
>>> Tom
>>>
>>> On 08.07.14 11:19, Ujhelyi Zoltán wrote:
>>>> You are right, the hard SWT dependency is the killer here. :) The JFace API itself is not good...
>>>>
>>>> I will do some research about alternative patterns already used (I am not confortable with designing an entirely new paradigm here ;) ).
>>>>
>>>> Thanks for the feedback,
>>>> 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 11:13, Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx> wrote:
>>>>
>>>>> [...]
>>>>>
>>>>>> In summary, I guess, JFace Viewers API support is still not a strict requirement, but I would have troubles designing a different API that is still at least as good for creating the displayable models.
>>>>>
>>>>> JFace would drag in SWT and isn't GEF4 to be widget toolkit neutral?
>>>>>
>>>>> Beside that I think the JFace-API shows is age in it's API:
>>>>>
>>>>> * useage of Array-Types (=> you can not generify it completely no
>>>>> matter how many GOSC projects you setup)
>>>>>
>>>>> * No SAM-Types wouldn't you want to write a label-provider like this in
>>>>> Java8
>>>>>
>>>>> Viewer<Person> v = new Viewer<>();
>>>>> v.setTextLabelProvider( (o) -> o.name );
>>>>>
>>>>> * Hard SWT-Dependency
>>>>>
>>>>> * (I could go on with more :-)
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>> _______________________________________________
>> 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
>