Reading about multi threading, looks like xojo may not be even suitable for modern day desktop applications, what a shame, getting convinced to not even use it for desktop. Am I overreacting or misunderstanding this whole multi threading thing ?
2 Likes
I am probably biased due to the reasons I stopped using Xojo and would recommend using a different tool. There are a lot of good ones out there. Unfortunately you will need to find the one that does what you need it to and you enjoy working with it.
1 Like
Multithreading is bringing the power of modern Systems. On my 32 Core 64 Thread AMD CDU I can use all the threads of the CPU and I have the computing power of 64 threads and not of one. The small difference. In Java I am using often threadings to fulfill database tasks and so on. Ends always of with a nice performance. When doing everything in one thread sometimes it is a bit of a problem. But okay, Xojo has letās say 200 concurrent users for a Webappā¦not that much.
Also it is so that my Webapplication writtn with the vaadin framework and the play framework is also threading. So even a few thousand concurrent users re not a problem.
1 Like
Yes but I strongly recommend using c#, java, Kotlin, go ā¦ letās say one of the established tools. And look which platforms you will run on. IOS-MacOSā¦Swift I would recommend. Android Linux Windows Web I would recommend Kotlin Multiplatform. Windows and Webā¦C# and dotnet. Web only: I rally fell in love with Java so I would recommend Vaadin. One UI Desktop and mobile (IOS/ANDROID) I would recommend Codenameone. So you can see: there are different decision bases. I can write desktop- and mobile also with Gluon Mobile and JavaFX. There are tons of possible solutions. The target platform mixture is the problem.
Should you switch, yes you should. Xojo have continually let many of their customers down over the last 5 years and the CEO has shown zero understanding or care.
It was a discussion with Xojoās CEO that pushed me over the edge. It was pretty easy for me to move as I only care about the Mac, but it will be a while before I have learned enough to move over a project as complex as Sleep Aid.
1 Like
Itās 2024. I canāt imagine trying to sell proprietary dev tools in the open source era.
2 Likes
Iād say the minimum requirement is the language and compiler to be open source.
1 Like
No will never be happened with this ceo. He want to sell for 799,-. Thatās it. And it is okay. But he has not the needed power to get the product in a production ready status. And that makes it impossible to use. Do you have a product relying on Xojo? Not a soooo good Idea at all. And I believe that will not change. They had chances. For example: the chance for one Language for IOS, Android, Web, Desktop when implemented Android with Kotlin. There it was: the chance to have native GUI with Android and IOS, Desktop and Web. Or the chance to have one GUI for all systems in one. What ever. They donāt want to have this. They started again to build up a mess mixture. When having this kind of stuffs: start to simplyfy. They builded up big parts of xojo langauge. They can do the rest. It is not a problem to implement the stuffs with Kotlin. Building the same compiler platform would be possible so building on all platforms for all platforms except IOS is possible. And it it always native compiled.
But they do not have what they would need for it: two hands full of programmers and a really goog compiler guy. And threading would come for free with it. No trouble no harming.
me a few weeks ago: the multithreading thing is probably overblown.
me testing something last week: (&#$(&%(*&$<(%$#)
I didnāt expect so many things to be UI blocking. Last time I hit that was VB6
- VB6: I take that back, because I remembered after submitting that I had a few apps doing background polling back then.
how can a web app dev not provide payment gateway integration? most web apps are subscription based and xojo doesnāt come with these integration, infact I think you have to use PHP page re-direction to get it working. They (xojo) need to really get these basics right, sorry something that I discovered today and I am winging about this player that is a half baked cookie.
In the most cases you may need to implement your paypal bridge for example by self. It is nothing the language has to bring with. It is something the programmer has to do. There is more the problem that it is really complex to do such stuffs with Xojo.
3 Likes
Thatās right. Sometime back, I saw a PHP plugin from MBS thatās deprecated, I believe. The market has changed now, with so many SaaS-based development platforms, one has to agree there are better options but every product has pros/cons, got to go with what suit best for the caseā¦
I see no way for Xojo. I am in a comfortable situation. Integration of paypal with Java or C# is working like a charm directly with the paypal Java / c# / PHP (I donāt want to be remindet for PHP from HAL) API. The big point is: paypal could implement a Xojo API. But they will not. Why? Nobody uses this language. And that is the most important point to use a language many people using.
2 Likes
Itās a REST API, I see no reason why Xojo could not be used.
4 Likes
It could
just someone would have to write the code to do it
Other langs already have that done
dunno if it exists for Xojo already
it may
I thought the point being made was that the complaint that PHP is required is invalid. The REST API uses client/secret tokens and the Webhooks use CRC32 hashes available since 2021r3.
I can build these things for people willing to pay for my time.
No offence, youāre missing the point and acting like Christian 
Many many years ago I thought to do something like that for my products and services, iāve ended up with simple Javascript Carts and REST link to paypal (Example in german only) cause it was not worth the time for developing and maintaining.
1 Like
Iām offering services to implement things Xojo users arenāt going to get on the forum.
If thatās of no need to you, thatās fine, but your link isnāt going to help average Xojo users who might be mislead to believe they need PHP to accept payments.
Indeed you dont need PHP to do this
There just isnt any prebuilt code like there is for some other languages
To clarify, are you saying that paypal api support should be built into the language or an official library?
When dealing with APIās the logic is generally exactly the same across languages. Itās just a matter of putting it together. For most services (outside healthcare ā im jaded but its true), the api documentation is enough to get connected within an hour or so.
I mean, oauth2 is a bit of a tedious bitch sometimes, but once you do it enough times its not too bad. The problem I see here is the logic to support api requests becomes varied enough where it gets close to what the language supports itself. And then adding specific service support is a matter of plugging in values in some cases, where adding support for paypal specifically becomes the equivalent of the Okay, Cancel, Button buttons in the object library.