Hey guys, Thank you all for your comments. I guess the line is a bit blurry, since we want to create a test bed for experiments, but with an actual product as test object. So I can see it making sense in either project for different reasons, but for the reasons outlined below, e4 seems a bit more natural to me:
>> as far as I know, the Yatta team wants to prototype things and if >> they >> prove to improve the UI experience, integrate them into the >> mainline. >> I don't think they target a provide a new EPP incarnation. As Lars and Wim pointed out, the core idea behind this project is as a test bed for UX ideas and improvements. Code-wise, most of that will be targeting the Platform, e4, and the "core" IDE if you will. Those will also most likely be the main areas that contributions would flow back into. UX is also a lot about packaging and configuration though: Starting with what's actually needed in a minimal viable product, over rethinking menu and toolbar structure, available views and so on. On the one hand, this looks like EPP-territory. On the other hand, quite a bit of that looks like it won't work with configuration/packaging only out of the box. So this is something to target in Platform/e4 as well. > Does this minimal IDE have dependencies on projects/bundles that aren\t part > of the Platform or e4 projects? Not right now. I could imagine a future incarnation of the product to pull in e.g. EGit, but see below on that. > Have you considered making it an EPP package? If yes, what makes you prefer > e4 over EPP? Yes, we have. The experimental nature of the E4 incubator and the close(r) relation to the Platform seem a more natural match. While we want to ship an actual, packaged product, EPP didn't seem like such a good fit, because it's going to take some iterations until it's in a shape to provide actual user value. And even then, the focus is on continuing experiments and pushing on. Another thing is speed. While I'm sure this can be accomodated by the EPP project, right now the package build structure targets "big bang" builds of all packages and only a few releases. Where I think EPP would fit in perfectly is to spin off an actual Eclipse package from the results in the incubator in the future, with less frequent and more stable releases, once it reaches a good first MVP status. > Does Sandbox for Eclipse contain specific bundles (that would make sense > in e4 if they can serve other use-cases), or is it doing packaging only? > If it's only about packaging, I don't get how e4 is a more suitable than > e4, for both Sandbox and potential end-users. Right now it doesn't. However, we already plan to do a couple of things that might make sense to host in e4 for now, and later flow back into Platform. For example, the spell checker is currently a part of the JDT and we'd like to extract and possibly restructure it and make it consumable e.g. by the generic editor. The same goes for utilities like simple(r) highlighting, e.g. for plain-text word selection a la Notepad++, which is certainly already possible with the existing API but still takes a lot more effort than seems necessary. In that vain, I'm of the opinion that good UX needs good framework support to make it normative, i.e. whenever a UX guide says 'do X', then ideally 'X' should be the thing that the APIs make it natural to do. In addition, as hinted above, I expect us to need quite a bit of "glue code" to achieve the configuration results we imagine. Not sure if that will benefit other projects, or if a simple branding plug-in for packaging will suffice for that. So overall, our impression was that E4 would be better suited than EPP. Cheers, Carsten _______________________________________________ e4-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/e4-dev
