The plans for 3.3 are coming more into view... the time frame is not so much but here are the new goals for 3.3:
1) New platform stabilization:
iOS: Fix memory leaks:
This is the only major issue I currently see on iOS. I had disabled some code due to a crash regarding destroying windows which is leaving memory/UI objects dangling.
Andrdoid:
a) Fix layout issues:
Things don't layout quite the same as other platforms, there are workarounds which I am using in Interface Builder currently so it works, but really these issues need to be addressed in the library itself.
b) Improve performance:
I did a preliminary test of moving the dw_window_s/get_data() logic entirely into C/C++, however the performance gain was negligible. This also required rather large changes to the code, requiring subclassing basically every widget class in Kotlin to provide a "data" Long field member I could store the root pointer in and providing a callback in the class finalize() method so the data could be freed during object destruction.
So I need to profile the code and see where the performance issues are and possibly come up with a new plan for improving it.
c) Fix stability issues when calling message loop sensitive APIs in the EXPOSE callback. The EXPOSE callback is the only one that MUST run on the UI thread, and because of this everything follows different code paths. Due to the (poor) design of Android this requires us to do some really nasty things to get this code to work which causes potential instability. Currently it is just recommended that you only do what is absolutely necessary in EXPOSE callbacks and avoid calling any functions that might block (requiring us to run the nasty message loop code). Not sure if this is fixable, but it definitely requires revisiting before 3.3 is finalized.
GTK4: Evaluate the shortcomings and see if any can be addressed with the new GTK4 releases, usually many of these initial issues get addressed by changes in the first few minor updates after a major release. Current GTK4/Wayland issues: All coordinates window relative and very limited, positioning completely disabled. Popup menus require temporary additions to the window layout (the developers had told me they would probably add a new way of doing this, but last I checked it was still a TODO item).
2) Mobile container changes:
I have decided I will add a new feature test DW_FEATURE_CONTAINER_(MOBILE_)MODE
On desktop platforms this will report DW_FEATURE_UNSUPPORTED.
On iOS and Android this will have 3 possible values:
0 - Default single line/column mode... Due to limited space on mobile platforms this is the default only showing the bare minimum.
1 - Double line mode... Add a second line to the row, which will display the additional column data (no column buttons)
2 - Multi line mode... Add an additional line to each row for each column, also add buttons with the column header to the far left of each line.
These buttons will act like clicking the column header on the desktop platforms.
3) Mobile splitbar dragging:
Figure out some way to allow dragging, arbitrary positioning of the splitbar position on iOS and Android.
Currently the splitbar functions on iOS and Android, but it can only be reposition via the dw_splitbar_set() API.
4) Mobile groupbox support:
Add visual support for groupboxes on iOS and Android. This was one of the shortcomings in 3.2... groupboxes functionally work. They provide support for groups of radio buttons contained in them, however on desktop platforms there is a visual rounded box around it and a text title. These visuals are missing on the mobile platforms. If possible add support for this.
5) Add support for upcoming MacOS 13 Ventura and iOS 16. Often times there are breaking changes in new releases, so will need to test on those new platforms, I should be able to test iOS 16 easily, however MacOS 13 I only have one machine capable of running it currently and it is Apple Silicon based (ARM64) so unless I get a donation of an Intel machine capable of running it, this might have to wait until the OpenCore team gets Ventura running on older Intel hardware.
Time frame for 3.3... I have for the last few versions been on kind of a yearly cadence. I was hoping this version could get out a bit sooner but, worst case I will aim for January 2023.... and see if I can possibly get it out soon after the final versions of MacOS 13 Ventura and iOS 16.
1) New platform stabilization:
iOS: Fix memory leaks:
This is the only major issue I currently see on iOS. I had disabled some code due to a crash regarding destroying windows which is leaving memory/UI objects dangling.
Andrdoid:
a) Fix layout issues:
Things don't layout quite the same as other platforms, there are workarounds which I am using in Interface Builder currently so it works, but really these issues need to be addressed in the library itself.
b) Improve performance:
I did a preliminary test of moving the dw_window_s/get_data() logic entirely into C/C++, however the performance gain was negligible. This also required rather large changes to the code, requiring subclassing basically every widget class in Kotlin to provide a "data" Long field member I could store the root pointer in and providing a callback in the class finalize() method so the data could be freed during object destruction.
So I need to profile the code and see where the performance issues are and possibly come up with a new plan for improving it.
c) Fix stability issues when calling message loop sensitive APIs in the EXPOSE callback. The EXPOSE callback is the only one that MUST run on the UI thread, and because of this everything follows different code paths. Due to the (poor) design of Android this requires us to do some really nasty things to get this code to work which causes potential instability. Currently it is just recommended that you only do what is absolutely necessary in EXPOSE callbacks and avoid calling any functions that might block (requiring us to run the nasty message loop code). Not sure if this is fixable, but it definitely requires revisiting before 3.3 is finalized.
GTK4: Evaluate the shortcomings and see if any can be addressed with the new GTK4 releases, usually many of these initial issues get addressed by changes in the first few minor updates after a major release. Current GTK4/Wayland issues: All coordinates window relative and very limited, positioning completely disabled. Popup menus require temporary additions to the window layout (the developers had told me they would probably add a new way of doing this, but last I checked it was still a TODO item).
2) Mobile container changes:
I have decided I will add a new feature test DW_FEATURE_CONTAINER_(MOBILE_)MODE
On desktop platforms this will report DW_FEATURE_UNSUPPORTED.
On iOS and Android this will have 3 possible values:
0 - Default single line/column mode... Due to limited space on mobile platforms this is the default only showing the bare minimum.
1 - Double line mode... Add a second line to the row, which will display the additional column data (no column buttons)
2 - Multi line mode... Add an additional line to each row for each column, also add buttons with the column header to the far left of each line.
These buttons will act like clicking the column header on the desktop platforms.
3) Mobile splitbar dragging:
Figure out some way to allow dragging, arbitrary positioning of the splitbar position on iOS and Android.
Currently the splitbar functions on iOS and Android, but it can only be reposition via the dw_splitbar_set() API.
4) Mobile groupbox support:
Add visual support for groupboxes on iOS and Android. This was one of the shortcomings in 3.2... groupboxes functionally work. They provide support for groups of radio buttons contained in them, however on desktop platforms there is a visual rounded box around it and a text title. These visuals are missing on the mobile platforms. If possible add support for this.
5) Add support for upcoming MacOS 13 Ventura and iOS 16. Often times there are breaking changes in new releases, so will need to test on those new platforms, I should be able to test iOS 16 easily, however MacOS 13 I only have one machine capable of running it currently and it is Apple Silicon based (ARM64) so unless I get a donation of an Intel machine capable of running it, this might have to wait until the OpenCore team gets Ventura running on older Intel hardware.
Time frame for 3.3... I have for the last few versions been on kind of a yearly cadence. I was hoping this version could get out a bit sooner but, worst case I will aim for January 2023.... and see if I can possibly get it out soon after the final versions of MacOS 13 Ventura and iOS 16.