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).
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
I didnāt mean to suggest that Xojo should seek to replace the native controls, but instead maybe leverage the amazing flexibility XAML provides for creating more custom UIs for different platforms possibly at some point in the future. Maybe it would be possible by using the .NET core runtime that is available on multiple platforms. Of course, .NET MAUI is not even a year old at this point, so who knows what the future really holds.
I donāt see XAML controls as a replacement for native controls for Mac or Linux, but instead maybe a replacement for something like Electron apps that can provide a consistent look and feel across all platforms - if that is what the developer was looking to accomplish.
Iāve certainly no interest in making my Mac look like a Windows machine. 
Iām certainly of the school that apps should look and behave like the rest of the apps on the platform do, and that they should adopt the changes in look that the operating system versions make. Putting a .Net or XAML layer between the app and the platform pretty much complicates that issue for no benefit (if you start from this point of view). Putting XAML on Mac in no way helps your Mac apps look like a Mac app.
Iām aware that there are apps that like to offer āskinningā, but thatās a feature that I would never wish to have. It makes me think of the 80s were websites used every available font and colour, all on the same page, just because they could. Pretty much the visual equivalent of the time sound cards came available. The tend to attach silly little noises to every action imaginable. Iām having flashbacks to āIām sorry Dave, Iām afraid I canāt do thatā when ever an error dialog is shown. 
1 Like
Without UI it wouldā¦ ahhhā¦ work? With maybe some additional steps? But thereās no WinUI outside Windows.
To Xojo make WinUI desktop like apps run on a Mac they will need to use UNO, a WinUI replacement, C# dependent, and Xojo would need to change its IDE to be a transpiler from Xojo to C# behind the scenes depending on Visual Studio as Xojo Android is a transpiler depending on Android Studio to use Kotlin.
While I generally agree with everything youāre saying, there are plenty of situations where controls simply do not exist on the mac, and where the app doesnāt need to look like a mac app. Think of all the professional video editing, color correction, vfx tools - none of them really look like the OS theyāre on, in part because there are so many controls they need that simply donāt exist in the built-in toolsets available, or arenāt available cross-platform. Hereās an example from Resolve, which looks the same on Mac, Windows, and Linux. I donāt find this to be offensive because it doesnāt look like a mac button, a windows button or a linux button, and I use this app every day on all three platforms. If anything, the consistency across platforms is a benefit!
Or also from Resolve, a color wheel like this that has to have very specific behavior. I could see this being implemented with XAML, based on that webinar, pretty quickly:
I am 100% about keeping as much native as possible, but there are times when you have to venture outside the native controls and make custom stuff and XAML looks like a great way to do that. Iām looking forward to trying it out on an app Iām working on soon for Windows.
1 Like
yes, there are native color wheels. No, theyāre not really the same. Also, that much color on screen messes with your eyes, something thatās bad when youāre color correcting. Thatās why all these apps are grey with minimal color in the user interface. But the color wheel was just one example.
Many apps will be absolutely fine with native controls and should use them. But there are always going to be cases where the controls you need simply do not exist and need to be created from scratch. Hereās a good example, again from Resolve:
This is the node tree for a very simple color correction to some faded film. it requires 7 nodes each with slightly different types of adjustments, connected together in a linear pipeline. These can get much more complex when you start adding in trackers to follow and limit effects to certain sections of the frame, for instance. You could set this up pretty easily with XAML. (Yes, you could probably do this in a custom container in Xojo, but everything this does could be done more quickly with XAML, from what I can see in the XDC presentation).
Fair enough, but one of the nastier parts about using Lightroom and Photoshop with having to deal with their alternative dialog boxes. Thatās what I think of when application start bringing foreign frameworks over for interface work. The odd control here or there could be OK, but is all going to hang on the implementation between platforms being constant.
Wholesale implementations, because theyāre easy for the developer is never really a good thing for the user.
Nova is another company that is obviously using some whacky interface layer to make their lives easier. You can tell by the fact that their windows donāt even have the right corner radius on newer versions of macOS. Obviously there are many other, more important, issues that make life more difficult than it should be. However, it is the best of a bad bunch when it comes to HTML editors for the Mac, since Iām no longer willing to pay for DreamWeaver (which has itās own issues) on subscription.
1 Like
Do you ever used GIMP or JDownloader2 (this one is developed on Java) ?
No, I especially dislike Java, the installation and updating is pretty annoying. In work I had to use it and in particular an old version that was only supported because the university paid a lot to keep it going. It became increasing frustrating. I also found it to be far too slow for me personally.
1 Like
Two. I have the same feeling for anything with instructions like:
- First, install our runtime engine.
- Then install the program or it simply will be garbage in case of missing the proper runtime engine.
3 Likes
This reflex to have 100% native controls dates back to the time when the Mac was on the verge of dying, drowned in a Windows and Java world. And those Windows and Java worlds were so awful and so far from our OS X world! Mac OS X had just been born, it was the last chance of survival for the Mac, it was so beautifulā¦ You had to support it intensely.
But the situation has completely changed, and itās funny to see that a reflex to have as much Mac innovation as possible has turned into conformism. On iOS, many UI innovations have came from third-party applications. And thatās fine.
I didnāt follow the thread well, but I guess the suggestion was more about being able to manipulate native controls through code like this.
Thatās kind of what we were doing with the Titanium SDK a long time ago: it was possible to create native IOS and Android apps, with native controls, using XML to describe the views, controls, etc. (and javascript to manipulate them, code, etc.). And it was great. We get so caught up in our habits that we sometimes forget that there are other interesting ways of doing things.
1 Like
I assure you it doesnāt. It comes from the desire to offer applications that work the way people expect them to do, the way their other applications do. It has nothing to do with Windows at all. I used windows from version 3 (even before 3.1) and got on fine with it. I would be complaining just as much if someone tried to port Mac controls and behaviour over to Windows.
2 Likes
Only developers think like that. As weāve seen in the mobile world, itās actually the users who have embraced the new UI innovations in third-party apps, and who have ultimately pushed the OS manufacturers to adopt them. The situation has reversed.
There are no longer pure, perfect native controls on the one hand, and horrible, ill-thought-out non-native controls on the other. Users choose the best, no matter which company produced the innovation they like. They donāt care where the innovation they like comes from.
Now, sometimes there are poorly thought-out native controls, and great non-native controls. And sometimes itās the other way aroundā¦ In the end, the user decides, and the OS adapts.
2 Likes
Counterpoint: Users today are increasingly multi-device. When REALbasic was started, the mobile platform didnāt exist, and many homes did not have a computer at home. The only computer many families had access to was at work, school, or the library. So odds are, theyād stay on a single platform. Then, native controls made the most sense every time.
Today, most homes have at least one computer, which may be a different platform from the computer used at the office, and mobile devices are everywhere. The value of native controls has waned in favor of consistent experiences between devices. Slack on Mac looks and works the same as Slack on Windows and iOS. Thereās significant value in that, both to the user and to the company who has to document and support all those devices.
The landscape has changed. Users donāt care. Never once has my wife, mother, or kids ever complained a button looks wrong, but they will absolutely complain when something doesnāt work as they expect. Keeping the experience the same between platforms has become more important than keeping the experience the same as the platform itself. Iām personally not a fan of saying that, but itās just the reality of the market.
12 Likes