[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: [Panel-devel] Pager extended for "viewports"
From: Timothée Lecomte <timothee.lecomte () ens ! fr>
Date: 2006-09-21 20:36:06
Message-ID: 4512F7B6.9010008 () ens ! fr
[Download RAW message or body]
Aaron J. Seigo wrote:
> On Thursday 21 September 2006 4:44, Timothée Lecomte wrote:
>
>
>>> 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.
>
lol
I'm not going to argue about compiz design decision, that's not my
problem (right now, it only has viewports).
Let's just precise that the idea of multiple large desktops is
implemented by fvwm:
http://www.fvwm.org/screenshots/desktops/Windows95-desk-1280x1024/screenshot.png
Anyway, let's come back to KDE.
I don't have a strong opinion between the two alternatives:
-One KMiniPagerButton per desktop
-One KMiniPagerButton per viewport: it's a little easier in terms of
implementation, more flexible in terms of space consumption in the panel
(it seems to be very important, a couple of users on compiz.net already
reported it). We lose the visual correspondance between the pager
miniature and what the user see when he switches its viewports, but it's
easily fixed by manually choosing the number of rows of the pager.
(When discussing with Dirk on #kde4-devel, we noticed that the specs
talk about viewport scrolling, where the viewport is not obliged to be
snapped on a grid. The desktop size is not even obliged to be a multiple
of the viewport size. However, this clearly falls into the category of
"window manager weenies" ;)
I conclude that Dirk idea is better. Let's do it with one
KMiniPagerButton per viewport.
But I suddenly have another idea: it seems that your point of view, Dirk
and Aaron, is that the user should not see the difference between
viewports and desktops. Why don't we go further and make so that all KDE
applications don't see the difference by modifying the underlying
libraries, kwin.h and kwinmodule.h ?
What I mean is that even after we will have fixed the pager, the taskbar
and kdesktop remain to be fixed. As said before, the taskbar should only
show tasks that are on the current viewport and kdesktop should be able
to recognize that we can put a different wallpaper on each viewport.
This could be easily done if we could abstract the difference between
viewports and desktops in KWinModule and KWin.
The current "desktop" index would be something like:
currentDesktop*number_of_viewports + currentViewport
and all the corresponding functions would be modified accordingly.
For example, the following have to be modified:
- KWinModule::numberOfDesktops() [would return
number_of_desktops*number_of_viewports]
- KWinModule::currentDesktop() [would return
currentDesktop*number_of_viewports + currentViewport]
- KWinModule::currentDesktopChanged() [would be signalled also on
viewport changes]
- KWinModule::numberOfDesktopsChanged() [would be signalled also on
desktopGeometry changes]
- ...
- KWin::setOnDesktop()
- KWin::setOnAllDesktops()
- KWin::setCurrentDesktop()
- ...
- KWin::WindowInfo::isOnDesktop()
- ...
That way, it would be transparent for the taskbar, for kdesktop, etc.
What do you think about that ?
Best regards,
Timothée
_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic