Progress view bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=401655#c6
On Tue, Mar 4, 2014 at 4:01 PM, Doug Schaefer <[email protected]> wrote: > Thanks, Eric. I think you hit where I was thinking of going first, at > IWorkbench and friends. I need to see how the current compatibility layer > works. I don't think changing APIs and then getting all the plug-ins to use > it is a path to success. But I do want to make sure they play nicely when > you have a non-swt renderer and non-swt part contributors. Easy to say, but > I'm sure I'll uncover a hornets nest as I dig. > > D > > From: Eric Moffatt <[email protected]> > Reply-To: E4 Project developer mailing list <[email protected]> > Date: Tuesday, March 4, 2014 at 9:20 AM > To: E4 Project developer mailing list <[email protected]> > Subject: Re: [e4-dev] e4-izing the IDE > > Doug, one of the sticking points to doing this is that the framework > based 3.x API has lead to all the components being built on top of it to be > heavily dependent on parts of the infrastructure that they don't actually > require. Any code that references IWorkbench* (which is effectively all of > it) has hauled in practically the whole universe due to the number of > services...available through the APIs. > > As an example I've already tried a test port of the Error Log view, it > being the one I identified as needing very little from the IDE (the > location to look for the .log file in). After 6-7 solid days I gave up, > it's like pulling string...new dependencies crop up as you try to satisfy a > higher one. It's truly disappointing (and I'd love to be wrong on this) but > my guess is that each discreet element that you want to 'break off' of the > IDE framework will require tweaking of some kind, sometimes substantial > amounts (i.e. java editor). > > I'm not sure what the starting point would be but perhaps splitting the > current IWorkbench, IWorkbenchWindow and IWorkbenchPage by creating a new > (simpler) base interface to be used by the ported components. Once a > critical mass of ported IDE code is in place the work required to port any > particular component will go down but it's unclear what the true > 'requirements' are. > > I wonder whether Marcel and the folks from Code Recommenders could help > here ? It'd be really nice to see a histogram of which APIs are most > commonly used by views within the EPP universe (CDT if you want a smaller > universe...;-). > > We might also be best off to do the initial ports of the views without any > menus / tb. There's a couple of reasons for this but the alternative is to > port *all* the commands simply because making an item by item decision and > getting agreement is very time expensive. The secondary reason is that IMO > we have to finally get out from under the current commands infrastructure > except for what's provided by the 'org.eclipse.ui.menus' extension point > (no Actions / ActionSets...) and, unfortunately, that's what most of the > more valuable views use (since they were implemented early because they > were needed). > > We've just released an e4 version of the Progress View, perhaps there are > lessons to be learned from that exercise ? > > Onwards, > Eric > > > [image: Inactive hide details for Doug Schaefer ---03/03/2014 04:46:49 > PM---Is there anything lower level we should be doing. I can¹t i]Doug > Schaefer ---03/03/2014 04:46:49 PM---Is there anything lower level we > should be doing. I can¹t imagine how we¹d be successful without a c > > > > From: > > > Doug Schaefer <[email protected]> > > To: > > > E4 Project developer mailing list <[email protected]>, > > Date: > > > 03/03/2014 04:46 PM > > Subject: > > > Re: [e4-dev] e4-izing the IDE > > Sent by: > > > [email protected] > > ------------------------------ > > > > Is there anything lower level we should be doing. I can¹t imagine how we¹d > be successful without a compat layer to support the massive amount of IDE > plug-ins we have out there. But is there a better way to do it than what > we have now? > > My understanding of the vision of the compat layer was that it simply > populated the model from the extension points. But it looks like we > instantiate the legacy UI first and then build the model from that. Or am > I misinterpreting what I see in the debugger. > > Doug. > > On 2014-03-03, 4:31 PM, "Tom Schindl" <[email protected]> wrote: > > >Hi, > > > >I think the road to follow is to make core bundles who are needed for > >IDE compat free. > > > >To my mind are coming: > >* org.eclipse.ui.navigator to get a project explorer > >* org.eclipse.text & org.eclipse.jface.text to get the main text > > editing infrastructure > > > >Something happing as part of that is to move the IEditorInput stuff from > >org.eclipse.ui to a standalone bundle and/or design a completely new > >story for editors & their input in e4 but I think for the start you > >should port IEditorInput directly. > > > >I've already done most of this when writing > > > http://tomsondev.bestsolution.at/2013/03/11/build-an-intelligent-code-edit > >or-with-javafx-and-jdt/ > >so I know for sure it is doable! > > > >Tom > > > >On 03.03.14 21:27, Doug Schaefer wrote: > >> Hey gang, > >> > >> OK, I¹ll state first that I¹m not sure what OEe4-izing the IDE¹ means. So > >> count me a newbie. Taking the newbie approach, I simply changed the > >> application for my IDE to E4application and gave it a spin. Of course, I > >> ended up with an empty window and menu and exceptions when legacy > >> plug-ins tried to get a hold of the legacy Workbench object. > >> > >> Is there a list of things that need to be done in order for this to do > >> something proper? > >> > >> Just to be clear of my intentions, I¹d like to use Tom¹s JavaFX > >> renderers to render the IDE along with an SWT port to JavaFX for compat > >> at the widget level. I¹d like to understand what needs to be done to get > >> there. > >> > >> Thanks for any info. And yes, I do have a certain amount of my work time > >> to contribute to this. > >> Doug. > >> > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > 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 > >
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
