Dock from Dash: a light dock for GNOME Shell

fthx · December 25, 2021, 4:25pm

Hi,

That’s here at the moment:
https://extensions.gnome.org/review/28634

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

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 ?
Thanks!

fmuellner · December 25, 2021, 5:28pm

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)

fthx · December 25, 2021, 6:18pm

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?
:-p
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:
https://extensions.gnome.org/review/28637
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.

fthx · December 26, 2021, 9:27am

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

extension.js code:

github.com

fthx/dock-from-dash/blob/main/extension.js

/* 
	Dock from Dash - GNOME Shell 40+ extension
	Copyright Francois Thirioux 2021, 2022
	GitHub contributors: @fthx
	Some ideas picked from GNOME Shell native code:
	https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/dash.js
	https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/overviewControls.js
	License GPL v3
*/

const { Clutter, GLib, GObject, St } = imports.gi;

const Main = imports.ui.main;
const Dash = imports.ui.dash;

var DASH_MAX_HEIGHT_RATIO = 0.15;
var DASH_OPACITY_RATIO = 0.9;
var SHOW_DOCK_BOX_HEIGHT = 3;
var SHOW_DOCK_DURATION = 200;
var HIDE_DOCK_DURATION = 200;

This file has been truncated. show original

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 !

fthx · December 26, 2021, 1:47pm

Ok, I finally got it here:
https://extensions.gnome.org/review/28643
Pffffffff…

fthx · December 26, 2021, 1:48pm

The extension page is here:
https://extensions.gnome.org/extension/4703/dock-from-dash/

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

PRATAP · December 28, 2021, 2:54pm

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.

fthx · December 28, 2021, 7:56pm

The goal is not to have options.
I know I will have dozens of options request.
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.

github.com

fthx/dock-from-dash/blob/40d64c20002a009e8b55f6065b217bd8f16dd176/extension.js#L160

    
      
          }
          
          
_create_dock() {
              this.dock = new Dock();
              this.screen_border_box = new ScreenBorderBox();
              this._dock_refresh();
          }
          
          
enable() {
              this._create_dock();
              this.dock.showAppsButton.connect('button-release-event', this._show_apps.bind(this));
              this.dock_hover = this.dock._dashContainer.connect('notify::hover', this._on_dock_hover.bind(this));
              this.screen_border_box_hover = this.screen_border_box.connect('notify::hover', this._on_screen_border_box_hover.bind(this));
              this.workareas_changed = global.display.connect('workareas-changed', this._dock_refresh.bind(this));
              this.main_session_mode_updated = Main.sessionMode.connect('updated', this._dock_refresh.bind(this));
              this.overview_showing = Main.overview.connect('showing', this._hide_dock.bind(this));
          }
          
          
disable() {
              if (this.show_dock_timeout) {
                  GLib.source_remove(this.show_dock_timeout);

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

fmuellner · December 28, 2021, 11:04pm

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.

fthx · December 29, 2021, 9:39am

If I put ‘notify::checked’ it works if I remove:
https://github.com/fthx/dock-from-dash/blob/40d64c20002a009e8b55f6065b217bd8f16dd176/extension.js#L42

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?

fthx · December 29, 2021, 9:43am

fmuellner · December 29, 2021, 4:08pm

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.

fthx · December 29, 2021, 4:26pm

Ok I see (and saw) that here:
https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/overviewControls.js#L387
I’ll recreate a clicked action, that was what I meant.
I did not mean the ‘signal’ but the overview action, my fault.

fthx · January 5, 2022, 8:57am

Hi,

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.

Thanks!

fthx · January 5, 2022, 1:18pm

Ok I did it with prototype.