Is the new framework abandonware?

I ask this not to be inflammatory but out of disappointment. Is anyone else concerned about the pace of development of the new framework? It’s been out 3 years (maybe longer?) but it’s nowhere near feature complete with the old framework.

Personally I really like the new framework but I dislike mixing and matching. I especially loathe the fact that the Shell and Regex classes have not been updated.

Is anyone else wondering if we’ll see new framework classes for desktop at XDC?

Please delete this thread. Please.

File a feedback, or as many as you think are needed. That may yield better results.

Self-Censorship is the worst kind of censorship …

I do not see any reason to delete or lock this thread. The original poster is civil and share his frustration with us. Honestly, he has a very good point. The new framework mess, is one of the reason we let our license expires early April.

A feedback case is a better place but what do you do if feedback is also not working? That is our case. We never could use feedback because it didn’t work.

We have sent an email to Xojo inc explaning our reasons and the conditions which has to be met to renew our license. That is our (African) way of doing things.

Unless you have to develop in Xojo iOS, which is entirely new framework, or need a feature no found in classic, such as Xojo.Net.HTTPSocket which supports HTTP 1.1 that classic does not, stick to classic.

Until the new framework becomes able to correctly support Desktop, let alone with a decent specialfolder.Desktop, don’t waste time with it. Clean and simple.

[quote=381617:@Garry Pettet]I ask this not to be inflammatory but out of disappointment. Is anyone else concerned about the pace of development of the new framework? It’s been out 3 years (maybe longer?) but it’s nowhere near feature complete with the old framework.

Personally I really like the new framework but I dislike mixing and matching. I especially loathe the fact that the Shell and Regex classes have not been updated.

Is anyone else wondering if we’ll see new framework classes for desktop at XDC?[/quote]
You may have missed it, but there was an extensive discussion at the end of 2017 around this topic and I’m fairly sure that Xojo Inc heard us all in no uncertain terms. Just to fill you in, it also led to a little agro and I guess this is why Kem wants the thread deleted so it doesn’t happen again. Nothing you said above wasn’t said a few months ago, so I think we are all on the same page and we can only wait now to see if they deliver.

@Gavin Smith: Thanks. I think I must have missed that thread but have searched and (for other’s reference) have found it here. I won’t seek to re-open that thread so apologies.

The thread had hundreds of replies and was deleted.

I’m fine with Classic, and very glad it’s been left alone and still works.

The only one that is basically essential is Xojo.Net.HTTPSocket because old socket does not support SNI or HTTP 1.1. Downside to the new one is you need to learn Xojo.Core.MemoryBlock and Xojo.Core.TextEncoding to use it. It is nowhere near as easy to consume as the old one. I understand the benefit of being able to specify encodings but it should be optional. Almost every other language makes generic HTTP requests significantly easier to use.

I’m using the Xojo framework where possible to both future proof my code and keep as much of it xplat as possible. I’m assuming that the new Android target will only be Xojo framework, so why limit myself?

Xojo if you are watching it would be nice to have the compatibility settings available prior to delivering the new Android target.

[quote=381800:@Julia Truchsess]very glad it’s been left alone[/quote]I too am glad Xojo are following the Microsoft way rather than deprecating the classic framework.

I’ve been trying to stay quiet on this thread because I’ve already made my thoughts pretty well known. No need to beat a dead horse. However, I’ve got something new (to me) to share.

Xojo has done literally the worst thing they could done with the new framework: nothing. Even if they told us it was a failed experiment, that would be a plus because that tells us to stop trying. They give us a barely functional framework that’s missing threads, sockets, regex, and countless others, and simply stop developing it. Anything would be better than this.

For a new user, the two frameworks make for a confusing mess. It’s a terrible time to get into Xojo development. And I really take no pleasure in saying that. You can’t say new users can avoid the new framework, because if you want to do anything with HTTP, you pretty much have to use the new framework.

Love it or hate it, the new framework NEEDS progress.

I think we’ll know more at XDC in a couple of weeks. No need to start a panic just yet.

The biggest issue is cross platform. Xojo touts cross platform, but de facto, Xojo has now three dialects, requiring more or less intense refactoring, when it would have been so simple to keep the same methods and property where applicable.

Let us say someone starts a project on Desktop, and wants to move it to Web : dang, the language is not quite the same, there are a flurry of differences, for instance Window.Control() and WebPage.ControlAtIndex(). Why ? Especially since ControlCount is identical. Then our user wants to go iOS. Meet our glorious new framework which is now even more alien.

I may be stupid, but what made all the interest of the RealBasic language was its coherence. Then warts got grafted on that. I can understand the need to support asynchronous processes, and can even see where the Text type can be better. But WHY, WHY systematically use yet another dialect ? Why a full range of new property names in iOS graphics ? Was it that difficult to use the good old property and method names ?

The result of all that fragmentation is that now, more than ever, the claim of multiplaform has never been more bogus.

You can blame that one on me. I tend to prefer more descriptive names as a means of future proofing. WebView has ControlWithName and ControlWithID, both take a string, so multiple signatures of Control would not work. So if those two were going to be “WithX” variants, shouldn’t we be consistent and use ControlAtIndex? ControlCount is just ControlCount because… well what else would it be?

That was the train of thought. The next step was to deprecate Window.Control in favor of similar names.

Thank you for explaining the thinking. Unfortunately, Xojo iOS went even more systematically the same way. As if the team or the person who did iOS did not want to keep any Desktop property or method. Gone is existing code.

The new framework is inspired heavily by Cocoa/AppKit.

There is a reason why we don‘t program in Cocoa.

Xojo is removing that reason bit by bit …

I understand why. Yet, it seems Xojo lacks the rigor that would command coherence between platforms. Especially for a brand that pretends to do cross platform.

I was naive enough to think Xojo would understand the need to abstract the underlying system in favor of a more coherent language with desktop. Unfortunately, that is not at all the case.

I bet you Android will have yet other incoherent idiosyncrasies.