I've released the source code for Bintracker, a powerful, hackable
"chiptune audio workstation" written in Chicken Scheme.
The project is work-in-progress, and is currently in an early alpha
stage. Basic features work and the editor is usable, though not
necessarily useful ;) I'm publishing the source now in order to
receive some feedback from early adopters, and maybe also find some
new contributors along the way.
More info on the project site: https://bintracker.org
The source is available at https://github.com/bintracker/bintracker .
Wow! Neat project.
I love the GUI.
I've had a (very) quick look at the code. It looks like bt-gui and
bt-gui-lolevel are the core of the UI engine and there's a binding to tk?
Could you talk more about the architecture of the UI? The screenshots
look great and I've not seen many UI heavy Chicken programs yet. This
could be a winner! Is the UI toolkit reusable?
Sure. The UI is indeed using Tk, controlled though the pstk egg. On
startup, a custom Tk Theme is generated from user preferences, based on
Tk's built-in "clam" theme. Icons are based on Material. Currently
Bintracker generates icon PNGs in matching colors, since full PNG
support has only recently landed in Tk.
bt-gui provides a set of high-level abstractions over Tk's widget
primitives, in the form of coops classes. All UI classes inherit from a
"ui-element" base class. There are 3 types of classes: Decorations (used
to implement taskbars, modelines, etc.), buffers (like Emacs/Vim
buffers, used to implement all the major widgets), and metabuffers,
which are used to dynamically manage recursive collections of buffers.
Input focus is managed manually, because Tk's automatic focus handling
is insufficient for this project. There is a central focus handler for
Bintracker proper (defined in bt-state); all buffer instances must
register with this handler. Additional focus controllers can be
constructed for pop-ups etc.
Most of the high-level UI abstractions are very Bintracker specific,
though there are certainly parts that could be reused for other
projects. I am considering ways to separate the non-specific parts
better, but at the moment it's not practical for me to have half of the
UI classes defined in one module and the rest in another.
There is one major drawback to this setup: Tk does not support any of
the a11y APIs provided by the major operating systems. The current
solution to this is very primitive and hacky: There are two keyboard
shortcuts to output information about the location of and content under
cursor to a user-defined screen reader or tts tool. A lot more work is
needed here. The best solution would be to implement a11y support in Tk
itself, but that is beyond my current capabilities.