Wavebox services to get unread count still need an icon on the toolbar.

[deathau]

I'm assuming that this extension API is replacing the old service API. To that end, I've replicated the Basecamp adapter I made for the old wavebox service API. But because it's an extension, its icon will be displayed in the top right with all the other extensions.
I wonder if there could be a way to identify an extension as wavebox service-based and have an option to hide its icon by default?

[deathau]

Another idea I had might be to have some sort of HTML UI baked into this API that gets the messages for the service from wavebox and displays them, just so the toolbar button actually does something. I'm considering building something like this for the Basecamp one I've just built and will report back if/when I go ahead with it.

[Thomas101]

I'm assuming that this extension API is replacing the old service API.

That's the long term goal here.

But because it's an extension, its icon will be displayed in the top right with all the other extensions.

Yeah, it's a bit of a waste of space at the moment. As for providing a baked in popout, it sounds like it would probably just be reproducing what's already offered in Wavebox Mini with the unified unread counts, so not sure how that would work in a unified UI sense. We could auto-open Wavebox Mini, but again it just feels like a lot of buttons to do the same thing :-/

That said, if an extension wants to add a popout, it's perfectly feasible to do so using the popout API, we won't be changing that behaviour.

Looking at something that works out the box which also reduces the amount of code an extension has to ship with, we're thinking about bringing the Wavebox permission into the standard extension install prompt (the current one is a bit janky) and giving the user the option to auto-hide the browser action during this install process. We'd probably look at checking which permissions are requested before offering this (e.g. just the Wavebox service API, no browser action defined etc).

Chromium made a change around v40 to make all extensions appear in the toolbar for security purposes, and I don't think we'd want to deviate too far from that, so we'd probably look at just placing the icon in the extended extension menu. You can toggle this behaviour manually at the moment by right-clicking on the browser action and using Hide in Wavebox Menu

That said, this isn't set in stone our end at the moment, so it would be good to get some feedback on it!

[deathau]

I went through the options in my own head after posting initially and came to basically the same conclusions: if it's Wavebox specific, have an option to hide it by default.

Another idea I had would be to possibly add a Wavebox-specific flag to the manifest file so that the extension can say that the button is effectively useless and hide it by default, rather than putting the onus on the user to decide at the permission dialog.

Also, (and I know this is probably a little off topic), are there plans for a Wavebox-specific extension repository? If I decide to publish my Basecamp adapter extension, it doesn't make sense to put it on the Chrome web store, as it would effectively do nothing on Chrome.

[Thomas101]

Another idea I had would be to possibly add a Wavebox-specific flag to the manifest file so that the extension can say that the button is effectively useless and hide it by default, rather than putting the onus on the user to decide at the permission dialog.

Something along those lines is what we were thinking. Probably something like wavebox permission + a permission for a single site (not <all_urls>) would have the checkbox during the install process, automatically checked, so pressing okay, okay, okay gets the right behaviour

Also, (and I know this is probably a little off topic), are there plans for a Wavebox-specific extension repository? If I decide to publish my Basecamp adapter extension, it doesn't make sense to put it on the Chrome web store, as it would effectively do nothing on Chrome.

Yes. It doesn't make any sense to publish it to the Chrome store and in all honesty, Google would probably reject it because it serves no purpose in Chrome. We're planning on adding our own extension repository early next year