Can Xojo please put attention on improving Mac applications built with Xojo

[Jonathan_Ashwell]

I have. But again, that’s not what this thread is about (please scroll up to the original post by Sam Rowlands). I’ll bow out now, I think the point has been made, even if not everyone wants to hear it.

[Tim_Parnell]

@Martin_T

For my taste using declares isn’t a workaround. It a tool developers can use to extends functionality. You just need to learn how to use them.

Check whose thread you’re derailing please.

[Martin_T]

@Tim_Parnell

Check whose thread you’re derailing please.

Tim, I wasn’t derailing the issue, merely pointing out what I’m sure was an unintentional spread of misinformation about Xojo’s feature set.

[Tim_Parnell]

@Martin_T

Tim, I wasn’t derailing the issue, merely pointing out what I’m sure was an unintentional spread of misinformation about Xojo’s feature set.

No, you absolutely weren’t. Thom and Greg did. You were putting the onus for building features Sam, the original author of this thread, master of macOS declares, who has spoon fed you more than one solution in your time, has asked be built into the framework:

@Martin_T

Well you can do a lot of those things using Xojo Declares on macOS.

@Martin_T

For my taste using declares isn’t a workaround. It a tool developers can use to extends functionality. You just need to learn how to use them.

The point of this thread is that we shouldn’t need so many declares and workarounds. Xojo has areas that it needs to improve. Some things are on the roadmap, but it is unwise to make plans for anything unreleased.

Let people discuss the shortcomings of Xojo without derailing the thread. It makes those of us who are dissatisfied feel like we aren’t being listened to.

[KarenA]

@Martin_T

For my taste using declares isn’t a workaround. It a tool developers can use to extends functionality. You just need to learn how to use them.

Declares are not exactly X-Platform RAD or “Citizen Developer” friendly.

-Karen

[Emile_Schwarz]

@TimStreater

This site talks about ‘products’ on the Welcome page

No. His bisiness (as far as I understand it) is to enhance the user interface of your application.

Now it is clearer.

[Arnaud_N]

@Greg_O

I made a sign for my office door that says “Change Glasses!” Now you’d think that would be enough, and it does work for a few days, but usually within a week I stop seeing the sign.

I like your example. But I’d be tempted to think that for these few days, you slowly take the habit to change your glasses automatically when leaving your room and, one week later, if you happen to forget to change them, you’ll start the habit of thinking “There’s something I haven’t done right now… Ah yes, that’s changing my glasses”. And weeks later, you won’t even be able to forget.

It’s the same thing as if you said “Oops, I forgot to launch Xojo to make my apps today”. That would have been valid when you started using the product, but now it’s an habit.

[Greg_O]

@Arnaud_N

I like your example. But I’d be tempted to think that for these few days, you slowly take the habit to change your glasses automatically when leaving your room and, one week later, if you happen to forget to change them, you’ll start the habit of thinking “There’s something I haven’t done right now… Ah yes, that’s changing my glasses”. And weeks later, you won’t even be able to forget.

Man I wish that were true. I usually notice when I get to the bottom of the stairs and can’t see through to the back of the house as my computer glasses are set to focus at arm’s length.

[Paul_Rodman]

@Greg_O

Man I wish that were true. I usually notice when I get to the bottom of the stairs and can’t see through to the back of the house as my computer glasses are set to focus at arm’s length.

Hang a piece of string and a hook in your office doorway, and swap out your glasses each time you bump into the other pair hanging in your way…

[Rick_Plummer]

@Sam_Rowlands

Mac Console applications should include a Info.plist within the Mach-O binary at build time, it’s not impossible to add it later, but this is a tremendous amount of work. I’ve made slow progress over the years.

I strongly second this. I have resorted to a complex workaround for my console apps, for years. IMO,this should NOT be that difficult.

[Sebastien_REMY]

@Michel_Bujardet

Sure, XCode is native throughout, but Swift is much less stable than Xojo. Not easy to maintain.

And learning curve is an infinity loop with Objective-C, Swift, SwiftUI, AppKit, CoreData and now SwiftData.

[Emile_Schwarz]

Last additions from the Roadmap:

022r4	ARM64 for Linux	The ability to build ARM64 apps for Linux.
2022r2	ARM64 for Windows	The ability to build ARM64 apps for Windows.

…and Linux’ Xojo IDE cannot be run in ARM computers… only build applications…

[Greg_O]

I don’t know why you find that funny. The same was true for ARM32 (raspberry pi). There are parts of the IDE that are not written in Xojo which also have to be converted… internal plugins and the compiler to be exact, without which the IDE is useless on those platforms. So yeah, the IDE can build for those platforms first because it helps gauge how many people actually want an IDE running on that platform so they can figure out whether it’s worth putting in the effort and then having to maintain it.

[Emile_Schwarz]

@Greg_O

I don’t know why you find that funny.

You are correct, its not funny.