While still trying to figure out how to do lens correction, I've spent some time re-doing code that underpins how the interfaces work. Interfaces in the The Dark Room are like their own little plugin. I designed it this way so that someone in the future could potential write their own plugin for my software. Just about every program in existence has an interface of sorts, so it's no surprise I've had to make something for my software.
Where my software differs however, is I don't use in-built elements (like buttons and user interaction gadgets). My interface is completely customised, which means I've to build a lot of the functionality myself. Like, capturing the mouse coordinates, and testing if it's over a button. Drawing the button, drawing the button in a mouse down state, and etc. A bit of a pain, but it's just the way I've had to design it.
I began by re-modelling how data is stored in each interface object. I had been keeping things at a class-level, but I've instead moved this to my display container. Doing this means that data is unique to each display. For the moment this won't mean much, but in future if I was to add the capability for the user to have more than one display open at once, then it means each display can send the appropriate data container to the interface, do it's thing, and not interfere with another display. It means I only need one instance of the tool, but can have it interact with multiple displays.
Another thing I worked on as well, was a completely custom made radial menu system. Cinema4D does have radial menus in it's viewport, but the code to do this is not exposed to plugin developers. Which means, we can't use Cinema4D's own built-in system. It's pretty crappy that software makers do this. They've done the same with the viewport, you can't have your own viewport in your own window. Seriously, who limits a 3D program by not allowing plugin developers to have their own 3D viewport engine, in a 3D program? How ridiculous. I can think of a number of plugins where this could be used. Cheap shot on my part maybe, but it's probably down to manages int he company who don't have a clue how the rest of the world may want to use their software.
Moving on.
So I made my own radial menu system. It's pretty basic, but does enough to do what I need it to do. It looks like this:
It's disappointing to have to waste time making this when Cinema4D has this functionality already. I had to jump through some hoops to make it work, including using OS-specific functions to obtain and test window focus. Up until now I had been avoiding OS functions, because it means I have to make code that's different on Windows and Mac. But it's the only way I could make it happen. And having the radial menu takes pressure off having to make a lot other intricate interface draws. I can call the radial menu instead of making a bunch of icons and clickable areas that I have to make work in the display. And users generally like shortcuts. So if this helps the user experience, then hopefully it's for the better. If nothing else, it's convenient.
These updates and additions I think will help future proof how the program works, particularly for the way interfaces are done.
While working on these updates, I've also been thinking about how to allow my interfaces to draw into the deep viewport as well. There are reasons for wanting to inject draws from some of the interfaces. For example, to draw a visual aide to help the user interact with the interface. And looking at this, I've come to an early conclusion that I'll probably have to rework the way the viewport engine pipeline works as well. This one will be more difficult, as the viewport engine is currently fairly fixed. So I'll have to figure out a more flexible pipeline for this to work.