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 Am 13.02.2013 um 21:12 schrieb Eric Moffatt <[email protected]>: > > 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
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
