XDC Day One Thoughts

Keynote:
Typical. Nothing to move on. Numbers given with no context. Platitudes about change. Platitudes about bug fixes and quality.

XAML Control:
I think they’ve forgotten what made Xojo good. This ‘solution’ means having a window/container for Mac/Linux and a window/container for Windows. Seems like a better solution would have been to create a background XAML control that mimics the controls they have now with an event/property to customize it. The demo’s were nice and its obvious that William has done a lot of work on it but I don’t see how this works in anyones workflow that does cross-platform work.

In many respects this presentation reminds me of version 1 of Cocoa presented oh so many years ago where I walked about the session say, “Yeah, I’ll never do that.” It was too much work and did nothing for my Windows users.

Android:
The amount of time, money, and effort that has gone into Android would have been better spent on projects that could help EVERY developer rather than the small subset of developers that are interested in mobile. The goal of being everything to everyone simply means they’re not good at anything in particular. They’ve lost what made them special in this pursuit of more and more targets.

I did not watch Paul’s session.

Overall:
The pursuit of ‘shiny’ keeps interfering with the pursuit of solid/good/useful. In many ways I’m glad I’m not blogging about Xojo any more because I would find it hard to come up with nice things to say. Don’t get me wrong, I’m keenly aware that the developers work very hard to get these things done. And if I was working there I’d be doing the same thing. However, I feel like no one is challenging/asking IF they should be doing them.

3 Likes

This!!

Or like “discussed” here:

My opinion: the underlying old bugs are perhaps getting a prettier ui look (assuming XAML will not have bugs at first launch, which of course it will have).

It is as shame. And all that while the IDE still needs a significant amount of screen space to show some big buttons …

And as in the past, people are excited, and will complain soon about delays or just new bugs. That’s what you describe perfectly that they have too much on their plate, and now just another huge topic.

Last but not least some people seem to like the new love for Windows and agree that they mainly use Windows only. That’s ok, but why should I then use Xojo at all? For those who really need / want cross platform XAML will be (at least at the beginning) a huge step back IMHO.

Disclaimer: I only swiped quickly through William’s video and the TOF postings, don’t have the time nor the interest for a deep dive into Xojo topics.

1 Like

Thank you for the excellent summary! I couldn’t bring myself to watching the keynote.
From the posts in TOF it can be taken that many devs who actively use Xojo are confused about XAML.
There is no clear timeline when things that are promised to converge will actually do so. All promises.
Xojo has indeed a good dev team. The product manager, however, is doing a horrible job.

Remains one recommendation we can give to Xojo customers: lower your expectations!

2 Likes

https://forum.xojo.com/t/my-popupmenu-control-project/75442

A Xojo pop up control cannot display a larger font correctly.
How could XAML help?

I’m assuming the XAML would help with Windows since it can be customized with more options - but that is a guess on my part. On the Mac and Linux side there is no customizations (that I’m aware of) to make the control larger than the default sizes.

According to Christian Schmitz:

“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.”

So this is their path to WinUI API, but my thoughts are:

  1. I never loved XAML

  2. XAML = Xamarin and Windows Presentation Framework (WPF). From what I can tell WPF is being put out to pasture semi-unofficially (now supported by MSFT India, where technologies go to die). Meanwhile, WinForms appears to have been given a new lease on life and they have returned to actively investing in it. And with WinForms XAML isn’t in the picture.

So I conclude that this may be a little bit late to be committing to XAML on the theory that MSFT will always support it. Also, I believe I’ve read that building decent interactive designers for XAML is way harder than it looks or than you’d think it is.

All in all, my spider-sense is tingling …

1 Like

exactly
if you’re going to have to write xml to use this right as well just use VS and get hot reload & everything else

Lately, I’ve been getting annoyed with myself for constantly nagging. It’s encouraging to see that Xojo is dedicating more time to Windows and has plans in place again, among other things. However, when you examine it objectively, it’s evident that the cross-platform concept is becoming increasingly diluted.

Xojo has always promised to compile your code for all platforms. Of course, it’s not entirely Xojo’s fault that this is becoming increasingly complex, but soon there may not be much left of the original promise. We saw with Web2 how many users were surprised to find that if they wanted to go beyond the standard offerings, they had to learn CSS and JavaScript on their own. Despite all the enthusiasm around XAML, this scenario will likely be no different.

Considering that the Xojo IDE is beginning to show its age, runs slowly, and lacks modern features such as git, CodePilot, refactoring, and more, there seem to be no advantages in that regard either. Furthermore, the presence of UI features like XAML does not alter the fact that hundreds of bugs in the actual language remain unresolved.

I believe Xojo is on the verge of acknowledging the truth: while cross-platform compatibility remains the stated objective, it increasingly deviates from the original concept and views it as a temporary necessity at best. This situation benefits plugin developers, who can seize opportunities to create even more plugins that aim to simplify or maintain cohesion.

Xojo may need to entirely revise its strategy, focusing on a tool that generates only boilerplate code for all platforms. They have already begun adopting this approach to some degree with Xojo Android. However, the effectiveness of this strategy remains debatable. While it might seem like a good idea on paper, it appears nearly impossible to implement given the current staffing levels.

In addition, Xojo faces significant competition from AI. Although these tools do not generate flawless code (and that is unlikely to change anytime soon, but possibly faster than many can envision), obtaining assistance and gathering ideas for designing algorithms in a new language has become considerably easier.

Lastly, it is essential to consider today’s overall effort required for cross-platform development, including signing, design, installers, and the fact that each platform adheres to different design principles. A valid question arises: should you tackle this as a solo developer or a small company wanting to handle everything in-house, or should you specialize in just one platform?

Alternatively, you could use a tool specifically designed for this purpose. Naturally, compromises must be made, but with Java, you have an approach that, even in 2023, still delivers on the promises Xojo made two decades ago but can no longer uphold.

You can choose to use web frameworks for the front end and accept the limitations that come with them. Alternatively, you could opt for Rust or Go and deal with the compromises of their rudimentary user interfaces. With these options, you gain a modern and relatively bug-free programming language as a foundation.

However, if you wish to fully realize the original promise of Xojo in 2023, Java is likely the best choice at the moment. Not everyone will share my opinion, but the idea of another “Man in the Middle (XAML)” just seems like the next bug slingshot to me. In any case, the original idea of Xojo is channelled again and that’s a shame, but unfortunately unavoidable.

2 Likes

To Xojo’s defend, you have to admit, the uncertainty in Windows UI and design languages is based on the erratic course of MSFT the past - lets say 10 years.

1 Like

MS’ flip-flopping about whats the long term UI toolkit is definitely on reason Xojo didnt move to anything else from Win32

It was never clear what their long term commitment was with Winforms, WPF & Win32 or WinUI

Now that seems to be more clear so it make sense to do something
Just seems sucky that it wont have any cross platform applicability so now Xojo becomes less x-platform if you use this
:man_shrugging:

Fair argument. They could have worked on a true x-plat enabling abstraction layer instead of doing API2.

3 Likes

bah

quit being sensible :stuck_out_tongue:

oh yeah, you’re all right, I don’t envy Xojo, not at all.

But after more than 2 decades one might have to ask oneself whether “native controls” is still worth striving for, especially when the Inc. has fewer developers than platforms and their derivatives. The future only offers one certainty: there will always be changes.

In addition many devs are less interested into native look & feel. Okay, who knows, perhaps that might be the future unique selling point and the final break through for Xojo, but I doubt it :wink:

3 Likes

There are a few people with wanting native. Most of them I know and met (and yes, all of them I met were only online) are Xojo programmers. All the others: don#t even bother bout. That is a big difference. But when always telling naive is the only thing worth to think about and to consider and also ranting bout apps which are not native UI on IOS or Android or what ever will bring the customers to. native. And then not to present the native in 64 bit is painful. Not ore, not less. There is no need for anymore. And yes, I know, all of the customers of the customers are wanting only native. I have the experience totally different. And there is no need for thinking about. Yes, I wrote a few mouse events for coupling copy paste native like. Not more, not less, that’s it. I can’t recognize the needs for always and only native in the market of people looking at the same moment for Swift UI for Windows, Flutter and Dart, and the same for Desktop and so on.

ja but then it wouln’t be “native” (whatever somebody is understanding with this term).

I am one who is always in favor of “native” controls. Mostly because only with native controls you have a good chance, that your business software works in Windows Terminalserver Enviroments (RDP/RDS), here’s a video of my software:

Everything with HTML Webcontrols, Flutter etc. has problems in high-latency/ low-bandwith Remote-Desktop-Connections. This was in 2009 aswell today in 2023.

1 Like

Good news for Xojo, as Microsoft plans to sunset the terminal server in a few years :slight_smile:

Don’t believe that, RDP/RDS is crucial for everything in their cloud. Do you have a link or source for your statement?

Both approaches have value in different ways

Native, for instance, means that if you turn on accessibility in iOS macOS, possibly Windows & Linux as well, that the controls just works expected for that use case and screen readers etc can deal with them
Emulated controls may not
And non-native controls may have other characteristics that are not “platform correct” that people will notice. The IntelliJ based IDE’s and VS on macOS do this and it drives me crazy as their editors do not behave like any other text editor I’ve used on a Mac for the last 30 years.
Many short cuts are just wrong

BUT the “non-native” controls may be easier to create a consistent look & feel across multiple targets

Theres no necessarily right or wrong answer to this that works for everyone
You, as developer, and your client(s) have to decide which option works best for what you intend to do

That is what I would expect as a low code developer. My code uses one control for all target platforms of a window. If I’d had to code it separately for each target platform, low code is gone.
I’m not saying that ‘Xojo-native’ controls are the best of all solutions, as many of the current ‘native’ controls have severe limitations.