Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Changes for upcoming version
After some contemplation on where things are and where they are going...

Two changes coming to the Interface Builder design... one to the distribution and one to the user interface.

1) Single Window User Interface 

With the upcoming addition of tree control support for iOS and Android in 3.3 it should be possible to release the Interface Builder for iOS and Android. 

However the mobile interface paradigm is very different from the desktop and requires some changes.  I plan on making it into a single window with a splitbar separating the user interface tree and the properties explorer.

This will also solve a problem that has developed on Linux.  With the introduction of Wayland into general use (a mistake I feel) we can no longer count on the fact that we can place windows on the screen where we want since using Wayland with GTK3 and GTK4 windows will just appear wherever the window manager feels like putting them. The single window design will alleviate this problem as well. 

I personally preferred the floating properties inspector on desktop platforms at least, but this change will be better overall, allowing easier mobile usage and preventing annoyances on Linux (and any other platforms that choose to pick Wayland over the superior but only slightly maintained X11).

2) Multi architecture distribution archives on Windows and MacOS (maybe others)

As someone made me very aware of, that developers who use the interface builder might not care about building their own packages from source.  The installers should contain the header and libraries from any possibly supported architectures.

Minimally on Windows, the next version's installers will have x86-32 and x86-64 support and possibly ARM support (although currently I don't have any Windows ARM systems).

On MacOS the classic builds will include PowerPC and Intel libraries for both 32 and 64 bits. The modern builds will have Intel and ARM 64bit libraries.

OS/2 only supports Intel 32bit so this requires no changes.

Unix typically relies on the distribution to do the packaging or build from source, however I will look into options for this as well.

I don't think these changes will be of any concern to users, but if you are worried about anything please let me know!
I have made the preliminary changes for both of these... Windows now builds libraries into separate platform specific folders, and the installer packages up both x86 and x64 DLL and import libraries when found.

I have also added a single window mode for Dynamic Windows Interface Builder, which currently gets enabled by default.  On Windows, OS/2 and MacOS for now it keeps the multi-window mode, this may change in the future.

With the new tree widgets for iOS and Android Interface Builder should become usable on both these platforms after I work out the bugs. I have successfully built the Interface Builder for iOS... however on Android there is no libxml2 included in the NDK it appears.

I found the following:

However it hasn't been obvious how I should include this in my Dynamic Windows Android projects.

So slow progress, but it is definitely being made!

Edit: Managed to get libxml2 compiled for Android and the basics now work on Android as well as iOS!

Screenshots coming soon once I fix a few glitches.
Edit: Third iOS screenshot... fixed issues with properties inspector and the titlebar!

[Image: Screen_Shot_2022-07-19_at_10.54.00_AM.png]

...and the second screenshot on Android... fixed a number of display and layout issues!

[Image: Screenshot_20220719_110412.png]

For more information on the Android tribulations see my post in the Dynamic Windows forum:
With the exception of some minor visual issues, a few on iOS and quite a few on Android things seem to be starting to stabilize. Once I fix these visual problems, thing will be in extremely good shape on iOS. Android however, I am noticing a bit of an issue that might be harder to address. Performance.

Interface Builder is an extreme test of the Dynamic Windows API. Recreating interface elements on the fly. Destroying parts of the interface and recreating them. I have two tablets, of similar age, (2018 iPad and 2019 Fire HD) but comparative performance, the Android tablet recreating the interface is very slow. Like when I touch an interface node in the tree, I watch the properties inspector recreate the interface line by line. Whereas on the iPad it is essentially instantaneous like on the desktop platforms.

Both platforms have the user code running in one thread and the UI thread running separately, with a need for the user thread to call into the UI thread to make changes to the user interface, however on Android it isn't just calling into a different thread, it also calls into a totally different language. The UI code is in Kotlin/Java and has to cross over a JNI which the documentation warns is expensive to do. However keeping with the Dynamic Windows design goal of writing DW code once and running it on all supported platforms, I don't really see another way than JNI.

Once I work out these visual problems I think I will need to spend some time to figure out how to speed up these code transitions, I am not sure the performance is acceptable currently, at least on my current testing hardware.

Update: I've been looking at the code in a bit more depth, and I think I see what may be a contributing factor to the slowness. dw_window_get_data() calls.... Interface Builder makes tons of calls to this, and they all result in a JNI call to look up the data. If dw_window_s/get_data() could be redesigned so they don't require JNI calls the performance could be drastically improved. It is a simple data lookup which doesn't need to be run in a UI context or even in Kotlin/Java... that is just how I originally designed it.

Update 2: That did not seem to fix the performance issues, so will need more research... I updated the plan for the new version in the Dynamic Windows sub-forum:

Forum Jump:

Users browsing this thread: 1 Guest(s)