I’ve started working on the Xojo Shim for Buoy. This is going to ship as a package that gets imported to the Buoy source file(s) to expose Xojo-syntax wherever possible†.
I do have some questions for this community though:
Workers – Right now, workers become preemptive threads under the hood. To support the whole separate building, running and bundling of Workers would require infrastructure that we have no use for in Buoy at the moment. If they still work the same and they’re debuggable (because VSCode seems perfectly capable of handling that), do you think this is a problem that needs to be solved?
MySQL/MSSQL/ODBC – Buoy currently does not have any support for these, mostly because I don’t have an immediate use-case. None of these are currently on the roadmap, and they could certainly be handled by a 3rd party if necessary.
MySQL - At best this would be a MariaDB plugin. The unpredictability of Oracle’s licensing for MySQL makes it a non-starter.
Web/iOS/Android – At this very moment, I have no interest in pursuing these, but if I did,
iOS might be able to be compatible with Xojo
Web almost certainly would not
Android, definitely would not.
I would like some discussion and if necessary, please ask questions.
† Wherever possible because there is some overlap in the API and I have run into some issues that probably won’t work the same
Nice to have but not a V1 MUST have
And TBH Its possible someone in the community might build these since that’s imminently doable
Nice to have but not MUST have for MVP
IF I had to pick ordering probably something web first then iOS / android
Western it remained kind of Xojo like really depends on whether the web architecture would be similar or not
There’s no requirement that it be
It goes without saying that what I’m writing is for my own needs. I’ve a project which is currently under discussion with specific requirements regarding the database and web components.
Workers: No particular opinion, although this approach works for me.
MySQL/MSSQL/ODBC: I’d prefer PostgreSQL. The license seems clearer and I don’t see what is the benefit of MariaDB compare to PostgreSQL.
Web : I’d need something that lets me mimics a desktop application running in a browser without writing HTML and/or CSS. Qooxdoo allows for that and seems to be a good candidate even if its reputation isn’t widespread as other framework.
iOS: iOS could be interesting, provided it goes much more further than Xojo
Android: No need in the short, medium or long term. In short I’m not interested by that.
As for web, having worked on two frameworks at Xojo, it’s clear to me that whatever is done would need to support responsive layouts. Brock Nash tried to convince us of this way back then, but I just didn’t have a way to do it within the scope of web 2. With a layout editor that’s made with CSS now… who knows.
iOS and Android. This one’s tricky. Seeing what happened with Xojo gives me great pause. Specifically the fact that Apple and Google are evolving so fast in that space. Keeping up with that could be a full-time development job for one person and even more if you wanted to be able to offer everything Apple does every summer as soon as it comes out in the fall. Not saying “never” but Buoy has a long way to go to get there.
I am curious about what you mean by “much further” though.
That’s the best of the worlds. MariaDB client protocol is completely compatible with MySQL. That means that MariaDB can add new features that MySQL may not handle, but whatever MySQL does, the MariaDB is able to execute and return contents as if it were a native MySQL client.
For your own design, none; but dealing with legacy… A must have.
Having a MySQL client is a MUST due to the POPULARITY of this DB on the web. It comes preinstalled in many turn-key solutions.
I also prefer PostgreSQL but I HAVE TO support systems that runs on MySQL, ONLY; most people dealing with web projects will find such things here and there.
At some point, Greg will get some request from his users.
It’s been a long time since I last used Xojo. I think it was version 2025r2.1. It’s possible that some interesting features have been added since then. What I’d need is support for USB and BLE, as well as MapKit and SceneKit. I’m not sure about BLE and USB, but for the rest, I think there are plugins available that I don’t want to buy. In any case, I don’t want to use Xojo anymore.
Good things are coming to Buoy because of this Xojo converter work…
Fixing a regression which caused string comparisons to be case-sensitive in places where it shouldn’t.
Window definition is getting easier
Control event handlers have been moved back into the code blocks and no longer require the magic Handle < control >_< event > naming to work. Soon you’ll be able to define them in a With block:
Class MyWindow Inherits MyWindowLayout
With SaveButton
Handle Action()
ParentWindow.Close
End Handle
End With
End Class
We’re also adding this pattern for use with controls on TabPanels and PagePanels:
Window SettingsLayout
Title = "Settings"
Frame = (200, 200, 440, 380)
Control TabView tabs
Frame = (10, 10, 420, 300)
Tab "General"
Control Label nameLabel
Text = "Name"
Frame = (10, 10, 100, 24)
End Control
Control TextField nameField
Frame = (120, 10, 200, 24)
End Control
End Tab
Tab "Advanced"
Control Checkbox verbose
Caption = "Verbose"
Frame = (10, 10, 200, 24)
End Control
End Tab
End Control
Control PagePanel wizard
Frame = (10, 320, 420, 50)
Page
Control Button nextButton
Caption = "Next"
Frame = (10, 10, 100, 24)
End Control
End Page
Page
End Page
End Control
End Window
The Xojo shim and converter are coming along, as you can imagine they are highly intertwined, and revealing a lot of idiosyncrasies about Xojo that I haven’t thought about in a long time. I’m running the full test suite on the Buoy source today, encompassing the language feature changes from above along with lots of bug fixes.
Try Objo or Buoy