Is Xojo on a downwards trend?

Yeah Listbox is really a work horse and should be redone with newer native controls and not be the Swiss army knife thats not native everywhere

but I doubt that will happen any time soon

He said always “not needed” or “people will shoot their knees”. Will that help? no. The big problem is: there is no need for this kind of gui. It ListView is the best example. It is slow. And it is everything but native. Under Windows, Linux and macOS it is crap. But it is simply the only available. Try to compare the performance of a complex JavaFX Table with the Xojo ListView and you will see: the simple JavaFX Table View and also the Java Swing JTable are much faster with a complex table than a Xojo ListView with only a few entries in a simle list.

But like always; it is at least still working and makes no problems. So no problems directs to: never change a running system. And that exactly is their only way. If you have no people for BugFixes why should you write a new component while the old one is too stlow? They will not. What triggers me is this scattering about “native”. Xojo GUI isn’t native. And to become it really native looking it is an extreme effort. The Display behavior is also not really native. Anchors are missed like I have in Swift for example. Look in the fine grain of the UI you will realize: the Display looks in it’s first view like native and uses also native components. But the behavior is never like it. SwiftUI is much better.

Even if I am writing most Applications as Java XPLAT: some I am maintaining and actually one I am writing just now are native applications. And yes: I have the same problem. I need native for macOS in this case. So I am writing the application native.As I said: the Xojo behavior, scaling and positioning is not the same as it is with SwiftUI on macOS. So I need to use something really native. SwiftUI. Simply. There is no native Xojo as an alterntive. Between the big problem of needed Workarounds and tricky UI, massive declares and so on and the code consistency between versions of the IDE it is also so that it is impossible to work with Xojo in a performant way.

Why I am writing this? Because I have to listen too often about “not native” and the NATIVE XOJO. I can’t listen to this. It is not native and that’s it. Let’s say Xojo is the simplest way of kind of native. I would agree. But please, native is different. And we have to realize that it is impossible to ignore the differences.

By the way to use native controls with Java you can use Eclipse SWT. It uses Cocoa and has as a result the native GUI. It uses a native GUI framework for XPlat programming. And it uses always native components. You can control the views in a fine grain. But still: not like it is with SwiftUI possible. But better than with Xojo. By the way it can be installed for free as a plugin in the free IDE Eclipse. Even that can be used without problems for building native GUI aplications. The fundamental reason that I was never writing about: while still even SWT is not a native GUI. That what I had everytime to listen to when people spoke about the Xojo Gui and the difference to swing and JavafX.

At the end you can do what you want. No question. But to have the GUI really native it is needed to write the App native. And possibly it is for you more comfortable to write your code in Xojo language. Feel free. It is a good thing to do that what you can do. No question. Be aware of the small ecosystem behind it. That’s it.

But where is the difference? When and if I write Java GUI Applications in most cases I do not care about native GUI. Why should I. And I also don’t care about native GUI behaviour. Many systems are acting like this. It is not only Java Swing. Also all javaScript based applications. And many ways to generate apps for XPlat more. If I have the requirement of native GUI I can’t use pseudo native, At least not in my “world”. It is the same problem which I have with IOS and Android applications. To be clear. I have many of them I wrote but XPlat. I have got this jobs done with CodenameOne and a not native GUI. A few with GLUON mobile. But the rest I had to write with native GUI. Two I realized with Kotlin Multiplatform mobile. Quite nice with a native GUI for both, Android and IOS. a bit more than a dozen we realized as native Apps for IOS and Android. And there is the difference. As it is now, Xojo can write Android apps and IOS Apps. As native GUI applications. The Android one is realized with Kotlin as native Android App.

As far as I can see there is no other possible way to act. Native GUI use in Kotlin multiplatform mobile allows you that. I guess that will be also the future way for me in case of mobile XPlat. But for Desktop? There is a small problem. macOS users often are used to the fine grained UI System of macOS. It has a unique look and feel and also layout management. Not comparable with Windows and Linux. So I can not see another way then writeing native code for macOS if native UI is needed.

3 Likes

Open a Xojo app in Xcode’s View debugger and you’ll see what IS and isnt “native controls”
You MIGHT be surprised

FWIW the IDE WILL be awful but it is still operable in view debugger - mostly like using a ton of custom controls based on NSView in Xcode

1 Like

It’s not flickering , I am trying to do 3d rendering but you can’t call update from a time me or thread only buy using a infinite loop in the main thread can I update it, mac works ok. Which means I can’t port graphic apps to windows.

A timer can call the canvas invalidate method (refresh is way more heavy handed)
In a thread use the UserinterfaceUpdate event as at that point it IS Safe to do something with the interface

I’d have the canvas backed by a picture where the actual drawing is happening at whatever rate you want and whenever you want into that picture

Then the paint event of the canvas just draws the updated backing picture

Under API2, Canvas.Refresh is the new Invalidate. It takes an optional True parameter for “Immediately”–aka the old Refresh. Might(!) be useful info to someone :slight_smile:

1 Like

I really didn’t like that renaming as there is a clear difference between “update this view when possible” to “stop everything and update this view and any overlapping views now”.

labeling both as “refresh” is asking for trouble. They should have called invalidate, markForRefresh or something to that effect.

1 Like

In short: they had no Idea how to handle it and done something. Best is: getting rid of this policy while it kills creativity. Nothing good coming out to follow their policies. The drama of Web 2 and API 2 will not be the last one. Starts wird msgbox → ok better messagebox → ok better msgbox. It will not help anybody but they felt good: we have done something.

There is the need of an API 3 for clearing the differences between the platforms.

1 Like

Yeah - this is known as control coupling - where passing a parameter alters the flow of control
And is usually NOT a desirable trait - but I wasnt there to argue against it and probably would have been overruled anyway since it would be “very computer sciencey” (Is that even a word - sciencey)?

I’ll stick with invalidate until such time as they remove it as the [purpose is more clear

1 Like