Re: [e4-dev] How to manage refactorings necessary to support the API

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

Hi,

I'm ok with doing the forceFocus stuff in the renderer but I'm uneasy
with moving the renderer stuff to "org.eclipse.e4.ui.workbench".

We once defined that the only interface between the generic workbench
and the rendering is the PRE and I'd like to stick with this.
AbstractRenderers could look completely different for other toolkits
(e.g. most of them don't need the parent for rendering) forcing them to
fullfill the AbstractRenderer contract feels wrong!

It should be up to the PRE implementation to decide how things are
implemented. What do you think is the drawback of my approach going
through the PRE and giving it a focusGui method?

Tom

Am 13.02.13 21:12, schrieb Eric Moffatt:
> 
> 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
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
> 


-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                 geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834