I saw the blog post about this and my immediate thought was “why isn’t the XAML container just an empty rectangle on the other platforms?” That would make the use of these things a lot easier.
2 Likes
Yep. For other platforms, a DesktopXAMLContainer should render as some kind of a “special DesktopRectangle” with equivalent do-nothing events of a DesktopXAMLContainer. All layout space and code preserved, doing nothing until replaced by something proper for such platform.
I’m curious what the purpose of “subclass the control” is in that blog post. If the placed control won’t compile, surely the subclasses one won’t either.
That would certainly make it easier to put one on a pagepanel with other platform specific controls on other panels.
1 Like
I thought the same, I’ve read the article very superficially without interest as it looked an herculean effort to make a do-nothing control to do nothing and my mood was just “Meh!”. But if someone wrote an example, they made it.
I already said, with Xojo becoming “specialized” on each platform, Xojo needs a more MVC approach. You make entire “views” discarded (not compiled) if not set for the target platform. And the one set will assume the UI in its place.
Isn’t there already a “compatibility flags” system built in. You can see evidence of it in Modules, where you can choose Desktop, Web, Console etc. Could that not be extended to include Mac, Windows, Linux etc. If extended to Window, ContainerControls etc it would be a great benefit.
It would also pave the way towards a universal project type, were you could include mobile windows for mobile apps, desktop ones for Desktop apps etc.
I’m torn on that idea. On one hand I can see a benefit for being able to separate Mac, windows & Linux from one another, but the idea of being able to put controls from different project types into the same file would be a huge change for Xojo and feel that their time would be better used elsewhere.
The problem is that you’d have to do the same thing with all the linkage code as well and that would be a huge pain to maintain. I’d rather have the XAML control just be a null control on macOS and Lunux that could just be closed and set to nil.
1 Like
I was thinking along the lines of window with the same name etc. However, by introducing a control that just doesn’t work on two of three platforms they’ve already broken the cross platform abilities.
The idea is keep the current way, Desktop project, just set views to “Target platform: [choose them]”
Target platform can be any combination of Windows + Mac+ Linux, default to all those.
Then you can duplicate a Window, select for example Mac only, and remove the Mac from the previous one. So you can adjust that window to Mac only, and one generic for the rest.
The names can be duplicated as they won’t clash (unless you set mac in both on error) but the compiler will notice it and will alarm the clash for inspection.
Both windows can be called windowInputData for example. But when compiling for Mac, one is chosen, when compiling for Windows, the other is chosen. Shared code as windowInputData.Show will just work anywhere without changes.
Specialized code will need < #If TargetWhatever > in specific places.
You know what? I used to ask that same question and was assured by Geoff that if something existed only on a single platform that it wouldn’t prevent Xojo from offering a control only that single platform. This XAML thing is a hack while they get the actual controls created, but I’d rather the controls get created than worrying if they exist on macOS and Linux.
1 Like
Other tools do the exact same thing. Many controls available are native, so many simply doesn’t exist outside that target platform. And the user do what I said, have separated views and a “common interface” to talk to the view. A MVC kind of approach. There are others that took a much more complicated route, and ALL CONTROLS are not native, but complete drawn bit to bit to simulate the native one. The second one takes an insane effort Xojo in no way will be able to compete, but the first one is… kind of simple?
The way Xojo handle its palette of controls should change for easy location of controls based on targets too. Xojo would start as is today. A palette of “Shared ones” (works on all them, some are not native as ListBox) to achieve that. And then will add native ones in other palettes.
I agree about the stock controls. They will be just there and work via XAML transparently. I get that.
However, the now that people have the flexibility of the islands, that isn’t going away.
Sure, Windows only control. Should raise a compiler error if found in an incorrect platform. 
That would kill the idea of a cross platform project, not a good idea. You either need a way of saying to not include it, or for it simply to be completely ignored by the compiler when used on other platforms.
Nope. I already explained how.
Doing nothing while expecting doing something is a door for errors. Errors can’t be silent. And that’s why the behavior should be pointing an error asking to use a proper “whatever” there, at least remove the offending control, but better using something equivalent to the desired platform. And that can be achieved using separated views.
But that is either a radical resign of the whole of Xojo or the same as my idea (compatibility flags).
I guess you are not getting how the thing works. What I said sets some attributes for some objects (I guess it is kind of similar to what you think as marking flags) as compilable to some desired targets. I don’t want to repeat again what was already written. I think it is enough explained. It’s not radical, and whatever you think about flags can be a bit analogous, but maybe not completely, if you are not used to the concept of separation of concerns and UI isolation in separated views, in this case chosen at compile time in the proposed ‘simple’ design. 
What I described is already a part of Xojo and could “easily” be implemented, without adding much extra. It’s kind of the equivalent of TargetWindows / TargetMacOS, but applied to a whole Window or module. The Mac/Linux platforms would simply not know the control / window existed.
You mean with the Compatibility Flags? If so, then I’m sorry to say that it’s not as easy as you think. The last time I looked (about 16 months ago) the IDE didn’t have a built-in way to have controls from different project types in the same project. Code is one thing, controls are completely different. It brings up many different challenges, both internal and external, which will take a lot of time and planning to get right.