Month: March 2011

I recently switched to using gnome-shell in my day to day work, and so far I like it a lot. However, I use a dual monitor setup, and the gnome-shell support for multihead was very rudimentary.

Here is an example desktop with a 1920×1080 primary monitor and a 1280×1024 monitor on the left:

And the corresponding overview:

There are a number of issues here:

All previews are on a single monitor. So, while we have a lot of space for normal windows with two monitors we need to cram them all into part of a single monitor in overview mode. This makes the windows way to small to be usable.

Due to internal issues the part of the overview that shows the windows is always the same aspect ratio as the screen (i.e. the total size of all monitors). This is fine in the case of one monitor, but with two monitors it doesn’t match the monitor aspect ratio making windows even smaller.

During the overview switch the windows on the extra monitor fly a long way, making the animation not work really well, as well as breaking the natural grouping of related windows being on the same monitor.

The extra monitor space is unused

The thumbnails that normally slide in from the side in a slick way instead overlap the other monitor and its hard to make slide in since the mouse enters the other monitor instead.

The thumbnails include the “dead” area due to the different sized monitors and generally look weird.

Additionally, but not visible here:

Its hard to hit the hot corner on the primary monitor if there is a monitor to the left. (And to hit the menu in the right corner if there is a monitor to the right.)

If the top-left monitor is not the primary there is no hot corner in the easy to reach corner, instead you have to mouse into the primary and then try to hit the corner.

If another monitor is taller than the primary, its very hard to hit the message tray on the bottom of the primary monitor, as the pointer passed over to the dead area.

In most typical cases the external monitor is used to show something static, like always visible information, a presentation on a projector, or a movie on a TV. However, the extra monitors are connected to the same virtual workspaces as the primary, so when you switch workspace the apps on the extra monitors switch around too.

The last few weeks I’ve been working on this, and these changes have now landed in git.

Here is how it looks now:

And the overview:

We can see here:

There is a window overview on each monitor, showing the windows on that monitor.

The window overview area is not artificially constrained by aspect ratios but as large as it can be, so the windows are larger in the overview.

The thumbnails are always slided in if there is a monitor to the right of the primary monitor.

The thumbnails only show the primary monitor. This is because the whole workspace feature only affects the primary monitor. Windows on extra monitors stay in place when switching workspaces, only the primary monitor changes.

Additionally some things we can’t see:

Every monitor with a natural top-left corner (i.e. the top left monitor, or a monitor to the right that is taller but aligned at the bottom) gets a hot corner that activates the overview.

The ever-rocking ajax has added pointer barrier support to the Xserver for us. If this is available (he backported it to Fedora 15, yay!) we add one-sided barriers in the panel and the message tray so that its easier to hit these, even if there are monitors on the sides.

Additionally, as part of the pointer barrier support the Xserver now automatically blocks the mouse from entering the dead areas that are not shown on any monitor. This is great if monitors have different resolutions.

These are not enormous changes, but the difference in day to day use in a multimonitor setup is like day and night. These should be in the next release which is out soon, so if you’re a multimonitor user, do try it out!

The last few days I spent fixing up some more details in the new HTML5 gdk backend. Not everything is supported yet (keyboard input in particular is very weak), but much more things work now. Even thought the backend is not of production quality it is now good enough that I think its interesting for a larger audience to play around with. So, today I merged the branch into the Gtk+ master branch (i.e. what will be Gtk+ 3.2).

The new multi-backends setup in Gtk+ 3.0 makes this much easier to test. All you have to do is build Gtk+ with –enable-x11-backend –enable-broadway-backend.This will give you a normal X11-based Gtk+ where you can enable the broadway backend at runtime by setting the GDK_BACKEND enviroment variable.

The backend only supports firefox 4 atm, and Mozilla disabled websockets by default, so you have to enable enable websockets for any input to work. However when this is done you can test any app by running: