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
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
