Ok Garry, be honest, API v2.0 when? 
Thanks for taking the time to leave this feedback @Karen, itās greatly appreciated. Let me address them individually:
Do you mean like this on the Visual Designer? This is for a button on a window:
As of the current version 26.5.3, the Listbox control currently fully supports the concept of String ārow tagā. Iāve added support in the in-progress next release (26.5.4) to not only support cell tags but for them to be any Object, not just a String.
This is a really good suggestion and Iāve added it to the feature tracker:
I do plan on extending DB support beyond SQLite soon. I have a few issues being tracked around this:
I few people have asked about this and it is definitely on the road map:
If youāre interested, the current solution format is publicly documented:
I donāt know if Objo supports interfaces as Xojo does. But I think Treenodes Should either be a class of their own that can be subclassed and passed (OR an interface If Objo supports that). The string method of creating a node would use a default minimal implementation.
It looks like the TreeView is single column onlyā¦ Is that the case? I have found being able to have multiple columns in Xojo hierachical listboxes usefulā¦
Being able to use a node subclasses (or interface) combined with CellPaint events would help deal with that in the most flexible way without that feature. The subclass (or other class implementing the node interface) could handle the painting for different display on a row depending on depth for example.
- Karen
Objo does support Interfaces yes.
You have to remember that the UI there is based on Avalonia. So I would suspect some of the controls Garry has in Objo might be reflecting a bit what Avalonia UI framework has in it and supports.
I donāt know anything about Avaloniaā¦ Just mentioning things that I have found useful in Xojo (or other ways to accomplish them) that Objo does not support.
Iāve not actually played with Objo yet- just fired it up and looked at some of the docs.. I have too many other things I have to do right now.
Avalonia is a multiplatform UI Kit for Windows, Linux, macOS, Android, iOS and the Web. It is deivered for c# which is the language ObJo is written in. The ObJo programs running on a dotnet server.
So the entire ecosystem of the dotnet world is opened for ObJo. He will be able to build ObJo mobile and ObJo web with less then ten percent of the needed amount of working hours than XoJo needed for Web 2.0 and API 2.0. That said it is the most flexibel solution he could use for the former XoJo users while it will have the chance to grow.
I just Googled Avaloniaā¦ it does have a combined grid and TreeView (which is what the xojo listbox is):
The
TreeDataGridcombines tree view and data grid functionality in a single control, displaying hierarchical and tabular data together.
Donāt know exactly what it does or how, BUT itās not part of the free code base of Avaloniaā¦
You have to pay to get it so Garry could not use it.
Yeah I definitely donāt want to use Pro/Accelerate licensed Avalonia controls but I do want to offer functionality the Xojo ListBox provides. Once Iāve stabilised the existing standard library, I will most likely write my own control.
Hi All,
I have create a Discord group!
Garry,
I have followed, enjoyed and respected your work in recent years and Iām excited to see this product come into being. Iāll be downloading and experimenting and if itās half as good as I expect Iāll buy a license to support the work.
Couple of questions.
Do you plan a Linux version of your IDE?
What is your roadmap for database support?
Thanks,
--Bob
Thanks for beating me to the post Tomas 
As Tomas has said - I fully support the IDE on Linux (unlike the shambles that is the Xojo Linux IDE editor). My test rig is Fedora.
I am planning on adding additional DB engines very soon. Probably MySQL and PostgreSQL first.
This is maybe not the greatest marketing / framing on speed ā to me, anyway. While itās improving lately, Python is not historically noted for blazing speed and relies on C interop for many of its high performance libs that are widely used. That said, Objo probably doesnāt need to be more than that, especially out of the chute ā sufficient speed for typical apps (if not maybe elaborate gaming) and otherwise a nice glue for pieces built in other languages where needed.
(For the target audience I wouldnāt ask for C interop, but for .NET Core interop. Even the ability to call into .NET code within the limits of Objo (e.g. .NET canāt return something Objo doesnāt support, such as a char[] or Decimal) would allow writing performance-critical things in .NET languages where desired. Even, ahem, VB.NET.
Also you donāt apparently have anything like the Python GIL and in fact you have a modern approach to async that is not the obscene kludgy half-measure I found in Xojo (and Iām being charitable to Xojo). Iād imagine that eventually as the user base supports it, you will have something akin to AOT compilation. Iād think it would be feasible to translate Objo to C# and compile from there in fact, if it came to that, and then youād have all the options .NET would provide for compilation / optimization.
All that said, I think youāre making very careful choices for what to support first. Especially at this stage what you leave out is almost as important as what you include. And you should never support more than the user base will encourage you to take on. This early selectivity feels SO much more confidence-inspiring than the willy-nilly dogpile of random ideas (and false starts) that Xojo has devolved into. I love that someone is in charge of this that understands software architecture, lol!
Looking forward to exploring this further in coming days. I wish I had a little more time on my hands than I do!
Thanks, I missed that in the initial post, and like a dolt assumed Linux wasnāt offered yet as Iād have had to scroll down to see that option, lol. What can I say, yesterday was a long day followed by a short night.
Iām starting with MacOS as Iām just setting up my first Linux VM but would prefer to develop and test in the IDE on each OS so thatās a nice option.
Thatās my feeling exactly. 99% of use cases are more than adequately served by ObjoBasicās runtime speed. It was important to me to maintain a BASIC-like syntax and in order to do that I felt I had little choice but to roll my own language. ObjoBasicās VM is pretty sophisticated but is never going to be as fast some other languages. What I think is most important is reducing friction between a userās idea/creativity and production and that is where I think Objo can shine.
This is on the roadmap. I have an implementation plan for how this might work and when I built the VM I did so with this in mind.
Thanks - Iām pretty proud of the async implementation. Not easy to engineer!
Totally agree. It is just that I can see myself using it for lots of routine command line utils and any desktop GUI especially that needed to be cross platform, if it has just a few, erm, amenities, to wit:
ā¦ and that would also be one way for third parties to contribute or sell products that could be useful to Objo devs.
Yeah, I can imagine! Personally I go out of my way to avoid async unless thereās a REAL need, as it carries a lot of cognitive burden and tends to be a source of subtle bugs and debugging challenges (in C# anyway). And I hate that it really only works properly when an app is āasync all the way downā so that you just about have to go all-in whether you need to or not, or every person you discuss any issues with will say āthatās the problem, the whole call chain isnāt asyncā. If youāve managed to solve that I would love Objo for that reason alone. I would like to contain async to the places where itās needed and forget about it everywhere else.
This is a really good newsā¦
Bought a license today to support your excellent work @Garry
Any hint when you will make .objo file-format more git-friendly?