matryer / xbar

Put the output from any script or program into your macOS Menu Bar (the BitBar reboot)
https://xbarapp.com
MIT License
17.57k stars 643 forks source link

Refresh from URL steals focus, displays "Updating..." #331

Closed dagware closed 3 years ago

dagware commented 8 years ago

When I tell BitBar to refresh using the URL syntax "bitbar://refreshPlugin?name=blablabla", two things happen which I find undesirable.

1) BitBar steals the application focus, or at least un-focuses the app I'm in. An example of this is that I'm using Keyboard Maestro which will periodically ask BitBar to refresh a plugin. This happens in the background, as a result of some action like a timer. When it happens, The app I'm in loses focus.

2) When I use the URL plugin refresh, BitBar displays "Updating" in the Mac Menubar. Is this really necessary, when I'm only refreshing one plugin? It's annoying and distracting. ;p

Or is there another syntax which will not cause this to happen? I'm really just saying "I know you're supposed to run on the hour, but please run right now". So perhaps "refresh" is the wrong thing to use? Thanks.

PS: Love BitBar!!

mm2270 commented 8 years ago

Wow, I was going to post something here very similar to what you wrote yesterday, so you beat me to the punch. I agree that the "Updating" text in the menubar seems a little unnecessary. Given BitBar plug-ins auto refresh on a schedule determined by the timing you set for the plug-in, and in those cases it does so completely silently, I would also love to see some method of invoking that silent refresh without seeing the menubar icon change to the Updating text. Maybe they can keep the original method, but add an additional url syntax to make it update in a silent way, just as the plug-ins do now.

And yes, the app stealing focus is also annoying, but I think this happens because technically the open bitbar:// url syntax is actually activating BitBar, and since its an app, it will change the focus to that app. That said, I hope this issue can be fixed with some way of not making it steal the focus, but that might be tricky.

iosdeveloper commented 8 years ago

I think you can use the -g option with open, so the app won't focus.

iosdeveloper commented 8 years ago

I wouldn't want a refresh via the URL scheme to be silent, so I could notice any malicious activity i.e. from a website.

mm2270 commented 8 years ago

Ah, thanks for that. Just tested and yes indeed adding -g to open fixes the focus stealing problem. Nice!

As for the concern about malicious activity, I guess I'm not understanding the concern. You're worried about a site refreshing your BitBar plugins surreptitiously? Or am I misunderstanding what you mean here?

dagware commented 8 years ago

Thanks for the tip. I'm confused, though. Where is this "open" to which I should add the "-g"? Thanks!

iosdeveloper commented 8 years ago

@mm2270 Exactly. Imagine a script that uses a paid API key like forecast.io. I admit it is unlikely but still a possibility.

mm2270 commented 8 years ago

@dagware I include code in my scripts that when certain lines are selected in the menu, it calls the following syntax:

open bitbar://refresPlugin?name=pluginname.*?.sh

If I change it to:

open -g bitbar://refresPlugin?name=pluginname.*?.sh

It does the same refresh, but does not steal the focus.

mm2270 commented 8 years ago

@iosdeveloper OK, I see what you mean about a paid api where it could rack up a big overage bill, or blow through a quota very quickly if it were being done silently. As you said though, that seems very unlikely to happen, but I guess its still enough of a concern for some that it probably shouldn't be changed. I'd still love to see it not say "Updating". Maybe the icon can become greyed out temporarily while its updating. Or maybe instead of "Updating" can it just change to ... while its refreshing? That would be a little less distracting, but still noticeable for anyone that needed to monitor those refreshes.

dagware commented 8 years ago

@mm2270 Ah, I get it. I'm actually calling this from another app (Keyboard Maestro), so I don't think this will work for me.

mm2270 commented 8 years ago

@dagware I don't use Keyboard Maestro, but from what I've read about it, it can do a million different things. I can't believe one of those things isn't the ability to run a simple shell command. That's all that open -g command is, so I'd be surprised if you couldn't make KM refresh your plug-in with the open command instead of accessing the URL directly.

dagware commented 8 years ago

I tried that, actually (and yes, KM can do a million different things). I wonder if I'm doing something else wrong.

Hmmm. I just ran it from terminal, and it worked. I must be doing something wrong from KM. I'll check on there forum. Thanks for the clarification!

dagware commented 8 years ago

Yes, it works from KM. I'm just an idiot. ;)

Still would like it to not display "Updating" though...

mm2270 commented 8 years ago

@dagware Looks like my comment above was labeled as "todo" which means they are planning on looking at it. Probably not to be completely silent, but less intrusive at least. Good enough for me! :) Thanks @iosdeveloper!

dagware commented 8 years ago

Cool! There's so many things I would consider doing if it would update silently.

mm2270 commented 8 years ago

Just circling back on this, I wanted to post that I was able to make the changes myself to change the Updating... text when manually refreshing (or refreshing using the URL method) to simply ...

It seems the one location this is in is the ExecutablePlugin.m from the Xcode project. I located it by searching and found the following section in that file.

- (void)performRefreshNow {
  self.content = @"Updating ...";

I just changed it to:

- (void)performRefreshNow {
  self.content = @"...";

And rebuilt BitBar successfully. I needed to quit and relaunch BitBar after moving the new build into place, but after that any manual refreshing only shows ... in the menu briefly.

It occurred to me you could use this method to change it to anything you want, possibly localizing it for example to your native language, or even replacing it with a symbol, such as ⟳ to indicate a refresh is taking place. The only reason I say this is because when BitBar is first starting up from a fresh launch or after choosing Refresh All from the Preferences submenu, it shows ... for all plug-ins, so using ... also for a manual or programmatic refresh could be confused with a launch or full refresh. So maybe using something else, also discrete, but unique might make more sense. Either way is good though.

For anyone wanting to do this now, you can just pull down the project and make the change yourself. Hope that helps.

iosdeveloper commented 8 years ago

@mm2270 I liked your suggestion to grey it out during refresh.

mm2270 commented 8 years ago

@iosdeveloper Oh, yeah. I like that idea too, and hope to see that implemented. I was only posting the above as an interim solution until that gets done. I wouldn't know how to make the icon/text for the plug-in grey out, so that will be up to you guys to do :)

BTW, any chance we'll be seeing a new full build at some point? Its been a while since the last one and I see that there have been several PRs with some interesting new features, which haven't been incorporated yet into the master, I don't think.

iosdeveloper commented 8 years ago

@mm2270 You can switch to the latest beta release, which should contain these PRs. Some still need testing and feedback. We might also be simplifying the Plugin API before releasing v2.0.0.

mm2270 commented 8 years ago

@iosdeveloper Thanks. I'd forgotten about the beta builds. So I'm trying it out now, and there seem to be issues with it. My custom plug-ins are not displaying fully with the v2 beta 4 version. This is happening on 2 of them that I have loaded. Essentially, the menu becomes truncated at some arbitrary location and doesn't display everything it should be displaying. Its almost as if the echo or print to generate the menu is being cut off prematurely and BitBar is only receiving some of the information, not all of it.

So for now, the beta is a no go for me given this issue. If there's anything I can do to assist with tracking down the problem, I'd be glad to help.

iosdeveloper commented 8 years ago

@mm2270 Do you use ~~~ in your scripts? This is reserved now for long running plugins.

mm2270 commented 8 years ago

@iosdeveloper No, none of my scripts are using that. I'm aware of that change in the beta and it was actually one of the things I was curious about experimenting with. But those characters are not in the output. To be clear, the script output is pretty long, and depending on screen size, might require some menu scrolling to see all the output. It can take several seconds on a refresh when the script runs to complete. I did some testing and I noticed that it seems to get cut off at slightly different locations when I refresh it manually. So its not even being cut off in the same place each time it refreshes.

I'm not sure what it could be. Is there a limit in the beta for how long the script can run before it finalizes the menu information to display? I can do some testing with another plugin that has lots of lines but completes much faster to see if its a timing thing.

iosdeveloper commented 8 years ago

@mm2270 No limit. It should read all standard output until the script exits. I would really like to fix this bug but I'm unable to reproduce it. Could you try to come up with a minimal script you can share with me that does not contain anything sensitive? Maybe we stop reading the output too early after the script exits.

mm2270 commented 8 years ago

@iosdeveloper. Hey, sorry. I saw your post, but didn't get a chance to respond until now. I'd be happy to post up an example plugin script that exhibits the cut-off issue i described. I'll work on something.

As an aside, I got several email notices about a BitBar 1.9.2 beta 1 release, but when I click the links in the email notification, it brings me to a github 404 page. Where is the 1.9.2 beta 1 version I can access? I don't see it on the beta release branch. Should I be testing out these scripts with this 1.9.2 beta as well, or were you looking for something to test around the 2.0 beta only?

iosdeveloper commented 8 years ago

@mm2270 Sorry, these were published accidentally while testing the Sparkle integration that I'm working on.

mm2270 commented 8 years ago

Ah, Ok. No worries. I just wanted to make sure I wasn't missing anything. So the latest beta right now is still 2.0 beta 4. Is that right?

iosdeveloper commented 8 years ago

@mm2270 Correct.

iosdeveloper commented 8 years ago

@mm2270 Please open a new issue with the example script, so we can track it better.

iosdeveloper commented 8 years ago

@dagware @mm2270 Grayed out status item in v2 beta 5.

iosdeveloper commented 8 years ago

@mm2270 Standard output truncation should be fixed in v2 beta 6.

mm2270 commented 8 years ago

@iosdeveloper. Just commenting back that, yes, with the latest beta 6 release, my plug-ins are now fully rendering in the menu(s). So far all refreshes, both from the command line and from the menus themselves have rendered the full menu out, not truncated like I was seeing before. Nice! Thanks for fixing that!

Also, I'm loving the grayed out icon/menu text now for refreshing, and I'm playing with the checkmark function as well. Looks good! One new feature I haven't been able to really make sense of yet is the screenshot url. Any further documentation on how to use that? Its not super clear how that works right now in the docs. I think I could make use of it in one of my plugins, but I'm just not clear on the syntax to use with that.

iosdeveloper commented 8 years ago

@mm2270 The screenshot endpoint was initially added to enable automated screenshots from Travis CI in the plugins repo. Here is a proof of concept: https://github.com/iosdeveloper/ScreenshotTest/blob/master/screenshot.sh#L6

mm2270 commented 8 years ago

Thanks! That helps. I was able to get it working by looking at the example. And thanks for the clarification on its original intent. Not certain it will prove useful in normal use, but its good to know it can be done anyway.