Help with making Open Rocket parts library more kid friendly.

[woodywong]

Hi there,
Openrocket is an awesome tool that I have used to make several rockets. I have a student that is blowing through the kits I give him. I think its time to get him into designing his own rockets. Its probably easier for me to just show you the issue on video than type a massive post;

Any help with this would be much appreciated.
Thanks!

 

[neil_w]

This is tricky. I can think of only one idea for now, which may or may not be a practical solution for you.

Basically, set up the presets to include only the parts from the Designer's Special, and uncheck the option to always open the library dialog:


After doing this, you can skip the library entirely, and just use the pull-down to the left of the Parts Library button:

You'll get a list of the available parts you checked previously. You can always go into the library if you want, and change the set of presets or pick something that's not a preset. But it gives you a shortcut to get to the list of "preferred" parts without needing to weed through the whole library listing.

Unfortunately, the shortcut listings don't give you all the info for those parts (length, shape, etc.)

You'll need to manually go and do this for each component type. The hardest part is probably the nose cones, but ideally you'll only have to do this once.

Then, close OR and copy the settings file to each machine that you want to configure this way. The settings file is.... oh crap, I don't actually know. If you want to proceed this way I'll find out and post back.

So that's the only idea I have. See if it might work for you.

 

[Hobie1dog]

to the forum

 

[caveduck]

(Parts database data guy here) That's a great idea! The current data model and UI in the OR code lacks any support for custom filter tags in the database, which I really think it should have. They need to borrow some concepts from the Excel UI for quick column filtering. I'd recommend filing a feature request issue over on the openrocket github: https://github.com/openrocket/openrocket/issues

 

[neil_w]

Then, close OR and copy the settings file to each machine that you want to configure this way. The settings file is.... oh crap, I don't actually know. If you want to proceed this way I'll find out and post back.

Regrettably, this will not be practical on Windows, because the settings are in the registry. You could do it on Mac but if I had to guess you're going to want Windows.

 

[caveduck]

@neil_w I think using the platform-dependent mechanism (Windows registry, Mac prefs) for user settings for OR is a serious UX bug and should be changed to placing a human-readable yaml/xml/json file in $HOME so that people can manipulate them easily with a text editor. Registry etc. is more for recording settings from a big preferences dialog where there is a full UI for everything. The OSX prefs interface is just as painful as the Windows registry. YAML would probably be the best file format since it allows line breaks and comments while supporting a full nested object structure, and it's much less clunky than XML.

 

[neil_w]

I *believe* that right now OR is using standard Java APIs to manage preferences. There's a good philosophical argument to be had regarding whether it is better to conform to system standard prefs or to do something like you describe, with a bespoke but easy-to-edit prefs file. However, under no circumstances am I going to defend the Windows registry.

Implementing our own prefs file format is certainly possible, although I don't know how likely it would be to bubble up to the active portion of our TODO list. Hand editing and/or sharing prefs would be nice in this particular instance and in general, but I don't think it's really a critical need for OR right now, at least not compared to other things. But I will raise the issue with the team.

As always we would welcome the help if anyone wants to jump in.

 

[SiboVG]

The Java Preferences API provides an easy way of exporting the preferences to an external XML file. You can then also import those preferences back into OR. I created this demo to demonstrate the principle:

View attachment Screen Recording 2023-03-31 at 17.42.07.mov

So, in theory @woodywong could create a desired preferences file (including selecting component presets), send that file to the student and he could then import those preferences in OpenRocket.

Note: this is a quick demo, and requires some cleaning up, so I'm not sure if this feature will be done in time for @woodywong to actually use it. But it could be interesting for future OpenRocket workshops.

 

[SiboVG]

@woodywong when are you planning on giving the OpenRocket assignment? We're gonna push a new release, normally within the next month, so with a bit of luck, this feature can be implemented by the time you need it.

 

[woodywong]

Thank you for all of your responses. I appreciate it. I love openrocket and thank the dev team for all of their work.
@SiboVG I was planning on starting him on it in a couple of weeks so that isn't much time. But, in the meantime I think I can make it work with the checkbox suggestion from @neil_w

 

[neil_w]

Good luck and let us know how it goes. We don’t get a lot of feedback on pain points from younger users, so anything you can tell us will be helpful.

 

[Tobor]

Hey guys,
Actually you can share custom preferences with other people/machines. After changing your preferences and exiting OR, you can launch the registry editor and EXPORT that registry key.

Then just copy the key to any machine you wish to update and double click the key file to launch registry editor and follow the prompts to add the key.

ATM I do not recall the specific key to export but I will look it up and report back.

 

[rlboothbna]

THANKS to the OR development team for being interested in the problems of young users and their mentors!!!

 

[Tobor]

Hey guys,
Actually you can share custom preferences with other people/machines. After changing your preferences and exiting OR, you can launch the registry editor and EXPORT that registry key.

Then just copy the key to any machine you wish to update and double click the key file to launch registry editor and follow the prompts to add the key.

ATM I do not recall the specific key to export but I will look it up and report back.

Okay the key is HKEY_CURRENT_USER\SOFTWARE\JavaSoft\Prefs\/Open/Rocket\favorite/Presets

Do a search for HKEY_CURRENT_USER\SOFTWARE\JavaSoft\Prefs\ and then navigate from there. Right-click the Preset key (Looks like a folder) and select export.

 

[caveduck]

I *believe* that right now OR is using standard Java APIs to manage preferences. There's a good philosophical argument to be had regarding whether it is better to conform to system standard prefs or to do something like you describe, with a bespoke but easy-to-edit prefs file. However, under no circumstances am I going to defend the Windows registry.

Implementing our own prefs file format is certainly possible, although I don't know how likely it would be to bubble up to the active portion of our TODO list. Hand editing and/or sharing prefs would be nice in this particular instance and in general, but I don't think it's really a critical need for OR right now, at least not compared to other things. But I will raise the issue with the team.

As always we would welcome the help if anyone wants to jump in.

The Java prefs library tries to use system facilities but on both Windows and Mac those facilities are decidedly unfriendly to human editing, which would seem to be an important use case here. I believe in Linux it just puts a dotfile somewhere but I haven't looked at the format, but maybe you could swipe that code, or just use a YAML or XML library more directly.

One approach other than changing the storage format would be to really beef up the UI surrounding prefs, with multi-item copy/paste both inside the app and across different instances of OR, full export/import-from-file capability, elimination of hardcoded density values, etc. That would be worth doing eventually and would fix up some warts that just changing the storage format would not address. But making the storage more accessible for editing looks like it would be *much* less work and would definitely help the cause, though it does nothing per se for the UI.