Ah now i know why i've added the PRE method i don't think it is a good idea to move AbstractRenderer! One could implement the rendering in a completely different way and we would prohibit that so -1 from me on moving and +1 on going with PRE.focusGui!
Tom
Von meinem iPhone gesendet
While looking into fixing
https://bugs.eclipse.org/bugs/show_bug.cgi?id=379024
We decided to eventually go with an
approach that delegates the default behavior back to the element's renderer
(so that we can implement the SWT 'forceFocus()'). Unfortunately this means
that the PartServiceImpl must have access to at least AbstractPartRenderer
which is currently in org.eclipse.e4.ui.internal.workbench.swt.
This is obviously not the place for
it since it's properly agnostic (i.e. contains no SWT imorts) *and* it's
not really 'internal' since it is part of the API we're declaring...
So now the question becomes where to
move it ?
For me since it's a part of the rendering
setup it should be under a new package (bundle?) "org.eclipse.e4.ui.workbench.renderers"
which is where we might also put any other platform agnostic rendering
stuff (including the PRE once we've cleaned it up).
Warning !!
Whatever we decide in this case we need an approach to this because as
part of making the API public there will be *significant * churn which
will likely affect both existing implementations as well as impacting Tutorials
/ Blogs... This is unavoidable, these classes cannot stay
in their current packages and at least some of them should be moved into
new bundles. The question is how best to do this with the least churn...note
that the case above is likely not the only one (we should be so lucky...;-).
The best idea I can think of is to do
this in as few passes as we can. I'm still gathering up the API bits into
a GoogleDocs presentation and I'll try to call out which classes have to
move and then we can decide on where they need to go...then we do the re-factoring
in one pass and update any public materials accordingly.
If anybody wants to make suggestions
as to the shape of the API packages / bundles *now* is the time,
Eric
|