Update to build 64-bit only on Xcode (macOS) with XPLM v3.1 #4
Conversation
* [Usability/New Feature] Provide users with a "restore" button, to always revert to the settings BLU-fx loaded at the last start-up.
* [Usability] Provide explicit "load" and "save" buttons to allow users to control when the .ini file is saved. (Note: multiple files can be added later.)
* [Usability] Allow users to add a keyboard shortcut or joystick assignment to toggle the settings window open/close.
* [Usability] For XPLM 3.1 runtime, add keyboard shortcut to Settings menu item (using new XPLMAddMenuItemWithCommand, when available).
* [Xcode-specific] Update Xcode project for building 64-bit plugin targeting macOS 10.10 and above.
* [Xcode-specific] Rename scheme and split into separate "Debug" and "Release" shared schemes to Xcode project, and add shared schemes to
git repo. (To change schemes, just click and change between "Release" and "Debug" in the Xcode toolbar.)
* [Notes]:
- The settings are no longer auto-saved upon closing the settings window! Instead, there is one auto-save when the plugin is stopped. This is
an important usability issue, since the new "save .ini" button implies it will only save if the user asks it to. (Though, saving on exit seems
very reasonable, since "restore" and "load" are no longer relevant at that point, and people expect the state to persist.)
- The new "User" preset (connected to the "Restore" button) is *only* loaded at start-up, and never again. So, it represents the settings the
user started X-Plane with (which will either be the .ini file, or the default settings if it's the first time). So, no matter how many times the user
saves an update to the .ini file, "Restore" will always restore to the earlier setting! This is a feature. That is why there is a separate button,
"Load .ini", which explicitly updates the current settings from the saved file. However, loading does not overwrite the User preset, until the
plugin is re-loaded (usually by restarting X-Plane). The reason it works this way is as a foundation for the likely future option to
save/restore multiple files. This will set things up nicely for that.
- For the Xcode project, there is an optional "copy" step to auto-install the .xpl file into your X-Plane library. To get that to work, simply edit
the project settings to define your XPLANE11_INSTALL_DIR path (i.s., the absolute path ending in .../X-Plane 11). Do not include a trailing
slash or any other directories past X-Plane 11 root directory.
- I hope this is useful! I know it helps me a lot to have these features. (And since macOS will block 32-bit libraries soon, having it updated
to be 64-bit gives BLU-fx the new lease on life it deserves!
(Thank you for making this open-source.)
|
I just realized, this may actually be similar to the feature request in #3 .. I in fact started out calling it "user" but I then decided this would be the first step in possibly having a way to save/restore from many different saved user presets. So, I opted to just call it "restore". Ideas welcome on that. Steve |
|
As of right now I'm no longer working on BLU-fx nor do I use it myself anymore as right now. |
|
Well, I thought it was worth a try. I'm loving the changes in my version, so I'll just keep it for myself, thanks. The whole fricking point of the install directory variable is that it isn't predefined. I don't know what is wrong with you kids today that you can't have a little imagination. I just sent it to you to start the discussion, get your feedback, etc. I am really annoyed that you think the variable is a problem. I made the variable as a way for you to generalize the installation directory for a quick install -- of course in the real repo it should be blank (or maybe be set to "/dev/null"). I just didn't clear the variables. OBVIOUSLY one would put a mention in the README.md file that if you want the feature that building immediately copies it to X-Plane, you just have to fill in the variable. What the heck is so different about that and a configuration file that CMake needs you to set environment variables for? I'm so over you kids treating people like crap when they try to help. I don't believe how ridiculous you are. I'm not asking you to actually integrate the code. I just wanted to show it to you. That's the thanks I get -- public berating for just trying to help. I also got it working on XPLM 3.1 which your last checkin did not do. So if you're not working on it, why make such negative comments? Open source is not turning out to be the collaborative thing I thought it would be. Kids today, seriously. Steve |
Note: I only build and tested these changes on Xcode (for macOS target). However, there are two types of changes:
(1) Mac-specific: Xcode project changes to build correctly for 64-bit with XPLM 3.1 based on previous updates; and
(2) All platforms: Usability improvements to add settings restore and explicit load/save buttons.
Therefore, these changes are tested and work great on macOS 10.14.6 (Mojave) with X-Plane 11.35r1 (August 1, 2019). However, as I could not build (yet) for Windows, I have not yet tested anything there (nor Linux). So, there may be build issues, but I think it should be straightforward if not already working there. (So, I recommend testing it on those first of course).
Oh, and I also didn't test on a pre-XPLM3.1 system. I believe my changes correctly switch from XPLMRegisterMenuItemIWthCommand() to XPLMRegisterMenuItem() -- but I'm not 100% sure.
-- Detailed changes in this pull request:
Add new restore with explicit load/save buttons:
Add commandref to open settings window, and show key binding (if any) in menu.
Update Xcode project to correctly target XPLM 3.1 and 64-bit architecture.
Fix up Xcode "schemes" so there is now a one-click way to switch btw Debug and Release builds, checked into repo in a common way (not user-specific).
Notes:
--
I hope this is useful! I know it helps me a lot to have these features. (And since macOS will block 32-bit libraries soon, having it updated to be 64-bit gives BLU-fx the new lease on life it deserves!
Thank you for making this open-source.
Steve