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

List:       kde-devel
Subject:    Re: KDE vs. QT classes: overlaps and choosing
From:       Frank Osterfeld <frank.osterfeld () gmx ! de>
Date:       2006-08-26 17:32:24
Message-ID: 200608261932.30317.frank.osterfeld () gmx ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 26 August 2006 18:47, Jerry Blanco wrote:

> So, the questions:
> a) Is it even possible to write a KDE application without using KDE
> classes? Is it advisable? (probably not, right?) Is it a good idea at all?

It's not possible to write a KDE application without using KDE classes, but 
you can of course restrict yourself to Qt if you want. Then you don't have a 
fullfledged KDE application, but at least a Qt application running reasonably 
well under KDE (or any other desktop enviroment). That can make sense if you 
want to support other platforms like OSX or Windows and don't want to wait 
for KDE4 where these platforms are supposed to be supported. On the other 
hand, it won't integrate so smoothly into the desktop like a KDE application 
would. 
If you want to keep it flexible, you can separate backend and frontend and 
make the backend use only Qt (or even STL only). Then you can provide 
different frontends if necessary.

> b) If you want to use a hybrid approach, how do you decide if you're using
> a KDE or QT class in a specific instance? For example, how do you decide
> between QApplication and KApplication or KPushButton and QPushButton? Are
> they 100% compatible, in general? Does it matter if I use the K or Q class?

In most (all?) cases, the KFoo class extends the QFoo class. Usually it adds 
functionality needed in KDE or make it respect special KDE settings. So if 
you decide to write a KDE application, don't do it half-assed and use the KDE 
classes where available.
The KDE apidocs usually contain a little inheritance diagram where you can see 
the relation between Qt and KDE applications.
They are compatible like class<-subclasses usually are: If you have a 
KLineEdit extending QLineEdit, you can pass it everywhere where a QLineEdit 
is expected. The other way round that of course doesn't work.

Frank

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

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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