XDC 2023: XAML Islands, William Yu

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.

Ditto what @Thom_McGrath said.

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.

2 Likes

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.

If you are correct, we will lose most of the controls and have just a small xplat subset, looking weird, trying to match shapes and sizes of the other OSs counterparts for a 1:1 placement layout.

Ummm I wonder what the likelihood of that including the current listbox with all its functionality is…

A recurrent complaint I see from Mac users are that ListBox does not have the look and feel and power of a NSTableView. The View/Model separation would let that happen. In a future release, What is being done for WinUI, would be done for UIKit, having separated, kind of full powered, native controls.

And yes, we would have a small set of xplat controls, like today, for an one size fits all lazy and simple approach to be used on xplat windows (the current model).

This was a great session. I hadn’t been paying too close attention to what was being worked on. I was really surprised at how nice this feature has turned out.

I really like the idea of the basics being rolled into the old controls, while the XAMLContainer remains to have very custom UIs for Windows when desired.

Who knows where this leads to in the future. Maybe down the road .NET MAUI will offer a way for Xojo to take advantage of this in a cross-platform way.

In any event, knowing XAML isn’t the worst thing in the world since it is so prevalent in Microsoft front ends (which does not mean Windows only in today’s world).

image

Interesting times we live in…

Anyway, I have to congratulate @William_Yu and Xojo for bringing forward a great update to developing apps for the Windows platform.

4 Likes

Well, a lot of people asked for modern UI on windows and this may be a way to get to it.

The concept is not new as I think William showed this as prototype years ago.

A lot of questions remain and may not be answered until Xojo staff tries to implement it. Like how a canvas plays with controls if you have a canvas behind or in front of the new controls. Or how they want to transition the listbox. And how older controls via plugins play along the new ones.

Calling methods with an invoke method may not bring you far. Since calling a method to do something on the control may need an object as parameter and how to make one? Like passing a Pin object to a map view.

And then the whole transition. Like can we turn it off to build an older project without adjusting the windows?

1 Like

The day that Xojo makes me use .Net for a Mac app would be the day I stop using Xojo.

I know that is not what is being suggested by Xojo, but comments like that from @Michael_Stephan just make me shudder. Native Mac applications and controls as much as possible is the only way I would go.

1 Like