Panel relative layout
The problem: absolute positionning on the panel
The problem of resolution changes has been raised in [1], and I would like to discuss the effect of these changes on the panel in particular.
The current situation is that the panel layout often gets mixed up when one changes the screen resolution. Here is an example (pretty artificial I admit, but I think it demonstrates the problem) where I deliberately placed a few applets and launchers at (approximately) equal distance one to another (1680x1050 here):
http://www.manucornet.net/pub/GNOME/Capture1680x1050.png
When I switch to a lower resolution (1280x960), I get:
http://www.manucornet.net/pub/GNOME/Capture1280x960.png
and even this with an even lower resolution (960x600):
http://www.manucornet.net/pub/GNOME/Capture960x600.png
The way that the positions are stored in GConf (with absolute values, in pixels) makes that absolute positions are favored (it seems) above global coherence of the layout.
Proposal
I suggest that we make use of "spaces" that behave like LaTeX's \stretch{value} command (where value can vary), if you know about those.
Storing the layout
- Current storage (in GConf) of the absolute values in pixels can be retained for current needs.
- However, the layout could be stored in an XML format with a relative layout (see below), in a single file. This file can be read when the panel is started, whenever the resolution changes, and maybe on other occasions.
Layout file
Instead of having applets being mentioned in an arbitrary order, but with absolute positions (like currently with the GConf way), applets will simply be mentioned one after another, and when the file is read, they will be added from left to right and top to bottom (maybe the opposite for RTL languages, not sure what conventions are in that case) in the corresponding toplevels.
The XML file will not mention positions at all, but will have a special type of element playing the role of a space so that applets can be placed wherever the user wants. These empty spaces' size will vary in function of the resolution (see below).
User changes in the layout
Of course, we don't want to make users take care of all that (spaces), so we need to retain the current way of modifying a panel's layout. The way that the current panel's appearance and the user modifications communicate with the GConf keys could be left unchanged. However, when a user has finished moving an applet, here is what could happen:
- We would "parse" the current layout, from right to left or top to bottom (and take care of RTL langs).
Whenever an element (applet/launcher/menu) n + 1 is located further than the position of the previous element n plus the size of the element n, we store the value of the difference (the "space") somewhere.
When we finished parsing, we compute the sum of all space values (let it be sum).
Then we write the XML layout file, writing each element after the other (without writing positions), and when we have a space, instead of storing its absolute value s, we store s / sum as a float.
Making the layout from the XML file
We first compute the total number of pixels that are available for this particular panel (in the case where the panel automatically extends to fit the screen). Then we parse the XML file, to compute the sum of all elements sizes. This gives us the available space between elements. We then parse the XML file again, and we add each element when it appears, but whenever we get a space (which is a value from 0 to 1), we allocate it the correct proportion of the total available space. Because of rounding problems, we might not reach an exact proportion of 1, so we might want to allocate all the remaining space to the last space in the file (or maybe do something smarter). As we realize this layout, we write the absolute position values to the GConf keys like it is done currently.
Details
- It is possible that a space exists at a given resolution, but when switching to another resolution that space disappears because there is not enough room for it, either because the total size of elements is greater or equal to the panel's size, or because it is allocated a size smaller than 1px, therefore rounded to 0. It might then not reappear in bigger resolutions, so we need to have a way to remember that we want a space here when the resolution allows it. Well, if we only load the XML file on a resolution change but do not overwrite it unless the user changes the layout, at least the space will reappear when the resolution goes up again.
We could have a way to tell an applet to always be visible (eg menus & the clock) even when there is not enough space for everybody. Then, we could have something a bit like the bookmarks toolbar in a browser, where the remaining applets would be listed inside a small menu.
Consequences
- This would solve the problem mentioned above.
- Applets that are placed at the end (eg far right) of a panel would stay there because the spaces will expand, regardless of the resolution.
- The global aspect of the panel will not change with the resolution.
- We can manage the case where there is not enough space to fit everybody without "overflowing" the panel.
Possible problems/drawbacks
- Moving the layout outside of Gconf makes sense, but it can also add some problems, like lockdown
- And initial configuration
- Some applets should be able to have 'visibility priority'. E.g. in the current setup, the grandr screen resolution applet can move out of sight when setting the screen to a lower resolution, leaving the user with no means to switch back to the previous resolution.
External References
[1] http://mail.gnome.org/archives/usability/2007-March/msg00026.html