GNOME Bugzilla – Bug 664318
dock extension should let user choosing monitor
Last modified: 2012-05-07 21:07:46 UTC
Created attachment 201648 [details] [review] git format-patch patch When you have more than one monitor, the dock is placed on the right of the first one, making it difficult to open if there is another one on the right of it (mouse pointer is not stopped) I wrote a little patch to add a config key to choose the monitor where you want to display the dock.
Created attachment 202937 [details] [review] git patch against gnome-3-2 This patch applies to gnome-3-2 branch
Created attachment 212809 [details] [review] git format-patch patch on 3.4.0
Review of attachment 212809 [details] [review]: Sorry it took me this long to review... ::: extensions/dock/extension.js @@ +320,3 @@ this._hidden = false; this._hideable = this._settings.get_boolean(DOCK_HIDE_KEY); + this._displayMonitor = this._settings.get_int(DOCK_MONITOR_KEY); You should probably connect to changed:: + DOCK_MONITORY_KEY and update this, so the user is not required to restart the shell. ::: extensions/dock/org.gnome.shell.extensions.dock.gschema.xml.in @@ +38,3 @@ + <default>-1</default> + <_summary>Monitor</_summary> + <_description>Sets monitor to display dock in.</_description> You should mention that -1 means primary.
Created attachment 212930 [details] [review] git format-patch patch on 3.4.0 I amended the commit to make the changes you suggested
I rebased and pushed this to master. It would be helpful if you could test this before I update extensions.gnome.org, since I have only one monitor. Thanks,
Thanks, I'll test that on wednesday
I think there is a clipping problem, on shell start, the dock don't show up if not configured on the primary monitor, but it works if I change the monitor after that.
I logged calls to updateClip() and some values it uses : * extension start monitor: 1280/0 actor: 17.351253509521484/3.4485275745391846 alloc: 0/0/56/4 clip: 1262.6488037109375/-3.4485275745391846/38.648746490478516/0.5514724254608154 * monitor: 1280/0 actor: 2556/144 alloc: 17.351253509521484/3.4485275745391846/73.40556335449219/7.475681304931641 clip: -1276/-140.5514678955078/-2482.594482421875/-136.52432250976562 * monitor: 1280/0 actor: 2555.647705078125/144 alloc: 2556/144/2620/880 clip: 0.352294921875/0/4.352294921875/736 * monitor: 1280/0 actor: 2545.58447265625/144 alloc: 2555.647705078125/144/2619.647705078125/880 clip: 10.063232421875/0/14.41552734375/736 * monitor: 1280/0 actor: 2504/144 alloc: 2504/144/2568/880 clip: 0/0/56/736 * monitor: 1280/0 actor: 2517.1787109375/144 alloc: 2504/144/2568/880 clip: -13.1787109375/0/42.8212890625/736 * monitor: 1280/0 actor: 2526.197509765625/144 alloc: 2517.1787109375/144/2581.1787109375/880 clip: -9.018798828125/0/33.802490234375/736 * monitor: 1280/0 actor: 2533.68701171875/144 alloc: 2526.197509765625/144/2590.197509765625/880 clip: -7.489501953125/0/26.31298828125/736 the first 2 calls uses "invalid" actor/allocation values, and produces clip values that prevents the dock to display on screen.
Created attachment 213439 [details] [review] patch for clipping problem I solved the problem by not applying clipping when the actor is not in the configured monitor (checking its boundaries)
Review of attachment 213439 [details] [review]: I don't like this patch. I want to understand why the actor is not on the configured monitor right from the start, and then fix that.
Neither do I. Something like : let [_x, _y, _w, _h] = this.get_start_position(); this.actor = new St.BoxLayout({ name: 'dock', vertical: true, reactive: true, x: _x, y: _y, width: _w, height: _h }); works if get_start_position() ensures that this._nicons != 0 (or forces height to be monitor.height)
Created attachment 213593 [details] [review] patch for clipping problem
Review of attachment 213593 [details] [review]: Makes sense, although it prevents the showDock animation on startup. Well, screw that, I'm pushing it.
Pushed to master and gnome-3-4, extensions.gnome.org updated. I'd say FIXED for now. Reopen if you find new issues.