The image above shows the current state of the Linkage app for the Mac. There is a main editor window and a sidebar with two panels. The visible panel is the “properties” panel. The other panel is the element selection panel where elements can be selected and deselected from a list of all elements in the mechanism.
The properties panel shows prototypes of the property inputs. I have text, numeric, numeric pair, color, list, and checkbox inputs.
Above is a clip of the spreadsheet that I’m using to determine what properties are available at any one time. My plan is to have a single bit flag for each type of element to which a property will apply. There will be a bit for “plain connector” as well as another bit for “anchor”. When I create the list of properties, only those that apply to the bit flags that are common to all selected elements will be shown. For instance, the “name” property would be visible if a few links, a few splines, and a few connectors, are all selected… if I decide that more than one element can have a name change at the same time. The property for RPM will only ever be visible if all selected elements are rotating input connectors – if I link is also selected then that RPM property would not be shown. This all seems fairly sensible and easy to accomplish in the code once I create the constants with the bit flags and have a way to get those flags for any selected element. I sort of do this already for sorting the elements in the selection panel since I use bit flags to create numbers that are used for sorting.
The problem I’m having is related to the way that I will apply changes to the properties. The properties that are part of the elements are Swift member variables in objects of various types (connectors, links, splines). To change them will require code that changes each one specifically. I think that what I need is a four functions that loop through any element, connectors, links, and splines. The “any element” function would be able to change properties that are common to all of the elements. Each of these functions would take a code block (closure, lambda, etc.) that modifies the actual property. The sequence of events would be that a property item in the UI is changed and that causes a callback function to be called specific to that property. That function calls the loop function and passes it the code black that will change the specific property for all items processed by the loop. I can’t figure out a way to avoid having a callback function for every property UI element.
Interestingly, some code written by a co-worker a long time ago stored all properties in a dictionary. A dictionary is equivalent to a hash table and is essentially a way to associate a string with a value of some sort. That is a terribly inefficient piece code and is extremely error prone; The strings identifying the properties would need to be typed in accurately or a constant needs to be defined somewhere. That hash table or dictionary property storage would actually help in this situation since each UI element could just have a name associated with it that is the property name. I’m not going to do that because checking the properties for every frame of rendering the animation would slow things down too much for my taste. And it’s just ugly code that still requires lots of lines of code, just different code than what I’ll need for my solution (with callback functions).
I have the UI elements working and now I’m writing the code that keeps track of the bit flags. Even though the editor still doesn’t let me click to select an element, I might still be able to get this part fuly functional in the next few days.