[Panel-devel] Pager extended for "viewports"

[Aaron J. Seigo]

On Thursday 21 September 2006 4:44, Timothée Lecomte wrote:
> You're right, but that's not the pager's problem. The taskbar has to be
> adjusted to show only the apps from the current viewport (conditionnally
> to the settings "display windows from all desktops" probably).

this makes sense.

> > There might be a window manager out there, either now or in the future,
> > that supports both desktops and viewports at the same time. What I'm
> > thinking about: should we really bother the KDE user with the difference?
> > Does he care if it is a viewport or a desktop?
>
> The only reason a window manager would support both at the same time is
> precisely because there's a difference between the two: viewports have
> some "physical" meaning as a tiling of a larger desktop, whereas virtual
> desktops are disconnected. That's a good reason to make the difference
> visible in the pager too, and to show that the tiling is there for
> viewports.

however this doesn't make sense at all.

it does on a technical level. it does on a "if you wish to be pedantic or are 
a window manager weenie" level. but you know what? that's not our target 
audience. the % of people who use kde who care about this is vanishingly 
small and, more importantly, it's simply a bad, bad, bad idea.

it's like so many other choices made in the past in our UI: yes, we COULD do 
it, and because we COULD we DID never asking ourselves SHOULD we. what does 
multiple desktops per viewports (or vice versa) get one? nothing much except 
the possibility to make a very confusing system.

this is one reason (there are a few) i believe the compiz people have their 
heads screwed on backwards.

> > The funny thing is that the viewport
> > implementation in compiz doesn't actually allow to scroll the viewport by
> > an arbitrary amount - it only simulates a desktop tiled over it. The
> > major difference is that the context menu has an option "move to left
> > viewport, move to right viewport, move to above viewport, move to below
> > viewport". Does the cube plugin in compiz support desktops above and
> > below?
>
> That's the purpose of the "plane" plugin in compiz (in David Reveman
> cvs). When you click on a different viewport in the pager, you "fly" to
> this viewport. You expect to have the same "flight" on the screen as
> what you can see from the pager preview.

heh. i really do wonder if these people read much about HCI.

> > The more I think about it, the more I believe we should not bother the
> > user with this difference. does the user really care if he moved the
> > stuff to the desktop "above" or below?
>
> I think it's more important than it seems. Compiz success comes in part
> from the fact that it adds some visual consistency when switching
> viewports as sides of a cube or tiles of a large plane.

yes, this is a very nice and defensible feature. it doesn't mean that the user 
needs to know that there is a technical difference in presentation that 
results in the improvement. it should be transparent to the user, an 
implementation detail they are spared from having to grasp. because, in the 
end, it's an esoteric splitting of hairs between two (to the user) synonyms.

> > Does the user care about if he moved it to desktop 1, viewport 2 or
> > desktop 2 viewport 1? Why should he?
>
> If somebody starts to use this kind of feature from a window manager, I
> think that's because he cares...

irrelevant. the real question is: is he (or she) who we are writing our 
software for? does catering to his or her needs impact more people that it 
should?

if, and ONLY if, we can cater to such niche choices without measurably 
diminishing the experience for the larger part of our target audience then we 
can push forward with such things. otherwise, forget it. that road leads to a 
desktop that is good for nobody but which has a couple features that 
enthusiasts of $CONCEPT like.

if you talk to our users now, even those who we have mistakenly catered to in 
this way in the past will note the various things they don't like in kde. you 
can't win using this approach, and people really won't miss things like "a 
viewport and a desktop aren't the same".

> > The moment we switch to viewports as children of desktops, the user is
> > confused: the desktop labels are not applied to viewports, the
> > documentation is all wrong, there are a lot of configuration settings in
> > various applications to be duplicated (each desktop related setting has
> > to be duplicated into a viewport related setting).
>
> I agree with the problem with desktop labels.
> But I don't understand what you mean about the documentation and
> configuration settings. Can you give an example ?

we'd have to rewrite the documentation and make it considerably more complex. 
that's a canary in the mine. or at least should be.

configuration settings: we'd have to have multiple sets of interpretations of 
the settings behind the scenes and perhaps even duplication to the user. this 
means twisting winding code paths in the pager and taskbar (and possibly 
elsewhere) all to deliver a dubious "feature".

dirk is exactly right here.

-- 
Aaron J. Seigo
Undulate Your Wantonness
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20060921/fb35f0a1/attachment.pgp