Too many great ideas, let's find some actionable.
On Wed, Sep 14, 2016 at 7:41 PM, Brian de Alwis <---> wrote:
> Check out
bug 501406 for an example of why theming is a good thing. (..)
> Our CSS engine is based on Batik — which seems dead — and our binding to Batik is suboptimal.
> And the implementation predates SWT's SWT.Skin events and I suspect we could get a lot of mileage switching to taking advantage of it. That's a fair bit of work.
Let's discuss this at the first opportunity. We should join the efforts in that direction. The UI & Best Practices Group should coordinate
On Thu, Sep 15, 2016 at 5:17 PM, Eric Moffatt <---> wrote:
> Andrey, what can I say...we did the best we could with the resources at hand. There is a back story as to *why* we decided to do e4 though:
>
> The 3.x codebase was so tied up in technical debt that is was essentially frozen:
> - We weren't able to recruit new committers because of the complexity of the code
> - The existing Platform UI committers were severely hampered when trying to make any but the most trivial changes
> - Almost all attempts to even get a valid contribution ended up the contributor giving up after 3 or 4 rejections
Lowering barriers is the way to find new contributors and have more adopters.
To have constant innovation, we need to regularly push updated guidelines and best practices.
Andrey already proposed to discuss this at
ECE 16 unconference,; we can also discuss this on
mattermost UI-UX channel On Thu, Sep 15, 2016 at 7:36 PM, Tom Schindl <---> wrote:
> [...]
>
>> Another example is e(fx)clipse. It's a very interesting project, but one
>> wonders if they could have gotten even further ahead if Eclipse has made
>> their life easier.
(..)
> The changes to e4 are deep and I'm afraid we can't get around without
> breaking APIs which means most likely we - e(fx)clipse - are going to
> fork the e4 platform.
Innovative projects should be incentivized to stay in the ecosystem if is a Nash equilibrium.
As a community, we should evolve our process and try to accommodate the needs of all, and care about innovation. Is there a way to negotiate API relaxation?
On Thu, Sep 15, 2016 at 7:40 PM, Ian Bull <---> wrote:
> To blame the current state of Eclipse on "Bad Software Practices" from 15
> years ago is a rather simplistic way of thinking. (..)
>
> When Eclipse started, there was no Maven. (..)
> Eclipse shipped, on-time, every-time, for 15 years. Eclipse Delivered.
>
> When Eclipse started, there was no GitHub. (..)
> When Eclipse started, there was no StackOverflow
> When Eclipse started, the concept of small, reusable, open-source components was practically non-existent.
(..)
> We can all point to a design flaw in bundle XYZ.
> We can all complain about a 12 year old bug that bothers us.
> We can all criticize some aspect of the UI.
> But blaming the development practices of yesteryear is unfair to those who worked very hard to ship Eclipse.
The people working on Eclipse are shaping the future of IT, since 15 years.
The Eclipse Community is constantly inventing new things and evolving.
We should continue to provide a healthy ecosystem for learning more, improving the existing software, and make things easier for the adopters.
Best Regards,
Patrik Suzzi
