Re: [e4-dev] Re: CSS relationship to e4 workbench

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

I guess I'd like to hear from the RCP
community on how they think they'll consume e4. RCP apps based on modelled
UI without CSS support would only get default system colors and fonts everywhere.
 This seems pretty boring as a desktop app.  To do more, I guess
they'd need to override the renderers.

If we decided to make the CSS support
optional, I don't think the service pattern alone would be enough since
the CSS engine must be initialized during bootstrapping.  Unless we
had some generalized proactive service initialization support.

> There's still some issue of how
to get the 'ApplicationCSS' product variable but that should be doable
(using the Context?). 

Possibly.  To support user selection
from N style sheets then we'd need to surface the variable somewhere, and
the topmost context seems a good place.  That assumes we have access
to the contexts prior to any widget creation.  We'd need to look at
the initialization sequence.  But we don't persist context state,
only model state.  Therefore we'd need to extend the workbench model
to have the notion of a current stylesheet, with the context providing
access to that model state.  Thus we'd an extensible EMF model.  How
do we do this?

Kevin

Eric Moffatt/Ottawa/IBM@IBMCA
Sent by: e4-dev-bounces@xxxxxxxxxxx

04/07/2009 01:26 PM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

To	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
cc
Subject	Re: [e4-dev] Re: CSS relationship to e4 workbench

Kevin, I think that 'simple' RCP apps may not want CSS styling even though
they use the SWT renderers. There seems to be some question of the footprint,
This would mean that the (swt) renderers now have the same issue...what's
the best way of setting up the optional dependency. At least ther're in
a position to perform any initialization necessary at the proper time (i.e.
before any widgets are created). 

I still think that the service approach would work, the difference being
that it's the swt renderers that would get/initialize the service rather
than the workbench. There's still some issue of how to get the 'ApplicationCSS'
product variable but that should be doable (using the Context?).

Eric

Kevin McGuire/Ottawa/IBM@IBMCA
Sent by: e4-dev-bounces@xxxxxxxxxxx

04/07/2009 10:48 AM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

To	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
cc
Subject	Re: [e4-dev] Re: CSS relationship to e4 workbench

Eric and I discussed this in person, so to relay the discussion:

- The CSS support needs to be initialized very early, prior to any widget
creation. 

- The services so far are for use by the parts.  We have a styling
service at present that sets the CSS id/cass. This may never get called
for a given part and thus is not a good candidate for CSS engine init.
 Eric observed correctly that the real relationship is between CSS
and the SWT renderers.  Thus I think the services aren't the right
mechanism for this initialization. 

- My argument, which I think Eric agreed with, is that if we're talking
about workbench model + SWT then we might as well also be talking about
CSS for any practical use of the workbench + SWT. 

- It's possible that the same model though could be used with a different
renderer and therefore maybe you don't want to use CSS.  Thus again
it seems reasonable to pair renderer + styling engine (or different renderer
+ different styling engine). 

- Currently the optional dependencies and reflective code are in org.eclipse.e4.ui.workbench.swt.
 Thus I think it's ok to make the use of CSS explicit there.

- Eric observed that most if not all the contents of that project could
be moved to workbench.renderers.swt.  We also noted that many of the
classes in the project seem like left over experiments to be deleted.

Eric chime in if I missed anything. 

Regards, 
Kevin

Eric Moffatt/Ottawa/IBM@IBMCA
Sent by: e4-dev-bounces@xxxxxxxxxxx

04/07/2009 09:22 AM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

To	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
cc
Subject	Re: [e4-dev] Re: CSS relationship to e4 workbench

The way we handle this for the legacy code (also an optional dependency)
is that the legacy bundle registers a service using the org.eclipse.e4.services
extension point. Then code that needs to gets the service from the global
context. A returned 'null' means that the bundle isn't there and the code
can take appropriate actions (if any). This mechanism uses the service
layer/context rather than reflection to determine the availability of the
necessary classes. It also avoids the eager loading cases since services
themselves are lazy loaded. 

Not sure if this will help in the CSS case but it might provide some avenues
to look at... 

Eric

Ed Merks <ed.merks@xxxxxxxxx>
Sent by: e4-dev-bounces@xxxxxxxxxxx

04/07/2009 06:11 AM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

To	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
cc
Subject	Re: [e4-dev] Re: CSS relationship to e4 workbench

Gunnar,

Well, you still have to be careful about Java wanting to load classes that
might not be available.  Certainly EMF makes quite heavy use of the
type of pattern you describe, i.e.,  non-reflective code guarded by
tests for availability of the classes used in that code.  That's how
we support stand alone execution with no Eclipse dependencies.  Often
it's necessary to put the logic in a separate class to prevent Java from
eagerly loading it.  It's obviously very important to test for proper
behavior when the classes aren't available.

Cheers,
Ed


Gunnar Wagenknecht wrote: 
Kevin McGuire schrieb:

1) The use of optional dependencies is cool, but makes writing more code
here tricky since it must be reflective which is brutal to write (I
believe Boris has a "reflectify" refactor but that only helps
the first
time and change/debug is still a challenge).  It also is a potential
point of introducing errors if we forget to add the CSS plugins to the
product since the tooling won't warn you of their absence (being optional).
  

The trick is to only use reflection to verify that an optional
dependency is satisfied. Thereafter it's totally fine to call out to a
different class which uses the API provided by the optional dependencies
directly.

An example of this can be found in the Equinox Preferences bundle.
org.eclipse.core.internal.preferences.Activator#start
org.eclipse.core.internal.preferences.Activator#addingService

OSGi services actually do support this very well because you only need
to reference the service class by name.

-Gunnar

_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev