Maybe it is a lot of work to fix the underground problems first but they could improve things under the hood with the same framework instead of adding “new” things and make users waste a LOT of time and money rewriting stuff.
its juts funny that a framework that was MORE capable is being hidden under one that is less
Introspection for instance
The “new” Introspection could inspect & tell you about ALL types - intrinsics or not
The “old” cant so you have to kind of hack around that with a variant to see if it is one of the primitive types
Datetime is way more functional
Text was as well (although not as speedy because it did things right)
And there were other examples, like memory block vs mutableememoryblock, where lots of speed optimizations could be applied to memory block because it was NOT changeable
And, probably THE biggest thing was it was entirely optional
You can actually mix & match code
What they’ve done with API 2 makes that not so optional and silent breaking changes happen
Again - all history
Renaming controls, events, methods, properties & changing things to be zero based indexes vs one based was just a waste of time
Its THE reason I’m now rewriting an app in C# with MAUI
I literally get the 2 targets the client cares about from one set of source code
I cannot do that with Xojo in any time frame
1 Like
Well even with missing so much what C# or Java offers, I could create enterprise grade Software and live from it. I even accepted the hollow announcements and unfinished features 'cause I knew, it will be finished in the next following release. What really broke everything was API 2.0 and the fact, that all my own business objects once created and gradually improved through a decade, become obsolete overnight. You just can’t go ahead and rewrite this.
You’re far from alone there
Lots of people found API 2 and the renaming of everything to be the final straw
It was a move that CLEARLY told everyone who had supported them for any length of time that they just did not give a damn about how this would hurt
And, as has a been said before, if you have to rewrite it anyway, why not move to a IDE/framework/language that DOES support all those things that are missing ???
Async/Await is handy as heck !
I dont expect to ever see that in Xojo
Preemptive threads ? Already delayed because of issues (no idea what those might be)
And yet a jump to something else I get them and they have been well beaten up and tested over many years
1 Like
I thought it was hilarious when someone on TOF told me the reason I left Xojo is because I’m incapable of learning a new programming language.
Ahuh…
3 Likes
There’s no denying that New shiny and discounts do appear to acquire new customers.
Sacrificing your existing customers in the hopes of acquiring enough new customers, is suicide… We’ve seen both Xojo and Apple do this and it tanked theirs reputations massively. I read recently that our generation (basically people over the age 30) are abandoning Apple’s products, because value wise they’ve declined.
Taking care of your existing customers, not only improves your product, it improves your reputation and further more, the enthusiastic of the community, improve your marketing.
Xojo had to move to mobile, there’s no doubt about that. But Xojo doesn’t have any specialized developers, which is why it took so long and why it came at the expense of existing targets.
Ideally, Xojo should have gotten a loan, hired a bunch of platform specialists and whipped it out in a few years. When they built iOS, they should have already designed it to be “mobile” not iOS and left it in a state that it would be easy to add a second target too.
2 Likes
Desktop for windows has some serious issues , the canvas bug is an issue for me the tab panel also.
Canvas bug ?
Refresh my memory ?
Can’t. Memory bug. 
2 Likes
Overflow ?
Hi Norman,
I believe that @DaveDuke might be referring to a few of the bugs with Xojo’s Canvas. A few of the many Windows issues which I immediately remember are:
- flickering
- slow speed
- Mouse movement changes canvas redrawing speed
Most of these Xojo issues are blamed on the Windows operating system. This, unfortunately, is false. I have written Xojo plugins for GLFW, OpenGL, and Windows (see OpenGL 2.1 64-bit for Windows) that releases the slowness of the Xojo language, and provides rapid updates in visual quality, refresh rates, and graphical speed.
Although I wrote the pluign for OpenGL, many of the same Canvas refresh issues also occur in the Xojo OpenGL control.
@DaveDuke is what I am saying, accurate in your situation?
Warm regards.
Edit - grammer
1 Like
Flickering is something I have seen, but have eliminated from the apps I have that use canvases. While Xojo made canvases automatically double buffer some time ago I basically triple buffer it. I write to my own picture then just have the canvas draw that picture.
BUT I’m also NOT trying to do animation so YMMV
Speed is an issue in all of Xojo
Mouse move affecting redraw speed probably has everything to do with Xojo being single threaded
1 Like
Speed is an issue which could be changed. Mana stuffs are not needed to be so slow. And they have done already a speed up. Not as fast as c++ or Java but still it was a move in the right direction. The GUI problems are omnipresent in Xojo. It is not native but looks like that and it shall under all circumstances be multi platform compatible. So Xojo has to build up it’s own internal API for the GUI elements and components. Sometimes they are not as good as native components. Something you may be aware of. We have a speaking. You can put a goath a nice dress on. But: Goath will be ever a Goath. And that is the problem with Xojo. It looks good dressed but…
And that is the problem not only since API2 and not only for a short time. It was always the problem of xojo. And in that entire time it was never changed and became never better. Xojo always had half baked features and not ready functionalities. And there will possibly never be a Xojo Version with new functionality which is production ready.
Coming up to the question: is that production ready? In my eyes not. Not usable I would like to say. Yes, you can write Apps with it. But the price is a big amount of time for becoming ready with it. And money. And later you may have to pay again while you need to write an Update and get out: ups, my code is not running anymore. Can be happened. Is happened. Often.
It is in many places native controls with just a Xojo API on top of the native control
There ARE some that are not
Otherwise you could not use platform specific API’s to alter the controls appearance and behaviour the way you already can
Declares would be useless
But there ARE definitely non-native controls - LISTBOX is probably the big offender
And there are ones that are native on one platform and not on others (segmented control was that way at one time and I have no idea if it still is that way)
I’m sure there are others that fall into this realm
1 Like
The way they implemented them is also not helping that all controls behaving native. But hey. Priority Number one is: native.
The ones that are done using a fully platform native control do
And when/if you need to alter their behaviour you can mostly alter them to behave better (like making the TextArea on macOS basically into the editor in TextEdit - you can enable rulers and all kinds of other features)
But not always
Toolbars for instance are particularly painful despite them actually being native macOS toolbars
There’s no mechanism to do whats required to make toolbars user modifiable etc
So you can alter some of their appearance but not alter everything about them
Look I get this DOESNT matter to you - in some ways that is enviable
To some it DOES. A lot.
No need to poopoo others & that choice just because it isnt important to you
1 Like
Pseudo native isn’t native Norman. Then do it like I do: use native. C++ on windows and Linux andax with qt and swift for Apple devices,java or kotlin for Android. Simple, isn’t it?
It is strange not to do that. If I want native I write native. Simple. It is not even expensive. As far as I know, swift and c++ are for free available. Qt as dynamical linked is also available for free. So what? Native is native and not kind of.
JoJo produces less native this then java set does. Ah. That I forgot. It’s also NATIVE. But I would never sell an app like that as NATIVE GUI.
This is basically what Apple does, but on the GPU and you’d don’t really need to think about it. It’s why animation on a Mac can be so smooth, because it just changes the location of the buffer in the composite.
It’s also a reason as to why the 8GB (of shared RAM) is not enough, if you open a complex UI, each and every control gets it’s own RGBA buffer, then each Window and then finally each screen. All taking away precious memory from that shared 8GB.
NSListView does do lazy loading, which means it only has enough views in GPU memory as what the user can actually see.
Meanwhile the Xojo Listbox is still a 90s control, so every-time it changes, everything and I mean everything is redrawn, that’s why it is so slow compared to a NSListView. I wanted to change that, Geoff said “Not needed”.
I have no idea what you mean by “pseudo native”
Imagine in C++ you had a header that exposed a Windows Win32 button, and using some ifdefs a macOS Button, and more ifdefs a linux button
The API exposed is the same for them all
Its a native button everywhere
The API is their own - but you CAN use the platform native API calls for it as well
How is this NOT a “native control” ?
1 Like