Closed micheleg closed 12 years ago
I've had a look into and see no problem emitting signals for you to listen and react too.
I found that emitting the "bolt-showing" and "bolt-hiding" signals from bolt has 1 major issue in that if a user has dash-to-dock enabled and then installs bolt then dash-to-dock would have to somehow notice its now installed/enabled and start listening for signals. The messy part here is that you would have to constantly poll all the extensions and see if bolt is installed/enabled which isnt ideal.
What we need is some object that we know is always defined that I can emit from and you can listen for. I purpose the following; Main.overview.emit("bolt-hiding", timeTakenTillHidden); // you may want to use timeTakenTillxx to determine how you want to show/hide? Main.overview.emit("bolt-showing", timeTakenTillShown);
It may feel like a cheat to use the overview for such communication but it simplifies the issue greatly.
I've added as a test to your intellihide.js the following which demonstrates both extensions coexisting;
Main.overview.connect("bolt-showing", Lang.bind(this, function(overview, timeTakenTillShown) {
this._hide();
}));
Main.overview.connect("bolt-hiding", Lang.bind(this, function(overview, timeTakenTillHidden) {
this._show();
}));
Would you be happy with this?
I didn't consider the case when bolt is lately enabled. What you suggested would be perfect for me and it also seems the most pragmatic way to achieve our goal. I'm not sure weather it is a good or bad practice from the extension system point of view, but I can't see any problem if custom signals are 'clearly namespaced' like those proposed.
An alternative could be to rely on signals emitted by the bolt object and on signals in extensionSystem.js ('extension-state-changed' , 'extension-loaded'). In this instance a bolt object would have to be added to Main anyway, so we actually get nothing in return.
I'm definitely for signals emitted by the overview.
Ok great I'll add this to the next version of Bolt which should be release within a week or so.
Hi,
is there any plan to further develop this extension? I'm cleaning up the code of the Dash to Dock extension. If no updates are planned, I'm going to drop the compatibility support code.
Thanks for checking. I'm super short on time these days so I don't think I'll continue to support it. Best of luck with your extension :-) On 26/10/2013 11:37 AM, "Michele" notifications@github.com wrote:
Hi,
is there any plan to further develop this extension? I'm cleaning up the code of the Dash to Dock extension. If no updates are planned, I'm going to drop the compatibility support code.
— Reply to this email directly or view it on GitHubhttps://github.com/zacbarton/gnome-shell-extension-bolt/issues/7#issuecomment-27136678 .
I'm the developer of gnome-shell extension dash-to-dock [https://github.com/micheleg/dash-to-dock , https://extensions.gnome.org/extension/307/dash-to-dock/].
A couple of users signalled me an incompatibility between our extensions. Depending on which one is last loaded, my dock ends up being above the bolt dash. Now the best thing I can do to prevent problems is checking if the bolt actor exists since you made it is already accessible in Main.bolt, and put my dock actor below it. This is not the best solution. I would rather prefer to hide the dock when bolt is showed.
My idea is that you could provide custom signals, for instance "bolt-showing" and "bolt-hiding" similarly to how the overview does, and a stable way to check the bolt object existence and to reach it and connect to its signals.
This could help your extension to coexist with other ones.