[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: [Kwin] Extended desktop enhancements
From:       Lubos Lunak <l.lunak () sh ! cvut ! cz>
Date:       2002-07-05 18:55:13
[Download RAW message or body]

On Friday 05 July 2002 13:56, David Boddie wrote:
> On Thursday 04 Jul 2002 10:59 pm, Cristian Tibirna wrote:
> > On Thursday, 04 July 2002 16:30, Lubos Lunak wrote:
> > > And I personally don't find it to be much different or more useful
> > > when compared to virtual desktops.
> >
> > I believe this was the opinion of Matthias Ettrich when he first designed
> > Kwm then Kwin. Viewports concept has the unpleasant property of
> > introducing confusion. And many things will play bad with it. E.g.
> > placement. If a virtual desktop of 200% of the actual screensize is used,
> > 50% of newly appearing windows will be placed outside the current
> > viewport. Virtual desktops made sense with twm, which only had manual
> > placement in the ancient time (I believe).

 No no, you misunderstood viewports. In fact moving the viewport is just 
moving the windows in opposite direction, and there's not really any such 
larger thing, the viewport is just virtual.

>
> With the system I have implemented, the desktop is still regarded as
> having the same dimensions as the display when windows are placed.
> For example, I may scroll to an empty part of the desktop then open a
> new Konqueror window using the panel, and the window opens on the
> screen as normal, using whatever placement scheme is in effect.
>
> > And anyways, there's another point. Why the heck write a load of code in
> > order to duplicate a feature that is already available in the Xserver?
> > Just use the appropriate VirtualSize in the "Display" section and you're
> > done. Granted, an appropriate video card memory is necessary, but the
> > upturn of this is that the whole thing is _much_ faster than anything we
> > can achieve with simulation in kwin (it's _hardware_ driven).
>
> I'm afraid that I'm guilty of not investigating that route in any detail.
> I did discuss it with a colleague, but we decided that it might be better
> to try a method that doesn't rely on the hardware supporting particular
> X server features.

 It doesn't require any special support. The VirtualSize feature and viewport 
are a bit different. VirtualSize is simply a higher resolution than the 
monitor has, and the monitor is a "peekhole" at it. Everything moves. With 
viewports, this is a bit different, e.g. the panel stays where it is (and I 
really hated to see it moving when I tried VirtualSize).

>
> We also thought that the user should be able to switch the new features
> on and off, so that users don't notice that these extras are available
> if they don't want them. Does XFree allow the VirtualSize to be
> changed without requiring a restart?
>
> If the X server's VirtualSize is larger than the display size, do
> windows like the Panel always remain visible to the user?
>
> > Is DCOP control of such a feature so important? If yes, isn't it possible
> > to just add a DCOP interface on top of controling Xserver virtual
> > desktops via mouse pointer position (or something)?
>
> I've added ways of scrolling other than via the electric borders, which
> were the last method to be added.
>
> Key bindings can be used to scroll the screen in either screen sized or
> arbitrary steps; these don't need DCOP methods, obviously.
>
> If control of the viewport via pagers can be done effectively via the
> NET or KWin classes, then the viewport-related DCOP methods would be
> obselete.

 I think the only really needed things are NET_VIRTUAL_ROOTS and 
_NET_DESKTOP_VIEWPORT - one for knowing the position in the viewport, the 
other one for moving it. Viewports are IMHO only a WM and pager things, 
nobody else should know or care.

>
> I notice that KPager uses Xlib's XMoveWindow function, so the DCOP
> methods for moving windows can be removed.
>
> > >  Opinions?
> >
> > I'd really like to hear Matthias Ettrich on this one. Kwin is his own
> > baby and I seem to know he has a strong opinion on the large viewports
> > concept.
>
> I'd like to know what he thinks, too. If he's against it, then it would
> be good to know sooner rather than later.
>
> David

>>>  Those two marked (*) would go away if this was modified to implement 
>>>NETWM
>>> viewports.

> Can you direct me to a good example window manager which implements these?

 I don't know if there are any WM implementing NETWM viewports. I think GNOME1 
had viewports (but those weren't NETWM compliant).
>
> As far as I can see, the main difference between the usual viewport model
> and this approach is the wraparound feature.

 Well, all I know about viewports is from reading the NETWM spec and your 
patches, but I think yes.


-- 
 Lubos Lunak
 l.lunak@email.cz ; l.lunak@kde.org
 http://dforce.sh.cvut.cz/~seli



_______________________________________________
Kwin mailing list
Kwin@mail.kde.org
http://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]