I rearranged the control_box API. The previous setup was causing impossible-to-find bugs... the storage was managed by engine_view, and there are just too many combinations of machine deletion / machine creation / slot reuse, too many events to get the engine viewer to deal with it correctly itself.
My solution was to make the control box totally manage its own storage, to the point where, when deleted, it nulls out the pointer that points to that storage. In addition, cb_create does nothing in the event that you try to create two control boxes for the same machine. When the control_box is either closed or when its machine is deleted, the GTK resources and memory are freed and the pointer is zeroed out. So there is never a dangling pointer around, despite the different kinds of events that can cause a box to get destroyed.
I guess the idea is that control_box really knows best when it should be destroyed, so why make another object understand it?
Octal 0.8b release thoughts
I have a few more changes to make to OCTAL's API before releasing it. They are all small, and if I can get the docs done I will release them on Sunday (tomorrow.) I'm thinking of revamping the use of "machine::state", and making it more like GTK+'s use of "user data". I'd rather just pass it as the last parameter to all the instance functions, and have them do a quickie cast like my_struct *s = user_data;.
Here is my master list of things coming in 0.8b:
- Adopt the GTK-style naming convention for all the enumeration constants.
- Draft of the machine writer's guidelines---about naming conventions, ensuring archival file formats, ideas on a possible OXAN repository...
- Hopefully some preview code for multiple widget control types in control_box. I would like to have at least trigger buttons work before releasing. I will try to get some consistent handling of creating different widget types, perhaps with a function accepting the OxWidget number and returning a gtk_widget* with its signals and data already connected. Perhaps the names for this data could always be the same, and a single callback can handle all widget types (much like the current one retrieves some data items from the widget's adjustment, widgets without adjustments could benefit from the same thing.)
- Version and Is_Beta fields in machine types
- Rename to Octal SDK or something
- stubs/docs for the wavetable extension