The Xojo Brain Drain

[npalardy]

@samRowlands

It starts with Xojo creating a whole new compiler, that supports primitive types and an OSObject.
Methods could be tagged as being platform specific (I know that we have pragmas, but having a single method for macOS code, one for Window and so I think it easier to debug).

Believe it or not you sort of can do this already
Compat flags are just the very smallest bit fo this that is exposed
Create a method and in the inspector mark it as Desktop (or 32 bit desktop etc) and the IDE only sends the compiler that code IF you are indeed compiling a 32 bit desktop app

The framework already makes use of this

@samRowlands

Fast forward a few years, and the entire IDE is built with Xojo 2.0, all the objects that we interact with are included as source code in the Xojo library, when they’re needed the compiler compiles them (of course it would need some caching and such).

It kind of already does this - except it drags around the giant assed dylib / dlls

@samRowlands

say the source list from the IDE. Everybody can now use it, we don’t have to spend the time making our own (if we want/need a source list)

that one is VERY tied to its role in the IDE and not really “generic”

@samRowlands

Heck this whole workers thing could have been added a decade ago when we as a community started experimenting with helpers. They could already have it with shared memory as I (and I’m sure I am not alone) have written the Sandbox safe shared memory code.

The xojo “community” has a very poor track record with open source
Everyone is rah rah yeah lets do it and then it turns into the very typical happening that is true with most open source. A few people contribute an a lot just use it and maybe dont even report bugs etc

@samRowlands

I didn’t suggest this to Geoff, because this can only work if Xojo is rebuilt from the ground up, and it’s a lot of work to do so, so it’s a pipe dream.

It DOESN’T really require a complete rewrite of the compiler
But it does require a rethink of how the framework is constructed and a pretty big rethink of the IDE itself
As I said there ARE things that already exist that could be really useful BUT, in the case of compat flags, they are deemed “not beginner friendly” and so they remain mostly hidden away from users.
And that philosophy of “it has to be easy for new users and less experienced users” permeates a lot of what is and isnt done in Xojo.

If you watched Geoffs keybote presentation what you should notice is that the argument he presents FOR API 2.0 is “look how easy I can cut and paste code between these different project types”. Sure cut and paste is handy for maybe filling in a few lines of code. But if I have a decently large app I’m not going to cut and paste individual bits of code for tons of events. Nor do I want to replicate or otherwise duplicate all the classes in my code.
That is where I was pointing with my post about the universal project.
Trying to make it so cut & paste wasnt necessary at all or at least could be really reduced

EDITED to alter DOES to DOESNT - my bad

[MarkusWinter]

@samRowlands

But they decide that my improvement is not something that they need/want so they choose not to include it.

I’ve now got an improved listbox, without having to rewrite or replicate the whole darn thing

But what if the next Xojo version comes out. It won’t include your bug fix(es) as Xojo decided not to use it. The same for a lot of other bug fixes. How do you migrate all those fixes or better modifications to the new version? Every time?

It’s like annotating the documentation - the changes don’t stick for the next revision )and I wouldn’t even know how to make them stick considering some changes remove stuff).

[samRowlands]

@npalardy

Create a method and in the inspector mark it as Desktop (or 32 bit desktop etc) and the IDE only sends the compiler that code IF you are indeed compiling a 32 bit desktop app

I was more thinking, flags for target rather then app form. i.e “macOS 64-Bit”, “Win 64-Bit”, “iOS 64-Bit”. And so on.

@npalardy

It kind of already does this - except it drags around the giant assed dylib / dlls

Lol… A simple “Hello World” was about 13 mb (desktop) last time I checked (and if memory serves me correctly). A simple Obj-C app was mere k, last time I tried Swift it was closer to Xojo, but I think that’s changed since Swift libraries are now included in the OS. Anyway, my point was to get a compiled Xojo application closer to Obj-C in file size. Which will also give it a minor launch speed boost as there is less to load into memory

@npalardy

that one is VERY tied to its role in the IDE and not really “generic”

Maybe, and I’m not sure it’s actually appropriate for my apps, but it sorta define the point, how many developers have rolled their own “SourceBar” when Xojo have already made one, but are not sharing it.

@npalardy

The xojo “community” has a very poor track record with open source
Everyone is rah rah yeah lets do it and then it turns into the very typical happening that is true with most open source. A few people contribute an a lot just use it and maybe dont even report bugs etc

That may very well be the case, maybe it would be different if everything that we use is exposed and could be tweaked, with the possibility of earning rewards for it?

@npalardy

It does really require a complete rewrite of the compiler
But it does require a rethink of how the framework is constructed and a pretty big rethink of the IDE itself

Which is why I don’t think it will ever happen, sadly.

For instance the listbox is pretty terrible IMHO, I use it while prototyping, but in many cases I end up replacing it with a custom class, because it simply lacks the features I want or has serious issues (don’t work correctly with a NSPopOver or NSScrollView). Because I can’t see what they’re doing behind the scenes I have to re-write a ton of functionality just so I can use other means of getting the mouse location (which work in aforementioned views). Filing Feedback for me is pretty much a waste of my time, as generally what I want is too specific. i.e. my last request was to expose the event for drawing a focus ring because ALL focus rings from a Xojo Canvas are square. I hacked the XojoView to capture this event and now some of my custom buttons have appropriate focus rings

I can share that code on the forum, XDev or my own site. Being able to submit it to Xojo, increases the possibility of that functionality being added, then everyone can draw correct focus rings (maybe just for macOS). As it stands right now, the work I’ve done can benefit a few who know where to look (If I take the time to share it). How many other developers will try to figure this out and possibly fail, give up, maybe even walk away from Xojo because something like this is simply not exposed and Xojo engineers are too busy with other things?

I alone, could add so much more functionality to Xojo, simply as I try to improve my own apps. The best bit is that Xojo wouldn’t have to pay me “one billion dollars” a year, we’d all win. I get better apps, Xojo developers get more powerful apps, Xojo saves money and can offer a more flexible product, which stands a better chance of retaining customers.

@MarkusWinter

But what if the next Xojo version comes out. It won’t include your bug fix(es) as Xojo decided not to use it. The same for a lot of other bug fixes. How do you migrate all those fixes or better modifications to the new version? Every time?

Given the current “Security” climate, I couldn’t/shouldn’t modify the classes included in the Xojo application, so I would expect them to be either stored per project or shared like we currently do.

Oh well, this is all pie in the sky. Speaking of Pie, time for lunch.

[Garry]

@samRowlands I love this concept. From a business point of view it actually makes a lot of sense for the reasons you outline. In some regards, it’s how .NET / .NET Core works. Almost all of the standard .NET libraries are written in C#. You can peruse them on GitHub. In fact, I often use that code (or sometimes code from the OpenJDK Java standard libraries) to figure out how to implement something in Xojo. For example, want to know how the Dictionary class in c# is implemented? It’s all here. In Microsoft’s case they have open sourced their Roslyn compiler but Xojo could keep their’s proprietary for sure.

One thing I’m not sure about though is writing GUI components in this proposed “Xojo 2.0” language. For example, it would be easy to create a Dictionary class using Xojo code as it can be constructed from primitives (arrays, integers, etc) but creating a Listbox class would require some way of calling into OS C libraries and I’m not sure how one would envisage that working? I’m genuinely interested though as the language I am working on at the moment will eventually need to do this. I’m modelling my language on Wren which provides a basic VM with classes and primitives and the standard library is written in itself.

[npalardy]

@samRowlands

I was more thinking, flags for target rather then app form. i.e “macOS 64-Bit”, “Win 64-Bit”, “iOS 64-Bit”. And so on.

What exposed in the IDE currently is only a tiny fraction of what is possible currently
IF they exposed the compat flags as a string you could write just about any boolean expression you wanted

@samRowlands

Lol… A simple “Hello World” was about 13 mb (desktop) last time I checked (and if memory serves me correctly). A simple Obj-C app was mere k, last time I tried Swift it was closer to Xojo, but I think that’s changed since Swift libraries are now included in the OS. Anyway, my point was to get a compiled Xojo application closer to Obj-C in file size. Which will also give it a minor launch speed boost as there is less to load into memory

A Xojo code based framework without all the underlying C++ code (which is whats in the XojoFramework.dylib) would be strippable in the same way out code is - at the level of whole classes and modules only (without a huge change to the compiler itself to strip at a more granular level)
And I’m not sure you could do it. Basically it would be all declares and there are thigns that are just not possible in Xojo code - async callbaks and such

@samRowlands

Maybe, and I’m not sure it’s actually appropriate for my apps, but it sorta define the point, how many developers have rolled their own “SourceBar” when Xojo have already made one, but are not sharing it.

I suppose IF that one had been written as something that would be shared then sure they could have = but it wasnt and is so tied into the IDE that it would be completely useless to anyone that wasnt writing the IDE.
I’m not saying you’re wrong about “they should make controls in a way they can be shared”. This one just wasnt

@samRowlands

That may very well be the case, maybe it would be different if everything that we use is exposed and could be tweaked, with the possibility of earning rewards for it?

maybe
it certainly would shift the discussion from “not enough resources” to something else

and whoops !!! I see I wrote

It does really require a complete rewrite of the compiler

and that should say it DOESN’T require a rewrite

a lot of the things we do complain about (listbox etc) have nothing to do with the compiler itself
But, like you, I dont foresee Xojo opening a lot of their code to the public since that is their IP and what makes the company worth anything at all
It would be nice but …

[samRowlands]

@npalardy

Basically it would be all declares and there are thigns that are just not possible in Xojo code - async callbaks and such

Yeah this one is a PITA, it’s kinda doable… For Core Image area based filters I actually resorted to a custom plugin, BUT that’s only for that scenario, it’s much harder to build a generic one.

Hopefully if Xojo engineers had to do it the same way as us, they’d devise a better system for it

@npalardy

But, like you, I dont foresee Xojo opening a lot of their code to the public since that is their IP and what makes the company worth anything at all
It would be nice but …

Yup

[npalardy]

@samRowlands

@npalardy

Basically it would be all declares and there are thigns that are just not possible in Xojo code - async callbaks and such

Yeah this one is a PITA, it’s kinda doable… For Core Image area based filters I actually resorted to a custom plugin, BUT that’s only for that scenario, it’s much harder to build a generic one.

Hopefully if Xojo engineers had to do it the same way as us, they’d devise a better system for it

to do this they would really have to go back to square 1 with much more
And that aint gonna happen
They dont have the “good will” any more for folks to endure years long waits for yet more stuff

~* I’m used to waiting for the future to arrive. I work with Xojo *~

[Rick.A]

Flutter and Dart are awesome but… still maturing. There is a huge TODO list for Mac, Windows, Linux and WEB for 2020. So, I´ll postpone anything NOT ANDROID for Flutter to the next year.

[npalardy]

I’ve now been asked by several Xojo Award Winners about Flutter and some of the other tools that Bob reviewed
There’s some serious interest in alternatives

[Rick.A]

Sometimes I reevaluate this “Lazarus” distro. It´s an all in one, do it all, studio. Last time I checked it, it was great for Windows / Linux, but had limits for Mac. https://www.pilotlogic.com/sitejoom/index.php/downloads/category/14-codetyphon.html

[npalardy]

Is that lazarus just prepacked ?
I did get lazarus installed on macOS but … “limits on the Mac” is generous

[Rick.A]

It´s not just prepacked, the guy in charge is very talented. He customized and automatized tasks, fixed codes, etc. Few clicks and the IDE downloads missing parts enabling desired cross-compilations, extra platforms, etc. Maybe I´ll try it again tomorrow (in Windows/Linux). Last time I tried it was 5.60, and now is 7.0…

[npalardy]

This is about how Xojo got its start from CrossBasic so many years ago
Geoff bought it, brought he author to the USA
I dont recall how long it was before 1.0 shipped and license were for sale
They eventually rolled out version 1.0 and the rest is history

[Rick.A]

When installing it, it will ask “small or big IDE” ? Small comes with just the basics like Lazarus, the big is like Xojo already including MBS.

[npalardy]

downloading the zip file right now to see

[Rick.A]

Have fun with the Wiki and the research. It’s huge, but the zero to hero factor is fast.
https://www.pilotlogic.com/sitejoom/index.php/wiki.html?id=231

[npalardy]

Karen asked this on the Xojo forum
But hasnt gotten an answer yet - which is either disappointing or concerning. Or both

I know the compiler strips unused modules and classes, but what about submodules of modules?

I have code organized like this:

 XplatformModule
        MacMethodsClassesModule
        WinMethodsClassesModule
        LinuxMethodsClassesModule

The submodules are only accessed from the main module, but only if the app is on that platform (using #If target blocks)
In this case would the submodules for the other platforms be code striped? That is what I would like to happen.

Putting the platform specific stuff into it’s own modules helps when one needs more than a simple declare or small snippet of platform specific code and in general helps keep methods small and easier to read…

I realize I could make then all top level modules and just put them in a folder to ensure the platform specific modules would be striped, but doing it this way helps keep the navigator better organized IMO, and promotes information hiding and not adding more cruft to the global namespace.

Thanks
-karen

FWIW modules and classes get stripped regardless of how deeply nested they are

guess we’ll see who copies my answer from here back to there

[npalardy]

The # of threads that go without replies seems to be going up

[eugenedakin]

@npalardy

The # of threads that go without replies seems to be going up

Yes, this seems to be true. I am getting more personal messages to fix problems than I ever have. I wonder why that is?