Re: [platform-dev] reference swt in a maven build

[Tom Schindl via platform-dev]

just to build you can use whatever platform binary you want or what am I 
missing? To run tests you naturally have to have the correct one.


Tom

Am 22.06.21 um 10:52 schrieb Stefan Kowski:

Hi,

I am using this definitions in my standalone SWT/JFace apps:

Parent pom.xml:

     
         
             
org.eclipse.platform
org.eclipse.jface
                 3.22.100
                 
                     

                     
org.eclipse.platform
org.eclipse.swt
                     
                 
             
             
org.eclipse.platform
org.eclipse.swt.win32.win32.x86_64
                 3.116.0
                 
                     

                     
org.eclipse.platform
org.eclipse.swt
                     
                 
             
             
org.eclipse.platform
org.eclipse.swt.gtk.linux.x86_64
                 3.116.0
                 
                     

                     
org.eclipse.platform
org.eclipse.swt
                     
                 
             
             
org.eclipse.platform
org.eclipse.swt.gtk.linux.aarch64
                 3.116.0
                 
                     

                     
org.eclipse.platform
org.eclipse.swt
                     
                 
             
             
org.eclipse.platform
org.eclipse.swt.cocoa.macosx.x86_64
                 3.116.0
                 
                     

                     
org.eclipse.platform
org.eclipse.swt
                     
                 
             
         
     

Application pom.xml:

     
         
             windows
             
                 
                     windows
                 
             
             
                 
org.eclipse.platform
org.eclipse.swt.win32.win32.x86_64
                 
             
             
             
         
         
             linux-amd64
             
                 
                     Linux
                     amd64
                 
             
             
                 
org.eclipse.platform
org.eclipse.swt.gtk.linux.x86_64
                 
             
             
             
         
         
             mac
             
                 
                     mac
                 
             
             
                 
org.eclipse.platform
org.eclipse.swt.cocoa.macosx.x86_64
                 
             
             
             
         
     

I am developing using Eclipse JEE on Windows, Linux (Ubuntu) and MacOS. 
I do not know if this is the recommended way, but it works fine


Regards
Stefan


Am 22.06.2021 um 09:47 schrieb Christoph Läubrich:
I need to reference swt in a maven build (not an eclipse product!) as 
a standalone dependency.


What is the recommended way to reference swt in maven so it could be 
build on linux/windows/...


I could think about creating a profile for each os as mentioned in [1] 
and define appropriate 'osgi.platform' properties but wondering if swt 
offers something less manual or can I include some kind of swt-pom 
that already does all the magic?


[1] 
https://stackoverflow.com/questions/19023109/values-for-os-family-in-maven-profile-activation-condition 


___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev


___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] most performant way to paint a (platform-specific) pixel-array

[Tom Schindl via platform-dev]

did you look at skija which is built on top of skia is what is powering 
Chrome and Firefox so it should work very well cross-platform. On 
Windows you have the possibility to use Angle to not suffer from bad 
opengl drivers and they have a CPU mode as well.


Tom

Am 21.04.21 um 05:32 schrieb Christoph Läubrich:

Thanks Ned and Nick for the feedback.

jGL is a pure java impl so no graphics-card memory involved. This might 
sound strange, but there are two problems with the native ones:


1) I always have had issues regarding different OS, library versions, 
driver combinations and so on, and its hard to get bugfixes
2) Most of the time its hard to integrate these as SWT sadly does not 
ship e.g. with at least one "reference" implementation that could be 
used out-of-the box (lwjgl3-swt even don't integrate with default SWT 
GL...)


I also don't need ultra-high gaming performance but a solid and working 
solution cross-platform.


If you are interested take a look at the examples here 
https://github.com/jzy3d/jzy3d-api/tree/master/jzy3d-emul-gl they use 
AWT but working really well and with acceptable performance, so I 
investigate how to best port that to SWT.


Am 20.04.21 um 21:12 schrieb Ned Twigg:
There are modern-ish (Open GL 3/3.2) SWT components maintained here: 
https://github.com/LWJGLX/lwjgl3-swt 



Ned Twigg
Lead Software Engineer, DiffPlug LLC
540-336-8043 (cell)
888-513-6870 (fax)
340 S Lemon Ave #3433, Walnut, CA 91789

ᐧ

On Tue, Apr 20, 2021 at 12:09 PM Nick Edgar > wrote:


    For OpenGL stuff, you want to avoid Image / ImageData and keep as
    much of the rendering in OpenGL as possible, running on the graphics
    card. Copying memory between GPU and main memory (Java heap) will be
    slow.
    SWT has bindings to some OpenGL libraries, but I don’t think they’ve
    been updated in quite a while. Have a look though:
    https://www.eclipse.org/swt/opengl/
    

    Best, Nick
    On Apr 20, 2021, 2:15 PM -0400, Christoph Läubrich
    mailto:lae...@laeubi-soft.de>>, wrote:

    Hi Nick,

    currently I don't have any measures and just trying to collect some
    information. My use case is to integrate a software OpenGL render
    (jGL)
    and for that I need to store the rendered pixels somewhere and of
    course
    later I need to paint them.

    I just wondering if I could short-circuit some of the steps
    (imagedata>image>gc) and maybe write directly inside some kind of
    direct-buffer.

    For example if I look at

    org.eclipse.swt.graphics.Image.init(ImageData) for GTK there seem to
    happen some more action than simply keeping a reference to the image
    data, e.g. a scale factor is computed, copy of data is involved, 
color

    transformation and so on are performed.

    Maybe as you mention it does not matter, on the other hand the 
faster
    the better here (maybe) this also is a bit depending on the 
effort to
    make this happen here of course but I'd like to investigate a bit 
if I

    should take some internals into account before starting to
    implement the
    actual thing.


    Am 20.04.21 um 19:19 schrieb Nick Edgar:

    Hi Christoph,

    That approach is generally the recommended way to paint images

> in 


    SWT. Painting of a pre-created Image should be as fast as the OS
    allows.
    Have you measured the times involved? Which phase do you need to
    speed up:

    1. creating ImageData,
    2. creating Image from ImageData, or
    3. painting Image?

    If 1, see if you can directly manipulate the ImageData’s data, or
    using
    setPixels

>. 


    If 2, check which image format you’re using — it may not map
    directly to
    the native display, and thus be expensive to convert.
    If 3, I’d be surprised, but it would be good to know details and 
the

    times for 1,2,3.

    Best, Nick
    On Apr 19, 2021, 5:20 AM -0400, Christoph Läubrich
    mailto:lae...@laeubi-soft.de>>, wrote:

    I have a pixel-buffer and like it o be painted in the most
    performant
    way onto a SWT Canvas.

    Current approach is to convert this into an ImageData, create an
    image
    and then paint it inside PaintListener to the GC.

    Is there a way to avoid this intermediate steps? I won't mind if
    I need
    to provide platform-specific implementations if it is possible
    to gain
    

Re: [platform-dev] canonical way to handle optional dependencies

[Tom Schindl via platform-dev]

Hi,

An option to ban the offending guy from the codebase would be to move 
the offending class to a fragment.


Let's say we have

MyBundle
  + my.class.UILeaker
- methodA(String)
- methodB(String)
- leakMethod(Shell)

We could refactor it to:

---8<---
MyBundle
  + my.class.NoLeak
- methodA(String)
- methodB(String)

MyBundleCompatFragment
  + my.class.UILeaker extends my.class.NoLeak
- leakMethod(Shell)
---8<---

Your fragment needs to provide a Eclipse-ExtensibleAPI in the MANIFEST, 
as the fragment but this would make your bundle free from the optional 
requires (the fragment would require the UI stuff) and as Host and 
Fragment share the same classloader you could even call package-scoped 
APIs from the fragment.


Tom

Am 15.04.21 um 15:42 schrieb Jonah Graham:
Thanks Alex for the insights. This is one of those APIs that I don't 
think is used in practice (but you can never be sure). CDT adopted the 
same API deletion process as Platform, so we can delete it without the 
major version bump. Therefore using new methods may be a good solution 
to handle the period between deprecation and deletion.


Jonah


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com 


On Thu, 15 Apr 2021 at 09:36, Alex Blewitt > wrote:


On 15 Apr 2021, at 14:05, Jonah Graham mailto:jo...@kichwacoders.com>> wrote:
 >
 > Most of the dependencies on the UI are relatively easy to
resolve. However one area is in the API - the API includes
references to org.eclipse.ui.dialogs.IOverwriteQuery, and in the
headless case these references are null.

The problem is that if it is part of the API (ie method argument,
return value) then the class has to be loaded in order to call that
method, even with a null value. If you attempt to call this method
then it will attempt to load the ui class and when it’s not found it
will raise a ClassNotFound error (or similar).

In order to fix it you’ll need to change the API to take a more
generic object (like Object) which will allow you to call the method
with a null value, and you can pass through the untyped value to
where it needs to be used, casting it at the point of use (or using
a reflective call that obscure the types).

You may find the right evolution path is to create a second method
with the same signature but using Object in place, migrating the
code paths to that method, and leaving a call path from the old to
the new. You can then mark the old API as deprecated and invite
callers to move over to the new call.

Using the same method name has both advantages and disadvantages; if
you are calling with null then you’ll need to disambiguate by
casting to Object but might facilitate changeover when you delete
the old method; if you use a new name then callers will have to
change source code to take advantage of the changed api but will
likely be easier to determine if code has been moved from old to new
patterns.

In either case it is a new method signature which won’t be source
compatible for old callers, so it’s probably a major version bump
when you remove the old call path.

Alex
___
platform-dev mailing list
platform-dev@eclipse.org 
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev



___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev


___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Extensibility of the application model

[Tom Schindl via platform-dev]

Hi,

I tend to disagree that we only want to contribute static data, if we 
use a service approach, we could eg in future add Predicate-Support (eg 
only merge that feature if you starting on locale-xyz, ...).


I think we should provide ONE extension story and not multiple who are 
not really supported and frankly looking at PDE I don't see the manpower 
to support yet another case.


One thing I like about DS is that it can be easily supported outside 
OSGi and there are already multiple implementations doing it (we have 
one as part of efxclipse, an internal one and IIRC there's another one 
from the OSGi-Community).


Your point of activation is correct but frankly it's not our job to 
solve all problems the rest of the world. It should be clear to already 
today to any decent dev that they should not do stuff in their Activator 
blocking the bundles from starting.


Anyways it's up to the active committers to decide where to go.

Tom

Am 15.04.21 um 08:24 schrieb Christoph Läubrich:

First of all, as mentioned before, DS is an implementation detail!

Actually extensions can be registered by anything else (Activators, CDI, 
BluePrint, Remote Service API...) and are just services.


The disadvantage of a service when we are talking about static meta-data 
like a fragement.xml is that a service always requires an active/started 
bundle and as a consequence the creation of classloader, and probably 
initialization of other services and bundles.


On the other hand, Manifest-headers could be inspected even for 
unresolved bundles and are widely used in OSGi (DS uses it, JPA Spec 
uses it and probably more), some of the using detaults (e.g. we could 
declare "/fragment.xml" as the default and make the header obsolete for 
the common case).


Beside that, creating an implementation, registering it as a service 
just to return a static string (we can't even profit from any typesafty 
or compiler checks here) does not sound very clever.
Instead some tooling that detects *.e4xmi files in the project and offer 
to add it to the Manifest-header or warning a users if path mismatches 
would be much ore helpful.


About the confused user (as this was brought up recently in another 
discussion also), we better improve the tools than trying to adjust 
technical implementation details to follow a vague 'user expectation', 
especially in case of fragment.xml there is a wizard already that setup 
everything for the user. If that's not visible enough we should improve 
the tooling.



Am 15.04.21 um 08:01 schrieb Dirk Fauth via platform-dev:

Hi all,

I have recently contributed a new way to extend the application model 
via fragment and processor that avoids the usage of the extension 
point. A model processor can be registered via DS, a model fragment 
can now be registered via a Manifest header.


Mickael and Tom have now mentioned on the ticket that the Manifest 
header solution for registering a fragment introduces a new way to 
extend the application model, which could be confusing for a user. 
Instead we should stick with one replacement for the extension points, 
which is the usage of DS.


The initial proposal was to have a service that simply provides the 
static information for registering the model fragment. In the review 
process this was changed to the Manifest header solution to follow the 
OSGi best practices as static information inside a bundle does not 
need to be provided by a service.


The goal of the new extension is to get rid of the extension points as 
I already mentioned. The nice side effect is that with this change it 
is even possible to handle dynamics, e.g. add/remove model elements 
like parts and menus on installing/uninstalling bundles. This actually 
works already for parts, but still needs some work for other stuff 
like menu contributions. But I need some support on the model side, as 
I am not that deeply familiar with this.


As there is now a discussion in the ticket whether to use DS only or 
keep the Manifest header, I would like to move the discussion to the 
mailing list. IMHO both ways have their advantages and disadvantages. 
Technically both ways are possible AFAICS.


Please discuss and let me know which way to go. The Manifest header 
solution is currently in the code base (see ModelAssembler). The DS 
solution could be restored/implemented with also not too much work. I 
would really like to get the new extensibility in, but of course it 
should be a solution that the majority of the Platform committers 
share. We are not yet in the code freeze phase, so I would be able to 
change it if that is the decision.


For more details have a look at the Bugzilla entry and the patches in 
Gerrit.


https://bugs.eclipse.org/bugs/show_bug.cgi?id=571866 

https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/177574 

Re: [platform-dev] GraalVM native-image with SWT

[Tom Schindl]

Not me but I saw that on twitter - 
https://twitter.com/mickaelistria/statuses/1311954684580712448

Tom

Von meinem iPhone gesendet

> Am 16.10.2020 um 21:55 schrieb Thomas Singer :
> 
> Hi all,
> 
> Does someone of you successfully compiled a (tiny) SWT application to a 
> native-image (AKA native executable) using GraalVM?
> 
> -- 
> Best regards,
> Thomas Singer
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Inconsistent version change in SWT 4.18

[Tom Schindl]

Von meinem iPhone gesendet

> Am 11.10.2020 um 17:26 schrieb Gregor Schmid :
> 
> 
> Hi Wim,
> 
> it's easy to dismiss my case as special. Every other case will be
> special too. My specific case is just an example and as I said, I've
> already got my workaround. But the issue requires updating code that
> was valid up to this point and we can't tell how many downstream tools
> and users will be affected.
> 
> When you say
> 
>> You should probably revisit your algorithm.
> 
> what do you suggest? If whatever convention in place is allowed to
> break so easily it becomes impossible to write an algorithm that can
> be relied on to reasonably interpret future SWT version numbers. In
> such a case it's easier to just create a map and update it every three
> months.
> 

Well if you know the Class you know the classloader and then you should be able 
to read the MANIFEST.MF - if you run in OSGi you should be able to even 
leverage OSGi APIs but to get access to those information your agent probably 
has to reside to reflection because your current classloader 
(systemclassloader?) does not has access to it (the class you are looking at 
although has)

>> The versioning scheme is not etched in stone.
> 
> Of course the scheme may change. But it should do so only for a good
> reason and after discussion. It should not be allowed to break by
> accident.
> 
> Thanks for your further suggestions. I'm not asking for a milestone
> respin, just that it gets fixed before 4.18 final.
> 
> I've filed bug report 567789. I know nothing about Gerrit so that's as
> much as I can do.
> 
> Thanks and best regards,
>Greg
> 
>> Hey Greg,
>> 
>> (I am not part of the releng team so all of this is just what I would do if
>> I was in a similar situation.)
>> 
>> This is a very specific use case. You should probably revisit your
>> algorithm. The versioning scheme is not etched in stone.
>> 
>> I don't know if this can get included for M1a on Monday. But even if it
>> can, in the future, I doubt if your use case is strong enough to call for a
>> milestone respin.
>> 
>> To increase your chances that this gets included in M1a, I suggest you file
>> a bug and prepare a Gerrit. Again, I am not part of the releng team but
>> this is what I would do, especially on a Sunday :)
>> 
>> Cheers,
>> 
>> Wim
>> 
>> 
>> 
>>> On Sun, Oct 11, 2020 at 11:51 AM Gregor Schmid  wrote:
>>> 
>>> 
>>> Hi Sravan,
>>> 
>>> thanks a lot for getting back.
>>> 
>>> I don't really know enough about the Eclipse CI system to comment, but
>>> speaking in general, if an automated build script fails half way I
>>> would expect a hard reset of HEAD to the previous commit before
>>> rerunning the script.
>>> 
>>> Anyway, my use case is as follows:
>>> 
>>> Our tool QF-Test does UI test automation for Eclipse/SWT applications.
>>> To that end we need to instrument SWT code. In earlier versions (this
>>> goes back to Eclipse 3.1) this was done by replacing the SWT jar,
>>> nowadays we use a Java agent to just swap the few classes we need to
>>> modify at runtime. Lest anybody wonders, the whole thing is
>>> license-conform and we make our patches publicly available via gitlab:
>>> 
>>> https://gitlab.com/qfs/qfs-swt-patches
>>> 
>>> So we're now shipping QF-Test with SWT instrumentation jars for SWT
>>> versions ranging from 3.7 to 4.17 with 4 versions added per year.
>>> 
>>> My specific problem is that when QF-Test encounters an swt.jar file
>>> for instrumentation or an SWT class being loaded at runtime it needs
>>> to find out which SWT version that is in order to determine the
>>> required instrumentation classes. The only reliable way to do that is
>>> getting hold of the SWT Library class and reading its version numbers.
>>> And then we map those numbers to version names like '4.17' and
>>> '2020-09'. With the skipped MINOR_VERSION my code now mixes up 4.18
>>> and 4.19.
>>> 
>>> It's easy to fix or work around, of course, but my case is just one
>>> example and there's a lot of code out there based on or working
>>> against SWT. I'm a big fan of maintaining consistency and I think that
>>> all such tools as well as code using SWT.getVersion() require and
>>> deserve consistent version numbering.
>>> 
>>> I'd be very happy If this could still be fixed. 4.18M1 now stands at
>>> 4940R9. If you fix that now and change it to 4938R* and later take
>>> care to start the real 4.19 with 4940R10 or higher there won't be any
>>> duplicates and the only misnumbered releases will be a few early-stage
>>> 4.18 releases nobody cares about instead of all official releases
>>> starting with 4.18.
>>> 
>>> Thanks for considering it and best regards,
>>>Greg
>>> 
>>> "Sravan K Lakkimsetti"  writes:
>>> 
 Hi Gregor,
 
 We have a job to upgrade the version number for each release. The problem
 here is that job failed when we ran
 https://ci.eclipse.org/releng/job/SWT-new-release/19/ . Se we had to run
 the job again to get the version numbers set 

Re: [platform-dev] Creating a whiteboard pattern for IResourceChangeListener

[Tom Schindl]

Hi Alex,

Maybe I'm totally wrong but I think I remember that early initialization 
of Resources-Plugin via by DS stuff caused problems in the past because 
the workspace-selection dialog did not come up any more (something you 
don't spot when running with an inner-eclipse).


Maybe I'm totally wrong and as it's been a looong time since I hacked 
the Eclipse Platform so if what say is BS just ignore it ;-)


Tom

Am 02.07.20 um 17:58 schrieb Alex Blewitt:

Hi everyone,

I’ve proposed a change at 
https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/165750 to 
provide a way of registering IResourceChangeListener instances via an 
OSGi service rather than an explicit call to IWorkspace.


There’s lots of calls in projects that look something like:

ResourcesPlugin.getWorkspace().addResourceChangeListener(resourceChangeListener);

This has an ordering dependency that the workspace needs to be running 
before this registration occurs. Of course, if the workspace doesn’t 
exist at this point we aren’t going to be receiving any events but we’d 
like to be able to start them in either order.


If we use the OSGi whiteboard pattern, we can turn it on its head and do:

context.registerService(resourceChangeListener, 
IResourceChangeListener.class);


(We do something similar in many places for DebugOptions.)

Now we have decoupled the start order dependency, and with the change 
above we’ll now pick up the binding when the resources plugin is 
available, and will automatically deregister when either service goes away.


We can also use this to register the listeners via DS:


http://www.osgi.org/xmlns/scr/v1.4.0; immediate="true" 
name="ExampleResourceListener">


   





The additional properties on the service will allow a subset of the 
event types to be passed in (in this case, 1 == POST_BUILD). There is a 
minor disadvantage in that this is an integer rather than a compile-time 
constant reference, though if the registration in code is used you can 
have a Dictionary including IResourceChangeEvent.POST_BUILD as the key 
in the dictionary.


This approach of having a whiteboard pattern (either DS or 
ServiceTracker) for listeners could be replayed on other listener types 
as well; but from what I can tell, the IResourceChangeListener is the 
most popular in hooking together the world.


Arguably it might be more ‘OSGi’ to attempt migrating the 
IResourceChangeEvent to an OSGi EventAdmin topic, but that would require 
more invasive dependency and code changes than exists at the moment. 
Having everything in DS means that we can start the components lazily 
and avoid the use of Activators, which will certainly help with the 
start-up times.


Thoughts?

Alex

___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev


___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Marking nested projects as derived, what are the risks?

[Tom Schindl]

Hi,

I think the only correct solution is to enhance the core API and then adjust 
all components. Is it a lot of work? yes! But I think it is the only viable 
long term solution.

Tom

Von meinem iPhone gesendet

> Am 22.01.2020 um 09:34 schrieb Mickael Istria :
> 
> 
> Hi all,
> 
> So I'm making progress in my thoughts around those issues.
> What about hidden resources? To rephrase "Marking folders for nested projects 
> as hidden, what are the risks?"
> 
> I'm not really sure of what hidden implies under the hood, but the 
> documentation seems pretty flexible in usage. Maybe it's just the exact match 
> for nested projects? m2e has is available as "Experimental", and Till found a 
> few (fixable) issues in 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=500624#c14 . Before investing 
> more in trying to fix some of those issues, I'd like some other opinions on 
> whether it seems like a good track to follow.
> 
> Thanks in advance
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Generic Text Editor for pure E4

[Tom Schindl]

Hi,

All I can throw into this discussion is
https://github.com/BestSolution-at/code-swt - It was a PoC which i did
not worked on afterwards.

In the end all main building blocks for editors are in
eclipse.text/jface.text who does not depend on any compat-layer APIs.

Tom

On 04.07.19 10:04, Mickael Istria wrote:
> Hi,
> 
> See below a few question, and then some ideas.
> 
>> the core of the Generic Text Editor is not dependent on E3.
> 
> Can you please elaborate what you specifically mean by this? I'm not a
> e4 user myself (not really interested in it for my IDE-related work
> since e3 just does the job quite well), so I'm genuinly curious about
> what specific criteria are to check to claim something is dependent on
> e3 or not.
> Are there already stories of the Platform TextEditor working on plain E4
> without E3? As long as it's not there, then we cannot really imagine
> moving downstream to the Generic Editor.
> Also, what is the issue shipping pieces of e3 in an e4 app?
> 
>> trying to remove E3 dependencies from the Generic Text Editor.
>> [...]
>> I browsed the code of the "ExtensionBasedTextEditor"
> 
> I confirm this is probably quite hard, I guess the type hierarchy of the
> editor itself (and it means a lot as parent are providing a lot of the
> value) is full of e3 APIs. But maybe I'm wrong on the type stack for the
> Generic Editor is already ready.
>  
> 
> but we can gain a lot from this.
> 
> 
> Can you please give example of use-case that E4 enables easily that are
> impossible or very hard to implement with e3 APIs?
> 
>> The Generic Text Editor may be a good starting point: it has a lot of
> services to interact with and it will be natural to utilize OSGi
> services and E4 approach.
> 
> If you want to add support for OSGi Services additionally to extension
> point in the current Generic Editor, that would be welcome, since it
> wouldn't reduce the feature set nor break backward compatibility.
> About using the e4 approach, then it seems to me you mean "ability to
> load extensions with e4 annotations". It also seems like something that
> can be done, if it's not already there.
> 
> Can a pure E4 generic editor be backward-compatible with the current one
> (read extensions and process them similarly, and have the same feature
> set)? If yes, then I would recommend migrating the porting Generic
> Editor rather than creating a new one. If we have both, then it's twice
> more maintenance cost, the IDE will keep the legacy one that just works
> for it and both editors will ultimately diverge, and given the
> priorities of the community regarding text edition (mostly the IDE),
> there will be new features in the current Generic Editor that won't be
> implemented in the pure-e4 one and the pure-e4 one will get obsolete and
> will conclude as an expensive unsuccessful experiment.
> For this reason, I'm personally -1 to have Platform hosting a new editor
> for this, however, I'm +1 in making the Generic Editor as much
> e4-friendly as possible (as long as it doesn't have any negative impact).
> 
> Cheers,
> 
> 
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Fwd: [jakartaee-platform-dev] about the status of atinject

[Tom Schindl]

Hi,

I forward this here to make you aware that there's a proposal to fork
JSR-330 (javax.inject) into the JakartaEE, while we are not immediately
affected (we can stick with javax.inject) we have a JSR-330 compatible
implementation and there's the potential for fragmentation if the
namespaces is changes.

Tom

 Forwarded Message 
Subject: Re: [jakartaee-platform-dev] about the status of atinject
Date: Fri, 10 May 2019 18:53:09 +0200
From: Mark Struberg 
Reply-To: jakartaee-platform developer discussions

To: jakartaee-platform developer discussions

CC: Antoine Sabot-Durand 

Hi Tom!

Yes, this is surely something to take into consideration.

Would the JCP maintain atinject? My answer is: no
We tried to have smallish additions for CDI-2.0 and also already had
talks with a few of the involved people.
ccing Atoine because he also has a stance in this story and it would be
great if he also might share his opinion on the topic.
Back then it was not possible to change anything as the EG did not come
to live up again and Oracle doesn't own anything for atinject. So they
simply will not touch it - likely ever. This is not legally an actual
problem but only an extremely defensive position on Oracle side. Which
is perfectly fine from their pov. Happy to be proven wrong, but I don't
think this is likely to change.

So no, if there will ever be a change necessary, then we need other ways
to deal with it for CDI, EJB, etc.

Otoh the compatility with javax.inject.Inject is practically deminished
to people being familiar with the annotations.
Not much more. That's because an application or library written for CDI
will never run on Spring or picoContainer. Or vice versa. Also moving
javax.inject to jakarta.inject only for Jakarta will still allow all the
other libs to use javax.inject IF they want. Ideally even allowing
co-existance.

Makes sense?

LieGrue,
strub

> Am 10.05.2019 um 09:08 schrieb Tom Schindl :
> 
> Hi,
> 
> I fully understand your desire to get atInject changed but I'm not
> really happy if atInject gets forked because it is not only used in
> Spring/JavaEE applications but in simple Java-Applications via Google
> Guice or Eclipse DI to name 2 libraries implementing the standard.
> 
> Forking it means that you potentially put pressure not only to EE world
> but the rest of the Java ecosystem. If I'm not wrong it is still
> possible to evolve atInject but you need to keep it in the JCP, would
> that be the better way to go for atInject.
> 
> I fully understand that those frameworks could still use the "legacy"
> javax-namespace but you open the door for fragmentation in a part of the
> java ecosystem who would not have been affected at all!
> 
> Tom
> 
> On 10.05.19 08:10, Christian Kaltepoth wrote:
>> I'm also +1 for integrating AtInject into Jakarta EE.
>> 
>> And +1 for contacting the former EG first. 
>> 
>> Am Fr., 10. Mai 2019 um 05:57 Uhr schrieb Josh Juneau
>> mailto:juneau...@gmail.com>>:
>> 
>>   +1 on forking for Jakarta EE.
>> 
>>   Josh Juneau
>>   juneau...@gmail.com <mailto:juneau...@gmail.com>
>>   http://jj-blogger.blogspot.com <http://jj-blogger.blogspot.com/>
>>   https://www.apress.com/us/search?query=Juneau
>> 
>>   On May 9, 2019, at 4:01 PM, Mark Struberg >   <mailto:strub...@apache.org>> wrote:
>> 
>>> 
>>> 
>>>>   Am 09.05.2019 um 21:54 schrieb Mike Milinkovich
>>>>   >>>   <mailto:mike.milinkov...@eclipse-foundation.org>>:
>>>> 
>>>>   The patent grant in the ALv2 is far, far weaker than the patent
>>>>   grants in the Jakarta EE Spec Process.
>>> 
>>>   This is a very broad argument and we should rather clarify this to
>>>   avoid confusing non legally trained readers.
>>> 
>>>   I personally strongly believe that the patent grant in the ALv2 is
>>>   absolutely sufficient.
>>>   The main difference afaict is that for some older specs Oracle
>>>   wanted to sign over patents to them, while the ALv2 only _grants_
>>>   patent licenses to *every* downstream consumer [1]. So the ALv2
>>>   patent grant is - in my eyes - evenmore aligned with the new
>>>   Jakarta Specification License than the old (imo overreaching)
>>>   handling. It's also way more practical also in hindsight of tax law.
>>> 
>>>   Anyway, since I don't believe that there are any patents filed for
>>>   atinject stuff anyway it is hopefully a merely theoretical
>>>   discussion. So I will stop here.
>>> 
>>>   And first we need to focus on whether JakartaEE is interested to
>>>   fork atinject at all - from a purely business demand point 

Re: [platform-dev] Need to add a fixed bottom pane

[Tom Schindl]

Look at E4Workbench there is a constant RENDERER_FACTORY_URI which
defaults to ...WorkbenchRendererFactory. You need to subclass
WorkbenchRendererFactory and provide the framework your custom URL.

You can do that via:
* plugin.xml
* command-line parameters

Take a look at E4Application to findout how this is done.

Tom

On 10.05.19 18:28, Arian Fornaris wrote:
> Hi Tom, thanks for the quick replay.
> 
> 
> Do you have any tip about how to say Eclipse to use my custom WBWRenderer?
> 
> 
> Arian
> 
> 
> 
> On 5/10/19 12:17 PM, Tom Schindl wrote:
>> You need to write a custom WBWRender
>>
>> Tom
>>
>> Von meinem iPhone gesendet
>>
>> Am 10.05.2019 um 18:02 schrieb Arian Fornaris > <mailto:boniati...@gmail.com>>:
>>
>>> Hi,
>>>
>>> How can I add a bottom panel (Composite) to the Eclipse IDE
>>> workbench? I need to implement something similar to the perspective
>>> switcher but with bigger icons and custom layout, and custom widgets.
>>> I was trying to use the IDE status toolbar bit it really does not
>>> look well for my purpose. I need big buttons and custom layout.
>>>
>>> I tried by adding a view at the bottom of the IDE but I don't have
>>> full control of the view height and honestly, it was not possible to
>>> remove the "tab" from the view and make it fixed. It only worked to
>>> me if the perspective is marked as fixed too.
>>>
>>> As I know, since Eclipse 4 the UI renderer is independent from the UI
>>> model, and there are projects like Efxclipse that uses JavaFX as
>>> renderer, so I don't know if I can extends default SWT renderer and
>>> add a bottom pane.
>>>
>>>
>>> Thanks in advance,
>>>
>>> Arian
>>>
>>>
>>> P.S. I attach an image here of what I need.
>>>
>>>
>>> 
>>>
>>> ___
>>> platform-dev mailing list
>>> platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>
>>> To change your delivery options, retrieve your password, or
>>> unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] After addingorg.eclipse.osgi.services_3.7.100.v20180827-1536.Jar in bundle all my DM annotation stopped working

[Tom Schindl]

> Alexander Kurtakov
>>> Red Hat Eclipse Team
>>> ___
>>> platform-dev mailing list
>>> platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>
>>> To change your delivery options, retrieve your password, or
>>> unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>>
>>>
>>>
>>> -- 
>>> *Thanks\
>>> **Abhijeet Banerjee
>>> +919910512611*
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> platform-dev mailing list
>>> platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>
>>> To change your delivery options, retrieve your password, or unsubscribe 
>>> from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/platform-dev
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
>>
>>
>> -- 
>> *Thanks\
>> **Abhijeet Banerjee
>> +919910512611*
>>
>>
>>
>>
>>
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
> 
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] [platform-swt-dev] SWT-GTK3 bugs for 4.9

[Tom Schindl]

Hi,

Just a small heads up! Oracle really provides a backport for Gtk3
support in Java8u...!

See
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-October/022603.html

Tom

On 07.06.18 21:15, Tom Schindl wrote:
> Hi,
> 
> I brought up the Gtk2 problem to openjfx-dev and there's a chance that
> Oracle backports the Gtk3 fixes from Java9 to Java8.
> 
> See http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/021988.html
> 
> Tom
> 
> On 06.06.18 09:32, Tom Schindl wrote:
>> Hi,
>>
>> JavaFX has different components, the one we are talking about is the
>> glass-layer [1]. It's the responsibility of this layer to integrate into
>> the windowing system of your OS. There's implementation for each
>> supported OS ranging from iOS to linux where Gtk2 is used.
>>
>> Tom
>>
>> [1]http://hg.openjdk.java.net/openjfx/8u/rt/file/4d46b5956d59/modules/graphics/src/main/native-glass
>>
>> On 06.06.18 08:40, Aleksandar Kurtakov wrote:
>>>
>>>
>>> On Fri, Jun 1, 2018 at 6:13 PM, Aleksandar Kurtakov >> <mailto:akurt...@redhat.com>> wrote:
>>>
>>>
>>>
>>> On Fri, Jun 1, 2018 at 6:02 PM, Tom Schindl
>>> mailto:tom.schi...@bestsolution.at>>
>>> wrote:
>>>
>>> For JavaFX the statement is 100% true and this means anything
>>> using GEF
>>> 4 and later won't work anymore.
>>>
>>>
>>> I have no idea about that. Do you care to share technical details
>>> why this is the case?
>>>
>>>
>>> I'm really interested in hearing what the issue is but if no one care to
>>> explain give links to bugzilla and etc. I wouldn't have a choice but to
>>> assume this is smth that has already be fixed.
>>>  
>>>
>>>  
>>>
>>>
>>> I'd also like to state that I personally have no problem with
>>> dropping
>>> Gtk3 but I know many many projects who JavaFX-SWT-Interopt and
>>> without
>>> Gtk2 their Linux story is gone. So yes you could say I
>>> exaggerated for
>>> Swing but I did not for JavaFX.
>>>
>>> Anyways I'm not here to lobby anything but wanted to inform you that
>>> this decision (which I don't question makes sense technically, man
>>> powerwise, ...) could cause problems for (Eclipse) downstream
>>> projects.
>>>
>>>
>>> Furthermore, by the time this happens Java 11 (next LTS) will be out
>>> so there will be LTS Java version with proper JavaFX and GTK3 story.
>>> And thanks for jumping in  -  this is exactly the reason why this
>>> mail was posted to provoke people to either step up in helping with
>>> daily tasks or/and keep up their projects/products according to the
>>> manpower available.
>>>  
>>>
>>>
>>> Tom
>>>
>>> On 01.06.18 16:48, Aleksandar Kurtakov wrote:
>>> > 
>>> > 
>>> > On Fri, Jun 1, 2018 at 5:42 PM, Tom Schindl 
>>> mailto:tom.schi...@bestsolution.at>
>>> > <mailto:tom.schi...@bestsolution.at
>>>     <mailto:tom.schi...@bestsolution.at>>> wrote:
>>> > 
>>> >     IIRC it depends on the theme you use in swing!
>>> > 
>>> > 
>>> > So in this case, it's not ruling out pre Java 9 Swing integration 
>>> as
>>> > it's a matter of not using Gtk LnF which should be possible to 
>>> even
>>> > ensure in SWT_AWT if needed. Your statement seem to be way 
>>> exaggerated.
>>> >  
>>> > 
>>> > 
>>> >     Tom
>>> > 
>>> >     On 01.06.18 16:39, Aleksandar Kurtakov wrote:
>>> >     > 
>>> >     > 
>>> >     > On Fri, Jun 1, 2018 at 5:31 PM, Tom Schindl 
>>> mailto:tom.schi...@bestsolution.at>
>>> <mailto:tom.schi...@bestsolution.at
>>> <mailto:tom.schi...@bestsolution.at>>
>>> >     > <mailto:tom.schi...@bestsolution.at
>>> <mailto:tom.schi...@bestsolution.at>
>>> <mailto:tom.schi...@bestsolution.at
>>> <mailto:tom.schi...@bestsolution.at>

Re: [platform-dev] [platform-swt-dev] SWT-GTK3 bugs for 4.9

[Tom Schindl]

Hi,

JavaFX has different components, the one we are talking about is the
glass-layer [1]. It's the responsibility of this layer to integrate into
the windowing system of your OS. There's implementation for each
supported OS ranging from iOS to linux where Gtk2 is used.

Tom

[1]http://hg.openjdk.java.net/openjfx/8u/rt/file/4d46b5956d59/modules/graphics/src/main/native-glass

On 06.06.18 08:40, Aleksandar Kurtakov wrote:
> 
> 
> On Fri, Jun 1, 2018 at 6:13 PM, Aleksandar Kurtakov  <mailto:akurt...@redhat.com>> wrote:
> 
> 
> 
> On Fri, Jun 1, 2018 at 6:02 PM, Tom Schindl
> mailto:tom.schi...@bestsolution.at>>
> wrote:
> 
> For JavaFX the statement is 100% true and this means anything
> using GEF
> 4 and later won't work anymore.
> 
> 
> I have no idea about that. Do you care to share technical details
> why this is the case?
> 
> 
> I'm really interested in hearing what the issue is but if no one care to
> explain give links to bugzilla and etc. I wouldn't have a choice but to
> assume this is smth that has already be fixed.
>  
> 
>  
> 
> 
> I'd also like to state that I personally have no problem with
> dropping
> Gtk3 but I know many many projects who JavaFX-SWT-Interopt and
> without
> Gtk2 their Linux story is gone. So yes you could say I
> exaggerated for
> Swing but I did not for JavaFX.
> 
> Anyways I'm not here to lobby anything but wanted to inform you that
> this decision (which I don't question makes sense technically, man
> powerwise, ...) could cause problems for (Eclipse) downstream
> projects.
> 
> 
> Furthermore, by the time this happens Java 11 (next LTS) will be out
> so there will be LTS Java version with proper JavaFX and GTK3 story.
> And thanks for jumping in  -  this is exactly the reason why this
> mail was posted to provoke people to either step up in helping with
> daily tasks or/and keep up their projects/products according to the
> manpower available.
>  
> 
> 
> Tom
> 
> On 01.06.18 16:48, Aleksandar Kurtakov wrote:
> > 
> > 
> > On Fri, Jun 1, 2018 at 5:42 PM, Tom Schindl 
> mailto:tom.schi...@bestsolution.at>
> > <mailto:tom.schi...@bestsolution.at
> <mailto:tom.schi...@bestsolution.at>>> wrote:
> > 
> >     IIRC it depends on the theme you use in swing!
> > 
> > 
> > So in this case, it's not ruling out pre Java 9 Swing integration as
> > it's a matter of not using Gtk LnF which should be possible to even
> > ensure in SWT_AWT if needed. Your statement seem to be way 
> exaggerated.
> >  
> > 
> > 
> >     Tom
> > 
> >     On 01.06.18 16:39, Aleksandar Kurtakov wrote:
> >     > 
> >     > 
> >     > On Fri, Jun 1, 2018 at 5:31 PM, Tom Schindl 
> mailto:tom.schi...@bestsolution.at>
> <mailto:tom.schi...@bestsolution.at
> <mailto:tom.schi...@bestsolution.at>>
> >     > <mailto:tom.schi...@bestsolution.at
> <mailto:tom.schi...@bestsolution.at>
> <mailto:tom.schi...@bestsolution.at
> <mailto:tom.schi...@bestsolution.at>>>>
> >     wrote:
> >     >
> >     >     Hi,
> >     >
> >     >     This means you'll rule out all pre Java9 code who
> uses the
> >     >     Swing-Integration and JavaFX? IIRC only Java9+ is
> able to run on Gtk3.
> >     >
> >     >
> >     > I happily run SWT_AWT on OpenJDK Runtime Environment (build
> >     > 1.8.0_171-b10) so that seems to not be true.
> >     >  
> >     >
> >     >
> >     >     Tom
> >     >
> >     >     On 30.05.18 21:31, Aleksandar Kurtakov wrote:
> >     >     >
> >     >     >
> >     >     > On Wed, May 30, 2018 at 9:55 PM, Eric Williams
> mailto:ericw...@redhat.com>
> <mailto:ericw...@redhat.com <mailto:ericw...@redhat.com>>
> >     <mailto:ericw...@redhat.com <mailto:ericw...@redhat.com>
> <mailto:ericw...@redhat.com <mailto:ericw...@redhat.com>>>
> >     >     > <mailto:ericw...@redhat.

Re: [platform-dev] [platform-swt-dev] SWT-GTK3 bugs for 4.9

[Tom Schindl]

IIRC it depends on the theme you use in swing!

Tom

On 01.06.18 16:39, Aleksandar Kurtakov wrote:
> 
> 
> On Fri, Jun 1, 2018 at 5:31 PM, Tom Schindl  <mailto:tom.schi...@bestsolution.at>> wrote:
> 
> Hi,
> 
> This means you'll rule out all pre Java9 code who uses the
> Swing-Integration and JavaFX? IIRC only Java9+ is able to run on Gtk3.
> 
> 
> I happily run SWT_AWT on OpenJDK Runtime Environment (build
> 1.8.0_171-b10) so that seems to not be true.
>  
> 
> 
> Tom
> 
> On 30.05.18 21:31, Aleksandar Kurtakov wrote:
> > 
> > 
> > On Wed, May 30, 2018 at 9:55 PM, Eric Williams  <mailto:ericw...@redhat.com>
> > <mailto:ericw...@redhat.com <mailto:ericw...@redhat.com>>> wrote:
> > 
> >     Hello everyone,
> > 
> >     4.8 is almost done and many GTK3 bugs have been fixed. For 4.9, we
> >     are again focusing on GTK3 bugs and performance issues.
> > 
> >     If you are running SWT/Eclipse on GTK2, please try with GTK3 as we
> >     are trying to root out all SWT bugs which prevent GTK2 users from
> >     switching to GTK3. If you already filed a bug awhile ago, please
> >     feel free to email/CC me as a reminder -- we have a backlog of old
> >     bugs so sometimes these things slip through the cracks.
> > 
> >     We also have the 4.9 GTK3 bug tracker which can be found here:
> >     https://bugs.eclipse.org/bugs/show_bug.cgi?id=535255
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=535255>
> >     <https://bugs.eclipse.org/bugs/show_bug.cgi?id=535255
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=535255>>
> > 
> > 
> > It's worth noting that GTK 2 support will be dropped as soon as work
> > towards supporting GTK 4 starts so please stop using GTK 2 backend.
> >  
> > 
> > 
> > 
> >     Thanks,
> > 
> > 
> >     -- 
> >     Eric Williams
> >     Software Engineer - Eclipse/SWT Team
> >     Red Hat
> >     ___
> >     platform-swt-dev mailing list
> >     platform-swt-...@eclipse.org
> <mailto:platform-swt-...@eclipse.org>
> <mailto:platform-swt-...@eclipse.org
> <mailto:platform-swt-...@eclipse.org>>
> >     To change your delivery options, retrieve your password, or
> >     unsubscribe from this list, visit
> >     https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
> <https://dev.eclipse.org/mailman/listinfo/platform-swt-dev>
> >     <https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
> <https://dev.eclipse.org/mailman/listinfo/platform-swt-dev>>
> > 
> > 
> > 
> > 
> > -- 
> > Alexander Kurtakov
> > Red Hat Eclipse Team
> > 
> > 
> > ___
> > platform-dev mailing list
> > platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>
> > To change your delivery options, retrieve your password, or unsubscribe 
> from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/platform-dev
> <https://dev.eclipse.org/mailman/listinfo/platform-dev>
> >
> ___
> platform-dev mailing list
> platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/platform-dev
> <https://dev.eclipse.org/mailman/listinfo/platform-dev>
> 
> 
> 
> 
> -- 
> Alexander Kurtakov
> Red Hat Eclipse Team
> 
> 
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/platform-dev
> 
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] E4 model persisted (randomly)

[Tom Schindl]

Yes there is a timer running (and there's even preference value). My
guess is that the cleanup of the model is done directly before shutdown.

Tom

On 23.04.18 09:38, Erdal Karaca wrote:
> Hi devs,
> I observed the following behavior of the platform: it seems to randomly
> persist the application model at run time. Now, if the application
> process is killed (or not properly shut down), the platform will reload
> that intermediate model which leads to duplicated model entries, for
> example, any active dynamic menu items or toolbar items. This only
> happens if -clearPersistedState is not set/provided.
> 
> Do you know of such a mechanism and what it is good for?
> 
> Thanks.
> 
> Erdal
> 
> 
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/platform-dev
> 
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-dev