Dynamic Windows 3.4 Plans

[dbsoft]

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.

[dbsoft]

An update, already done some of this, the conversion to std:: string in the C++ bindings is complete. The initial version of calling into native code from javascript in the embedded HTML widget is done, subject to change after input from the community.

This post is basically about my thoughts on stabilizing the Android version. There are two problems with the Android version currenty, stability and performance. I think both are important but stability is MORE important. To that end, I have an idea for a feature that will improve Android stability at the expense of some performance.

This is related to the DW_SIGNAL_EXPOSE which is the signal that is generated when a widget (generally a render widget) is ready to draw. This is the most dangerous area of code for an Dynamic Windows Android application. Calling any functions that might block can cause app hangs or use some extremely hacky code in Dynamic Windows that I wrote to get things to work, but is really dangerous and can lead to instability.

A history of widget drawing is required. When I started writing Dynamic Windows, when I started this project I supported OS/2, GTK1/X11 and Windows. All three of these platforms allowed drawing onto any widget, not just render widgets and at any time. Later I added Mac as a supported platform, and at that time also allowed drawing to any widget at any time. So this is how Dynamic Windows worked everywhere.

As time went on, drawing became more complex, and more restrictions were put in place. Some being unintentional, depending on the rendering system on the platform, and some were absolutely intentional. For instance any applications running via Wayland cannot draw outside of the draw event, so GTK3 using Wayland cannot draw outside of the EXPOSE event, and not arbitrarily onto any widget. GTK4 has these requirements regardless of the backend, even GTK4 via X11 which technically could do it, are restricted. The mobile platforms I recently added both also have similar restrictions, iOS requires drawing in the expose event as well. Android requires it and due to the way the message loop (Looper class) works it is dangerous to block in those callbacks.

For backward compatibility I have left in the ability to draw onto non-render widgets and at any time for the platforms that still support it, however this silently fails on platforms it doesn't work on. So my idea for the next version, is a feature toggle that will allow you to disable that backwards compatibility.

This feature would enforce drawing restrictions on platforms that could technically draw in situations that won't work on newer platforms that have those restrictions. Also on Android it would toggle the ability to draw in the callback directly. So the default on Android would be the "safe" mode which basically cache the EXPOSE event, create a pixmap from the widget and shunt it onto the safe Dynamic Windows thread where most events are handled. So the EXPOSE handler would not be running on the Android UI thread at all. When the EXPOSE handler returns, it will call back into the Android UI thread, trigger a draw callback and copy the modified pixmap. This might hurt performance since drawing might be delayed slightly, unlike currently it draws immediately and it needs to redraw the entire widget each time. However it will remove the ability to call the unsafe code to break out of the message loop.

Initially I would just implement it on Android and have the feature unsupported on other platforms. Then over time when I can get around to it, I'll add it to older platforms that it can be useful to restrict drawing so they function like the newer platforms.

Any thoughts?

[dbsoft]

Just a development note, GTK 4.10 has deprecated a ton of stuff. Typically I try to move away from the deprecated stuff to the new components they want you to use, however, similar to what they did towards the end of the GTK3 series, they have deprecated some things with no possible replacements.

The GTK3 widgets that were affected this way were not quite as important, essentially the taskbar API. When using GTK3, it continues using the deprecated GtkStatusIcon API since there is no possible replacement. In GTK4 this functionality is unavailable. This functionality is kind of nice to have, but not necessary. So it kind of stinks, but it isn't the end of the world.

However in GTK4, things have gotten much more serious. They have deprecated the GtkTreeView and GtkComboBox functionality. There is a potential replacement for Tree, using the List and a Tree emulating model, this is similar how the tree widget was implemented on Android and iOS which don't have dedicated tree widgets either.

The big problem is the GtkComboBox, the suggested replacement is GtkDropDown. However GtkDropDown is just a list connected to a button. GtkComboBox does something completely different. It is a List combined with an Entry. There is no replacement for this, so for the time being in GTK4 I will just continue using the GtkComboBox in its deprecated state and hope they give us an actual replacement before GTK5 comes out and a huge number of applications become non-functional due to this missing functionality.

[dbsoft]

I think I've come up with a way to call the C++ destructors without attaching signal handlers to every single widget.

Basically windows or widgets can be destroyed two ways. A user close event on the top-level window or explicitly calling Destroy() on the widget.

So all we need to do is trap the top-level close (destroy) and add some additional code to Destroy() to enumerate all the children and call the individual widget destructors.

Since each platform will require enumeration, I think the best thing to do is add a user accessible child enumeration function, like:

dw_window_enum_children()

So this is the path to getting a stable C++ bindings ready for January release.