[Kstars-devel] Qt4 porting

[Jason Harris]

Hello,

This thread is for preliminary discussion of the impending Qt4 port of KStars.

0.  When is this happening?
See "SVN: 3.5 development branch" thread.  Short answer, it's up to us, but 
"soon".

1.  How can I help with the port?  
I'm prepared to do it myself, but if others want to help, you are most 
welcome.  In that case, we should use this thread to figure out some kind of 
plan for dividing up the work.

2.  What needs to be done?
See Trolltech's porting guide:
http://doc.trolltech.com/4.0/porting4.html

(is there a KDE porting guide?)

Notes:
- the qt3to4 porting tool merely replaces Qt3 classes with their 
"compatibility" counterparts, such as "QListBox" -> "Q3ListBox", so it 
probably won't be too useful (other than putting the codebase in a 
compileable "proto-port" state from which incremental changes can be made).

- QPtrList and QValueList are going away, replaced by QList<T> or 
QLinkedList<T> (where "T" can be a pointer).  QList uses an array-like index 
(using the "[]" operator) for fast random access.  QLinkedList uses an 
iterator-based accessor.

- There is no "setAutoDelete()" for QList, so we'll need to delete list 
pointers in class destructors.

- All painting must now be done within a paintEvent() (or functions called 
therein).  I don't think this will be an issue for us.

- QPainter now supports antialiased graphics natively!

- #include syntax changing to "#include <QWidget>"

- (for now?) the KDE4 branch must be built with "unsermake", which I've 
personallly never used.  Anyone know of a HOWTO document?

- Please feel free to add more items...

3. Can "normal" development proceed while the port is happening?
All changes made to the 3.5 branch need to be ported to trunk (the 4.0 
branch).  As work in trunk progresses, such ports will probably become 
increasingy difficult.

4. What is the plan?
Here's my current idea about the rough priority of tasks:

A. The classes in libkdeedu (ExtDate and friends, and KPlot[Widget|Object].  
ExtDate et al. will be the most difficult, since they are heavily rewritten 
versions of Qt3 classes (QDate et al.).  QDate in Qt4 is stil only valid over 
years 1752-8000, so it looks like this rewriting needs to be done all over 
again...maybe it will be possible to subclass from QDate, that might make the 
job easier.

B. data classes such as dms, SkyPoint and its many children, GeoLocation, etc.  
These are generally independent of Qt, so should be easy to port.

C. KStarsData and KStars.  The central nervous system of KStars. 

D. SkyMap.  All of the fun drawing stuff (I'm including the draw methods found 
in some of the data classes here).

E. KSPopupMenu, InfoBoxes, and major Dialogs.

F.  the "tools" subdirectory.

G. the "indi" subdirectory.

One thing we should discuss is whether we should develop alongside the port, 
or try to do a straight port first.  Doing concurrent development might make 
things messy.  However, some changes will surely be unavoidable.  And if we 
see a better way to do something, we should go ahead and change it, IMO.  
Still, we'll want to proceed with caution.

Okay, that's all I have.  Open for discussion!

Jason
-- 
KStars: KDE Planetarium
http://edu.kde.org/kstars