Browse plugins window is misbehaving

[magicus]

I typically make my own xbar scripts (or hack on the ones I downloaded). It would be great if the Preferences submenu had a "Open script in editor" option, that would, well, open the script in an editor. (Either just run the standard open on that file, or have a preference in xbar to select your favourite editor.)

[magicus]

I see now that there is a "Open plugin..." menu item, which shows the script source, and which has an Edit button. Still not really the same as opening in your favorite editor, but close enough.

However, when pressing the Edit button, xbar crashed for me. :-(

[magicus]

Huh. I misunderstood the button, I thought it would convert the source view frame into an editor. Instead it did indeed try to launch in my editor (which I did not notice since I already had that file open in VS Code, and then nothing happened). Maybe rename the button to "Open in editor"? Or move it out of the source view frame, to make it more clear that it will launch a separate editor.

And xbar did not really crash. But the Plugin window got "stuck". Clicking on the red close button in the window title does nothing. :-( Short of quitting xbar, there is no way to get rid of that window.

[matryer]

@magicus thanks for the report. Is that crash you describe reproducible? If so, could you provide the steps so I can look into it?

Secondly, you can control the editor by setting the $EDITOR environment variable to the executable you wish to use. Apparently this is standard, although I'd never heard of it.

[magicus]

I have $EDITOR set in my .bashrc for my favorite terminal editor. I don't have a clue how I would pass an environment variable to a vanilla MacOS app like xbar. But even if I could, I'm not sure if that would be the correct behavior -- $EDITOR is what CLI like git etc look for; I've never heard about it being used for GUI applications...

[magicus]

Also, the "crash" is not really a crash. I debugged it a bit more. In fact, xbar keeps on running. What happens is that I cannot close the Browse plugins Windows. And actually, this happens even if I bring it up by Preferences > Browse plugins...

And yes, it is completely reproducible for me.

[matryer]

@magicus yeah the $EDITOR thing doesn't seem to actually work anyway. xbar doesn't source any env var files.

I'm up for adding and explicit flow to choose the editor. For now, it uses the open command, which for me opens Xcode.

Can you please bullet point the things you do that leads to the app window refusing to close?

[magicus]

Actually, the entire window behaves strangely. I can't cmd-tab to it. If I open it while in fullscreen, it forces itself on top of the other application (which is double annoying since I cannot close it), but the menu bar still belongs to the fullscreen app. Even if not in fullscreen, the window does not have an associated menu bar, which feels weird on macOS -- I just get the menu bar of the most recently used app. It does not show up in the Dock.

More concisely put: the window appears to be a "normal" app window, but behaves like a dialog box. This is breaking a lot of user expectations.

[matryer]

Yeah, xbar runs primarily in the background, so it doesn't have front and centre app attributes, like a dock icon, application menu, etc.

@leaanthony Is this a 'once per app' preference (in info.plist) or can it be modified programmatically while the app is running?

[magicus]

Otherwise you might want to have the plugin browser and the background icon handler as separate executables..?

[matryer]

Yeah we discussed that and decided against it. Hopefully we can get that window to behave itself a little better, and then it won't be such a pain to manage.

[matryer]

Closing this because there's a lot of different issues discussed. Let's open new issues for the items individually.

The window not going away when you click the red close button: #647