Thank you so much for supporting me, it’s really appreciated.
I’m currently nearing the end of implementing ContainerControls which has been a big refactor. Then I’m probably going to tackle MySQL / PostgreSQL and fix any logged bugs. That’ll be the next release. After that, I think I will tackle the file format. I’m hoping that’s not too big a deal as internally the solution writing module is well abstracted.
I respect people who want a purely native control runtime but I’ve yet to see an easy to use comprehensive tool that can build completely native apps on three desktop platforms without effectively building three individual apps and guarding them behind countless platform specific declares/conditionals, etc. I think think is why unifying the UI between all platforms is really compelling.
Most of the professional tools I have used in my life as a physician and radiologist are completely custom UIs and I think this is true for many business areas.
Garry, yout tool is a real good Idea and is for former XoJo programmers for sure a good alternative. And with the Avalonia GUI you are save for all platforms so if you later want to add Android, iOS or Web you may have less problems. Especially while dotnet provides this functionalities it is possible to implement later. So your tool has real potential looking on XoJo cause from scratch your implementation is better than their tools are. If I would be basic programmer I would immediately look if I can switch with my code. For sure: that is not a trivial part but it makes sense.
I am (or was?) an analytical chemist and have used a lot of different software controlled equipment for routine use in a laboratory by chemist or techicians. All looked at home for the OS and looked like they used mostly native controls from what I have seen and followed platform standard behavior… And of course that is mostly true for most office based applications…
The familiarity is important outside of highly specialized applications for experts because of training costs… Even when using OS controls there is still a significant amount of learning to using software effectively… Keeping that barrier as low as possible by being more “standard” for the OS is important IMO…
That was one of the things way back when that attracted me to REALbasic.
Bought a license as well. It’s a bargain even for me and I don’t have an immediate need, it is just great to support a platform that hasn’t been enshittified by some nameless corporation.
Progress velocity is excellent. Responsiveness to questions, suggestions and bug reports is excellent. It’s already a very impressive product and it’s just getting started.
Ain’t he? I feel like I must be pushing my luck. I ask for bulk copy semantics for Memory instances thinking “maybe someday” and, boom, it’s scheduled for the next release (and so far, what he schedules doesn’t slip). Trying not to get spoiled, lol.
But this is also partly what comes from mindfully building on the shoulders of giants. He’s got .NET and Avalon doing much (certainly not all) of the heavy lifting under the hood and it makes it even easier for one guy to run circles around a whole competing team.
Also while Objo is kinda-sorta compatible if you squint enough, he’s not binding himself to being a clone, so he’s not having to adhere to any of their bad architectural choices – nor will Objo devs have to endure them. Objo will be conceptually familiar but in no way a clone. It will be an easier, more comfortable port than, say, Xojo to WinForms, but a user will still have to decide the effort is worth it. (Hint: it is)
I have to say, I’m loving it.
This reminds me of the early days of FoxPro when they cloned dBase IV, a notoriously mediocre and buggy product but the industry standard at the time nonetheless. They actually had a command in the language:
SET BUGS ON
… so that if you wanted to run code written for dBase IV to behave EXACTLY the same, it would oblige, lol. I don’t know how much effort must have been wasted on that.
Fortunately Xojo is no industry standard, so … Garry isn’t burdened by those concerns, either.
For what shall this be good? To compare with some basic language which is sooo perfect? I know this question and it has always the same target. The objo language is made for desktop but can also produce cli programs. And yes, written with rust or c it would be even smaller. But in times if GB of memory it is no problem having a 30mb exe. That’s a yesterdays problem.
Also, the executable size doesn’t equate to memory consumption anyway. Often not even close. I don’t know how Objo bundles the .NET support but even if it’s the entire .NET runtime and not AOT compiled, only the parts of it actually called by the app will actually be JITted and run in memory.
I am not privy to how Objo’s custom VM that runs your programs manages its own internals but I suspect that in most cases the developer’s own code is a relatively small percentage of what’s in the executable bundle.
I’m sure Garry will correct me if I bungled anything here but I believe the above is a correct and fair description.
Of course on a day to day basis I just run apps I’ve created in Visual Studio and they Just Work so I don’t think about the size of the executables or support libs much since I’m not creating distros for public consumption. It’s mostly command line and OS services and some small administrative desktop GUI apps, all used by myself and my client.
Then stop acting so pompous when someone asks a simple curious question or god forbid say something bad about Java. Ok, I’m done. Apologies to Garry, don’t mean to hijack this thread so lets just leave it at that.
I do not get your intention with this question. If size of Executables is your topic, than you should use Purebasic or Freebasic where Executable are measured in Kilobytes and a http-server fits on a single 3,5" Diskette.
Objo needs his .NET Framework like other languages need their Java or Python Frameworks. So you want to start to compare these frameworks with each other? I do not get your point. In fact, your comment looks confrontative.