Avoiding accidental quit from the IDE

this time for todays pc’s is abnormal … its like driving Ferrari with parking brake …
it should take seconds …

2 Likes

For me on my Intel iMac Pro with three projects, all for the same app, stored in Binary format:

IDE Launch: 1:01 (limited MBS and Einhugur plugins)
Open project (31.1 MB Desktop): 0:25
Open project (16 MB Web): 0:47
Open project (8.7 MB iOS): 2:00
Compile & run (Desktop): 0:23
Compile & run (Web): 1:13
Compile & run (iOS): 3:36
TOTAL (Desktop): 0:48
TOTAL (Web): 2:00
TOTAL (iOS): 5:36

Interesting that the smallest project in MB (iOS) is by far the slowest to launch and compile.

If you have this problem regularly my friend wrote an app that might help:
https://qblocker.com/

QBlocker is a small, free menubar app for OS X that stops you from accidentally quitting an app. It works by blocking OS X’s default CMD + Q keyboard shortcut and forcing you to hold to quit.

4 Likes

We still have a few people for whom the IDE start takes 60-90 seconds, whereas I’m around 25 seconds. I’m guessing this could be due to the unzipping of plugins… Can anyone test the unzip script and report back?

BTW, my benchmark speeds above are using unzipped plugins (via Plugins Pro).

What about your images ?
If you have some, were they dropped into the Navigation pane or direct access via FolderItem ?
In the former case, you read (at open time) all the images, and save them (at write time)… Imagine the waste of time and space.

in the former case, search elsewhere, sorry.

Remember, a 1024 x 1024 @144 dpi macOS Icon weight takes MB and I/O time.

me too, (without third party plug-ins)
20+ seconds nonsense for sure.
(as Example Lazarus IDE open in < 2 seconds)

This is a pretty easy fix if you’re on a Mac

  • Go to System Preferences → Keyboard and click on the Shortcuts tab
  • Select App Shortcuts on the left side
  • Click the + button
  • Select Xojo for the app, “Quit Xojo” (no quotes) for the menu title (or whatever is the quit menu item for your version of Xojo - I don’ t know if it changes)
  • type your replacement key command for Keyboard Shortcut field - I use option-command-q
  • click Add

Go back into Xojo (relaunch not typically required) and see in the menu that the keyboard shortcut has been changed

I’ve done this for Safari, Chrome, Preview and a number of other apps that I grew tired of quitting accidentally

Easy peasy

7 Likes

Wow, I didn’t know you could change the shortcuts app by app. Thanks for the info! Also, thanks to Kem if this is what he was getting at way up there as well. :slight_smile:

not sure if he meant @ the Mac level or within Xojo itself… also haven’t checked if Xojo allows that… which is why I posted

Xojo does allow it. In Xojo Preferences (on macOS is Cmd+, key by default) at the bottom of the first (General) tab is a button “Edit …” next to Menu Shortcuts. From there you can modify the shortcut keys used for any menu item – or add your own if there is not one for an item you want assigned a shortcut key.

Edit: I stand corrected; while the above is true there does NOT seem to be the option to override the Cmd+Q to quit. At least in my 2021 R2.1; but what DID work was to assign Cmd+Q to some less intrusive action such as showing the About box.

Always finding it unintuitive as I never know which (Mac OS’ system preferences or Xojo’s preferences) takes precedence.
One defeats the purpose of the other, but which?

Just for completeness, I now have numbers for my project with Turbo-mode on, and pre-unzipped plugins:

Launch 0:18
Open Project 3:23
Compile & Run 1:19

Total 5:00

This is less than half of my previously-reported 10:15, even if I have to withstand howling fans.

I suspect the long load time has to do with the immensity of the project that is stored in text format.

I appreciate the hints and suggestions I read here. However, I still feel that a (possibly) optional warning when quitting from the IDE if there are no changes to save (offering a chance to abort) is a good thing.

I also think a lot of the launch stuff (and even project-opening stuff) could be done as background tasks on another hardware thread, since typically after opening a project you’ll start by editing some stuff, so loading plugins and non-visible project files could take their time.

2 Likes

Slightly off topic but I see reference to ‘Turbo’ mode in your posts - are you referring to a physical Turbo button on your PC like used to be the norm before PC systems became adaptive and able to respond to processing, thermal and graphical demands?

Mark - I think Paul is referring to the “Turbo Boost” feature in some later Intel processors. It normally works automatically (no user controls in default OS X) but it can be adjusted.

Here’s an example of a helper app which will let you adjust this feature:

https://www.rugarciap.com/turbo-boost-switcher-for-os-x-blog/

The linked app lets you turn off the feature (per application apparently) since for most apps the performance boost isn’t perceivable but the batter drain, heat, and fan noise are.

I’m guessing this is why there was some discussion above about if Xojo used one or multiple cores when building apps (the answer being “both” – some parts of the Xojo build process use all the cores; some don’t).

HTH,
Anthony

Hiya Paul,

If you want to go the Keyboard shortcut route on OS X, here’s how you need to add it.

Notice for entires in the Application menu, no menu name is required; so add the shortcut like this: (only type “Quit” in the menu title)

I was inspired to figure this out because of your post/thread, so thank you. :grinning:

Yep, I did that (in light mode :grimacing:). Thanks for posting. Enjoy your Midwest winter :cold_face:.

1 Like

Right - I had throwbacks to the 90’s for a second!

1 Like

No menu name is required for any of them. Just put the title of any menu item (without the parent menu) and it works the same :wink:

Thanks for pointing that out Arnaud.

Indeed, this is the case, as long as the same menu item name doesn’t occur in two different places in an App’s menus.

But… if two menu items have the same name, the “full menu path” version (e.g. “File->New”) will call the expected item.

I made a silly example app to show this:

By specifying the explicit menu “path” the second “New” option in the “Error Report” menu gets the Option-Cmd-N shortcut while the first “New” option in the “File” menu retains it’s default shortcut, Cmd-N.

So “99%” of the time you’re ok leaving out the full menu path, but there are cases where doing so will cause unexpected results. (e.g. if there’s two Delete options, calling the wrong one may be pretty bad)

For me: it’s worth the trouble of typing the explicit path as to avoid getting unexpected results.