Dynamic Windows 3.3 Status Update

[dbsoft]

I haven't really got a solid plan for 3.3 yet, except for stabilizing iOS and Android... filling in whatever gaps I can.

To that end work has begun to add the tree widget to iOS and Android in 3.3. 



A few pieces still missing on iOS, but good progress. Android tree widget will be next.

After that the most likely update will be a new API to allow the display of additional container columns on iOS and Android.

Brian

[dbsoft]

I had a bit of a break from Dynamic Windows while working on the Apple Silicon version of White Star/Pale Moon. That work is now done... so back into Dynamic Windows... here is the first look at the tree widget for Android.

[dbsoft]

Okay, so in the process of getting Dynamic Windows Interface Builder to work on Android, I discovered the frustrating source of an issue I was having during the testing of Android in the 3.2 cycle.  Essentially the issue is that sometimes the file path returned by dw_file_browse() is inaccessible.  I chalked that up to security settings and such, but I discovered workarounds for it by putting the files in different places during my testing.  Now with the testing and the need for this function to work as intended in 3.3 for use in the Interface Builder, it has become very clear to me... many of these locations that dw_file_browse() can return are not accessible through the normal filesystem... even if they are verifiably in the locations being returned. The code that returns the path to these files is rather complex, since the API gives us a URI and then we look at the type of URI and figure out the path based on it... if the URI is even resolvable to a path. 

Over the course of trying to get it to work in Interface Builder I tried many things... but no matter what I did, some of these URIs, when resolved to a path... and then the path verified in the Android Device Explorer... they would not open via the path either by the native APIs nor from Java/Kotlin APIs.  They only are able to be opened via their URI.  I discovered there is a way to open the URI and then return a native file descriptor which can be used for IO.

So I added an API specifically for Android dw_file_open() which calls Java/Kotlin fileOpen() function which can open a URI and return a file descriptor.  I had been using xmlParseFile() to open the XML, which takes a file path... so this would not work, but fortunately there was a xmlReadFd() which takes a file descriptor.  So using this I was able to get Interface Builder to function on Android.  (On other platforms dw_file_open() is just a macro to the system open() function)

The problem with this approach is the path returned by dw_file_browse() on Android would no longer be a path, it is a URI instead.  So any code that manipulates the path would likely fail because the URI format is completely different.  So my current approach is to return both the physical path AND the URI from dw_file_browse() on Android.  It returns two back to back strings with a leading \n (newline) before the second string... the first string is the physical path and the second string is the URI.  This allows the Android dw_file_open() to locate the second string and pass the URI to to the fileOpen() function allowing it to open and get the file descriptor.  This approach allows dw_file_open() calls to function and the main string returned by dw_file_browse() is a physical path that matches the format on all other platforms. 

The drawback to this approach is that the physical paths it returns on Android are mostly useless.  It really requires the URI to do any file access.

So thinking about other approaches, I have come up with a few options.  Adding flags for 3.3 to pass to dw_file_browse() that will change the behavior.

1) Make the default behavior of dw_file_browse() to return a path OR a URI... apps would need to check if it is a URI by something like strstr(path, "://") and if it is a URI use dw_file_open() (or some other name for this function ... maybe dw_uri_open()) which would be able to open the URI on platforms that need to open URIs like Android.  Then add flag to force dw_file_browse() to return a URI or a path, maybe: DW_FILE_URI and DW_FILE_PATH.

2) Make the default behavior of dw_file_browse() return a path, which may not be openable on platforms like Android.  Adding a flag to dw_file_browse() to force it to return URIs like DW_FILE_URI which would require using dw_file_open() or dw_uri_open() to open the result.

3) Make dw_file_browse() always return a path, which may not be openable on platforms like Android. Add a new function dw_uri_browse() which returns URIs on all plafroms and requires dw_uri_open() to open the result.

All options would require code changes to work on Android, some options would require changes on other platforms.

Does anyone have any thoughts on these changes?

[dbsoft]

I've experimentally switched to option 1) to see how things work... trying to see how much stuff breaks, and there were immediately changes required for Interface Builder... the URI is URLencoded with the filename separated by a %3A (encoded : character) so I had to add Android special case handling for that.

Added DW_FILE_MASK which can be bitwise ANDed to get the open flag, on Android.

Also added DW_FILE_PATH which will cause Android to always return a path, if it would otherwise have returned a URI (it is 0 on other platforms since they always return paths already).

DW_DIRECTORY_OPEN also always returns a path on Android.

Edit: Basically I needed to put handling into all my apps for Android URIs, not sure if this is the way to go... if anyone has any input please let me know... you can see the necessary changes in the HandyFTP, Interface Builder and DWTest component of Dynamic Windows itself. Not sure if it is too much Android specific handling... if I should try a different option that appears more cross platform.

[dbsoft]

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.

[dbsoft]

Progress is being made the mobile container changes are almost complete, just some polish left to go...

Here is the DW_CONTAINER_MODE_EXTRA look on iOS:

and Android:

...and here is the DW_CONTAINER_MODE_MULTI look on iOS:

and Android:


Started work on supporting iOS 16 and MacOS 13 Ventura, although I don't have a test platform yet. My 2017 MacBook Air should support Ventura via OpenCore at some point. The M1 MacBook Air I do my ARM builds on is not technically mine and I don't feel comfortable putting a beta OS on it.

So unless someone wants to donate me a newer Intel model that supports Ventura, it might be after Ventura is released that potential issues are addressed.

[dbsoft]

Started work on supporting iOS 16 and MacOS 13 Ventura, although I don't have a test platform yet.  My 2017 MacBook Air should support Ventura via OpenCore at some point.  The M1 MacBook Air I do my ARM builds on is not technically mine and I don't feel comfortable putting a beta OS on it.

Just wanted to post an update. OpenCore did support my MacBook Pro a few days after Ventura's release, so I have been able to test with both Intel and Apple Silicon.  There were no noticeable issues on iOS 16... there were minor issues with the NSTableCellView on Mac. Either they no longer update the frame values and leave them as 0 or they update them at a later point. Thus the calculations I performed on previous versions now produce negative values that do not display properly.  The result was a minor cosmetic problem in Tree and Container controls when both icon and text are present. This has now been fixed.

[PierceNg]

Hello,

I got to know of dwindows from the Free Pascal (FPC) Lazarus forum. Lazarus is an IDE-cum-widget set for FPC that supports multiple platforms, much like dwindows does. Long story short, I'm interested to explore using dwindows with FPC for Android and iOS. (For desktop platforms Lazarus works well enough for me.)

Following your Android instructions in mobile.txt, I've set up a working Android project for dwtest. To use FPC for programming Android with dwindows, I've currently gone off a yak-shaving tangent to build a Gradle plugin to invoke FPC, the idea being to use Gradle (a) to build my Pascal source file as the main program (b) to compile dw.cpp as a shared library that my Pascal program calls. Suggestions on alternative approaches welcome.

My Mac is a 2012 MBP that cannot be upgraded beyond Catalina, so I'm not sure how much I can use dwindows with it. (Lazarus works fine on it.) I'll come to macOS when I get the Android Pascal hello world demo working.

Cheers.

Pierce

[dbsoft]

Following your Android instructions in mobile.txt, I've set up a working Android project for dwtest. To use FPC for programming Android with dwindows, I've currently gone off a yak-shaving tangent to build a Gradle plugin to invoke FPC, the idea being to use Gradle (a) to build my Pascal source file as the main program (b) to compile dw.cpp as a shared library that my Pascal program calls. Suggestions on alternative approaches welcome.

My Mac is a 2012 MBP that cannot be upgraded beyond Catalina, so I'm not sure how much I can use dwindows with it. (Lazarus works fine on it.) I'll come to macOS when I get the Android Pascal hello world demo working.

Sounds like an interesting project and should be doable, although I am not that familiar with Pascal, I haven't used it I was in high school. 

Dynamic Windows for Mac itself I test on various machines from a 2021 MacBook Air Apple Silicon, 2017 MacBook Air Intel, 2013 MacBook Pro, 2008 Mac Pro, 2006 Mac Pro and a 2003 PowerMac G5.

For iOS I have only been testing with Big Sur and later targeting iOS 13. I started transitioning to using ARC... maybe the instructions are out of date... the code was ported from MacOS which supports Mac versions which do not support ARC, so the Mac code uses manual reference counting.

If you are using the version in revision control, perhaps you need to enable ARC, I'll double check and let you know... I am currently working on C++ bindings for Dynamic Windows, hoping to have a new release ready in the next month. If I need to do any fixes or documentation updates I'll get them ready ASAP.

Also it is possible to get your 2012 MBP working with Ventura using OpenCore Legacy Patcher. That is how I am running Ventura on my 2013 MBP.

https://dortania.github.io/OpenCore-Lega...ent-status

[PierceNg]

Sounds like an interesting project and should be doable, although I am not that familiar with Pascal, I haven't used it I was in high school. 

Dynamic Windows for Mac itself I test on various machines from a 2021 MacBook Air Apple Silicon, 2017 MacBook Air Intel, 2013 MacBook Pro, 2008 Mac Pro, 2006 Mac Pro and a 2003 PowerMac G5.

For iOS I have only been testing with Big Sur and later targeting iOS 13. I started transitioning to using ARC... maybe the instructions are out of date... the code was ported from MacOS which supports Mac versions which do not support ARC, so the Mac code uses manual reference counting.

If you are using the version in revision control, perhaps you need to enable ARC, I'll double check and let you know... I am currently working on C++ bindings for Dynamic Windows, hoping to have a new release ready in the next month. If I need to do any fixes or documentation updates I'll get them ready ASAP.

Also it is possible to get your 2012 MBP working with Ventura using OpenCore Legacy Patcher.  That is how I am running Ventura on my 2013 MBP.

https://dortania.github.io/OpenCore-Lega...ent-status

I've now built the littlest demo for Android using dw_messagebox. Still mucking around with CMake to get it to invoke the Pascal compiler instead of compiling my Pascal artefacts 'out of band'. The demo runs on emulator and my midrange phone.

For iOS, I got dw.m to compile by changing the two spots using weak references to using strong references. That allowed dwtest.c and dw.m to build together enough that I could run the demo on the iPhone simulator. The dwtree part crashed though, probably due to my changes. Now working on getting Pascal compilers for the iOS targets to build.

Thanks for the pointer to the legacy patcher! Hopefully it'll give my old MBP new legs.