|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 >
> 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
> 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-) - 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. Dev
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.
Back to the top