Are you confused and tired to hear about all the technologies that Microsoft/Windows keeps pushing and deprecating? Are you ready to upgrade your life and go all in on WinUI? If this is you, then hop on this session to fast track your way onto XAML Islands with the guide of Xojo!
I can’t remember the last time I was so excited to see something new added as XAMLContainer. Kudos!
Is this coming in 2023r2 or I misunderstood?
As a WIP, I hope the final one have some way to have a list of draggable preset ready ones (Buttons, switches, Checkbox, TextField, Radio, etc) to make a more RAD, fast drag-and-drop, interface design experience.
Do i understand this correctly, in the future, dragging a button into a window will add a “DesktopButton” with parameters / events geared towards XAML that only work on Windows. So you can still have same source compiled to mac and window. Then for Windows you can access these XAML properties to customize the L&F for Windows only. Also will older projects convert to this and we automatically get new UI features on windows without changes. Building apps for mac and windows will still limit user to base controls that exist on both OS’s.
Nope, you will have 2 buttons. One is the current one, a common xplat Mac/Windows/Linux. Another one is a “WinUI” (MS XAML Island) only. Windows only.
Thats a shame, completely useless feature to me, as I have with huge complex gui’s. So I am stuck with win32 forever then?
What I understand is that, down the road, there will be controls that are available for Windows and Mac just as there are now. But the Windows version will use XAML under the hood. The initial release, possibly even in R2 will be incredibly flexible giving you access to 30+ XAML controls.
Why?
I Just want a way to write selective interfaces, a Xojo MVC way. The View, for Windows, compile this window, for mac, this another one (same name). Both using a “Control” module with the shared contents.
I hope they are doing things this way, things change depending on targets. That will allow the same thing happen to Mac, also using their native controls.
Based on XDC London, Day 1 Open Discussion - #29 by Dana_Brown it is my understanding that the “one or the other” design is temporary.
It makes no sense, because the WinUI set has no 1:1 counterpart in MacOS/Linux, unless hugely capped, so this effort will be turned into garbage and become the limited set we have today.
Have you watched the video? You can use the XAML control to do whatever Microsoft allows. No real limits. But it will not be cross platform because MacOS does not support it.
That’s exactly what I said. A Windows only set can’t be used as a xplat set. A common core one (what we have today) must exist for that (for compatibility reasons only) and very simple interfaces. The native ones does not match 1:1, sizes, properties, etc. Xplat is “forced” to fit in the middle ground between those. The best approach is using native ones, complete sets, in selective Views (native UIs) depending on targets.
I expect that you’ll be able to use XAML controls if you want full control, you can sacrifice the cross-platform compatibility and use the XAML control directly. If you need cross platform compatibility, you use DesktopPushButton, which will build a XAML control under the hood, but you give up a certain level of control.
I want Xplat AND using the native ones. That’s why MVC, MVVM, MVP, etc were invented.
And you will get them.
First step is to get the container, so if you need a XAML based control, you can make yourself one for Windows. Since that is extra work, you may only do it in a few spaces.
Later all the regular Xojo controls will use XAML under the hood to get the new look and behavior.
Then you have native GUI again on all three platforms for desktop, but on Windows based on XAML with WinUI API instead of older Win32 API.
This is what i as trying to imply was going to happen. This sounds good.
The complete set? Or the current subset?
And those without matching counterpart on the other OS? Even in the shape/size, behavior or existence? What’s the meaning of having it (because they simply does not exist on the other side) without having a separation of the View from the Model and different Views for each target?
I would imagine what we’ll get is the controls we already have, just updated to use WinUI. I’d hope that will help and/or solve flicker problems. If you want to change the style or use non-library controls, you can do that with a XAMLControl, but it’ll be Windows-only.
Switching the library controls isn’t about gaining theming. It’s about modernizing, so we get more accurate dark mode, better font rendering, buffering, and so on.
Of course, I’m not a Windows developer, but that’s what I’m expecting from this transition.