[Kstars-devel] KDE/kdeedu/kstars/kstars

[Jason Harris]

SVN commit 485517 by harris:

DetailDialog now compiles.  I've got custom widgets 
working in designer, without needing a plugin library. 
Also, using UI files is a bit more complicated than 
under Qt3 (see below for explanation).  

I also moved the "SkyPoint::constellation(csegmentList, 
cnameList)" function to 
"SkyMapComposite::constellation(SkyPoint*)".  This 
function returns the name of the constellation containing
a given SkyPoint.

-----------------------------------------------
How to use Qt4 Designer:

We don't need to create a plugin library for our custom 
widgets after all; I figured out how to make the 
"promote widget" feature work:

Just add a widget of the custom widget's base class, then 
right-click on it and select "Promote to custom widget" 
from the menu.  This opens a dialog where you can name the 
widget and specify the name of the header file.  It will 
guess the header file name from the widget name, but you 
can correct the header file if necessary (for example, many
of our custom widgets are now in a "widgets" subdirectory, 
so I usually had to prepend "widgets/" to the header file 
name).  If it complains that a class with that name already 
exists, it may be getting interference from another UI file, 
even if that file is not opened anymore.  Just restart 
designer, and open only the UI that you are working on, then 
try to promote it again.  Note that there doesn't seem to be 
a way to edit the promoted-widget data once you close this 
dialog (although you can "demote" it and then promote it 
again).

Using UI classes in the program works a bit differently under 
Qt4.  There's no need to append "UI" to the classname as we 
used to do, because it automatically puts the classes in a 
"Ui" namespace.  Also, under Qt4 we can't just create an 
instance of the widget defined in the UI file, we have to 
define a class that inherits from both QWidget (or QFrame) 
and the class defined by the UI file.

For example, the file details_data.ui defines the "General" 
Tab of the Object Details window.  When uic is run on this 
file, it creates details_data.h, which defines a class named 
Ui::DetailsData.  To use this class in the program, I declare
a class in detaildialog.h named "DataWidget" that inherits 
from QFrame and Ui::DetailsData:

class DataWidget : public QFrame, public Ui::DetailsData {
  Q_OBJECT
  public: 
    DataWidget( QWidget *parent=0 );
};

In detailsdialog.cpp, I define the ctor, which *must* call 
the function Ui::DetailsData::setupUi() (which populates 
the widget with all of its children).

Once that is done, you can instantiate an object of type 
DataWidget:

  Data = new DataWidget( DataTab );

Then you can use that object in the program.  As long as 
you inherited from the Ui class using "public", you'll be 
able to directly access all of the UI elements.  If you 
used "private", you'd have to handle all UI interactions 
inside the DataWidget class, or provide accessor functions.

--------------------------------------------
CCMAIL: kstars-devel at kde.org



 M  +392 -366  addcatdialogui.ui  
 M  +186 -152  addlinkdialogui.ui  
 M  +442 -432  ccdpreviewui.ui  
 M  +86 -126   contrastbrightnessgui.ui  
 M  +132 -174  detaildialog.cpp  
 M  +47 -46    detaildialog.h  
 M  +416 -599  details_data.ui  
 M  +58 -55    details_database.ui  
 M  +202 -188  details_links.ui  
 M  +63 -80    details_log.ui  
 M  +754 -920  details_position.ui  
 M  +251 -4    skycomponents/skymapcomposite.cpp  
 M  +6 -0      skycomponents/skymapcomposite.h  
 M  +247 -246  skypoint.cpp  
 M  +18 -16    widgets/Makefile.am  
 A             widgets/clicklabel.cpp   [License: GPL (v2+)]
 A             widgets/clicklabel.h   [License: GPL (v2+)]
 A             widgets/logedit.cpp   [License: GPL (v2+)]
 A             widgets/logedit.h   [License: GPL (v2+)]