Who is Xojo's Mac person?

I would like to have a discussion with a Xojo engineer over certain aspects of Xojo’s Mac built applications, which I’m not sure that are correct. Ideally that person should be open to discussion on these matters.


Let‘s hope they are smart and don‘t suffer from the “not invented here” syndrome …

1 Like

This is obviously not the correct way of attempting to reach Xojo’s Mac engineering staff, @Dana_Brown or @Alyssa_Foley, please could you point me in the correct direction.

I have tried using Feedback, but that also failed to reach someone there who was willing to discuss such matters.

Sending you a pm

1 Like

So I’m assuming this is about one or both of your cases that I closed last night.

As I recall (since I don’t have the case numbers in front of me) they were

  1. Don’t include the Resources directory for macOS console builds.

As I stated in the case, you don’t get a Resources folder if you don’t need it.

So what do you propose we do with the things that need to go there? Like images, localizations or user files that they want in the Resources directory?

  1. Allow you to turn off the drag and drop mode badge.

Again, I addressed this on the case. We have a plan for dealing with this.

It will require overhauling how drag and drop work though because the underlying system is asynchronous. If you were to look at how this was done on Web 1.0, we imagine it will be like that. In that scenario, drag sources and destinations get to indicate a data type and one or more of the three possible modes: Copy, Move or Link. The possible drags are just the intersection of the source and destination parameters.

I was only notified about one of the cases.

The response I received suggests (at least in the first case) that Xojo doesn’t/didn’t understand the issue, and by closing the case with “Will Not Implement”, they’re shutting down and preventing any further discussion over the matter.

It is incredibly frustrating; given the amount of time that Xojo’s customers invest in researching problems, discussing with other Xojo developers and finally in trying to summarize the matter in a way that hopefully Xojo would understand, or at least begin a discussion.

In this situation the technical problem is Apple’s decision to prevent Xojo built console application from using a “Resources” folder, when they’re included in a bundle.

I was trying to create awareness for this issue, because I do not know of a solution I can suggest to our shared customers, except to implement their own localization system that can draw strings from elsewhere.

I am not able to provide you with the correct solution to this, as it would require technical knowledge of how Xojo currently handles it, and a discussion with Apple’s engineers for their recommendations.

At least in this response, it shows that you understand the issue I am raising and I am pleased to hear that this is something that Xojo will address. I would imagine that a more intermediate solution, could be the option to simply disable the auto cursor adjustment. At least then if a developer is aware of the situation, they can do something about it. Perhaps, if it were not closed in this shut down matter, we could have conversed and hammered out something that wouldn’t require a complete re-write?

While we’re discussing some things, might I bring your attention to <https://xojo.com/issue/61413>
Which again is where Xojo is providing a potentially misleading situation to the end user (IMHO), and there’s currently not an easy solution (that I am aware of).

In this particular instance, If case <https://xojo.com/issue/30959> were implemented, then I could actually assist in the matter as I would able to propose an interim solution to the community, allowing Xojo engineers more time to focus on other tasks.

In summary; I report these issues because I want to build better applications with Xojo. Closing cases as “Will Not Implement” on first glance and without holding a discussion with the customer to make sure the problem is actually understood, is…


As far as I know, the OS handles this based on the asynchronous drag parameters, which is the problem here. Because we’ve got a hack that makes drag and drop synchronous, we lose the ability to control some of this stuff.

FWIW, the last time we touched D&D was when Catalina came out. Apple had deprecated the way we were doing some things and Catalina finally removed it. As you know, the replacement process isn’t always straightforward.

I do understand. The flip side is that we get hundreds of feature requests per week and based on conversations that we have internally, it’s usually pretty easy to tell when something won’t be done or at least, not in the way the user is proposing.

What I’ve found is that the most effective feature requests are the ones where the writer describes in great detail what it is they are trying to do and why they think it is important. The thing not to do is to tell us how to implement it, especially using comments like “all you need to do is tweak this one little thing”.

Personally, I find statements like that insulting. That would be like me going to Subaru and saying “I want my Forester to get better gas mileage so all you need to do is install a solar panel and some batteries”. What statements like that lack is a basic understanding of how all the pieces of the product work together and of any future plans that reach years into the future. It also sets us up to disappoint the user, because if we don’t follow the instructions given in the case, people get steamed about that too.


I think that is a big problem. Human nature will make you react differently than if you don’t find the information insulting and maybe even stop considering that user input or at least take their cases with a grain of salt.

Why take a client/user input insulting if they don’t have the knowledge needed to understand how the pieces work together?

Sometimes, even a user that doesn’t know how the pieces work could give a good idea on how to improve things. True, the “just do this” will not be feasible, practical, or even possible, but I think something else can be done.

Or maybe insulting is not as strong word than in Spanish and you consider the idea even if you find it insulting.


I understand what Greg is saying here. Flip it around - you may know what you are doing as a programmer, but the Xojo programmers and designers ALWAYS have it up on you on how Xojo internally works. In fact, there’s really no possible way a program user can understand the program maker (a bit of theology and Pinocchio here). So I understand the word “insulting” in this context.

… is the realisation that if I make them, then sure, feel insulted, as I have no clue.

But if someone like Sam makes them? Maybe take it as constructive criticism?

What it certainly shouldn’t be is an Ego trip. That would be bad for everyone.

1 Like

I have spent the day considering your response.

  1. In regards to the original case (that sparked this situation); is this to remain closed or will Xojo reopen it and provide a solution that will allow Xojo’s customers to create localized console applications that can be embedded into an macOS application bundle?

  2. I am not the enemy here; both you and I want similar things for Xojo, I suggest that we put this behind us and commit to working together to improve Xojo and it’s capabilities in the ways that we can individually do so.

  • I propose that I will endeavor to write better explained reports that should help the reasoning for these reports to be understood, which in turn will hopefully lead to better experiences for myself, you and Xojo’s customers.
  • I propose that I will no longer offer suggestions to issues or improvements, instead awaiting Xojo’s request for my input on such matters.

In return:

  • Xojo will consider my feedback cases, and provide me with access to the underlying OS object that the Xojo framework is built upon, so I in turn can extend Xojo’s capabilities or provide interim solutions for problems.
  • Xojo will also consider my requests for information regarding Xojo’s built apps, and provide assistive information in a timely manor which will enable me to better optimize my products to the benefit of Xojo’s customers.

Does this sound reasonable?


The only person at Xojo that could make such a bargain with you is Geoff.

If you like a solution, would you be interested in using MBS Plugin?

We have NSSavePanelMBS as class. I can add code for tag fields if that is needed by someone.

I could also provide a class to intercept the normal open dialogs from Xojo and let you customize them just before they show.

The Xojo engineers have a lot of stuff on their plate and anything we can do ourselves helps them to concentrate on the big issues.

Would this be Xojo ui controls or Cocoa ones?
Some years ago, I tried to customise a NSSaveDialog. Not doing Cocoa programming, it was hard for me to implement.
I eventually managed to make it somewhat working, but I had to handle weird crashes and couldn’t uncheck some checkboxes when conditions were met.
I don’t know whether I’d make a better attempt these days, as I gave up on this, but a Xojo-controls way would be very nice.

The NSSavePanelObserverMBS class is coming for next pre-release of our plguins
Would work for all Cocoa based file dialogs in Xojo, whether built-in or via plugin.

But I guess it won’t allow adding controls to a dialog, correct?

You could change accessoryView if you like and add controls.

Yes, that’s what I referred as “Cocoa controls” earlier. Not really Xojo-like.

You would like to create a Save As Dialog like above, but use Xojo to design the accessory view?

The source code to do this is included in the Ohanaware App Kit, which is part of the Omegabundle 2020. https://www.ohanaware.com/appkit/