KWin in the multi-OS API (was: KMainWindow)
l.lunak at suse.cz
Thu Nov 16 18:22:50 GMT 2006
On Wednesday 15 November 2006 22:45, Aaron J. Seigo wrote:
> On Wednesday 15 November 2006 4:08, Lubos Lunak wrote:
> > There's also a TODO about moving all the functionality from KWin to
> > KWinModule (I hate using KWinInternal in KWin the app). I'm fine with
> > calling the result KWMModule, KWM (gee :) ) or whatever suitable.
> as a user of these classes, i've come to think of it this way:
> - KWinModule is about "whole desktop" information as it provides
> information about window stacking, virtual desktops, etc...
> - KWin is about managing individual windows and their state
> - KWinInfo is to query information about individual windows
> there are a few places in KWin where this breaks: currentDesktop(),
> numberOfDesktops(), setCurrentDeskto() and invokeContextHelp() ... but
> generally it's pretty consistent.
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.
> would it make sense then to reorganize these classes into four parts:
> with the above methods currently in KWin moving to KDesktopInfo? this
> leaves two setters (setCurrentDesktop and setDesktopName) in KDesktopInfo
> making it not strictly informational. one could make a tiny KDesktopManager
> class with those things in it, bringing the total to four classes?
KDesktopInfo being current KWinModule, i.e. the class that also has signal
windowChanged( id, how ) ? 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.
SUSE LINUX, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12 tel: +420 284 028 972
190 00 Prague 9 fax: +420 284 028 951
Czech Republic http//www.suse.cz
More information about the kde-core-devel