Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] e4 debate


----- Original Message -----
> From: "Fabio Zadrozny" <fabiofz@xxxxxxxxx>
> To: "Discussions about the IDE" <ide-dev@xxxxxxxxxxx>
> Sent: Friday, 16 September, 2016 1:54:25 PM
> Subject: Re: [ide-dev] e4 debate
> 
> On Thu, Sep 15, 2016 at 6:09 PM, Pascal Rapicault < pascal@xxxxxxxxxxxx >
> wrote:
> 
> 
> 
> Come on Fabio..... SWT..... I think you are failing to realize the state of
> the world in UI toolkit, JVM performance, hardware performance back in
> 1999/2000....
> 
> If you and the many others who think that could have done better back then,
> then it is time to show the world your awesomeness and fix up Eclipse to
> help it regain its shine from the early days.
> 
> Meanwhile, I'll be watching your code quality :)
> 
> ​Hi Pascal, I'm not claiming that historically it didn't made sense, and I'm
> full aware that it's probably one of the main reasons why Eclipse became
> popular back then (and it was made possible because there was a big team
> with proper funding behind it)​. But still, had it used something as Qt
> (which I find quite speedy this days and was comparable to SWT back then
> too) and helped evolve it instead of doing a new UI toolkit could've been
> better... anyways, as I said, history is history and I'm looking forward now
> (and have already provided many patches to improve the dark theme).
> 
> The hardest thing right now is on those 3 points I outlined because this
> really should be done in the SWT layer, but doing those requires SWT
> committers to:
> 
> 1. See value in the dark theme.

We do see a value in it but just don't have the resources/time to actually look into them.

> 2. Accept that in order to implement this a patch which doesn't use only
> native capabilities of the system is accepted.
> 
> Right now, this is close to impossible because I don't think any SWT
> committer cares about a dark theme

It's funny how people's opinion range from "committers don't care about dark theme" to "committers prioritize dark theme".  The truth is in the middle guys - we do care for all issue and we do dynamically prioritize based on the amount of people affected by certain issue. The fact that given issue didn't get attention doesn't mean we don't care but just that there are so many hours in the day.  

> and it requires a change in thinking
> that's really old in SWT, which was conceived as a thin wrapper over what
> the OS provides... 

I can go in further details but custom drawing of widget done right is a lot of effort it's not just setting pixels colors in a pixmap - there is high maintenance cost of yet another code path, performance issues, inconsistencies with rest of SWT with diffrent version of the OS UI toolkit or theme, a11y and etc. This is not something to be taken lightly and if one looks at CTabFolder (as an example of such component)+ it's hacks in Platform UI one would understand the resistence from committers to maintain such beasts.

> I may still try to provide a patch for that, but I know I
> have to prepared for it to not be accepted (which means I'll be just wasting
> time here, which is one of the reasons I keep postponing this).
> 
> Personally I think that one of the main reasons why the theming is taking so
> long is because it was done in the wrong place... it should've been done in
> SWT, not Platform UI, and because it was done in the wrong level, things
> just take much more time to get right (but as SWT committers don't see value
> there and it requires a change on how it sees the world, this would probably
> be impossible to do anyways).

I fully agree that it would be better done in SWT and efforts are ongoing despite what you say of no interest (see Oxygen M2 N&N https://www.eclipse.org/eclipse/news/4.7/M2/#Platform-Dev) - I need a buy in from Mac and Win persons and we can deliver it but so far I haven't heard of such interest so we are going the GTK only path. Even with that restriction we are paving the road towards proper support in SWT and help with driving it further is more than welcome. But this has to happen in maintainable way aka not being fragile on OS theme changes and keeping the existing capabilities.
Regarding changing the way SWT sees the world - you're actually asking for throwing away SWT altogether and creating a new toolkit. Mixing the two concepts just doesn't fit well - there are times when it is "or" and can't be "and" in any maintainable way.

> 
> ​Cheers,
> 
> Fabio​
> 
> 
> 
> 
> On 9/15/2016 1:49 PM, Fabio Zadrozny wrote:
> 
> 
> 
> Ned,
> 
> I must say that having a decent dark theme nowadays is a minimum requirement
> to lots of users (there's a reason for
> http://marketplace.eclipse.org/content/eclipse-moonrise-ui-theme being #6
> and http://marketplace.eclipse.org/content/eclipse-color-theme is #4 in the
> eclipse marketplace), and also a reason why so many users flocked to
> Intellij after it released the darcula theme or to other environments such
> as sublimetext with a better dark theme.
> 
> Personally, I think that Eclipse can't thrive without a proper dark theme
> (yes, I think that it's unfortunate that the creation of SWT was done in the
> first place, as besides making an IDE Eclipse development also has to
> support a UI Widget toolkit, but history is history, we should look forward
> here, and currently, fixing the remaining issues -- namely: table headers,
> buttons and themed scrollbars -- at least on windows -- is probably less
> work than changing to another direction -- although making those fixes in
> SWT is an uphill battle because they're not native on the platform, so, even
> with a working patch, it's probably really hard to get accepted in SWT).
> 
> Cheers,
> 
> Fabio
> 
> On Thu, Sep 15, 2016 at 2:01 PM, Ned Twigg < ned.twigg@xxxxxxxxxxxx > wrote:
> 
> 
> 
> It's a difficult debate to have, but I think it's unlikely that the best path
> forward will involve only "new stuff". Sometimes cutting out old stuff is
> necessary to concentrate resources, and that will require an honest
> assessment of technical results.
> 
> For years, planeteclipse has been peppered with screenshots where Eclipse
> with Windows MFC widgets is slowly getting darker. It was a worthwhile
> experiment to run: "Can we make native widgets as flexible as HTML/CSS", and
> the answer turns out to be "with the resources we have, it will take more
> than 6 years". Maybe I'm giving up too soon and it's gonna look fantastic in
> year 8. Or maybe, if we say "the theming engine is now an opt-in experiment,
> not a default", we would find that there are more resources available to
> squash more mundane UX issues.
> 
> Ned Twigg
> Lead Software Architect, DiffPlug LLC
> 540-336-8043
> 340 S Lemon Ave #3433, Walnut, CA 91789
> 
> On Thu, Sep 15, 2016 at 8:59 AM, Eric Moffatt < emoffatt@xxxxxxxxxx > wrote:
> 
> 
> 
> 
> 
> +1 (especially the beer part...;-)....just had to take a try at defending my
> baby. I'm extremely encourages to see the extent of the interest in moving
> forward.
> 
> Eric
> 
> Doug Schaefer ---09/15/2016 11:52:35 AM---I’m not sure how helpful this
> debate is. We have ended up where we are. There’s a new crop of contri
> 
> From: Doug Schaefer < dschaefer@xxxxxxxxxxxxxx >
> To: Discussions about the IDE < ide-dev@xxxxxxxxxxx >
> Date: 09/15/2016 11:52 AM
> Subject: Re: [ide-dev] e4 debate
> Sent by: ide-dev-bounces@xxxxxxxxxxx
> 
> 
> 
> 
> I’m not sure how helpful this debate is. We have ended up where we are.
> There’s a new crop of contributors that have been working hard and bringing
> Eclipse forward. We’re headed in the right direction.
> 
> I got to know the platform committers in Ottawa very well over the years and
> was at the e4 Summit that kicked it all off. They had their hearts in the
> right place and were trying to do what they though was the right thing. But
> that’s over and we need to look forward.
> 
> Happy to talk more on the subject, but I and you need a beer in our hands :).
> 
> Doug.
> 
> From: < ide-dev-bounces@xxxxxxxxxxx > on behalf of Mickael Istria <
> mistria@xxxxxxxxxx >
> Reply-To: Discussions about the IDE < ide-dev@xxxxxxxxxxx >
> Date: Thursday, September 15, 2016 at 11:41 AM
> To: " ide-dev@xxxxxxxxxxx " < ide-dev@xxxxxxxxxxx >
> Subject: [ide-dev] e4 debate
> 
> 
> 
> 
> On 09/15/2016 05:17 PM, Eric Moffatt wrote:
> 
> 
> 
> The idea of e4 was to simplify the platform code to the point where we could
> allow contributors to 'get in the game' and to be *successful*. It's worth
> noting in this context that in 2015 the Platform UI project was voted the
> 'Most Open' having garnered many new committers from diverse sources (I'm
> not sure but I suspect we have more now than ever before). As a relatively
> new regular contributor to Platform UI, I must say that what made the
> project more open to me are more the changes about releng (move to Tycho)
> and contribution infra (Hudson, Gerrit) than the move to e4. On the "higher
> level" parts of the IDE (Wizard, views, and very user-oriented things more
> than core, performance and so on), I currently didn't perceive any benefit
> of e4 and I never have the opportunity to take advantage of its features. My
> only attempt so far (adding a context-menu to the main toolbar) of adding
> some extensibility and tweaking some renderer is currently still a failure.
> I do not question whether e4 was necessary or not, I'd just like to share
> that in my opinion, e4 still fails at provided huge value for developing the
> Eclipse IDE, has definitely cost a lot of resources that end-users would
> rather have seen placed elsewhere, and that it's not what has caused the
> recent boost in the contributions to Platform UI.
> 
> 
> 
> As for the reason for the drop off I'd point to the decision of Apple to go
> with Android Studio as being the turning point, followed by the current
> unrelenting marketing campaign from JetBrains... s/Apple/Google, but yeah,
> overall I agree. But about JetBrains, it's not about Marketing, it's really
> about a very good strategy in their product that has allowed them to deliver
> a good functional quality. They've basically implemented years ago what
> we're still discussing here (solid factorization of common parts - editors,
> commands, views...), so they can simply create nice features for new technos
> faster than we can do now. We're just paying the price of the Tragedy of
> Commons, and luckily, there are now enough motivated contributors to succeed
> on this challenge! -- Mickael Istria Eclipse developer for Red Hat
> Developers My blog - My Tweets
> _______________________________________________ ide-dev mailing list
> ide-dev@xxxxxxxxxxx To change your delivery options, retrieve your password,
> or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ide-dev
> 
> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/ide-dev
> 
> 
> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/ide-dev
> 
> 
> 
> _______________________________________________
> ide-dev mailing list ide-dev@xxxxxxxxxxx To change your delivery options,
> retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ide-dev
> 
> 
> 
> 
> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/ide-dev
> 
> 
> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/ide-dev

-- 
Alexander Kurtakov
Red Hat Eclipse team


Back to the top