So, having gotten 3.3 out, I am taking a look at where things are, where to focus.
A few things I had hoped to get into 3.3 didn't quite make it, specifically visual groupboxes and movable splitbar on iOS and Android.
Android also didn't stabilize quite as well as I had hoped, so these things are still in the plans, but for 3.4 now.
Additionally a feature I hadn't initially planned on did make it into 3.3 in an alpha state, C++ bindings.
Current plans for the C++ bindings are to make std:: string versions of all the API calls, so you can call them with either std:: string or UTF8 char * parameters. I had held off on this because I struggled to determine what the requirements were for std:: string, but it looks like this support predates C++11 which is the target for the fully functional bindings. So I should be able to implement std:: string versions of the APIs without too much trouble.
Then it is just a matter of figuring out if the miscellaneous API functions should remain in the DW:App singleton class or find homes elsewhere, was hoping to get input from the people who requested the bindings, but one has gone silent and the other seems to have left GitHub where they requested it.
It would also be nice to implement "override detection" that I had attempted at the start. The information I have gleaned from the internet is that there is no "official" way to do this, there are several implementation specific ways it can be done, but that can be a mess, and not guaranteed to work in the future. My workaround to this, is fairly simple, but not very elegant. Essentially, on initialization since I don't know if a function will be overridden I connect the signal handler automatically, even if it isn't needed. If the function isn't overridden our base function will be called the first time this event is triggered, and our base function will remove the unneeded signal. I left my original work in place as macros that currently always fail, causing this fallback method to work always. I can use these macros to do implementation specific detection, so the unneeded signals don't get added (and then removed) saving us some unnecessary work... or if in the future there is some new way to do this, it can be done there.
Finally, I need to connect the destructors to DW_SIGNAL_DELETE for cleanup. The reason I haven't done this yet, is I hadn't decided the best way to do it. The options are to connect a DW_SIGNAL_DELETE to every widget that has an associated C++ class, and when it is called, call the C++ destructor. This is the most simple way to do it, but most signal heavy, way more intensive than I had ever planned for the Dynamic Windows API. The other option, is to connect a single DW_SIGNAL_DELETE to the top-level window, and when it closes, iterate through all the child windows calling their C++ destructors. I might have to try both methods and see which one works better. There may be other options too that I haven't thought of yet.
So I hope to get the C++ bindings to at least beta (stabilized API) if not all the way to stable for 3.4.
Pierce Ng suggested an API/Signal to allow calls into native code from JavaScript in the HTML widget, so that will probably be in 3.4. The idea was from the Webview project on GitHub which supports Edge and WebKit. This would cover most of our platforms, but I will need to look into IE fallback support and Chrome support for Android.
If anyone has any other ideas or suggestions for 3.4, I'd love to hear it.
A few things I had hoped to get into 3.3 didn't quite make it, specifically visual groupboxes and movable splitbar on iOS and Android.
Android also didn't stabilize quite as well as I had hoped, so these things are still in the plans, but for 3.4 now.
Additionally a feature I hadn't initially planned on did make it into 3.3 in an alpha state, C++ bindings.
Current plans for the C++ bindings are to make std:: string versions of all the API calls, so you can call them with either std:: string or UTF8 char * parameters. I had held off on this because I struggled to determine what the requirements were for std:: string, but it looks like this support predates C++11 which is the target for the fully functional bindings. So I should be able to implement std:: string versions of the APIs without too much trouble.
Then it is just a matter of figuring out if the miscellaneous API functions should remain in the DW:App singleton class or find homes elsewhere, was hoping to get input from the people who requested the bindings, but one has gone silent and the other seems to have left GitHub where they requested it.
It would also be nice to implement "override detection" that I had attempted at the start. The information I have gleaned from the internet is that there is no "official" way to do this, there are several implementation specific ways it can be done, but that can be a mess, and not guaranteed to work in the future. My workaround to this, is fairly simple, but not very elegant. Essentially, on initialization since I don't know if a function will be overridden I connect the signal handler automatically, even if it isn't needed. If the function isn't overridden our base function will be called the first time this event is triggered, and our base function will remove the unneeded signal. I left my original work in place as macros that currently always fail, causing this fallback method to work always. I can use these macros to do implementation specific detection, so the unneeded signals don't get added (and then removed) saving us some unnecessary work... or if in the future there is some new way to do this, it can be done there.
Finally, I need to connect the destructors to DW_SIGNAL_DELETE for cleanup. The reason I haven't done this yet, is I hadn't decided the best way to do it. The options are to connect a DW_SIGNAL_DELETE to every widget that has an associated C++ class, and when it is called, call the C++ destructor. This is the most simple way to do it, but most signal heavy, way more intensive than I had ever planned for the Dynamic Windows API. The other option, is to connect a single DW_SIGNAL_DELETE to the top-level window, and when it closes, iterate through all the child windows calling their C++ destructors. I might have to try both methods and see which one works better. There may be other options too that I haven't thought of yet.
So I hope to get the C++ bindings to at least beta (stabilized API) if not all the way to stable for 3.4.
Pierce Ng suggested an API/Signal to allow calls into native code from JavaScript in the HTML widget, so that will probably be in 3.4. The idea was from the Webview project on GitHub which supports Edge and WebKit. This would cover most of our platforms, but I will need to look into IE fallback support and Chrome support for Android.
If anyone has any other ideas or suggestions for 3.4, I'd love to hear it.