| Re: [e4-dev] e4-izing the IDE |
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 <emoffatt@xxxxxxxxxx>
Reply-To: E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
Date: Tuesday, March 4, 2014 at 9:20 AM
To: E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
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
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 <dschaefer@xxxxxxx>
To:
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,
Date:
03/03/2014 04:46 PM
Subject:
Re: [e4-dev] e4-izing the IDE
Sent by:
e4-dev-bounces@xxxxxxxxxxx
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" <tom.schindl@xxxxxxxxxxxxxxx> 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 Œe4-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
>> e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>
>
>_______________________________________________
>e4-dev mailing list
>e4-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
