Dockbarx: group applications when space is limited

Registered by Eemil Lagerspetz on 2010-05-21

On netbooks, in vertical panels, or when space is otherwise limited, Dockbarx should provide a way to access applications that spill over the displayed area. Scrolling is one idea, but it may confuse users; it's hard to click on the last button if it moves while trying to click it. I propose grouping applications by alphabetical order, by current dockbarx order, or the like. Pinned applications would be kept ungrouped as long as possible. Dockbarx could show a pop-up similar to the current one when multiple windows are open, but have two or more headlines for the different applications shown in that popup. The icon of this multiple applications group button would then become a merge of the two (or more) icons of the applications contained within. Dockbarx could show the first application's icon scaled down in the top left corner of the new icon, the second's in the lower right (in case of two). If there are three, top right, top left, bottom middle makes sense, and clockwise corners from top left on for 4 applications. 5 would not show by the icon, but this would be very rare; space-constrained screens are rarely attached to devices that could handle this many applications (41 with 4 per icon and 10 icons)

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

Could you do some mock-ups? Pictures says more than words. (Though your words might be enough if I weren't so tired, maybe I get a better picture reading this again tomorrow.)

Mockup: http://i48.tinypic.com/25tvswy.jpg

Matias: Something needs to be done about situations where dockbarx takes up too much space, but this solution seems hard to implement and manage. I agree that scrolling isn't a good solution either. The easiest sollution would perhaps be to decrease the aspect ratio for group buttons when more space are needed. That would make room for more buttons hopefully without too much visual errors.

Eemil: In Mac Os X, the bottom launcher bar makes icons smaller and smaller and more and more overlapping when space becomes limited. On the other hand, it has the gradual zoom around the mouse, which makes looking at the ones you are pointing at easier. On the other hand, the zoom and heavy overlap makes things messy in the long run, so grouping is better in that sense.

Matias: How do I know if an applet takes up too much space? Gnome panel applets doesn't seem to be really well documented...
The size allocation seems to be documented here:
http://library.gnome.org/devel/pygtk/stable/class-gtkcontainer.html
I would look for invocations of size_allocate().
When a rectangle given to a child (group button) steps out of the top level dockbarx size allocation rectangle, dockbarx is too big (too many group buttons).

Matias: I'm still a bit fuzzy on how request-allocation thing works, but isn't the problem that the top level allocation rectangle automatically resize when there isn't enough room and that dockbarx then pushes other applets offscreen? When signal for size allocate is sent the new allocation is already done?

Fubarbundy: Unity's concertina effect seems much more elegant than the grouping idea - how about using that at least as a benchmark? Also see https://bugs.launchpad.net/dockbar/+bug/619503

Eemil: This thing you mean?
http://www.webdevonlinux.fr/wp-content/uploads/2010/06/dock+accordion-112x560.png
It looks kinda nice and hopefully doesn't cause other icons to move as much as scrolling or the Mac Os thing. But I am afraid it may require acceleration, so there should be a fallback for non-accelerated desktops.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.