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

List:       kde-core-devel
Subject:    Re: KWin in the multi-OS API (was: KMainWindow)
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2006-11-16 19:32:09
Message-ID: 200611161232.09837.aseigo () kde ! org
[Download RAW message or body]


On Thursday 16 November 2006 11:22, Lubos Lunak wrote:
>  Actually the real reason for the KWin/KWinModule split is that KWin has
> only static's while you need an instance of KWinModule (and so it can track
> changes and so on). And the static's could simply move into KWinModule or
> whatever you call it.

yes, i understood that. from the perspective of someone who uses these 
classes, though, the semantic separation between "information on a 
window", "controlling aspects of a single window" and "information about all 
windows/desktops information" is really clear.

>  KDesktopInfo being current KWinModule, i.e. the class that also has signal
> windowChanged( id, how ) ?

yes.

> I myself don't see any need to separate it this 
> way, I think just having KWindowManager (or KDesktopManager or whatever)
> and its WindowInfo class should do.

and then we have a class that is used to both control aspects of a given 
window as well as get information on desktops and all windows, which is a 
quite a number of concepts in one class. i personally prefer classes with 
clear, singular purposes. *shrug*

i wonder what others think =)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)

[Attachment #3 (application/pgp-signature)]

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