Elias Volanakis schrieb:
Hi Christian,
I agree that doing this as late as possible is good.
However this line will cause an exception:
ColorLnfResource:
return new Color(null, rgb);
^^^^
Color.java:
public Color (Device device, RGB rgb) {
super(device);
if (rgb == null) SWT.error(SWT.ERROR_NULL_ARGUMENT);
[...]
Kind regards,
Elias.
Elias,
I dont think that this will cause an exception:
...
if (rgb == null) {
return null;
}
return new Color(null, rgb);
...
so rgb isn't null and if the device is null, Color will create a new
Display()
ekke
On Tue, Sep 22, 2009 at 3:23 AM, Christian Campo
<christian.campo@xxxxxxxxxxxx> wrote:
after some further testing and investigation I changed the two renderers in
question EmbeddedTitlebarRenderer and SubApplicationTabRenderer so that they
access the ColorRessource only once they need it. Further RienaLnF was
changed to create "black" and "white" only pretty late (not in init, but in
the first access to getColor).
So i think the lesson learned is that we should access Ressource that
require Display like Color only as late as possible to give the workbench a
chance to exist.
I also replaced the ColorLnfResource code to supply a null Display to the
Color constructor.
public Resource createResource() {
if (rgb == null) {
return null;
}
return new Color(null, rgb);
}
So Color can figure out the Display.
Ekke's code is running, the SWT Example Client of Riena is running and the
two testcases mentioned by Steffen are running.....
christian
Am 22.09.2009 um 09:13 schrieb ekke:
Christian Campo schrieb:
Ekke,
I am not sure why the current solution to check whether the Workbench is
running and then decide does not please everyone......
if (PlatformUI.isWorkbenchRunning()) {
return new Color(PlatformUI.getWorkbench().getDisplay(), rgb);
} else {
return new Color(Display.getCurrent(), rgb);
}
That code should work for testcases and for the Ekke and certainly for the
SWT Example Application......
I also think that this code should work in all cases, but I'm not the SWT
expert to know what's recommended
...but this change only avoids some errors - not the problem that creating
Color resources
in 1.2 still creates the Display too early in DS ResolveComponents Thread
perhaps I can use Elias idea to dispose this Display I don't want
...but at first I'm interested to hear if these changes in 1.2 are really
needed by Riena
ekke
Of the two testcases pointed out by Steffen, ChoiceCompositeTest runs with
this current code and ComboRidgetTest has two failures which are unrelated
to this change (they also happen with the old version).
+1 for keeping the code as it is now....
christian
Am 22.09.2009 um 08:03 schrieb ekke:
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
<ATT00001.c>
________________________________
_______________________________________________
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
<ATT00001.c>
_______________________________________________
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
|
