New alternative for web app RAD (in Visual Studio Code)

??? What did I miss?

In one of the first Versions of 2020 they renamed for web msgbox to message box and later back to msgbox why ever they where doing it.

People can’t write a Xojo loadable code freely right now, the current “code” is not “human compatible”.

E.g. that’s how Xojo define the App Class of a “Hello World” app, just an example of the #tag mess:

#tag Class
Protected Class App
Inherits Application
	#tag Constant, Name = kEditClear, Type = String, Dynamic = False, Default = \"&Delete", Scope = Public
		#Tag Instance, Platform = Windows, Language = Default, Definition  = \"&Delete"
		#Tag Instance, Platform = Linux, Language = Default, Definition  = \"&Delete"
	#tag EndConstant

	#tag Constant, Name = kFileQuit, Type = String, Dynamic = False, Default = \"&Quit", Scope = Public
		#Tag Instance, Platform = Windows, Language = Default, Definition  = \"E&xit"
	#tag EndConstant

	#tag Constant, Name = kFileQuitShortcut, Type = String, Dynamic = False, Default = \"", Scope = Public
		#Tag Instance, Platform = Mac OS, Language = Default, Definition  = \"Cmd+Q"
		#Tag Instance, Platform = Linux, Language = Default, Definition  = \"Ctrl+Q"
	#tag EndConstant


	#tag ViewBehavior
	#tag EndViewBehavior
End Class
#tag EndClass

Here is one human targeted equivalent:

Protected Class App Inherits Application

	Public Constant kEditClear As String = "&Delete" _
             Platform Windows = "&Delete" _
             Platform Linux  = "&Delete"

	Public Constant kFileQuit As String  = "&Quit" _
             Platform Windows  = "E&xit"

	Public Constant kFileQuitShortcut As String = "" _
             Platform macOs = "Cmd+Q" _
             Platform Linux = "Ctrl+Q"

End Class

That now, seeing more extra disposable redundancy, we could even clean it up a bit more as:

Protected Class App Inherits Application

	Public Constant kEditClear As String = "&Delete"

	Public Constant kFileQuit As String  = "&Quit" _
             Platform Windows  = "E&xit"

	Public Constant kFileQuitShortcut As String = "" _
             Platform macOs = "Cmd+Q" _
             Platform Linux = "Ctrl+Q"

End Class

Yes that is because, what you see in the .xojo_code files is just how Xojo saves project, nnot how it handles it in the IDE.

I guess the binary project format is more like what the language “thinks”.

I assume that the compiler takes the loaded Project, wich is close to the binary project format and builds the app out of it. Xojo-Code doesn’t really exists. What we write is just an intermediate state, also what we save.

Thats why an external compiler always first had to load the entire projct into its very own format and then starts to compile.

If one would use an external IDE, then you’ll have to write either a compiler which translates you written Xojo code into the readable xojo-text-project-code, which then can be loaded by the compiler/ide to compile the app.

So to say, Xojo as a programming language doesn’t “really” exists, since half of the things are always handled by the IDE.

I just don’t know how to express my disagreement with your above opinion. So many levels… So I will just avoid comment the details because all the efforts by myself, beyond my first attempt, and even you or anyone wanting a CLI compiler (surely target to users using external editors) right now, will surely end in a cloud of nothingness in the current form, anyway.

Except he’s 100% right
What you see in project files is NOT what the compiler ever sees
It sees “code” - plain textual code

That a text project has all those tags and other markup is a convenience for the IDE to be able to save & load a project

2 Likes

It’s no opinion, It is just how Xojo in particular works. I know that other (most, all?) languages work different.

But Xojo Inc. couldn’t “just” deliver an CLI Compiler, which was made external from the IDE, since the IDE is absolutely necessary for the compiling process since only the IDE knows the exact project format and data.

An external compiler always had to load the .xojo_code files into it’s very own format, before even thinking about the compiling of the app.

And with that, you’ll lose a lot of time. An external compiler would be much slower, at least in the current state of the language.

With that structure a compile Process would look like that:

[your writable Xojo Code] → transpile → [readable xojo_project_files] → load the Files → [Xojo IDE internal format (binary or whatever)] → compile → [Application]

The IDE only does the last step.
Any other Code Editor had to go though all steps, everytime (without proper caching though)

And having that behavior it is a shame that they couldnt manage all the naming changes internally and they need “new controls” to do it :roll_eyes:

“Xojo code”, as a purely text file format, doesnt exist
What we have is what you see now with text projects - it has various tags & such to aid with loading that data into the IDE

Xojo code, as “this is what the compiler gets”, does
Its just not accessible EXCEPT by using the IDE
The IDE and the compiler / linker work in concert to achieve the end result; a compiled application

THIS is why a “command line compiler” is a big job - you then have to move all the project reading etc into the command line compiler so it can take a binary project, xml project, text project, read it all and compile

Which is why I dont think we’ll ever get a “command line compiler” like you get with many other tools that just take “files full of code” (in whatever language) compiles them and spits out object code you can then link together (some compiler integrate calls to the linker as well)

EDIT : Let me say its not that it CAN’T exist
I just think its very unlikely to exist as it doesnt serve Xojos goals - regardless of how well it might serve ours

1 Like

Sure, and here lies all the disagreement about a “Xojo code”, external editors and CLI compilers.

Then tell us

A Xojo command line compiler could exist
I would expect that it would do just like the IDE - read a project, check your licenses, maybe obey some command line switches about that target to compile, and build the project

Do I ever expect you will be able to just have a directory fill of .xojo_code files that do NOT have all tags etc ?
No

That wouldn’t make sense for Xojo & their licensing etc

Already said.

Useless

Even if they did have a format without all the tags, which is doable, I doubt the command line compiler would work with anything but a xojo project in one of the supported formats
And it would still need to enforce their licensing etc

Xojo is a business not a charity
They need to remain making $ or the whole thing goes kaput

That’s an unnecessary statement. Sure. I already said how to do it. Having CLI tools does not mean having free CLI tools. CLI tools would be companion software installed with XOJO IDE, and will inherit the same licensing/capabilities unlocked by the IDE. Unlicensed XOJO CLI tools should emit just copyright, version, license and help info; not compile.

A command line compiler could be separated from the IDE so a licensed user could run some CI tools on a headless server

For that either

  1. Xojo makes yet another new file format (100% plain text)
  2. the command line compiler reads existing projects

Its MUCH easier to do # 2 than to come up with yet another format to maintain and try to keep 4 of them in sync. 3 was damned hard.
And to make it so you can run just the command line compiler on such a headless server (separated from the IDE) the command line compiler cant rely on the IDE or its functionality in any way (no window managers etc)
It pretty much HAS to stand on its own
So it has to include all the normal licensing checks etc that are part of the IDE currently
Otherwise you make your own “IDE” and just lift Xojo’s compiler out and use it - again NOT something they are likely to enable since that would hurt their business.

Lets just say experience has told me creating a command line compiler is NOT a trivial job
And why I dont expect it to occur any time soon

Regardless of how much we whine about it or debate its merits

EDIT : I’d truly LOVE to see them prove me wrong (Really I would!)

Easy, as others does. The CLI tooling solves everything. Let’s suppose the main Xojo tool is called “xojo”, let’s suppose that installing it is just unzipping a set of files that include the “xojo” executable and do:

$ ./xojo --install
Verifying… OK
Path updated
Done.

$ ./xojo --build --platform windows /tmp/myproj/myapp.xojo_project
Error: No license

$ xojo --license rick@mymailprovider.com --selectlic 0d23a78
Fetching license 0d23a78 for rick@mymailprovider.com from xojo.com
License 0d23a78 was authorized for this machine.

$ xojo --build --platform windows /tmp/myproj/myapp.xojo_project
Compiling…

Me too.