[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Well, actually I am not very ambitious about whether we are going to factor it into plug-ins or fragments. Just thought fragments to be the right "abstraction"...
Cheers
Alexander
Von meinem iPhone gesendet
Am 25.09.2012 um 08:20 schrieb Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>:
> Why fragements? I'm not a fan of fragments at all, e.g. they are causing
> problems when building with tycho, ... .
>
> Tom
>
> Am 25.09.12 09:16, schrieb Alexander Nyßen:
>> Hi Tom,
>>
>> great you are contributing that! Concerning the SWT dependencies, we had in mind to put the SWT-dependent things into fragments. That's the reason we already refactored everything, so that SWT dependencies within the geometry component are now only located within the respective transformation package. Maybe I can factor that out by next week.
>>
>> Cheers
>> Alexander
>>
>> Von meinem iPhone gesendet
>>
>> Am 24.09.2012 um 20:25 schrieb Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>:
>>
>>> Hi,
>>>
>>> Ok - writing the rendering for FX using the JavaFX-Canvas API was really
>>> easy ;-)
>>>
>>> Tom
>>>
>>> Am 24.09.12 18:31, schrieb Tom Schindl:
>>>> hi,
>>>>
>>>> just checked out the git-repo to see what would be needed to make JavaFX
>>>> a supported technology for GEF4.
>>>>
>>>> The first thing that strikes me a bit is that the bundles:
>>>> * org.eclipse.gef4.geometry
>>>> * org.eclipse.gef4.graphics
>>>>
>>>> hold an SWT dependency. For geometry this makes no sense IMHO and this
>>>> one should not depend at all on SWT. For the graphics one I'd suggest to
>>>> split it in:
>>>> * org.eclipse.gef4.graphics
>>>> * org.eclipse.gef4.graphics.swt
>>>> * org.eclipse.gef4.graphics.awt
>>>> * org.eclipse.gef4.graphics....
>>>>
>>>> At least the SWT-Dependency should be optional else OSGi will require me
>>>> to always have org.eclipse.swt available which makes no sense if I'm
>>>> writing a pure JavaFX or Swing/AWT application.
>>>>
>>>> Having no SWT-Dependency is preferred so it is not possible at all to
>>>> introduce one.
>>>>
>>>> Like mentioned already on the bug in JavaFX one often does not uses
>>>> direct drawing but constructs a Scene-Graph of Nodes so that one can
>>>> transform, animate them inside the Scene-Graph instead of doing it on
>>>> the CPU when using DirectDrawing (Canvas).
>>>>
>>>> Should I create an new bug where I dump my JavaFX implementation? I
>>>> think in the first take I'll implement it through a JavaFX-Canvas but
>>>> ideally the final one is done as nodes inside the SceneGraph.
>>>>
>>>> Tom
>>>>
>>>
>>>
>>> --
>>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH
>>> ------------------------------------------------------------------------
>>> tom schindl geschäftsführer/CEO
>>> ------------------------------------------------------------------------
>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833
>>> http://www.BestSolution.at phone ++43 512 935834
>>> <gef_fx.png>
>>> _______________________________________________
>>> gef-dev mailing list
>>> gef-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/gef-dev
>> _______________________________________________
>> gef-dev mailing list
>> gef-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/gef-dev
>>
>
>
> --
> B e s t S o l u t i o n . a t EDV Systemhaus GmbH
> ------------------------------------------------------------------------
> tom schindl geschäftsführer/CEO
> ------------------------------------------------------------------------
> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833
> http://www.BestSolution.at phone ++43 512 935834
> _______________________________________________
> gef-dev mailing list
> gef-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/gef-dev
