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