New Xojo controls

see swift playground app (mac or ipad) and date planner example.

ok, but i not have NSScrollViewMBS

I don’t use Swift or XCode. You have to actually explain what you mean.

2 Likes

interesting concept…

https://developer.apple.com/documentation/swiftui/picking-container-views-for-your-content

1 Like

See also:

those are containers that align and arrange controls automatically. They can even be nested and automatically adjust your layout to any screen size or aspect ratio. (not resizing controls, just rearranging them) even using scrolling with the scrollview if they dont fit in the available area.

And they have existed for decades in other GUI tools and frameworks, like gtk that xojo already uses on linux:

I think that xojo still does not update to 4.0 but you can see some examples: Gtk – 4.0: Widget Gallery. In gtk are called Boxes.

2 Likes

in java, it is called hbox and vbox

1 Like

and because most data on screen comes on demand from database
it would be great if we get events by a central method (alternative) without using add remove handler. creating/removing ui objects is still unround in xojo.
it should be easy as .AddObject(obj) .RemoveObject(obj, recursive true/false)
also for container controls and without offer older api beside which is confuse.
generally if “add” (+) is used there must be the opposing “sub” (-) method (interface!)

1 Like

Like this?

That’s the example “ListboxTV with ContainerControl Cells” from the MBS plugin.

I started using Xojo at 2022R2 so the DesktopControls are all I know. I have no issue with them. What does worry me is that eventually there will be an API3, the benefits of which will be unclear to me, but which will require some kind of joyless slog to convert to nevertheless, lest any bugs I run into tend to get blamed on legacy classes / controls / APIs.

In other environments TBH I have been accustomed to there being a conversion tool in these situations that’s powerful enough to at least get you into the ballpark where you just have a bit of fine tuning to perform. Or a shim like the Microsoft.VisualBasic namespace that eases the biggest mismatches between VB6 and VB.NET In fairness though, MSFT tooling for converting from, say, ASP.NET MVC 5 to ASP.NET Core are not very good, so even they are getting cavalier about breaking changes with no good safety net. That particular change almost feels like namespaces were renamed just to break things.

I understand that making abstractions that never leak is basically impossible and that keeping up with industry fashions is another input to all this thrashing. Still, I hope they have learned something from the API1 => API2 debacle, or even understand that it’s a debacle.

1 Like

There is always going to be change, unless everyone stops upgrading their operating systems. As the OS API changes, so too does the XOJO API’s need to be updated around them.

It is frankly unclear whether “OS API changes” have necessitated some of Xojo’s recent moves.

2 Likes

There is change for “changes” sake and there are actual improvements.

QuickTime → AVFoundation was a hard “change”, I hated the first few days. Until I appreciated how much more of an improvement it is. AVFoundation is far more flexible and performant, which resulted in my application not only processing video faster, but I had far more control, which lead me to implement new features that I hadn’t previously thought of.

API 1.0 → API 2.0… I have asked Xojo many times for the advantages of this transition as I have been unable to find anything tangible or beneficial.

As someone who reads the API changes to see how Apple’s “changes” affects my apps, I do not see any correlation either.

I do not believe that you need to worry about this, however we did believe that after the first API 2.0 debacle, the second, they wouldn’t proceed with DesktopControls, but they did. This has made some long time developers feel that Xojo doesn’t respect them and that might turn out to be worse than the actual changes.

4 Likes

Except that these changes were not to accommodate OS changes and even if that was the impetus, those changes can be abstracted away with adapter patterns. The Xojo API can change how it communicates with the OS without changing how it communicates with Xojo apps. Those things can vary independently in nearly all cases.

API2 reminds me in a general way of the changes in the Python language from v2 to v3. That, too, was controversial and painful for users, but the people in charge of that language made IMO a better argument for why the pain of those changes was necessary, and made a meaningful commitment to maintain v2 alongside v3 for a really long time, on the order of a decade IIRC, in explicit recognition that converting the massive base of existing apps and libraries was very nontrivial. And by “maintain v2” I mean really maintain, not just “if you run into a problem we’ll look into it”.

Of course it’s all water over the dam now and like I say, selfishly I just don’t want to be having this conversation about API3 or some other significant change someday. To that end it would be reassuring to see things like a system of LTS releases with clear commitments on how long Long Term Support lasts; more transparency in and commitment to keeping up with bug reports. Things like that would be not only reassuring but also a selling point both to new and renewal license purchasers.

3 Likes

I wouldn’t worry about a wholesale change like the one they just went through happening again any time soon. The API 1 names were created in the early 2000’s and the chances of it happening again before another 20 years passes is probably slim to none.

2 Likes

You wrote you comes to Xojo with 2022R2.

Then you talk about a debacle transition from API to API2.

You were not included in this debacle at all, sincce you learned ti use API2.

Why I can talk about API → API2 debacle ?
Change appears all the change. What makes these changes different from this ongoing movement ?

Ongoing changes are done slowly, some features here and there.

Massive changes are like using a brand new software. And so you loose 20 years of investment without asking anything. That hurts. Ask people here who provide support (third party) for Xojo… / Magazine that have years of now useless legacy…

And they have the experience of the Xojo.Xxxx framework.

At last, the question was: must I learn to use another new developer environment or API2 ?

And they finally provided (apparently) an API2 converter (I do not saw it nor searched for it).

What will do the future to us ? Who knows ? One thing is sure, it will be surprises after surprises. Look at the Car (bus, planes, etc.) industry future: electricity everywhere.

Look at the computer industry past… Where is Think C (for example) ? APW ? Borland ?

That capability was present when API2 was released. It’s in your IDE. I didn’t use it when I converted, however. I just went step-by-step and developed a couple of strategies for doing so. Now I have no API1 or Xojo.Xxxx stuff in my app and don’t miss any of it at all.

1 Like

Conversion from API1 → API2 controls / windows etc has been available from the time API2 controls were released.

You can convert an entire project using the menu Project > Convert Project to API 2.

You can right click on a Window and choose Convert to DekstopWindow.

If you convert the entire project it will search through and change Var/Dim statements for Window etc and convert them to DesktopWindow, which may not be what you want in all cases. Especially true if you are using a library like macOSLib.

I found it better to convert each window and then deal with thing that didn’t compile due to changes in control types.

I do not judge API2 to be a debacle. That is the stated judgment of others, which I was merely remarking upon. I have no reason to disbelieve them when they say it caused a lot of expense that wasn’t commensurate with the advantages – in fact some seem to see no advantage at all. I don’t have a personal handle on that as I didn’t go through it. I just credit what you and others say about it.

You are correct that our industry is one of the faster changing ones. Different parts of the industry vary in how they manage change. Sadly a lot of us developers have a tendency to chase The New Thing for its own sake, which actually encourages vendors to give us that change. I’ve mentioned before here I believe that MSFT went through several different RPC APIs, each one supposed to be the definitive end-all and be-all, each one abandoned (although to LTS at least). Beyond a certain point people need to make up their minds and put more thought and deliberate pacing into new innovations. This can be done without retarding the overall velocity of progress; it just means better-planned and tooled transitions that users who are content with the original API can insulate themselves from within reason if it meets their business needs.

1 Like

I wouldn’t say nothing. The two are not really that compatible. Old controls in a new window/container won’t aren’t included when iterating the controls list. Same with new controls on an old window. Showing a window with a parent requires matching types. In my opinion, the transition is kind of all or nothing. Once you start making changes to one item, you’ll find other things that need to be converted, to stay compatible, and then it becomes a rabbit hole.

I think I should start getting my controls updated.