Feature Requests for the IDE

Yes, I hide it too. The worst part (on windows at least) is that there is a real Windows toolbar (with a decent size) hidden in there :roll_eyes:

But, the 7 relevant buttons could be there without the current HUGE waste of space.

Maybe it looks ok for someone, to put it in perspective:

*The buttons are there without the huge bar


My brain doesn’t do any shortcuts except Cmd C, V and X. I use a Wacom tablet instead of a mouse and do almost everything with my pen.

1 Like

I use keyboard shortcuts wherever possible to counteract the one-sided hand strain of mouse operation.

Resorting to short cuts seems like going backwards. After all there is a reason Word won out over Word Perfect.

I’m currently using Netbeans to complete a PHP project and the thought of having to spark up Xojo again genuinely makes my heart sink. Love the ‘Real Basic’ language, hate the experience and the price I’m asked to pay to use it.

Some improvements I would love to see in the IDE:

  1. Comment / uncomment in the context menu
  2. A cursor in debugger hex dumps - So offsets can be found by counting cursor presses.
  3. Standard sized and properly customisable toolbars.
  4. Add property and method types grouped together in the context menu. To my mind if you are adding a property you want property, computed, shared, next to each other. Similarly method, shared, delegate etc.
  5. A complete rethink of the navigation tree and editor panels. The amount of time I waste clicking and re-sizing panels to see stuff in Xojo is extraordinary.

Cmd-’ do that (probably Alt-’ under Linux/Windows).

Same for me. Generally I only remember standard shortcuts. The only exception to this is doing some repetitive task in an unfamiliar app which uses some obscure shortcut(s) for some action(s). I’m likely to learn those in order to speed up the task I’m doing. But once that is over I forget them.

I’d like to have picture-sets marked for Mac or WIndows only (or both).
With AppWrapper I can remove unnecessary windows-images, but when building for Win32 I have to remove the Mac-ones manually.

Allowing external project items to include classes and modules. I have many project items I share between projects. Every time I update one of them I need to copy paste it to other projects that use it. In VSCode I have each item included as a git submodule, this allows me to see the change log and update right from inside the editor.


Allowing external folders would also be amazing. Link to a folder and any module/class thats added to that folder gets pulled into the project. Such a pain managing multiple projects with external items. Especially when you need to open them all to fix the missing items


This really belongs in the Pet Peeves threads since I never submitted a report… There seemed to to a lot bigger fish to fry… but it is annoying.

Because i want stay API 1 I mostly code in 2019r1.1 this behavior aways bothered me. They eventually did something about it, but IMO misfired…

I tend not use any shortcuts but the standard ones, but I do use contextual menus a lot…

If for 2019r1.1 in a class you right click in say Methods in the Navigator you get a menu like this:

Add To Methods >
Inspect Methods (disabled)

OK but why what is “Add To methods” hierarchical? What else can you “Add to Methods” besides methods? NOTHING!!!

When you click on it you get a submenu with 31 items on and the only thing enabled is “method” and its the 18th line down (if I counted correctly)!
The first item on the contextual menu should have just been “Add Method”!!! I should only have to select that…

This was braindead behavioral for all navigator subheadings navigator headings for a number of years…

At some point between 2019r1.1 and now that behavior must have gotten under the skin of one of the engineers… Because they changed it

But in typical Xojo fashion, while they made a little “better” (as in more justifiable) it still is not as convenient as it should be IMO.

Now when you click on subheading you get a similar (but shorter ) Contextual menu than before:

Add To "Class Name" >

And the submenu is a list oif things you could add to the parent object and is 16 lines long… Methods is 2nd from the top so at least for that there is less mouse movement…


What the first Contextual menu should be when I click on the method header IMO is:

Add Method (or in verbose API 2 Style "Add Method To Class Name")
Add To "Class Name" >

When I right click on something I expect the contextual menu to be well contextual, and know specifically what I clicked on! The most likely desired action should be at the top not on a submenu.

The less specific actions on the parent object should be available as shown above too, but the most intensional one should be right on top!



I agree with this. If I right-click on property, Add Property should be at the top of the before the Add to submenu.
Same goes for methods, constants, event definitions etc.