RTL layouts are mirrored layouts. There are “issues” to make it work correctly.
I’m currently working on that for iOS projects.
It works quite well, auto-layout is completely handled by the system on its own.
But it requires adding all controls by code and handling events in code too. Not a RAD system.
2 Likes
That’s a reasonable start but doesn’t cover UI such as RadioButtons. They should be presented in the opposite order for RTL languages. So this example:
Should become:
Xojo’s RadioButtonGroup doesn’t currently support this.
https://tracker.xojo.com/xojoinc/xojo/-/issues/72616
DesktopSearchField also doesn’t work correctly:
https://tracker.xojo.com/xojoinc/xojo/-/issues/72816
Windows don’t open on the right hand side of the display as they should:
https://tracker.xojo.com/xojoinc/xojo/-/issues/72877
Multi column list boxes should reverse their order also (and don’t),
https://tracker.xojo.com/xojoinc/xojo/-/issues/72119
https://tracker.xojo.com/xojoinc/xojo/-/issues/42225
The Xojo of my dreams has a UI designer that let’s you design UI’s separately, you may design a generic one, clone it to a platform specific one or start one from scratch for that platform, and will design for that platform using native controls with their idiosyncrasies (usual sizes, shapes, colors, etc) and also could clone again and be able to redesign RTL options for those platforms (basically same controls you wrote for LTR in different dispositions with the RTL property on and maybe overriding some common code)
The logic for all is in a shared logic system.
So, the Mac one will always look native, the Windows one too, as the Linux one. Some screen can have additional controls for such platform, or less controls, whatever you want. The Hebrew and Arabic locales will use the RTL options (if present) automagically.
The compiler will discard UI’s not used by the target platform, but will keep both RTL and LTR UIs per platform, chosen at load time, depending on the locale language.
The current issue, same platform, different version (before Tahoe vs Tahoe+) could be addressed too as LTR and RTL, also present and chosen at load time.
You must introduce an “UI pendency” that must be satisfied or discarded on each UI variant of a base model for every new multi-platform change you introduce, or the final build won’t complete due to missing features.
This is kind of a Xojo2, because it demands deep changes on how the current one works.
OMG I hate that idea. So I upgrade Xojo to the version that supports Tahoe and suddenly I can’t compile my app until I go in and re-jigger my layout for the new OS? Yuck. What happens to an app that’s already out in the wild? Does it also start showing a message that says “sorry, the developer hasn’t updated this app or his development tool for the Tahoe layout system so you can’t use it any more until they do”? No thank you. I’ll screw with auto layout over that any day.
2 Likes
You are completely wrong.
The control is at your hands. But how you avoid the “Oh, I forgot this” is using some annotation needing checks on each design. Like a new check box you introduced, but one of those “views” still don’t have it…
Nope. Let’s suppose such Xojo2 existed, and you wrote a mac UI before Tahoe, it will work, the layout will have issues as Thom pointed out, but then you design a new UI for Tahoe+, and now Tahoe also will look and feel Tahoe with proper design, places, sizes, glass, effects, etc. Not just a distorted screen that works.
At this point you are hallucinating as an AI. 
sorry.
@Greg_O : what does your constraint kit example do? I ran the example and changed the window size. Then I took the code in Container1 → Opening out and the window behaves the same way as before.
For me as absolute auto layout newbie the documentation doesn’t tell me anything what the code does:
This is an autolayout library for use with Xojo iOS and Xojo macOS Desktop projects. It gives access to Apple's newer Anchor system as well as Animation and about 40 helper methods to make dealing with constraints a little easier.
I have a vague idea what auto layout is. But I have no clue about anchor systems. A quick goggle gives me some information I do not understand.
The usage section is also rather thin. When should I use your code? What does it help with? Some screenshots would be great. Even better would be a window with the auto thingy and then a window without the auto thingy.
And the method section of the docs is even worse:
Creates a new constraint equal to the current layout dimension and another, using a multiplier and an offset.
This just makes me scratch my head.
I have no clue how to use the code.
This one here is good starter for understanding basics of Autolayout
1 Like
Yeah - this has been itching at my brain for a while but your post finally made it come into focus.
In desktop publishing, for decades, we’ve had this idea of “master pages”. These are template pages that contain page elements with positioning, styling, sometimes content, and user-defined relationships that describe how the page elements interact (for example, text might start in one box, fill it up, and then continue into another box).
Master pages can have inheritable relationships -they can be based on other master pages. Subclassed master pages start with all the page elements of the original but they can be repositioned, deleted or added to, etc. without losing the original styling and inter-element relationships.
This is a close analogue to what you are describing. You have a master window layout that stores all the code and the original positions of the controls. Then, you can flip over to the Mac-specific layout for the window and tweak the positions (or rearrange to a greater extent of needed) to better match that platform’s layout expectations; same for Linux etc. The IDE stores a set of layout dimensions for each targeted platform and uses them as appropriate during compilation.
Perhaps you could even have a more general rules-based system where a window layout is used if certain criteria are met; a right-to-left system language, for example, could trigger a swap to a different Container layout that has those buttons and fields reversed as in your example. Detecting that the user has a smaller display could trigger a layout that is redesigned to be more compact.
A great example of this platform-specific layout is the standard yes-no-cancel dialogs in recent operating systems. For a long time, they were all horizonal and close enough in design that you could get away with one design, but a few years ago Apple had the terrible idea of making those dialogs vertically oriented, with the three buttons stacked like pancakes. This proposed layout system would let you cleanly create a multi-platform dialog that looks native on each system while using a single codebase to manage it.
The key advantage to this system is that no code would need to change. The window swapping would occur as the window is being created and before any of the control Open events are triggered. As long as your code doesn’t have any dependencies on the exact positions and sizes of the controls, it would be seamless.
In our case we need more freedom than Master Pages, but the analogy for understanding the concept fits. 
I’m going to suggest that you go watch my webinar from last year first before I go into any particulars. It gives an overview of what auto layout is and why it’s important. There’s also a section about Anchors in there.
I just realized that Greg’s Constraint kit has stack views for iOS.
Maybe it could be adapted for macOS.
Anyway, I will stop working on my implementation of stackview and use Greg’s for my iOS apps.
1 Like