Community
Participate
Working Groups
win32 has some limitations that make SWT apps look older (eg lack of support for "native" themes) and performing not so well. WinUI is the new recommended framework for desktop apps. It has a lot of nice things that SWT apps could benefit from and is expected to perform much better. SWT should be ported to WinUI at some point, and possibly open the door to dropping win32.
I have my doubts. I think the biggest doubt is that over time, SWT accumulated a large number of tweaks to make things work as desired. Trying to reimplement all that with completely new controls is going to be quite an effort. Next, appearance of controls will probably change, which is a compatibility issue. What if applications want to stay with old looks? What exactly do you mean by "performing not so well" and what are the advantages of WinUI in that respect? As for "native themes", I'm also in doubt that WinUI is going to be an advantage. What would help is if someone will prepare some proof of concept. I feel that I'm not prepared to spend time on that task, sorry.
(In reply to Alexandr Miloslavskiy from comment #1) > I think the biggest doubt is that over time, SWT accumulated a large number > of tweaks to make things work as desired. Trying to reimplement all that > with completely new controls is going to be quite an effort. Yes, that's certain! > Next, appearance of controls will probably change, which is a compatibility > issue. SWT has never guaranteed anything about appearance beyond "delegating to underlying native widget toolkit". So it's not really a compatibility issue as per SWT contract. > What if applications want to stay with old looks? They'd still use the win32 port of SWT. It seems to me from the few things I've read that there are enough differences between win32 and winUI so it's better to make them separate SWT ports instead of morphing win32 port into winUI. The winUI port could start as a clone of win32 though. And in the end, the goal would obviously be to get rid of the win32 port as soon as winUI becomes better. > What exactly do you mean by "performing not so well" and what are the > advantages of WinUI in that respect? Unless I'm mistaken, winUI uses hardware/GPU acceleration while win32 doesn't. > As for "native themes", I'm also in doubt that WinUI is going to be an advantage. I don't know. While working on the "System" theme and noticing that windows themes don't propagate to SWT, someone reported that win32 is not themeable at all and having theme support for Windows would require using a newer toolkit. I didn't verify.
> They'd still use the win32 port of SWT. It seems to me from the few things > I've read that there are enough differences between win32 and winUI so it's > better to make them separate SWT ports instead of morphing win32 port into > winUI. The winUI port could start as a clone of win32 though. > And in the end, the goal would obviously be to get rid of the win32 port as > soon as winUI becomes better. Yes, having a different port resolves compatibility problem. > Unless I'm mistaken, winUI uses hardware/GPU acceleration while win32 > doesn't. I think that's not exactly what happens: 1) Most of SWT controls are rather trivial and do not have any embedded video or complex animations, hence they don't need GPU acceleration. 2) Many controls are still rendered by Windows Kernel and that's pretty fast. 3) If SWT wants to paint anything, for example custom draw items of a list, we're now talking about Java and JNI, which is quite a performance loss. Neither kernel nor GPU acceleration could help with that. To summarize, I think that there is no performance problem with *rendering* controls, and there will be no improvement that is interesting to talk about. > I don't know. While working on the "System" theme and noticing that windows > themes don't propagate to SWT, someone reported that win32 is not themeable > at all and having theme support for Windows would require using a newer > toolkit. I didn't verify. I worked quite a bit on SWT theming on Windows recently. I picked a lot of things that Windows has support for, and added a couple custom patches. This gives a very reasonable dark theme to SWT. Completely custom themes are not supported, that's true. Question is, will WinUI work any better in this respect? Again, everything goes down to someone who will be willing to spend time to prepare some test application in WinUI to see what is it capable of.
(In reply to Alexandr Miloslavskiy from comment #3) > I worked quite a bit on SWT theming on Windows recently. I picked a lot of > things that Windows has support for, and added a couple custom patches. This > gives a very reasonable dark theme to SWT. Completely custom themes are not > supported, that's true. Question is, will WinUI work any better in this > respect? I don't know. To narrow down, is it possible to implement with winUI Display.getColor(SWT.COLOR_WIDGET_BACKGROUND) so it returns the system defined black-ish color when using Windows dark theme thanks to WinUI (or some other background color if using another OS theme)?
> I don't know. To narrow down, is it possible to implement with winUI > Display.getColor(SWT.COLOR_WIDGET_BACKGROUND) so it returns the system > defined black-ish color when using Windows dark theme thanks to WinUI (or > some other background color if using another OS theme)? I think the biggest misunderstanding here is when you speak of "another OS theme". For native applications, Windows has exactly one theme: Light. 'Display.getColor()' will correctly work with it. There are no other themes on Windows. The recent Dark theme is not a theme for native applications, and not even fully implemented for any application as of today.
> (In reply to Alexandr Miloslavskiy from comment #1) > > Next, appearance of controls will probably change, which is a compatibility > > issue. > > SWT has never guaranteed anything about appearance beyond "delegating to > underlying native widget toolkit". So it's not really a compatibility issue > as per SWT contract. It would change a lot. And in my opinion a lot worse. Just like the new settings dialog is not better than the old one, or the Win10 calculator not nicer than the Win7 one. An annoying lack of distinguishability between active and inactive window title bar. And the context menu just bigger and less informative. From the last one I would expect that I have to scroll the context menu of a Java Editor in Eclipse because it will not fit my screen anymore. After writing this I found WinUI widget example project [1] and seemingly not all the ugliness of WinUI applications comes from WinUI itself. But it still wast a lot of space which might be problematic for existing SWT applications. Especially things like list views, menu bars and context menu. [1] https://github.com/microsoft/Xaml-Controls-Gallery/tree/winui3preview (has also a Microsoft Store link at the end) > > What if applications want to stay with old looks? > > They'd still use the win32 port of SWT. It seems to me from the few things > I've read that there are enough differences between win32 and winUI so it's > better to make them separate SWT ports instead of morphing win32 port into > winUI. The winUI port could start as a clone of win32 though. > And in the end, the goal would obviously be to get rid of the win32 port as > soon as winUI becomes better. Why get rid of the alternative and what is the metric for better? Is keeping the win32 implementation such a burden? And I don't like the term "old look". For once because IT sector has this annoying mindset of old = bad/disposable. And even after 5 years Win10 the old looking apps feel more native than the few WinUI apps I noticed. (the context menu seem to be a good indicator to recognize a WinUI app) > > As for "native themes", I'm also in doubt that WinUI is going to be an advantage. > > I don't know. While working on the "System" theme and noticing that windows > themes don't propagate to SWT, someone reported that win32 is not themeable > at all and having theme support for Windows would require using a newer > toolkit. I didn't verify. Windows was once much better in theming. Just think of the old classic look or 'color and appearance' dialog removed in Windows 10. https://answers.microsoft.com/en-us/windows/forum/windows_10-start-win_theme/advanced-appearance-settings-missing-in-windows-10/ed6c1a6b-ea99-4643-913f-31392f472a15 > > What exactly do you mean by "performing not so well" and what are the > > advantages of WinUI in that respect? > Unless I'm mistaken, winUI uses hardware/GPU acceleration while win32 doesn't. Things like bug 300403 might help but in general you are right here.
Thanks for the link to test application. I played with it briefly. Everything looks bigger, as if it's designed for tablet and not desktop. I can't imagine a control-heavy thing, like settings page, with such big controls. Is SWT a framework for tablet apps with 3 buttons total? I doubt it. It's hard to say if the controls will properly things such as owner draw. It's hard to say if they have enough features to cover SWT needs. So far, to me, it looks like another library that aims to conquer all others. Well experience shows that Windows developers just stay with old good native controls, mostly. So the choice is between a trustworthy thing that works and unknown. It could be fun to try with a new project, but making it work with things like Eclipse or the product I'm working on will probably take human-years of development. And maybe the end result will be worse in every respect. I think I've made my mind: I will just ignore the whole thing. Unless there's someone willing to demonstrate significant measurable advantages.
