Closed tylerFowler closed 8 years ago
Yep this is definitely an imporatnt subject. The Breach API is still undergoing a major revamp so we'll want to wait until then to start "standardizing" stuff as you mention.
We have a pull request we're working on that adds configuration to modules. We could use that configuration object to specify action types and icons... Then it would be the responsability of whichever module is running and taking care of the tab bar as an example to show the appropriate icons and trigger the appropriate calls...
Another solution would be for Breach to expose an API to setup such actions so that the list of such actions, its format and its access/modification is entirely standardized (though the way it is displayed to the user is totally up to the modules he runs)...
Make any sense?
Yes this sounds like something I had in mind, if the tab bar had the responsibility of actually organizing and placing all available modules with a certain type (such as icon or menu placement) it would solve that problem quite nicely.
Going further, would it be practical to expose an API for adding OS specific stuff such as menus/context menus? This would allow developers to recover a lot of functionality offered in most major browsers (i.e. new tab, open from file, new window, etc...), though I imagine it would be done on the exo_browser side rather than breach itself.
Context menus are already exposed. Menu are on their way :)
It's inevitable that people will want to create extensions for Breach (in fact some lovely weekend I'm going to sit down and make an 'Add to Pocket' extension), but there needs to be a single, unified place to put them. I love that Breach is reliant on the module system, but you don't want people putting extension icons or whatever wherever they want or else there could very easily be conflicts between where the developer chooses to put their extension functionality.
So I propose that something like an expandable panel be added to the browser where developers can choose to put any icons that their modules require, this way extensibility is maintained while also providing some order for people who want to mix and match different extension modules. Perhaps there's another solution, but I'm not sure what it would be.