I understand the reason why the buttons behave as they do, and I thought about suggesting something like what you're thinking about. But I reached the conclusion that it'd just add confusing behavior to an already confusing situation. That is, it might make things easier for a first-time user but at the cost of more confusion down the line ? as well as unnecessary complexity in the code. In the end it might be the best idea but first I think it'd be worthwhile spending some more time thinking whether the present interface for the configurations tab might have been the wrong direction to go.
One possibility I think might be cleaner, though requiring one or two more clicks, is to select only whole rows, and then get rid of the motor and ignition buttons, and add an "Edit" button. That would bring up a dialog specific to a single configuration, in which you'd have buttons or, perhaps better, dropdowns for each motor mount.
The point is, to my mind, trying to make all motors for all configurations editable from a single tab puts too much of a load on the user interface.
My concern with the older interface was how interminably long it took to accomplish certain simple tasks. I don't want to add 2 more clicks to each single-motor-mount configuration; in a cluster rocket with 4 MMT groups (aka the typical 7 motor cluster) that would end up being 6 more clicks per configuration, on top of the greater variety of configurations there would be to simulate!
Even worse, because of the way it hid the configurations in a dropdown box, there was no way to check "Have I done this configuration before?" in the old interface.
The additional pointing tasks, and the hiding of information, made setting up large numbers of configurations interminably slow.
For a streamlined, power-user friendly interface, the number of clicks should be minimized, and helpful visual information (such as what other configurations are already set up) should not be hidden. Case in point: you suggested using dropdown boxes.
Dropdown boxes are the worst of both worlds: it takes two clicks to do what could otherwise be done in one with checkboxes or a table, and it hides the options until you make the first click, delaying the decision further.
You are concerned with visual clutter: one man's trash [clutter] is another man's treasure [helpful information]. Instead of simply hiding clutter [useful information] away, the proper response is to provide visual clues for navigating clutter.
========================================
I just created a new file with a nosecone and a body tube just to see what a new user sees.
What do I do here? I click "New Configuration" and get nothing.
Here's what it ought to look like:
Note that a) the user is not allowed to make a configuration, and b) there is a big highlighted box telling them COME HERE NEXT.
We can't really automate the selection for them, because it'd be very hard to figure out which tube is the one they want. So we use color to point them toward a list of all the options (one in this case), and give them a choice. Once they make their choice, the box would turn back to white.
Once they do that, they currently have to create a configuration. This shouldn't be. Selecting a motor mount should automatically create a configuration if there was none to start.
As it is now, once they figure out to create a configuration, they get to this stage. I presume this is where confusion REALLY sets in:
"I've chosen my motor mount, I've made a configuration. What now?
The key here is in the implementation details: if a configuration is newly created, it should be immediately selected so that the user
learns that it needs to be selected. That holds true whether the configuration was created by the "New Configuration" button or by selecting the motor mount. By showing them that configurations, when selected, let you choose motors, they will not need to be told to do so.
