Re: [platform-ui-dev] Theming and CWidgets

[Aleksandar Kurtakov <akurtako@xxxxxxxxxx>]

----- Original Message -----
> From: "Mickael Istria" <mistria@xxxxxxxxxx>
> To: "Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
> Sent: Thursday, 15 September, 2016 10:21:57 AM
> Subject: [platform-ui-dev] Theming and CWidgets
> 
> Hi all,
> 
> I have some questions as a followup of some conversation on the ide-dev
> mailing-list, about theming.
> One thing I'm wondering is whether CWidgets (CTabs, CButtons...), which AFAIK
> don't use the system widgets and then can look inconsistent with other parts
> of UI/OS and require more customization, are still necessary? With progress
> on Cocoa, GTK and Windows API, I would expect that some of the features
> they're providing would now be accessible via the regular widgets.
> First question: am I right to assume that some CWidgets do not all provide
> added-value over regular Widgets nowadays?

That's true for CCombo, CLabel - I don't see much need to use them and if there are usecases I would like to hear them so we can add them to the regular widgets. For CTabFolder the story is entirely different it's heavily customized widgets providing ability to add toolbars and what not - I'm not aware of any native WS providing all these.

> If yes, 2nd question is: then shouldn't we deprecate those widgets and
> encourage everyone to use the system ones, which would look better in the
> Window System without CSS styling and that could more easily take advantage
> of Window System customization?

This can be done for CCombo/CLabel if/when one researches their capabilities and usages and we are sure that resp. Combo/Label provide all features.

> I'm asking that because on Linux, if one removes styling, the result is that
> most partStacks (views, editors...) show some unconventional tabs that do
> not look very good. I don't really know how it would look like without them,
> but I'd expect them to look a bit better, or at least a bit more "usual"
> compared to what I see in other apps.

Now we are entering the "hairy" CTabFolder business. There is no easy replacement for it. But to make things worse CTabFolder on pure SWT and with e4 look entirely different (despite both being non-native). This is caused by org.eclipse.e4.ui.workbench.renderers.swt.CTabRendering and theming engine usage of it. This class should have never existed (esp. in its current form using reflection to call package protected CTabFolderRenderer drawing methods and etc.). First step of improvement would be working on CTabFolderRenderer in swt to change the rendering and expose functionality needed by e4 theming. There have been so many times where CTabFolder works properly after changes in SWT just to find out later this breaks workspace due to playing with internals.

> 
> Cheers,
> --
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat
> My blog - My Tweets
> 
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev

-- 
Alexander Kurtakov
Red Hat Eclipse team