On the Mac x64 ARM build the toolbar at the top of the window is justified to the right and combined with the Window title.
Is there any way to move it to the left?
On full screen the buttons are hard to notice and so far from the areas where the user is interacting with the form.
This is how apps that say they’re compatible with Big Sur operate. “You’re gonna love it”.
However there are options.
This article is part of the series I’ve written on making your Xojo application Big Sur style.
2 Likes
Thanks Sam, I’m glad someone else recognises there is problem here. I’ll take a look at the option.
1 Like
Or use MBS:
'show normal toolbar on arm
dim theNSWindow as NSWindowMBS = self.NSWindowMBS
#Pragma BreakOnExceptions False
try
theNSWindow.toolbarStyle = NSWindowMBS.NSWindowToolbarStyleExpanded
catch err as NSExceptionMBS
'ignore
end try
2 Likes
I do not see a problem. It’s just some changes in macOS 11 and it was discussed here months a ago. Declares can be found here or use Sams Appkit.
That said, Xojo should handle this by default.
There’s not a problem, it’s the new design language for the new MacOS. It’s supposed to look like that.
Whether you like it or not is of course a different matter but it’s not a bug or problem.
1 Like
If a lot of users are emailing for support then it is a problem. There was 8 toolbar buttons visible before, now there is only 5.
Users are confused. They don’t know you need to click the end to see the rest.
Combining the title bar with the toolbar only gives half the space. Previously the database title fitted nicely along the top now it takes priority over the toolbar, reducing the amount of buttons to fit in the text.
4 Likes
Combining the title bar with the toolbar looks really weird and it is really impractical. If you don’t like Big Sur’s new window title style and want to revert to how it looked in Catalina, type in Terminal:
defaults write -g NSWindowSupportsAutomaticInlineTitle -bool false
Then force Finder to quit or log out.
Find an application that runs in BS and also have a toolbar, then explain your users this is a BS thing: have a look at application XYZ (of course, an Apple application is better).
This will not avoid mails from users, but they will understand that is a new stuff, stuff from 2020/2021.
Of course, and as already said, this have nothing to do with I love or I dislike that new UI.
Is someone telling "This is progress on the move!“ ?
It sounds you did not do your job and adapt your software to the latest macOS version.
1 Like
Yes, you’re right but adaption means removing something so many people are familiar with.
All the functionality is there but you need to click on the end of the toolbar to see the hidden buttons now. And of course it isn’t really a toolbar anymore because it doesn’t have all the buttons visible so that sort of defeats the purpose of what a toolbar is for - having access to regular functions at a click of a button.
So I need to remove some buttons from the ARM64 version of my program and add to the help file that some of the controls you are familiar with for 10 years and now only available in the program menu.
I swear the next request for help will be “Where is this menu?”
But hang on, the program is available on other systems and all the buttons appear there. Should I remove the buttons from the Windows, Linux and Mac x64 versions. What about the users that have multiple systems and swap between them to access their cloud data. Different interface for different systems? Is that what Xojo is about?
I’ve already go tons of code to make Linux behave and look like the others, now ARM64 as well?
Maybe this can help to display old window toolbars in your application:
https://ohanaware.com/blog/202049/Preparing-your-Xojo-made-Mac-App-for-macOS-Big-Sur-Part-5.html
The problem is the execution of a processor and UI/UX transition at the same time. Not allowing enough time for them to be separated.
There is no way (that I have confirmed) to get ARM compatibility without telling the macOS that this app is compatible with Big Sur. When you do that Apple automatically makes the toolbar conform to the “shiny” Unified style.
The Intel builds are NOT marked as compatible with BS, hence why they continue to get the traditional style toolbars.
The OP’s costs of this “two for the price one migration”, is the Arm version working inconsistently with the Intel version, Windows and Linux, which is frustrating OP’s customers.
Thankfully in this case, there are solutions available, and various members who’re willing to help.
Not in this case. Simply apply the code to make the Arm BS version toolbar revert back to the more traditional style.
Then when you are ready, you can work on a toolbar redesign and enable the compatibility flag on your Intel build so you get consistent toolbars (on the Mac at least).
You already done that: API 1 → API 2.
Adaptation: isn’t what humans do the best ?
(Erg… some humans, not all 
)
1 Like
This isn’t a Xojo thing, it’s Apple that have changed the operating system. Nothing to do with Xojo.
If it didn’t do this then people would be complaining that Xojo is non-native.
Xojo’s “Raison d’être” is Xplatform… so IMO they should provide a simple supported way to to be able to use the old, more X-platform friendly style, at least as long the as OS has a mechanism to optionally support it, and we should be able to chose which style to use.
While I agree native controls/UI should be available and used most of the time, in general to be able to be an efficient RAD for X-Platform work IMO, there needs to be some easy support included for some things that are not the default behaviors and/or have non-some non native UI OPTIONS that still look reasonably at home on the OS, to make X-Platform easier to deal with…
It seems to me Windows and Mac OS UI’s are diverging more than they have in the past, which IMO makes that important in the long run for a product like Xojo.
But I know I speak from the perspective of someone who creates X-Platform (Mac/Win) apps for use at work, not for sale…
While I want apps to look and feel appropriate to the OS they are running on, in that situation every last detail does not need to follow all the latest UI trends of the OS for every app…
Usability/productivity, both for the end users and the “citizen developer”, are king in that situation.
I understand that for those selling apps to consumers, or that don’t need to be X-platform, the priorities may be different, and absolute fidelity to the current defaults can be important… But I suspect Xojo is used more for in-house apps than those sold, so I don’t think that is enough.
-Karen
If you’re making an app whether sold or in house for a platform then going against that platforms design rules is a bad idea.
Even if you did what you’re suggesting the Xojo app would look different to every other app they open on that machine.
It would confuse the users as being the odd one out on their machine that looks different to all their other apps.
People will compare it to other apps on the same machine much more than the same app on a totally different platform.
What next? Swapping the close and minimise buttons to the other side on a MacOS so that it looks like Windows too?
1 Like
I am not talking about wholesale differences! I thought my post made that clear I was talking about relatively minor things… I don’t think having unified toolbar vs having a platform appropriate separate tool bar would confuse anybody, and certainly not the technical/scientific users of my apps!
Have you written many apps that were only for internal use in a department at a company?
In my situation sometimes a person will use the same app on both a Mac and a PC (PC in the lab, Mac at their desk)
You do realize that your response is way over the top as I did not imply any such thing… You taking things to an unjustified extreme… and I did say I cared that things look at home teh platform they run on.
I do deal with basic basic platform differences in my apps … For example I use a container control to swap Save and Cancel buttons by platform…
But some OS UI changes actually decrease usability/discovery etc for end users… and time is money.
-Karen
We are addressing this in the next cycle.
1 Like