Waldo Bastian wrote:
... what is this special case for? Can we just keep the spec clean, and say that both X and Y MUST have non-zero values?I can't think of a reason to have it offhand, really, no.It stems from the situation that our panel imposes either a X or Y value but the other value is a function of the number of desktops. By spec'ing it this way you will still have correct layout information when something else changes the number of desktops. Otherwise you may have incorrect layout between the time the number of dekstops change and the time the panel reacts to that change with new layout information.
Ok, but how long can it really take for the pager to update itself after a change?
It seems to me that:A) It can't take too long, because the pager is the user's primary visualization for the number of desktops. The pager really *should* update quickly. I've never noticed it updating too slowly, myself. Am I wrong about this?
B) Even if the pager were to update too slowly, the goal of this extension is to enable the WM to behave consistently with the visual layout of the pager. IMHO, the wm should always behave in a manner that respects the pager's layout, even if that layout is out of sync, because the pager's layout is the user's model of the system.
If the WM behaved w.r.t. the number of desktops instead of the pager's layout, we would have problems where "view-workspace-down" actually moved the current workspace down-and-to-the-left on the pager instead of just down.
C) If we did want the pager to advertise only the number of wrapped rows, and not the number of columns created by those rows, why not just have the pager advertise only the number of wrapped rows? I suspect that implementations of this protocol will choose to do one or the other anyway, and that the special case will just result all implementations maintaining the same pieces of un-exercised code.
All together, it still makes sense to me to remove this special case. What do you think, Waldo?