Getting Better All The Time
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