My wish for Xojo IDE and project formats

Off-Topic
1

Just venting or just hoping…

I only wish that XOJO would divorce the IDE from the compiler, make a stand-alone compiler for code and UI resources, make everything file based, make code files just PLAIN TEXT, make the IDE un-opinionated about your coding style and structures. Make a lighter yet powerful IDE, and I think it can be done without adding burden to the learning curve or “friendliness/easiness” appeal of Xojo. Matter fact it can:

  • add a more hipster appeal for newer generations
  • add appeal to people who like flexibility, openness, control from their development tools and environments
  • make Xojo easier to integrate with other development tools, options, workflows, etc (escape the Xojo bubble)
  • It is OK to let people thinker and hack around your development tools, it grows the community, adds exposure, imagine
    people using “grunt”, “make” or even their favorite text editor, people making pre-processors, transpilers.

Modularizing the dev environment is a good thing, it makes things more manageable/sustainable and I can even imagine a day XOJO could be offering cloud builds for IOS/Android, etc, or even cloud editors…

My dream is:

  • Module, classes, interfaces are all plain text files.

    Use keywords for scope, access modifiers, etc.

    Use attributes or #if Target conditional compilation

    A lot of the syntax already exists in XOJOScript…

  • Keep resources (icons, images, sounds, etc) as files. Even icons and masks and others created in the IDE will be saved as files.

  • Make a new project component named “assets” or “resources” that will be used on the IDE to represent and manipulate resources. In the IDE you can expand it and see different type of resources (like good old ResEdit, or InterfaceBuilder nib). I will see “icons”, “images”, “sounds”, file-types, and even menus.

This will be the UX in the IDE to handle them, as in the actual project the “resources” could be file with all the data and paths to actual files (as required). keep the format of this file simple, JSON is a simple and clean option for these type of files.

  • When editing code in the IDE it can still be parsed and presented visually under the project, but a more nimble and sustainable approach could be:

Let the project view just display files, when editing source code file the editor:

shows a full file, which it lets you poke at other parts of your code quite quickly, specially if we have tabs…

remove all of those fancy inspectors from methods/properties, their are annoying (every time I add a method and I tab to enter the arguments and the IDE takes the focus away it may have cursed unintentionally sorry, you guys are still heroes on my book!)

display a right pane with the visual representation of the code (source tree) (examples: Komodo IDE, Visual Code) and the same tree can be shown when expanding the file in the project view.

Use code intel to help navigate your code in addition to auto-complete, add “Jump to Definition…”

  • Just speculating about the syntax/type checks on the editor, but any index/cache etc could still be supported as an additional file the IDE creates in the project, similar to CodeIntel in Komodo, Sublime, Visual Code that create a sqllite db for code-intel.

  • For newbies the IDE could offer “assistant” dialogs for things like creating a class, properties, methods, etc…

For the UI a VisualBasic/Net approach is not bad. A file for the actual UI representation (rather not be binary) and one for the window object and its code. The IDE would make these two file almost transparent, meaning adding manipulating events from the UI editor jumps you straight to the corresponding code.

Make the compiler a CLI tool!, Build settings can be edited visually on the IDE or directly in the file. and JSON is a good format for a build file.

Now really of topic, with the language…

  1. The more that Xojo behaves and looks like CSharp/Net, Java and a like, it adds rigidity, flow, structures create cumbersome code and logic. If the basic problem requires me to write three classes, one interface, cast here, there, 50 lines of code for a simple loop, 100 more for forced exceptions, well your language doesn’t make me productive, even worst it has no sexiness for younger generations.

  2. Xojo can be a safe and fast compiled language without being so opinionated as how to use the language and its constructs. Old notions that you have to do things to save a programmer from its own mistakes, can lead you into that strict PARENTING, that kids hate (im still a kid!)…

  3. You want to be sexy!, make functions variables, Make “addressof” implicit in assignments, add object/structs literals, make it transparent for me to iterate over and object’s properties with a ForEach.

  4. Simplify JSON (I made my own) make JSON work with plain dictionaries, just stringify a dictionary, parse returns a dictionary. Arrays are dictionaries with numeric keys. There would be no need for JSONItem. An later I would take stringify an object properties sin you already added iterations for the foreach :slight_smile:

2

Made FB requests?

Truely plain text would be great.

3

Isn’t it already the case ?

4

By far, “.xojo_code” is a step there but is just awkward as a plain text format. (Not even going to mention XML formats)

Working with a “.xojo_code” file outside the IDE is futile…

I find the tagging un necessary…

In other editors/IDE file meta data, in particular volatile data like window state, position, editor preferences, etc is saved in the with the project file or in another file. An sql-lite for all of that would be perfect, if that file is not present with a prj the IDE could recreate all of it without anybody loosing sleep over it.

Tagging attributes of properties, methods, etc, could all be done with language constructs.

5

I think a really good argument for XOJO to divorce the IDE and the compiler and go with plain-text is that they can modernize the language with much less effort and with quicker turn-arounds.

For example this whole API 2.0 could be as simple as a “transpiler”/“preprocessor”, giving them more breathing space to work with the framework and compiler functionality.

You see the binding of the language with the actual framework implementation is killing them, there is no flexibility, is all hardwire.

They can even do this with cross-platform functionality, ie have common UI/Platform things represented the same on the language, (we create the abstraction on the language) but a pre-procesor will send platform specific code to be compiled.

6

This request is almost as old as Xojo. It’s unlikely to happen because it would be an absolute ton of work, and they’d have to figure out how to implement their licensing model in the compiler alone.

I’d say the chance of this happening are extraordinarily slim as there are many other things that have to take precedence over such a feature, like improving target support.

7

It would be very nice to have Properties / Methods etc. in my own Order. When I have Classes representing DataRecords, it very annoying to search for the Property. It I could arrange the order to match the Database Fields.

8

I can build or run the app with the debugger, with one click. I don’t want more clicks/keystrokes to do that.

Implementing various methods from the “new” into the classic framework would be favourite.

9

Things that might have been … :frowning:

a command line compiler doesnt necessarily change this

10

Just like as Norman said, I dont see issues with managing the licensing.

I think that XOJO can take a step back to regroup and make a new strategy moving forward. I think there is a good resurgence for RAD, low-code, no-code solutions. XOJO just need to find its place in this new world.

I see their mobile strategy too bloated and unsustainable. Just keeping the pace with iOS changes is an overwhelming undertake. How can Xojo keep up with changes in platforms, provide a one-one mapping of those features in Xojo and retain some level of backward compatibility is beyond my imagination.

How do you do all of that and keep your product fresh modern and nimble?

In my opinion (not worth anything) the one-to-one strategy for the framework went too far, there was nothing wrong with having a bit of abstraction. Xojo framework broke compatibility just to enable that one-to-one strategy for iOS.

I really love XOJO, I do, I just fear that it may become unsustainable…

For me the case to regroup is an introspection of Xojo core propositions and how their fair with the current market: cross-platform, write-once and easy to learn.

For mobile we have big players with actual cross-platform frameworks like Xamarin, Titanium, most of them have cloud-build options. Also you have some impressive cordova solutions out there.

Code reusability across platforms COULD be XOJO advantages, but right now it is not, and wont be for a long time. XOJO framework that came with IOS broke that. Now Android I imagine will be 2.0. So until we get 2.0 on all platforms, code reusability will be a struggle.

Write-once run everywhere is not Xojo’s main selling point it could be, but they like the one-to-one mirror of the language and the platform. But even there that one-to-one mirror of native features is not that attractive especially in mobile because:

You write so much platform specific code that at the end is almost as maintaining an XCode project for IOS, and another with Android Studio. If im a company I do not gain much from the Xojo strategy, specially with little code-reusability. As a consultant I may live with it, but event then learning swift and the story board is not that hard!

This is worst if you have competitors like Xamarin and other cordova tools that have common components across platforms but still have particular functionality to go beyond on a particular platform.

For example: even for IOS if you want to do a fancy UI or very particular functionality, chances is that you can’nt use the built-in functionality in XOJO and you end up creating views and drawing, handling events and more with pure declares.

The way I see it all the traditional/common UIs that you can build for IOS with XOJO, could have being abstracted to now work on Android.

The easy to learn part also went out the window. For example since IOS is just a mirror I have to look at Xojo docs but in many instances to understand it I have to go and read the docs at Apple. Even worst if you are new to development know you have to read Apple Docs out of contexts and learn to read Swift or Objective-C snippets/sample code.

11

Some of the things you’ve suggested I’ve wrirtten about on my blog
https://www.great-white-software.com/blog/2019/08/15/the-universal-project/
https://www.great-white-software.com/blog/2019/08/19/universal-project-ii/

a “universal project” where one project can be used to create several applications on different targets would be really nice and would make code sharing between those applications really simple for users of all skill levels and would not require SVN externals pr whatever gits equivalent is

13

When Xojo Inc provides a higher level of abstraction with new classes and namespace the vocal users say “not a new framework”. So when they overload / modify the existing classes the vocal uses say “not API2.0”. Then they say “Why so many declares, can’t you give us more built-in?” Tough crowd!

1 Like