Dock from Dash: a light dock for GNOME Shell


That’s here at the moment:

That’s a dock based on native GS dash. I reuse a lot of GS stuff without rewriting all the GS code.
150 lines. :wink:

There’s an issue with disabling/reenabling this extension. The error message is in the extension’s review discussion.
Could anybody help me with that? That’s related to native GS dash, maybe @fmuellner ?

The error means that _queueRedisplay() is called after the dash is destroyed. The underlying reason is that the built-in dash is sloppy with cleanup (mainly disconnecting signals), as it’s expected to be created once and exist for the duration of the session.

I’ll take patches that clean up those signals (and backport them to 41/40) :wink:

Ok, I thought it was something like that but I’m not that GS skilled!!
I hope you’re nevertheless happy that someone think to reuse your code?
It’s a long time since I’m thinking about reuse native GS dash to make a dock instead of recreating it from scratch. But that’s the first time I have some time to explore that.

You can find the new dock without major issue here:
The main issue was caused by a stupid startup-complete timeout I included, as pointed out in review by @JustPerfection .

Always very hard to find the bug when there are many causes.

Sorry @fmuellner but I’m stuck on a last issue.

extension.js code:

line 92: if I comment this line, the dock position is not correctly updated when I plug in a monitor with different size.
Well, I have a ‘workareas-changed’ signal line 133 that should update the dock position (_dock_refresh function).
If I uncomment line 92, the dock position is updated after the second show of the dock. Seems that the call to _dock_refresh here does really update dock position.
But it’s not satisfying to have to update dock position on each call to show it.

How can I do to really update dock position after a monitor plug-in?
I feel that there’s again some signals tricks but…

T H A N K S !

Ok, I finally got it here:

The extension page is here:

For those who want a dock but a simple and native one.

1 Like

I am waiting for years for this to happen. I infact offered bounty in stack exchange forum. That’s really great work of “dash to dock” and “dash to panel”. But I prefer native dock. Good initiation by you. May be in few reviews from gnome-extensions org website it will come to stable and have prefs button.

The goal is not to have options.
I know I will have dozens of options request. :wink:
But I just want to make here a pure GS dock. You enable it, it works reliably, end of the story.
So I’m aware of bugs or glitches.

Question for @fmuellner : I had to recreate the showApps button signal with a classical connect.

But is there a solution to grab the native GS button signals here?

But is there a solution to grab the native GS button signals here?

I’m not sure I understand the question.

OverviewControls connects to notify::checked if that’s what you mean, and that’s a better option: It’s emitted when the button’s toggled state changes, regardless of whether that happens by mouse click, keyboard activation or through code.

1 Like

If I put ‘notify::checked’ it works if I remove:

But there’s a problem here (that’s why I was using another way removing toggleState): when I click on dock’s showAppsButton, it turns in a hovered state (icon background) that is not restored when leaving app view (click - esc- esc for example). How can I remove this hovered background?

The main question is: why, when I consider the dock’s showAppsButton (dash.showAppsButton), the clicked signal is not natively created? When I wrote the first code of this extension, I was surprised that a click on this showAppsButton did not make anything. So what’s the better way in this extension to recreate the GS behavior/code?


why, when I consider the dock’s showAppsButton (dash.showAppsButton), the clicked signal is not natively created?

Again, this question is confusing (or confused?)

The showAppsButton is an StButton, and all StButtons have a native ::clicked signal. Additionally, if the toggle_modeproperty is set to true (which is the case here), the checked property reflects the toggled state.

None of those signals are handled by the ShowAppsIcon class itself though, if that’s what you mean. That’s because the button state is only part of the overall overview state, and that is handled centrally by OverviewControls.ControlsManager.

That is, your extension will either have to recreate the relevant bits from that class, or monkey-patch the class to consider your dash as well as the built-in one.

Ok I see (and saw) that here:
I’ll recreate a clicked action, that was what I meant.
I did not mean the ‘signal’ but the overview action, my fault.


How could I modify this:
js/ui/appDisplay.js · main · GNOME / gnome-shell · GitLab
to make a click on a running app to hide it? I mean, I know how to hide, but I don’t know how I can replace this GS function by a modified one.


Ok I did it with prototype.