Difference between revisions of "WxQt"

Revision as of 11:38, 11 September 2014

Getting started

Prerequisites

Currently, wxQT needs Qt 5 or later (recommended version is Qt 5.2.1). Other dependencies are needed depending on the features to be used (fo example cairo, opengl, jpg/tiff, etc.). For more information see docs/qt folder shipped with the source code, and/or Ubuntu / Android notes.

Building the Library

Note: "Google Summer of Code 2014" and previous wxQt branch was merged to master trunk!

Go to your development directory and download the source code zip archive or checkout the (current repository) with:

git clone https://github.com/wxWidgets/wxWidgets.git
cd wxWidgets

Now create the build directory e.g.: 'bldqt5' and from it call the configure script (using Qt option) and run make to start the compilation process:

mkdir bldqt5
cd bldqt5
../configure --with-qt --enable-debug
make

Building Samples, Tests and Demos

After successful build, you can go to the samples sub-directory, compile and run them, for example:

cd samples/controls
make
./controls

You can also try the tests and demos sub-directories.

Port status

Unit Tests results

Pass	Fail	Error	Total
378	155	18	551
68%	28%	4%	100%
Status: experimental

Completion

A table attempting to summarize progress in the port can be found at WxQt/Status.

Summary of features running (see bellow caveats and known issues):

Application, event loop (limited), FD/Socket monitoring, etc.
Most core controls: wxButton, wxBitmapButton, wxToggleButton, wxChoice, wxComboBox, wxTextCtrl, wxStaticText, wxStaticBox, wxStaticBitmap, wxRadioBox, wxCheckBox, wxGauge, wxSlider, wxSpinCtrl, wxNotebook, etc.
Some advanced controls: wxCalendar, wxListCtrl, wxTreeCtrl, wxGrid.
Top Level Windows: wxFrame (wxMenuBar, wxStatusBar, wxToolBar), wxDialog and common dialogs and wizards
AUI (limited)
Cairo graphic renderer (limited, not using cairo qt surface)
OpenGL (limited, some drawing issues)

General interface is almost 100% complete, at least for wxPython, as it compiles all classes (701 SIP cpp files, except wxHTML2 that is not implemented). See Phoenix notes for more information.

Known Open Issues

Although simple apps works, there are some problems that will affect more complex applications in the near term:

Complex painting is failing "mysteriously" in some situations (see clipping problems notes). Also, still there are many Qt warning about QPainter used incorrectly (most of them should not happen, there could be wrong logic about scroll areas or center widget where Qt painting is not direct / orthogonal to wx use cases). wxRichTextCtrl is the leading case here.
Mouse capture seems not to be working correctly, and that may be causing some issues in controls like wxHTMLWindow, wxHyperlinkCtrl, AUI, etc. There seems that some semantics are very different between wxWidgets and Qt about mouse movements events (see mouseTracking QWidget attribute). It is somewhat strange as some other samples relating mouse work (for example, MDI tiny doodling).
Nested Event Loop implementation is not optimal, as it is doing some kind of busy waiting. It could be enhanced with QEventLoop but didn't work, in fact it get worse: for example, the app no longer exits and some dialogs get blocked, test_gui never ends anymore, etc. Maybe the event loop could be refactorized with QAbstractEventDispatcher to join more tightly both wx and Qt event queues (the docs says there is an example for motif). NOTE that this doesn't affect main application event loop nor modal dialogs, only wxExecute.

Also, there are still some important features like webview (webkit), printing, drag and drop, data view control, native renderer, etc. that aren't implementated. Many of them should be easily achievable (at least webkit, following wxGTK work).

Developers

Developers can be contacted on the developer mailing list (not everyone could be active by now):

Mariano Reingart (GSoC 2014 developer)
Sean D'Epagnier (2014 contributor)
Javier Torres (GSoC 2010 developer)
Kolya Kosenko (2010, calendar and other contributions)
Peter Most (original developer)

@@ Line 1: / Line 1: @@
-== Adding files ==
+== Getting started ==
-To add a Qt derived class simply put it in a .h file and add the corresponding .moc.cpp file to the buid/bakefiles/files.bkl e.g.:
+=== Prerequisites ===
-<source>
+Currently, wxQT needs Qt 5 or later (recommended version is Qt 5.2.1).
-<set var="QT_LOWLEVEL_HDR" hints="files">
+Other dependencies are needed depending on the features to be used (fo example cairo, opengl, jpg/tiff, etc.).
-    wx/qt/menuitem.h
+For more information see docs/qt folder shipped with the source code, and/or [https://github.com/reingart/wxWidgets/wiki/WxQtUbuntuNotes Ubuntu] / [https://github.com/reingart/wxWidgets/wiki/WxQtAndroidNotes Android] notes.
-</set>
+=== Building the Library ===
-<set var="QT_LOWLEVEL_SRC" hints="files">
+'''Note''': "Google Summer of Code 2014" and previous wxQt branch was merged to master trunk!
-    src/qt/menuitem.cpp
-    src/qt/menuitem.moc.cpp
-</set>
-</source>
-The build rule in build/bakefiles/qtrules.mk:
+Go to your development directory and download the source code [https://github.com/reingart/wxWidgets/archive/master.zip zip archive] or checkout the ([https://github.com/wxWidgets/wxWidgets current repository]) with:
 <source>
-$(srcdir)/src/qt/%.moc.cpp: $(srcdir)/include/wx/qt/%.h
+git clone https://github.com/wxWidgets/wxWidgets.git
-	moc $< -o $@
+cd wxWidgets
 </source>
-will then ensure that the .h file gets translated by the moc to a .moc.cpp file which will be compiled and linked like any other source file. You don't have to put it in a separate .h file, you can put it in the same header as the wx class, but you can't embed it in the .cpp file i.e.:
+Now create the build directory e.g.: 'bldqt5' and from it call the configure script (using Qt option) and run make to start the compilation process:
 <source>
-// include/wx/qt/menuitem.h
+mkdir bldqt5
+cd bldqt5
+../configure --with-qt --enable-debug
+make
+</source>
-class wxMenuItem : public wxMenuItemBase
+=== Building Samples, Tests and Demos ===
-{
-   // ...
-};
+After successful build, you can go to the samples sub-directory, compile and run them, for example:
+<source>
+cd samples/controls
+make
+./controls
+</source>
+You can also try the tests and demos sub-directories.
-class wxQtAction : public QAction
+== Port status ==
-{
-    Q_OBJECT
-public:
+=== Unit Tests results ===
-    wxQtAction( wxMenuItem *menuItem, const QString &text, QObject *parent );
-private Q_SLOTS:
+{| style="border: 1px solid #CCCCCC; background:#F9F9F9; border-collapse:collapse; text-align:center;" cellspacing="0" cellpadding="2px" border = "1" align="center"
-    void OnActionTriggered( bool checked );
+|-
+!Pass
+!Fail
+!Error
+!Total
+|-
+|style="color:green"|378
+|style="color:red"|155
+|style="color:red"|18
+|551
+|-
+|style="color:green"|68%
+|style="color:red"|28%
+|style="color:red"|4%
+|100%
+|-
+|colspan="4" | Status: <font color="orange">'''experimental'''</font>
+|-
+|}
-private:
+=== Completion ===
-    wxMenuItem *m_menuItem;
-};
-</source>
-== Coding guidelines ==
+A table attempting to summarize progress in the port can be found at [[WxQt/Status]].
-* If you leave out an implementation for whatever reason, then mark it with the wxMISSING_IMPLEMENTATION() macro from wx/qt/utils.h i.e.:
+Summary of features running (see bellow caveats and known issues):
-<source>
+* Application, event loop (limited), FD/Socket monitoring, etc.
-void wxSomeClass::SomeMethod()
+* Most core controls: wxButton, wxBitmapButton, wxToggleButton, wxChoice, wxComboBox, wxTextCtrl, wxStaticText, wxStaticBox, wxStaticBitmap, wxRadioBox, wxCheckBox, wxGauge, wxSlider, wxSpinCtrl, wxNotebook, etc.
-{
+* Some advanced controls: wxCalendar, wxListCtrl, wxTreeCtrl, wxGrid.
-    wxMISSING_IMPLEMENTATION( __FUNCTION__ );
+* Top Level Windows: wxFrame (wxMenuBar, wxStatusBar, wxToolBar), wxDialog and common dialogs and wizards
-}
+* AUI (limited)
-</source>
+* Cairo graphic renderer (limited, not using cairo qt surface)
+* OpenGL (limited, some drawing issues)
-or if only some implementation is missing like evaluating flags:
+General interface is almost 100% complete, at least for wxPython, as it compiles all classes (701 SIP cpp files, except wxHTML2 that is not implemented). See [https://github.com/reingart/wxWidgets/wiki/wxPythonQtPhoenixNotes Phoenix] notes for more information.
-<source>
+=== Known Open Issues ===
-void wxSomeClass::SomeMethod( unsigned methodFlags )
-{
-    wxMISSING_IMPLEMENTATION( "methodFlags" );
-}
-</source>
-* To avoid name clashes with a 3rd party library like boost, don't use the internal moc keywords 'signals' and 'slots' but the replacements Q_SLOTS and Q_SIGNALS i.e.:
+Although simple apps works, there are some problems that will affect more complex applications in the near term:
-<source>
+* Complex painting is failing "mysteriously" in some situations (see [https://github.com/reingart/wxWidgets/wiki/WxQtClippingProblems clipping problems] notes). Also, still there are many Qt warning about QPainter used incorrectly (most of them should not happen, there could be wrong logic about scroll areas or center widget where Qt painting is not direct / orthogonal to wx use cases). wxRichTextCtrl is the leading case here.
-class wxQtClass : public QClass
+* Mouse capture seems not to be working correctly, and that may be causing some issues in controls like wxHTMLWindow, wxHyperlinkCtrl, AUI, etc. There seems that some semantics are very different between wxWidgets and Qt about mouse movements events (see mouseTracking QWidget attribute). It is somewhat strange as some other samples relating mouse work (for example, MDI tiny doodling).
-{
+* Nested Event Loop implementation is not optimal, as it is doing some kind of busy waiting. It could be enhanced with QEventLoop but didn't work, in fact it get worse: for example, the app no longer exits and some dialogs get blocked, test_gui never ends anymore, etc. Maybe the event loop could be refactorized with QAbstractEventDispatcher to join more tightly both wx and Qt event queues (the docs says there is an example for motif). NOTE that this doesn't affect main application event loop nor modal dialogs, only wxExecute.
-private Q_SLOTS:
-    void OnSignal();
-};
-</source>
-* Naming conventions:
+Also, there are still some important features like  webview (webkit), printing, drag and drop, data view control, native renderer, etc. that aren't implementated. Many of them should be easily achievable (at least webkit, following wxGTK work).
-** Global helper classes and global functions should start with the 'wxQt' prefix like wxQtButton or wxQtConvertRect().
-** Internal methods should start with the 'Qt' prefix like QtHandlePaintEvent
-If you would like to discuss this 'guidelines' then you can contact me (Peter Most) on the developer mailing list.
+=== Developers ===
+Developers can be contacted on the developer mailing list (not everyone could be active by now):
+* Mariano Reingart (GSoC 2014 developer)
+* Sean D'Epagnier (2014 contributor)
+* Javier Torres (GSoC 2010 developer)
+* Kolya Kosenko (2010, calendar and other contributions)
+* Peter Most (original developer)