KWin in the multi-OS API (was: KMainWindow)

[Aaron J. Seigo]

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061116/fc636648/attachment.sig>