Hi Elias,
Elias Volanakis schrieb:
Hi ekke,
I agree with Steffen - i.e. it would be best to revert the change.
...one shouldn't change things on a sonday ... tired after hours of
debugging ;-)
Actually, I think Display.getCurrent() is not problematic -- this will
return null when called from a non-UI thread and fail -- which is
acceptable from my POV. I.e. if one is trying to create UI things,
such as Colors from a non-ui thread, it means trouble in any case.
What I pointed out as a bad practice in my original mail was
Display.getDefault() -- because this will create the one-and-only
Display if called from a non-ui thread, instead of returning null.
This typically makes the code work in that thread, but creates
problems later.
thanks again for making things clear
@ekke: I think the key for fixing this is to find out where/how
Displays are created. Could attach stack traces for each display
creation to the bug? Setting a breakpoint in Display should help
pinpoint this.
I have done this - and so found out that from DS Thread UI Access was
needed
from ColorLnfResource while creating a resource
Some random thoughts: (a) if you need a display before the Application
launches you might be able to create one and the dispose it (for the
login). However, I'm not sure how this will work with potentially
cached resources (i.e. LnF colors, etc). (b) If you need UI access
from declarative services, how to you obtain the display?
I don't need UI Access from DS - and using Riena 1.1 it works well -
using 1.2 Riena needs UI Access while resolving my DS
(where I instantiate some LnF classes extending RienaDefaultLnf,
but where I don't need resources)
...exactly the same code is used from my site, at the time the first
Display is created,
excactly the same bundles from Riena with the same state are running.
to avoid problems from LoginView I started the app without LoginView -
same happens
Analyzing the stack where the 1st Display was created, finally I found
the reason !
RienaDefaultLnf.getTheme() in 1.1 needs no access to UI Thread
but in 1.2 there's a difference:
while initialize()
initWidgetRendererDefaults() was called
then SubApplicationTabRenderer was initialized
and there in 1.2 was new:
DEFAULT_COLOR = LnfManager.getLnf().getColor("black");
this results in.... ColorLnfResource.createResource
same happens in EmbeddedTitlebarRenderer
also the next method from initializing: initColorDefaults()
... in 1.2 there are new lines added:
getResourceTable().put("black", new ColorLnfResource(0, 0, 0));
//$NON-NLS-1$
getResourceTable().put("white", new ColorLnfResource(255, 255, 255));
//$NON-NLS-1$
and these calls are the reason !
so it wasn't the Display.getCurrent() - the reason is the creation of
ColorLnfResources
while initializing
in 1.1 Resources are created later
I did a test and commented out the creation of ColorLnfResources in:
SubApplicationTabRenderer
EmbeddedTitlebarRenderer
RienaDefaultLnf#initColorDefaults()
now my appliction runs under 1.2 same as under 1.1
but I dont know why this was added and if there's a way to avoid
creation of resources so early
also tried with LoginView - the View comes up (with some problems - but
this is work for flo,
to finish changes to use new DialogView)
so my question: is there a way to avoid creation of Color Resources
while initializing ?
if not, I have to rethink my LnF implementation, but this will take
time - so perhaps I have
to stay with 1.1 for next 2 months
ekke
Kind regards,
Elias.
On Mon, Sep 21, 2009 at 2:42 AM, ekke <ekke@xxxxxxxxxxxxxxxx> wrote:
Steffen Kriese schrieb:
ekke schrieb:
see bugzilla 287617
using Platform.getWorkbench().getDisplay() starts my riena rcp app without
SWT.error,
but using a LoginView or setting the LnF from DS now there's a problem,
because at some early points the workbench isn't started yet
...did some more tests and compared behaviour between 1.1 and 1.2:
same bundles are runnin from riena with same state
but in 1.1 Thread-0 from my RCPApplication (extending SWTApplication)
creates first Display
and in 1.2 the ComponentResolveThread from ColorLnFResource creates first
Display
so something must be different between 1.1 and 1.2 while activating the
running bundles
ekke
btw: so my first commit was only half-way-to-success :-(
Your commit had another side effect: Some of our UI-Tests don't work
anymore, because they are trying to create a Color-Ressource before the
workbench is started. Take a look at ChoiceCompositeTest or ComboRidgetTest.
so I think its best I revert the change and hopefully someone has an idea
why in 1.2 there's a different behaviour,
when the ColorLnFResource creates the Resource
ekke
Best regards,
Steffen Kriese
ekke schrieb:
after some more debugging and discussions with christian campo,
the reason was found:
I had to replace
Display.getDefault() with Platform.getWorkbench().getDisplay()
in ColorLnfRessource to correct the threading problems
btw: this was my first own Commit to eclipse cvs to fix a bug :-)
ekke
--
ekke (ekkehard gentz)
independent software-architect
senior erp-consultant
eclipse | osgi | equinox | mdsd | oaw | emf | uml
max-josefs-platz 30, D-83022 rosenheim, germany
mailto:ekke@xxxxxxxxxxxxxxxx
homepage (de): http://gentz-software.de
blog (en): http://ekkes-corner.org
twitter: @ekkescorner
skype: ekkes-corner
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490
________________________________
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
--
ekke (ekkehard gentz)
independent software-architect
senior erp-consultant
eclipse | osgi | equinox | mdsd | oaw | emf | uml
max-josefs-platz 30, D-83022 rosenheim, germany
mailto:ekke@xxxxxxxxxxxxxxxx
homepage (de): http://gentz-software.de
blog (en): http://ekkes-corner.org
twitter: @ekkescorner
skype: ekkes-corner
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490
________________________________
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
--
ekke (ekkehard gentz)
independent software-architect
senior erp-consultant
eclipse | osgi | equinox | mdsd | oaw | emf | uml
max-josefs-platz 30, D-83022 rosenheim, germany
mailto:ekke@xxxxxxxxxxxxxxxx
homepage (de): http://gentz-software.de
blog (en): http://ekkes-corner.org
twitter: @ekkescorner
skype: ekkes-corner
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
--
ekke (ekkehard gentz)
independent software-architect
senior erp-consultant
eclipse | osgi | equinox | mdsd | oaw | emf
|
uml
max-josefs-platz 30, D-83022 rosenheim, germany
mailto:ekke@xxxxxxxxxxxxxxxx
homepage (de): http://gentz-software.de
blog (en): http://ekkes-corner.org
twitter: @ekkescorner
skype: ekkes-corner
Steuer-Nr: 156/220/30931 FA Rosenheim,
UST-ID:
DE189929490
