IDE Modularization

OFF-TOPIC: Did not mean to highjack this thread, but I can resist :thinking: I can only speculate about and imagine the complexity of the XOJO IDE, but topics like this reminds of a thought on XOJO architecture and strategy, In my head I see the splitting of the compiler and the IDE as one strategy that could serve XOJO very well. This might require to make the IDE a bit dumber at first while the interface of the IDE and external compiler is improved, but for most thing the IDE should be as usable as before. This will give XOJO a whole lot of flexibility to work and deliver improvements with a more manageable code base. This would even open the door for inserting external apps, editors and process into the tool chains which at the end adds more to the value proposition of XOJO.

1 Like

The compiler has to be baked into the IDE for things like Autocomplete and Analyze Project. So you could only split a small portion, if any. They already split out the linker.

1 Like

Is the parser the same as the compiler in Xojo?

What prevents a communication beetween a separated compiler and IDE? The IDE sends proyect, the Compiler returns Analized Proyect.

Ever since I participated in RealBasic discussions back in 2000, I periodically see suggestions to be able to use another editor than the IDE.

It may be possible. However, as Tim quite rightly mentioned, you would lose autocomplete, as well as graphically represented event handlers. You would also lose syntax verification. If you look at projects saved in Text format, indeed it resembles a VB listing. With all methods and event handlers in the same long (potentially very long) text. After all, once could perhaps edit it in another app.

I currently use another Basic to create iOS and Android apps. That IDE is based on the same model as VB, with a very long text. It does provide autocomplete and syntax verification. Since I started long ago with VB, I can deal with that, but frankly, it is much less clean than Xojo’s IDE.

There are indeed separate code editors around. I don’t see them as a better solution than the IDE.

1 Like

This is not true - take a look at VS Code. It handles syntax coloring, autocompletion, and even runs debug operations for a huge selection of languages where the compiler, linker, and debugger are external. I use it over both Visual Studio and Xcode for the C/C++ portions of our code.

If someone took the time, there could be a syntax module for Xojo made available.

6 Likes

So, do you think that every single “code editor” has dozens of compilers built in to do the autocomplete? :expressionless: As others have said, autocomplete is not a problem for a code editor.

The autocomplete is way superior those IDEs and does not use a compiler for that. The compiler is part of another tool chain, NOT part of the IDE.

Well, that is YOUR opinion, mostly influenced for the VB to Xojo history, but the reality is that there are MILLIONS of developers that are used to the “only big text files”, that is the way it is teached in schools and if xojo wants new users they must star offering features like this intead of the just keyword changes nonsens.

I do feel the graphic implementation of event handlers is conceptually superior.

Once again, having coded since the early eighties, I am quite familiar with the “everything in the big text file”, Thank you. It does not mean I have to like it.

I understand you have your own pet editor, and would love to use it with Xojo. Why not ? Unfortunately, up to now, Xojo has elected not to make it possible to use an external editor.

It is not a reason to look down on people who legitimately prefer the IDE.

2 Likes

In my professional life, I coded in COBOL and Modula-2. I was an enthusiastic user of GNU EMACS with Modula-2. In my retirement, I still keep my hand in the game as a hobby via Xojo. If not for the Xojo IDE, I would not bother. Everything in a big text file? Ugh.

2 Likes

As a user of of this product I have seen many, many, many topics related to “why cannot the product be this, or that”
The product we know today as Xojo is designed the way it is for a reason and when you started using it that is what you signed up for.

The endless “why cannot Xojo have C syntax, why cannot it be open source, why cannot it split this and that”

Efforts will be better spent helping what Xojo is improve rather then wishing it was something else

7 Likes

Splitting the compiler & IDE could be useful for automating build workflows but I wouldn’t want to edit Xojo text format source code files with a 3rd party editor - yuck!

Maybe if the IDE, compiler & framework were broken into modules it would make releasing out of band fixes much easier. The current situation of having to wait several months for a fix to a potentially show stopper bug is one of the reasons why Xojo is becoming a poor choice for professional software development.

1 Like

Again, that is only YOUR perception.

I was only stating that there are MILLIONS of users that don’t prefer the “graphic implementation of event handlers”

It really slows down the work in many many cases. Sure, it is “easy” but many users preffer performance than a comodity that requieres heavy use of the mouse.

To be fair here, it is’t like you are viewing a big text file. It is more like a big text file is used by some things as a storage format, and the code editor tries to intelligently let you navigate that and view / edit the subset you care about at the moment.

In terms of actual code editing, some are quite feature rich and customizable. But to me the I in IDE stands for Integrated, and in its current project formats the Xojo projects would be very hard to Integrate to other code editors. Personally, I don’t want Xojo resources expending extra time to facilitate other editors. I want them to focus on other features.

4 Likes

I never said I preferred the IDE because it was “easy”. I simply believe the graphic structure of the code is conceptually superior to all in the same long text.

Now, perhaps you are using the wrong tool, if you really hate the IDE that much.

3 Likes

That is perhaps Michel’s opinion, but then the other sentences you write are your own opinion, to stay at the same level. Like this:

Quite easy to tell others’ sentences are their opinions but ourselves’ are just truth.

How do you know they are not just accepting that because the tools they already use and prefer for others things are that way, and are just annoyed by huge text files?

Having a command line compiler is desirable. Especially for something like nightly builds or automatic compile runs on committing to the source code repository.

But for use with the IDE, it won’t fly easily. Saving the project to disk (for a build run) and then having the command line compiler load it to build would be slower than we we have currently.

To better solve this, I would highly recommend to look into making the Xojo app a hybrid for console and GUI. Like if you launch it with /c as command line switch followed by path to project, the IDE could launch without windows, load the project, build it and output the result to console. Quite a complex change to the IDE and adding a lot of If (IsCommandLine) or so in dozens of places to prevent a window or dialog to show up.

We have sample code for hybrid GUI+Console apps.

And I’ll add this to Feedback case 3215.

2 Likes

That is the way.

Having a complete external compiler doesn’t give us the ability to be Xojo-IDE-independent. The compiler doesn’t use the files saved in the text format to create your applications, it uses whatever the IDE gives it while running. The text format is just a structured way to save your code, it is not the way how the IDE interacts with it. I aasume that the binary-format comes closer to what the IDE “thinks” internally.

What you want to achieve are these Points:

  1. Use an external editor, but compile a Xojo app:
    It wont be enough to just make the compiler external. You also need to build an interpreter, which translates your text into to binary, so that it then can be compiled. This would be much more work, also for large project, the compile time would sky rocket, since the text interpreter has always to interpret your project first, and then it compiles it.

  2. Use the external compiler for nightly builds.
    Then, it would be much easier for Xojo to build just a headless version of the IDE with no GUI, but the same code. This shouldn’t be so hard (if they have a clever code management in the background).

I think we all can bury the idea to use an external editor. It is just not worth the work for Xojo. Also they would heavily rely on either the open source community (what they’ve never wanted to do) or they had to maintain much more external modules, for example plugins und packages for VSCode.

What I suggest is, to hope, that they someday implement a “Pro-Mode” into the IDE, for professionals, which don’t want to stick with the current “clicky-bunti” approach.

Agree entirely with that! A command line compiler would be really useful.

I’m not fussed at all on an alternate code editor - the Xojo IDE allows the WYSIWYG visual editor alongside the code editor which is what I really missed last time I looked at VS for VB work.

1 Like

Then your IDE build number would contain many components, any of which might change as the corresponding part was updated.

Can you explain what you mean by “graphic implementation of event handlers”?