wxQT port merge [GSOC 2014]
126 views
Skip to first unread message
Mariano Reingart
May 24, 2014, 1:37:31 PM5/24/14
to wx-dev
FYI
wxQT (2.9.2) is finally merged against latest master trunk (3.1.0) and running (at least minimal sample with controls: wxStaticText, wxTextCtrl, wxButton, wxBoxSizer and wxCommandEvent).
To complete this milestone, I will remove old code and update it to the latest wx standards, so any advice is welcomed (see bellow)
Attached screenshot of the minimal sample (modified):
Commit history (SOC2014_QT branch):
Important: GitHub only show the first 115 changed files, but there were 7435 files changed just in the merge, and more than a hundred in subsequent commits. See the pages bellow for more detailed notes.
Some wiki notes about the process:
I think this first planned milestone is near to be completed, the remaining open issue is "update to wx standars":
Please fell free to add comments or more issues
Best regards,
Vadim Zeitlin
May 25, 2014, 12:29:46 PM5/25/14
to wx-...@googlegroups.com
On Sat, 24 May 2014 14:37:09 -0300 Mariano Reingart wrote:
MR> wxQT (2.9.2) is finally merged against latest master trunk (3.1.0) and
MR> running (at least minimal sample with controls: wxStaticText,
MR> wxTextCtrl, wxButton, wxBoxSizer and wxCommandEvent).
Very nice, congratulations! This was indeed a very important first step
and I'm glad you've already managed to finish it.
Do we have a list of things missing from wxQt at this point?
Thanks,
VZ
MR> wxQT (2.9.2) is finally merged against latest master trunk (3.1.0) and
MR> running (at least minimal sample with controls: wxStaticText,
MR> wxTextCtrl, wxButton, wxBoxSizer and wxCommandEvent).
Very nice, congratulations! This was indeed a very important first step
and I'm glad you've already managed to finish it.
Do we have a list of things missing from wxQt at this point?
Thanks,
VZ
Mariano Reingart
May 25, 2014, 2:07:42 PM5/25/14
to wx-dev
On Sun, May 25, 2014 at 1:29 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
On Sat, 24 May 2014 14:37:09 -0300 Mariano Reingart wrote:
MR> wxQT (2.9.2) is finally merged against latest master trunk (3.1.0) and
MR> running (at least minimal sample with controls: wxStaticText,
MR> wxTextCtrl, wxButton, wxBoxSizer and wxCommandEvent).
Very nice, congratulations! This was indeed a very important first step
and I'm glad you've already managed to finish it.
Thanks, indeed I think it was a good exercise to warm-up and get a better knowledge of wxWidgets internals.
Do we have a list of things missing from wxQt at this point?
http://wiki.wxwidgets.org/WxQt/Status
In the next weeks I'm planing to work in basic features and controls:
https://github.com/reingart/wxWidgets/issues/13 (suggested by you)
I don't want to add too much here as the mid-term evaluation is a month away and I wish to have something concrete to show (controls sample).
Vadim Zeitlin
Jun 1, 2014, 6:54:49 PM6/1/14
to wx-...@googlegroups.com
Hello Mariano,
I'd like to ask how are things going for you as we haven't seen your
weekly report yet and I haven't seen that many commits in your repository
neither recently. wxOVERRIDE addition aside (which is definitely nice but
hardly critical), what are you working on now? We have only 3 weeks left
until the mid-term evaluation and I'd really like to see progress on the
important issues such as #4 and #5 (as I've just commented, #6 is much less
important).
TIA,
VZ
I'd like to ask how are things going for you as we haven't seen your
weekly report yet and I haven't seen that many commits in your repository
neither recently. wxOVERRIDE addition aside (which is definitely nice but
hardly critical), what are you working on now? We have only 3 weeks left
until the mid-term evaluation and I'd really like to see progress on the
important issues such as #4 and #5 (as I've just commented, #6 is much less
important).
TIA,
VZ
Mariano Reingart
Jun 3, 2014, 7:27:24 PM6/3/14
to wx-dev
Yes, sorry, I just read this mail, I couldn't work on it this weekend due personal commitments, but I finished them to be able to focus on the gsoc again.
I didn't commited too much as clang-modernize didn't worked correctly and it made incomplete modifications, so I'll skip that and move on.
I did a second merge today without any conflict nor issue, and I cleaned up the wxQT code previuosly.
In the meanwile, to ensure I didn't broke other ports, I run tests for wxGTK (they pass ok as for master, I'd to fix some minor issues introduced in the merge).
Today I closed the first milestone and will work on the second one (the issues you mention, specially #4: add/fix critical missing controls).
Mariano Reingart
Jun 4, 2014, 5:02:40 AM6/4/14
to wx-dev
Hello Vadim:
I've made progress with the wxNotebook control for wxQT fixinig some issues and implementing image (icon) support and events.
For the signal connection, I've created a helper class wxQtTabWidget, similar to the others already implemented like wxQtPushButton, but instead of the old syntax (SIGNAL / SLOT), I've used new Qt5 syntax QObject member.
I think this is a better way as it doesn't requires the moc precompilation step nor separate files (_qt.moc.cpp and .h not needed)
This implementation is simpler as the notebook has only one custom event, but I'll have to investigate how to merge with wxQtEventSignalHandler if you agree this form is ok.
More info at:
https://github.com/reingart/wxWidgets/issues/4 (critical controls)
https://github.com/reingart/wxWidgets/issues/6 (controls sample)
I'd taken some screenshots and made some comments there.
As allways, any advice is welcomed
Best regards
Vadim Zeitlin
Jun 4, 2014, 5:48:50 PM6/4/14
to wx-...@googlegroups.com
On Wed, 4 Jun 2014 06:02:17 -0300 Mariano Reingart wrote:
MR> I've made progress with the wxNotebook control for wxQT fixinig some issues
MR> and implementing image (icon) support and events.
Good news! wxNotebook is useful on its own, but it's also an example of a
relatively complex control, so it's encouraging to see that you didn't have
any particular problems with it.
MR> For the signal connection, I've created a helper class wxQtTabWidget,
MR> similar to the others already implemented like wxQtPushButton, but instead
MR> of the old syntax (SIGNAL / SLOT), I've used new Qt5 syntax QObject member.
MR>
MR> I think this is a better way as it doesn't requires the moc precompilation
MR> step nor separate files (_qt.moc.cpp and .h not needed)
MR>
MR> https://github.com/reingart/wxWidgets/commit/ef2a4515515a46bbd944b79a3843466e05404bac
Yes, definitely better.
MR> This implementation is simpler as the notebook has only one custom event,
MR> but I'll have to investigate how to merge with wxQtEventSignalHandler if
MR> you agree this form is ok.
I don't know much about wxQtEventSignalHandler but if we can avoid using
moc, it would be really great.
MR> More info at:
MR>
MR> https://github.com/reingart/wxWidgets/issues/4 (critical controls)
MR>
MR> https://github.com/reingart/wxWidgets/issues/6 (controls sample)
MR>
MR> I'd taken some screenshots and made some comments there.
MR>
MR> As allways, any advice is welcomed
I've left some, mostly trivial, comments there, but I think you already
received notifications for them, haven't you?
Once again, good work!
VZ
MR> I've made progress with the wxNotebook control for wxQT fixinig some issues
MR> and implementing image (icon) support and events.
Good news! wxNotebook is useful on its own, but it's also an example of a
relatively complex control, so it's encouraging to see that you didn't have
any particular problems with it.
MR> For the signal connection, I've created a helper class wxQtTabWidget,
MR> similar to the others already implemented like wxQtPushButton, but instead
MR> of the old syntax (SIGNAL / SLOT), I've used new Qt5 syntax QObject member.
MR>
MR> I think this is a better way as it doesn't requires the moc precompilation
MR> step nor separate files (_qt.moc.cpp and .h not needed)
MR>
MR> https://github.com/reingart/wxWidgets/commit/ef2a4515515a46bbd944b79a3843466e05404bac
Yes, definitely better.
MR> This implementation is simpler as the notebook has only one custom event,
MR> but I'll have to investigate how to merge with wxQtEventSignalHandler if
MR> you agree this form is ok.
I don't know much about wxQtEventSignalHandler but if we can avoid using
moc, it would be really great.
MR> More info at:
MR>
MR> https://github.com/reingart/wxWidgets/issues/4 (critical controls)
MR>
MR> https://github.com/reingart/wxWidgets/issues/6 (controls sample)
MR>
MR> I'd taken some screenshots and made some comments there.
MR>
MR> As allways, any advice is welcomed
I've left some, mostly trivial, comments there, but I think you already
received notifications for them, haven't you?
Once again, good work!
VZ
Mariano Reingart
Jun 6, 2014, 5:34:02 AM6/6/14
to wx-dev
On Wed, Jun 4, 2014 at 6:48 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
On Wed, 4 Jun 2014 06:02:17 -0300 Mariano Reingart wrote:
MR> I've made progress with the wxNotebook control for wxQT fixinig some issues
MR> and implementing image (icon) support and events.
Good news! wxNotebook is useful on its own, but it's also an example of a
relatively complex control, so it's encouraging to see that you didn't have
any particular problems with it.
Yes, so far I could advance without major issues, most times I read wxGTK and other ports, and then apply a similar implementation to wxQT.
I've also started to debug and navigate the code more fluently.
I hope that no new complications arise in the coming weeks.
BTW, I've fixed two issues that caused Controls sample to not work properly: sizing event not triggered in wxWindow::Show() and GetBestSize() problem due qt's sizeHint() (detailed info in the issue #6)
MR> For the signal connection, I've created a helper class wxQtTabWidget,
MR> similar to the others already implemented like wxQtPushButton, but instead
MR> of the old syntax (SIGNAL / SLOT), I've used new Qt5 syntax QObject member.
MR>
MR> I think this is a better way as it doesn't requires the moc precompilation
MR> step nor separate files (_qt.moc.cpp and .h not needed)
MR>
MR> https://github.com/reingart/wxWidgets/commit/ef2a4515515a46bbd944b79a3843466e05404bac
Yes, definitely better.
Ok, I'll try to implement new controls this way, and then if I have enough time I could remove moc files at all (maybe in last milestone after the mid-term evaluation). See bellow...
MR> This implementation is simpler as the notebook has only one custom event,
MR> but I'll have to investigate how to merge with wxQtEventSignalHandler if
MR> you agree this form is ok.
I don't know much about wxQtEventSignalHandler but if we can avoid using
moc, it would be really great.
AFAIK wxQtEventSignalHandler is a helper template class that reimplements events (just methods, as they are different than signals in qt!). It is used mainly in *_qt.moc.cpp files to connect signals/slots.
From the wxWidgets side it just has a EmitEvent method to bridge to Qt Events and Signals.
As the helper instances derives from QWidget (QObject), I don't see any problem in advance with the new Qt signal connection syntax.
Just to be sure it is possible, I did an experiment with the notebook control (wxQT_no_moc_experimental branch):
It compiles but it doesn't link:
reingart@s5ultra:~/src/wxWidgets/bldqt5/samples/controls$ LANG=C make
g++ -o controls controls_controls.o -L/home/reingart/src/wxWidgets/bldqt5/lib -Wl,-rpath,/home/reingart/src/wxWidgets/bldqt5/lib -pthread -lwx_qtu_core-3.1 -lwx_baseu-3.1 -lQt5Widgets -lQt5Gui -lQt5Test -lQt5Core -lSM -lpng -lz -ljpeg -ltiff -lwxregexu-3.1 -pthread -Wl,--version-script,/home/reingart/src/wxWidgets/bldqt5/version-script -lz -ldl -lm -lQt5Gui -lQt5Test -lQt5Core -lz -ldl -lm -lQt5Gui -lQt5Test -lQt5Core
/home/reingart/src/wxWidgets/bldqt5/lib/libwx_qtu_core-3.1.so: undefined reference to `vtable for wxQtTabWidget'
collect2: error: ld returned 1 exit status
make: *** [controls] Error 1
I cannot figure out what I'm missing...
Could you give me any advice here?
I don't know if it lacks some macro or method implementation (or something else more advanced in C++)
MR> More info at:
MR>
MR> https://github.com/reingart/wxWidgets/issues/4 (critical controls)
MR>
MR> https://github.com/reingart/wxWidgets/issues/6 (controls sample)
MR>
MR> I'd taken some screenshots and made some comments there.
MR>
MR> As allways, any advice is welcomed
I've left some, mostly trivial, comments there, but I think you already
received notifications for them, haven't you?
Yes, I did receive the notifications via email, and I have answered in the commit comments too.
Once again, good work!
Thanks! and sorry for the delays
Let me know if you have any doubt,
Best regards,
Vadim Zeitlin
Jun 6, 2014, 8:41:38 AM6/6/14
to wx-...@googlegroups.com
On Fri, 6 Jun 2014 06:33:40 -0300 Mariano Reingart wrote:
MR> BTW, I've fixed two issues that caused Controls sample to not work
MR> properly: sizing event not triggered in wxWindow::Show() and GetBestSize()
MR> problem due qt's sizeHint() (detailed info in the issue #6)
Yes, I saw your comments, thanks!
MR> Ok, I'll try to implement new controls this way, and then if I have enough
MR> time I could remove moc files at all (maybe in last milestone after the
MR> mid-term evaluation).
Right.
MR> AFAIK wxQtEventSignalHandler is a helper template class that reimplements
MR> events (just methods, as they are different than signals in qt!). It is
MR> used mainly in *_qt.moc.cpp files to connect signals/slots.
MR> From the wxWidgets side it just has a EmitEvent method to bridge to Qt
MR> Events and Signals.
Looking at https://github.com/reingart/wxWidgets/blob/SOC2014_QT/include/wx/qt/winevent_qt.h
I don't really like this, having all events inside a single class is a bad
idea from dependencies point of view (compilation dependencies, as adding a
new event results in recompilation of everything; link dependencies as this
class is always used and pulls in all the code used in it even if it is not
used). What exactly is this class supposed to be doing anyhow? I just don't
see the big picture here...
MR> https://github.com/reingart/wxWidgets/commit/01a334bfe15348e87abf257e195b295790271a93
MR>
MR> It compiles but it doesn't link:
MR>
MR> reingart@s5ultra:~/src/wxWidgets/bldqt5/samples/controls$ LANG=C make
MR> g++ -o controls controls_controls.o
MR> -L/home/reingart/src/wxWidgets/bldqt5/lib
MR> -Wl,-rpath,/home/reingart/src/wxWidgets/bldqt5/lib -pthread
MR> -lwx_qtu_core-3.1 -lwx_baseu-3.1 -lQt5Widgets -lQt5Gui -lQt5Test
MR> -lQt5Core -lSM -lpng -lz -ljpeg -ltiff -lwxregexu-3.1 -pthread
MR> -Wl,--version-script,/home/reingart/src/wxWidgets/bldqt5/version-script -lz
MR> -ldl -lm -lQt5Gui -lQt5Test -lQt5Core -lz -ldl -lm -lQt5Gui -lQt5Test
MR> -lQt5Core
MR> /home/reingart/src/wxWidgets/bldqt5/lib/libwx_qtu_core-3.1.so: undefined
MR> reference to `vtable for wxQtTabWidget'
MR> collect2: error: ld returned 1 exit status
MR> make: *** [controls] Error 1
MR>
MR> I cannot figure out what I'm missing...
MR> Could you give me any advice here?
I suspect you'd work around the problem if you declared a virtual dtor in
wxQtTabWidget and defined it (even if it's empty) in src/qt/notebook.cpp
but I'm not really sure what's going on here, I'd need to build it myself
to see it (and be able to run nm on various object files).
BTW, it would be really great to have docs/qt/install.txt similar to the
other ports describing how to build wxQt, including the dependencies needed
and so on. Could you please write some minimal instructions?
TIA,
VZ
MR> BTW, I've fixed two issues that caused Controls sample to not work
MR> properly: sizing event not triggered in wxWindow::Show() and GetBestSize()
MR> problem due qt's sizeHint() (detailed info in the issue #6)
Yes, I saw your comments, thanks!
MR> Ok, I'll try to implement new controls this way, and then if I have enough
MR> time I could remove moc files at all (maybe in last milestone after the
MR> mid-term evaluation).
Right.
MR> AFAIK wxQtEventSignalHandler is a helper template class that reimplements
MR> events (just methods, as they are different than signals in qt!). It is
MR> used mainly in *_qt.moc.cpp files to connect signals/slots.
MR> From the wxWidgets side it just has a EmitEvent method to bridge to Qt
MR> Events and Signals.
Looking at https://github.com/reingart/wxWidgets/blob/SOC2014_QT/include/wx/qt/winevent_qt.h
I don't really like this, having all events inside a single class is a bad
idea from dependencies point of view (compilation dependencies, as adding a
new event results in recompilation of everything; link dependencies as this
class is always used and pulls in all the code used in it even if it is not
used). What exactly is this class supposed to be doing anyhow? I just don't
see the big picture here...
MR> https://github.com/reingart/wxWidgets/commit/01a334bfe15348e87abf257e195b295790271a93
MR>
MR> It compiles but it doesn't link:
MR>
MR> reingart@s5ultra:~/src/wxWidgets/bldqt5/samples/controls$ LANG=C make
MR> g++ -o controls controls_controls.o
MR> -L/home/reingart/src/wxWidgets/bldqt5/lib
MR> -Wl,-rpath,/home/reingart/src/wxWidgets/bldqt5/lib -pthread
MR> -lwx_qtu_core-3.1 -lwx_baseu-3.1 -lQt5Widgets -lQt5Gui -lQt5Test
MR> -lQt5Core -lSM -lpng -lz -ljpeg -ltiff -lwxregexu-3.1 -pthread
MR> -Wl,--version-script,/home/reingart/src/wxWidgets/bldqt5/version-script -lz
MR> -ldl -lm -lQt5Gui -lQt5Test -lQt5Core -lz -ldl -lm -lQt5Gui -lQt5Test
MR> -lQt5Core
MR> /home/reingart/src/wxWidgets/bldqt5/lib/libwx_qtu_core-3.1.so: undefined
MR> reference to `vtable for wxQtTabWidget'
MR> collect2: error: ld returned 1 exit status
MR> make: *** [controls] Error 1
MR>
MR> I cannot figure out what I'm missing...
MR> Could you give me any advice here?
I suspect you'd work around the problem if you declared a virtual dtor in
wxQtTabWidget and defined it (even if it's empty) in src/qt/notebook.cpp
but I'm not really sure what's going on here, I'd need to build it myself
to see it (and be able to run nm on various object files).
BTW, it would be really great to have docs/qt/install.txt similar to the
other ports describing how to build wxQt, including the dependencies needed
and so on. Could you please write some minimal instructions?
TIA,
VZ
Mariano Reingart
Jun 6, 2014, 12:10:10 PM6/6/14
to wx-dev
On Fri, Jun 6, 2014 at 9:41 AM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
On Fri, 6 Jun 2014 06:33:40 -0300 Mariano Reingart wrote:
MR> BTW, I've fixed two issues that caused Controls sample to not work
MR> properly: sizing event not triggered in wxWindow::Show() and GetBestSize()
MR> problem due qt's sizeHint() (detailed info in the issue #6)
Yes, I saw your comments, thanks!
MR> Ok, I'll try to implement new controls this way, and then if I have enough
MR> time I could remove moc files at all (maybe in last milestone after the
MR> mid-term evaluation).
Right.
MR> AFAIK wxQtEventSignalHandler is a helper template class that reimplements
MR> events (just methods, as they are different than signals in qt!). It is
MR> used mainly in *_qt.moc.cpp files to connect signals/slots.
MR> From the wxWidgets side it just has a EmitEvent method to bridge to Qt
MR> Events and Signals.
Looking at https://github.com/reingart/wxWidgets/blob/SOC2014_QT/include/wx/qt/winevent_qt.h
I don't really like this, having all events inside a single class is a bad
idea from dependencies point of view (compilation dependencies, as adding a
new event results in recompilation of everything; link dependencies as this
class is always used and pulls in all the code used in it even if it is not
used). What exactly is this class supposed to be doing anyhow? I just don't
see the big picture here...
So far my understanding is that the wxQtEventSignalHandler class is just a helper to map the Qt events methods: "The normal way for an event to be delivered is by calling a virtual function. ":
For example QWidget::focusInEvent() will be called by Qt (wxQtWidget::focusInEvent to be more precise), and then the helper will call wxWindow::QtHandleFocusEvent() on the wx side, to build the wx event objet and dispatch it.
This is similar to other ports, for example wxGTK has wxNotebook::GTKOnPageChanged() to send the page changed event, and uses the syntax g_signal_connect_after (m_widget, "switch_page", G_CALLBACK(switch_page_after), this);
With the new signal syntax, I'm trying to do the same, just a normal call for the signal QTabWidget::currentChanged(), without needing the preprocessor for SIGNAL() and SLOT()
Just in case, note that signal and slots are a different concept than events in Qt:
To do both, QWidget (QTabWidget) needs to be subclassed (hence wxQtTabWidget).
I don't see any other way except c++11 lambda functions for signal "slots" (but that will not work for event methods as they should be overridden anyway)
Clarification: the wxQtEventSignalHandler is there since the first commits for wxQT and was used in the previous GSOC.
MR> https://github.com/reingart/wxWidgets/commit/01a334bfe15348e87abf257e195b295790271a93
MR>
MR> It compiles but it doesn't link:
MR>
MR> reingart@s5ultra:~/src/wxWidgets/bldqt5/samples/controls$ LANG=C make
MR> g++ -o controls controls_controls.o
MR> -L/home/reingart/src/wxWidgets/bldqt5/lib
MR> -Wl,-rpath,/home/reingart/src/wxWidgets/bldqt5/lib -pthread
MR> -lwx_qtu_core-3.1 -lwx_baseu-3.1 -lQt5Widgets -lQt5Gui -lQt5Test
MR> -lQt5Core -lSM -lpng -lz -ljpeg -ltiff -lwxregexu-3.1 -pthread
MR> -Wl,--version-script,/home/reingart/src/wxWidgets/bldqt5/version-script -lz
MR> -ldl -lm -lQt5Gui -lQt5Test -lQt5Core -lz -ldl -lm -lQt5Gui -lQt5Test
MR> -lQt5Core
MR> /home/reingart/src/wxWidgets/bldqt5/lib/libwx_qtu_core-3.1.so: undefined
MR> reference to `vtable for wxQtTabWidget'
MR> collect2: error: ld returned 1 exit status
MR> make: *** [controls] Error 1
MR>
MR> I cannot figure out what I'm missing...
MR> Could you give me any advice here?
I suspect you'd work around the problem if you declared a virtual dtor in
wxQtTabWidget and defined it (even if it's empty) in src/qt/notebook.cpp
but I'm not really sure what's going on here, I'd need to build it myself
to see it (and be able to run nm on various object files).
Yes, I should be missing something like that but I can't figure it out.
I'll try to work around as you suggested.
BTW, it would be really great to have docs/qt/install.txt similar to the
other ports describing how to build wxQt, including the dependencies needed
and so on. Could you please write some minimal instructions?
I started to document that notes in github wiki pages (I've linked them in the first milestone ticket/issues):
I'm planning to make a new one called WxQtEventSignalNotes
Let me know if I should explain them more in detail
Best regards
Best regards
Vadim Zeitlin
Jun 6, 2014, 2:39:08 PM6/6/14
to wx-...@googlegroups.com
On Fri, 6 Jun 2014 13:09:49 -0300 Mariano Reingart wrote:
MR> So far my understanding is that the wxQtEventSignalHandler class is just a
MR> helper to map the Qt events methods: "The normal way for an event to be
MR> delivered is by calling a virtual function. ":
MR>
MR> http://qt-project.org/doc/qt-5/eventsandfilters.html
How interesting. I had no idea they put all the event handlers in the base
class. IMO this is a pretty bad design and, moreover, it seems to be quite
unnecessary with flexible event handling using Bind()-like mechanism (which
Qt5 connect() provides AFAICS).
MR> For example QWidget::focusInEvent() will be called by Qt
MR> (wxQtWidget::focusInEvent to be more precise), and then the helper will
MR> call wxWindow::QtHandleFocusEvent() on the wx side, to build the wx
MR> event objet and dispatch it.
I don't understand the need for the separate QtHandleFocusEvent() though.
Wouldn't it be enough to override focusEvent() in wxWindowQT and send
wxFocusEvent from there?
MR> Just in case, note that signal and slots are a different concept than
MR> events in Qt:
MR>
MR> http://qt-project.org/doc/qt-5/signalsandslots.html
I am running out of time right now but I'll try to read it later. If you
could please summarize the difference between them, it would be very
helpful though.
MR> I don't see any other way except c++11 lambda functions for signal "slots"
MR> (but that will not work for event methods as they should be overridden
MR> anyway)
If you can use a C++11 lambda, you can also use C++98 functor object,
can't you?
MR> Clarification: the wxQtEventSignalHandler is there since the first commits
MR> for wxQT and was used in the previous GSOC.
Yes, I realize this, it wasn't meant as a criticism in your address, I'd
just like to understand what's going on and whether we can improve things
and make developing this port easier in the future.
MR> > BTW, it would be really great to have docs/qt/install.txt similar to the
MR> > other ports describing how to build wxQt, including the dependencies needed
MR> > and so on. Could you please write some minimal instructions?
MR> >
MR> >
MR> I started to document that notes in github wiki pages (I've linked them in
MR> the first milestone ticket/issues):
MR>
MR> https://github.com/reingart/wxWidgets/wiki/WxQtUbuntuNotes
MR>
MR> https://github.com/reingart/wxWidgets/wiki/WxQtMergeNotes
MR>
MR> I'm planning to make a new one called WxQtEventSignalNotes
MR>
MR> Let me know if I should explain them more in detail
I'll read this later, but the main point remains that we need to have
something in the repository itself and not just on this wiki...
Regards,
VZ
MR> So far my understanding is that the wxQtEventSignalHandler class is just a
MR> helper to map the Qt events methods: "The normal way for an event to be
MR> delivered is by calling a virtual function. ":
MR>
MR> http://qt-project.org/doc/qt-5/eventsandfilters.html
How interesting. I had no idea they put all the event handlers in the base
class. IMO this is a pretty bad design and, moreover, it seems to be quite
unnecessary with flexible event handling using Bind()-like mechanism (which
Qt5 connect() provides AFAICS).
MR> For example QWidget::focusInEvent() will be called by Qt
MR> (wxQtWidget::focusInEvent to be more precise), and then the helper will
MR> call wxWindow::QtHandleFocusEvent() on the wx side, to build the wx
MR> event objet and dispatch it.
I don't understand the need for the separate QtHandleFocusEvent() though.
Wouldn't it be enough to override focusEvent() in wxWindowQT and send
wxFocusEvent from there?
MR> Just in case, note that signal and slots are a different concept than
MR> events in Qt:
MR>
MR> http://qt-project.org/doc/qt-5/signalsandslots.html
I am running out of time right now but I'll try to read it later. If you
could please summarize the difference between them, it would be very
helpful though.
MR> I don't see any other way except c++11 lambda functions for signal "slots"
MR> (but that will not work for event methods as they should be overridden
MR> anyway)
If you can use a C++11 lambda, you can also use C++98 functor object,
can't you?
MR> Clarification: the wxQtEventSignalHandler is there since the first commits
MR> for wxQT and was used in the previous GSOC.
Yes, I realize this, it wasn't meant as a criticism in your address, I'd
just like to understand what's going on and whether we can improve things
and make developing this port easier in the future.
MR> > BTW, it would be really great to have docs/qt/install.txt similar to the
MR> > other ports describing how to build wxQt, including the dependencies needed
MR> > and so on. Could you please write some minimal instructions?
MR> >
MR> >
MR> I started to document that notes in github wiki pages (I've linked them in
MR> the first milestone ticket/issues):
MR>
MR> https://github.com/reingart/wxWidgets/wiki/WxQtUbuntuNotes
MR>
MR> https://github.com/reingart/wxWidgets/wiki/WxQtMergeNotes
MR>
MR> I'm planning to make a new one called WxQtEventSignalNotes
MR>
MR> Let me know if I should explain them more in detail
I'll read this later, but the main point remains that we need to have
something in the repository itself and not just on this wiki...
Regards,
VZ
Vadim Zeitlin
Jun 7, 2014, 10:30:18 AM6/7/14
to wx-...@googlegroups.com
On Fri, 6 Jun 2014 13:09:49 -0300 Mariano Reingart wrote:
MR> Just in case, note that signal and slots are a different concept than
MR> events in Qt:
MR>
MR> http://qt-project.org/doc/qt-5/signalsandslots.html
OK, after reading this I see how Qt does it now. I still have no idea why
MR> Just in case, note that signal and slots are a different concept than
MR> events in Qt:
MR>
MR> http://qt-project.org/doc/qt-5/signalsandslots.html
do they do it like this BTW, having two strongly overlapping yet completely
different ways to do almost the same thing is very strange. Dare I say that
I think wxWidgets approach of using events for everything is more elegant?
MR> To do both, QWidget (QTabWidget) needs to be subclassed (hence
MR> wxQtTabWidget).
AFAICS subclassing is only needed to handle events, not for handling
signals.
Anyhow, my point is, I guess, that we shouldn't put all event methods in a
single wxQtEventSignalHandler class, but that we should have
wxQtWidgetEventHandler and wxQtTabWidgetEventHandler inheriting from it.
Does this make sense?
VZ
Mariano Reingart
Jun 7, 2014, 11:42:22 AM6/7/14
to wx-dev
On Sat, Jun 7, 2014 at 11:30 AM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
On Fri, 6 Jun 2014 13:09:49 -0300 Mariano Reingart wrote:OK, after reading this I see how Qt does it now. I still have no idea why
MR> Just in case, note that signal and slots are a different concept than
MR> events in Qt:
MR>
MR> http://qt-project.org/doc/qt-5/signalsandslots.html
do they do it like this BTW, having two strongly overlapping yet completely
different ways to do almost the same thing is very strange. Dare I say that
I think wxWidgets approach of using events for everything is more elegant?
Yes, and the problem goes further as Signals in Qt are very simplistic and cannot be vetoed, for example (at least as far I could read).
QEvent are a bit better but they doesn't have the target object associated reference and other useful data...
Both seems very limited and confusing (not to mention you need a string syntax / precompliation step for earlier versions)
wxWidgets approach not only is unified and more elegant, it also looks more powerful and flexible.
MR> To do both, QWidget (QTabWidget) needs to be subclassed (hence
MR> wxQtTabWidget).
AFAICS subclassing is only needed to handle events, not for handling
signals.
Yes, but using the new signal syntax it needs a QWidget or similar anyway: "It is possible to connect to any member function of QObject, not only slots.".
To avoid the QObject, I tried to connect directly to a member function of wxNotebook without success (it didn't even compile).
It support also simple functions but signals doesn't receive any event object reference so they are useless in this context (maybe c++ lambdas could help there to pass more parameters) as it cannot be used to map to the wxWidget associated object.
For example, wxQtTabWidget::currentChanged(int index) only receives the selected index, if it were not a member function how could you determine the associated object? (to send the correspondent wxWidget events):
Anyhow, my point is, I guess, that we shouldn't put all event methods in a
single wxQtEventSignalHandler class, but that we should have
wxQtWidgetEventHandler and wxQtTabWidgetEventHandler inheriting from it.
Does this make sense?
Sorry, I don't fully understand this.
Isn't it designed that way with the template class?
Or you're suggesting to remove the template class and make wxQtWidgetEventHandler just to inherit from QWidget/QObject?
Best regards,
PS: about documentation, my plan is to make some more personal wiki page with notes and when this is settled I'll update http://wiki.wxwidgets.org/WxQt if you agree
PS: about documentation, my plan is to make some more personal wiki page with notes and when this is settled I'll update http://wiki.wxwidgets.org/WxQt if you agree
Vadim Zeitlin
Jun 7, 2014, 11:54:41 AM6/7/14
to wx-...@googlegroups.com
On Sat, 7 Jun 2014 12:41:10 -0300 Mariano Reingart wrote:
MR> Yes, but using the new signal syntax it needs a QWidget or similar anyway:
MR> "It is possible to connect to any member function of QObject, not only
MR> slots.".
Hmm, this is really limiting. I really like that our Bind() can be used to
connect events to the methods of non-GUI classes which don't know about
wxWidgets at all and don't derive from wxWindow/wxObject.
MR> For example, wxQtTabWidget::currentChanged(int index) only receives the
MR> selected index, if it were not a member function how could you determine
MR> the associated object? (to send the correspondent wxWidget events):
MR>
MR> https://github.com/reingart/wxWidgets/blob/ef2a4515515a46bbd944b79a3843466e05404bac/src/qt/notebook.cpp#L30
You're right that while you could use a closure (i.e. C++11 lambda or
manually created functor object) to store the object in the handler itself,
there is no real advantage in doing it like this and the current code is
simpler and so better.
MR> > Anyhow, my point is, I guess, that we shouldn't put all event methods
MR> > in a single wxQtEventSignalHandler class, but that we should have
MR> > wxQtWidgetEventHandler and wxQtTabWidgetEventHandler inheriting from
MR> > it.
MR> >
MR> > Does this make sense?
MR> >
MR> Sorry, I don't fully understand this.
MR> Isn't it designed that way with the template class?
I realized that there is still one thing I don't understand about Qt
events: are they "fixed", in the sense that there is only a (small)
predefined number of them in QWidget and no derived classes add to this
set? Or are they like wx events, with derived classes adding their own
events?
MR> Or you're suggesting to remove the template class and
MR> make wxQtWidgetEventHandler just to inherit from QWidget/QObject?
If the set of events is fixed, I indeed don't really see any reason for
using a template here.
MR> PS: about documentation, my plan is to make some more personal wiki page
MR> with notes and when this is settled I'll update
MR> http://wiki.wxwidgets.org/WxQt if you agree
This would be fine but, and sorry to insist, I'd still very much like to
have docs/qt/install.txt with the instructions for building (and maybe
using, if there is anything non trivial involved) this port. E.g. I'd like
to build it now, I literally don't know where to start. I'd like to be able
to follow the steps in this file and arrive at a working (well, as working
as can be) wxQt build.
Thanks,
VZ
MR> Yes, but using the new signal syntax it needs a QWidget or similar anyway:
MR> "It is possible to connect to any member function of QObject, not only
MR> slots.".
Hmm, this is really limiting. I really like that our Bind() can be used to
connect events to the methods of non-GUI classes which don't know about
wxWidgets at all and don't derive from wxWindow/wxObject.
MR> For example, wxQtTabWidget::currentChanged(int index) only receives the
MR> selected index, if it were not a member function how could you determine
MR> the associated object? (to send the correspondent wxWidget events):
MR>
MR> https://github.com/reingart/wxWidgets/blob/ef2a4515515a46bbd944b79a3843466e05404bac/src/qt/notebook.cpp#L30
You're right that while you could use a closure (i.e. C++11 lambda or
manually created functor object) to store the object in the handler itself,
there is no real advantage in doing it like this and the current code is
simpler and so better.
MR> > Anyhow, my point is, I guess, that we shouldn't put all event methods
MR> > in a single wxQtEventSignalHandler class, but that we should have
MR> > wxQtWidgetEventHandler and wxQtTabWidgetEventHandler inheriting from
MR> > it.
MR> >
MR> > Does this make sense?
MR> >
MR> Sorry, I don't fully understand this.
MR> Isn't it designed that way with the template class?
I realized that there is still one thing I don't understand about Qt
events: are they "fixed", in the sense that there is only a (small)
predefined number of them in QWidget and no derived classes add to this
set? Or are they like wx events, with derived classes adding their own
events?
MR> Or you're suggesting to remove the template class and
MR> make wxQtWidgetEventHandler just to inherit from QWidget/QObject?
If the set of events is fixed, I indeed don't really see any reason for
using a template here.
MR> PS: about documentation, my plan is to make some more personal wiki page
MR> with notes and when this is settled I'll update
MR> http://wiki.wxwidgets.org/WxQt if you agree
This would be fine but, and sorry to insist, I'd still very much like to
have docs/qt/install.txt with the instructions for building (and maybe
using, if there is anything non trivial involved) this port. E.g. I'd like
to build it now, I literally don't know where to start. I'd like to be able
to follow the steps in this file and arrive at a working (well, as working
as can be) wxQt build.
Thanks,
VZ
petah
Jun 7, 2014, 12:25:24 PM6/7/14
to wxDev
On Sat, 7 Jun 2014 16:30:02 +0200
Vadim Zeitlin <vadim-dz6zkcJx...@public.gmane.org> wrote:
> On Fri, 6 Jun 2014 13:09:49 -0300 Mariano Reingart wrote:
>
> MR> Just in case, note that signal and slots are a different concept than
> MR> events in Qt:
> MR>
> MR> http://qt-project.org/doc/qt-5/signalsandslots.html
>
> OK, after reading this I see how Qt does it now. I still have no idea why
> do they do it like this BTW, having two strongly overlapping yet completely
> different ways to do almost the same thing is very strange. Dare I say that
> I think wxWidgets approach of using events for everything is more elegant?
Sig/slot is the #1 feature Qt users mention when asked why Qt is so great, including people who used wx as well, despite Qt's drawbacks (volatile crap licensing, opaque decision process, etc) so it'd make sense to dig a little deeper before reaching that conclusion.
Vadim Zeitlin <vadim-dz6zkcJx...@public.gmane.org> wrote:
> On Fri, 6 Jun 2014 13:09:49 -0300 Mariano Reingart wrote:
>
> MR> Just in case, note that signal and slots are a different concept than
> MR> events in Qt:
> MR>
> MR> http://qt-project.org/doc/qt-5/signalsandslots.html
>
> OK, after reading this I see how Qt does it now. I still have no idea why
> do they do it like this BTW, having two strongly overlapping yet completely
> different ways to do almost the same thing is very strange. Dare I say that
> I think wxWidgets approach of using events for everything is more elegant?
It's definitely much faster than wxEvents, which are slow to begin with.
Some gloating would probably be in order if wx could add it without Qt's source pre-parser or whatever it's called.
cheers,
-- p
Mariano Reingart
Jun 7, 2014, 12:33:51 PM6/7/14
to wx-dev
On Sat, Jun 7, 2014 at 12:54 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
I realized that there is still one thing I don't understand about Qt
events: are they "fixed", in the sense that there is only a (small)
predefined number of them in QWidget and no derived classes add to this
set? Or are they like wx events, with derived classes adding their own
events?
To my knowledge, they are not like wxEvents.
To trigger a new signal, it seems that there is even a qt special keyword "emit" handled by the c++ preprocessor.
To add a new event, it could be possible with registerEvent but it also seems to require more code
Events seems to be more rigid in Qt, subclasses reimplements standard and well known ones like focusInEvent, focusOutEvent, hitButton, keyPressEvent, paintEvent.
Signals seems to be more flexible, and each control add they own ones (like in QTabWidget::currentChanged)
MR> Or you're suggesting to remove the template class and
MR> make wxQtWidgetEventHandler just to inherit from QWidget/QObject?
If the set of events is fixed, I indeed don't really see any reason for
using a template here.
Ok
MR> PS: about documentation, my plan is to make some more personal wiki page
MR> with notes and when this is settled I'll update
MR> http://wiki.wxwidgets.org/WxQt if you agree
This would be fine but, and sorry to insist, I'd still very much like to
have docs/qt/install.txt with the instructions for building (and maybe
using, if there is anything non trivial involved) this port. E.g. I'd like
to build it now, I literally don't know where to start. I'd like to be able
to follow the steps in this file and arrive at a working (well, as working
as can be) wxQt build.
Ok, currently to compile wxQT you need just to do the steps listed in those wikis:
../configure --with-qt
make
SOC2014_QT branch should compile and run (minimal and controls samples)
I'll see docs for other ports and write something accordingly
Best regards
Best regards
Mariano Reingart
Jun 8, 2014, 1:14:41 AM6/8/14
to wx-dev
Well, the problem was Q_OBJECT macro (and the MOC), as the notebook class was not being pre-processed it should be missing some "meta-object" generated code.
Removing it works fine even without running the moc.
According to the docs, it is only required for QObject that declares its owns signals/slots, or uses other meta-object features (like tr(), properties, etc.):
http://qt-project.org/doc/qt-4.8/moc.html#moc
I've removed the macros, replaced the old style connect and reunified helpers in the branch wxQT_no_moc_experimental:
It compiles and runs ok without using the moc!
The new syntax should be more safer as it allows compile-time checks (it isn't converted to string like in the old syntax).
Also, as the new syntax doesn't requires the function to be a slot. and as we will not be declaring/defining signals, hopefuly removing Q_OBJECT (and moc) should be safe.
Do you think that I could merge this experimental branch in SOC2014_QT?
BTW, moc build rules stays (not used), just in case.
Vadim Zeitlin
Jun 8, 2014, 9:07:31 PM6/8/14
to wx-...@googlegroups.com
On Sun, 8 Jun 2014 02:14:18 -0300 Mariano Reingart wrote:
MR> I've removed the macros, replaced the old style connect and reunified
MR> helpers in the branch wxQT_no_moc_experimental:
MR>
MR> https://github.com/reingart/wxWidgets/commits/wxQT_no_moc_experimental
MR>
MR> It compiles and runs ok without using the moc!
Great!
MR> The new syntax should be more safer as it allows compile-time checks (it
MR> isn't converted to string like in the old syntax).
MR> Also, as the new syntax doesn't requires the function to be a slot. and as
MR> we will not be declaring/defining signals, hopefuly removing Q_OBJECT (and
MR> moc) should be safe.
MR>
MR> Do you think that I could merge this experimental branch in SOC2014_QT?
If you don't see any problems/regressions with it, yes, please, definitely
do this. It is great to not rely on moc any more.
MR> BTW, moc build rules stays (not used), just in case.
Please remove them too, why keep them if they're not used any more?
Thanks,
VZ
MR> I've removed the macros, replaced the old style connect and reunified
MR> helpers in the branch wxQT_no_moc_experimental:
MR>
MR> https://github.com/reingart/wxWidgets/commits/wxQT_no_moc_experimental
MR>
MR> It compiles and runs ok without using the moc!
Great!
MR> The new syntax should be more safer as it allows compile-time checks (it
MR> isn't converted to string like in the old syntax).
MR> Also, as the new syntax doesn't requires the function to be a slot. and as
MR> we will not be declaring/defining signals, hopefuly removing Q_OBJECT (and
MR> moc) should be safe.
MR>
MR> Do you think that I could merge this experimental branch in SOC2014_QT?
If you don't see any problems/regressions with it, yes, please, definitely
do this. It is great to not rely on moc any more.
MR> BTW, moc build rules stays (not used), just in case.
Please remove them too, why keep them if they're not used any more?
Thanks,
VZ
klaas.holwerda
Jun 9, 2014, 9:46:37 AM6/9/14
to wx-...@googlegroups.com
Hi Vadim,
On 06/07/2014 04:30 PM, Vadim Zeitlin wrote:
> On Fri, 6 Jun 2014 13:09:49 -0300 Mariano Reingart wrote:
>
> MR> Just in case, note that signal and slots are a different concept than
> MR> events in Qt:
> MR>
> MR> http://qt-project.org/doc/qt-5/signalsandslots.html
>
> OK, after reading this I see how Qt does it now. I still have no idea why
> do they do it like this BTW, having two strongly overlapping yet completely
> different ways to do almost the same thing is very strange. Dare I say that
> I think wxWidgets approach of using events for everything is more elegant?
I remembered our discussion (as a result of an unsolved bug in wx dealing with signal like usage).
I suggested to make wx event system more easy to use for signaling.
https://groups.google.com/forum/#!msg/wx-dev/xNKg3tYtVtw/JlDQ3b_mP3UJ
Unless I understood you wrong, you advised against it ;-)
Saying "But in any case I'm pretty sure it's a bad idea to mix both of them."
So now I am confused?? :-)
Still I do use the wx event system now for both purposes, and it works well, even receiving signals
via a static event table as an extra feature.
I think the key point is still the "1 to N relation" (there is no processing for the result/return
needed in general).
Therefore to use wx events, one needs to Skip the event in every "slot". If not the signal
distribution stops, and some other slot connected to the same signal will not be receiving the signal.
In the end I completely agree with you about Qt having two solution, for things which are very much
the same. Also do not understand why.
But to do that inside wx easily, a few changes would be needed I think.
Who knows it would make it much easier if Qt signals can be used as is through the wx event system.
Wrap the Qt signal into a "wxSignalEvent" or "wxCommunicateEvent", and maybe process that event just
a little different.
Regards,
Klaas
On 06/07/2014 04:30 PM, Vadim Zeitlin wrote:
> On Fri, 6 Jun 2014 13:09:49 -0300 Mariano Reingart wrote:
>
> MR> Just in case, note that signal and slots are a different concept than
> MR> events in Qt:
> MR>
> MR> http://qt-project.org/doc/qt-5/signalsandslots.html
>
> OK, after reading this I see how Qt does it now. I still have no idea why
> do they do it like this BTW, having two strongly overlapping yet completely
> different ways to do almost the same thing is very strange. Dare I say that
> I think wxWidgets approach of using events for everything is more elegant?
I suggested to make wx event system more easy to use for signaling.
https://groups.google.com/forum/#!msg/wx-dev/xNKg3tYtVtw/JlDQ3b_mP3UJ
Unless I understood you wrong, you advised against it ;-)
Saying "But in any case I'm pretty sure it's a bad idea to mix both of them."
So now I am confused?? :-)
Still I do use the wx event system now for both purposes, and it works well, even receiving signals
via a static event table as an extra feature.
I think the key point is still the "1 to N relation" (there is no processing for the result/return
needed in general).
Therefore to use wx events, one needs to Skip the event in every "slot". If not the signal
distribution stops, and some other slot connected to the same signal will not be receiving the signal.
In the end I completely agree with you about Qt having two solution, for things which are very much
the same. Also do not understand why.
But to do that inside wx easily, a few changes would be needed I think.
Who knows it would make it much easier if Qt signals can be used as is through the wx event system.
Wrap the Qt signal into a "wxSignalEvent" or "wxCommunicateEvent", and maybe process that event just
a little different.
Regards,
Klaas
Mariano Reingart
Jun 10, 2014, 5:20:27 PM6/10/14
to wx-dev
Done, and merged the experimental branch in SOC2014_QT
Best regards,
petah
Jul 17, 2014, 4:59:57 PM7/17/14
to wxDev
just built wx trunk on Debian Gtk2 x64, upon deleting a wxNotebook's last (remaining) shown page there's no changing/changed event. Works as expected through the penultimate shown page, then barfs.
Can be reproduced with samples/notebook without changing any code (w/out wxaui); just close pages one by one. Didn't come across a conspicuous reason from the code... though hardcoded zero page indices are puzzling. Trac has a couple of OSX patches that wouldn't affect me under Linux. Did I miss something obvious?
thx & cheers,
-- p
Can be reproduced with samples/notebook without changing any code (w/out wxaui); just close pages one by one. Didn't come across a conspicuous reason from the code... though hardcoded zero page indices are puzzling. Trac has a couple of OSX patches that wouldn't affect me under Linux. Did I miss something obvious?
thx & cheers,
-- p
Igor Korot
Jul 17, 2014, 5:06:45 PM7/17/14
to wx-dev
Hi, petah,
On Thu, Jul 17, 2014 at 2:04 PM, petah <w...@laufenberg.ch> wrote:
> just built wx trunk on Debian Gtk2 x64, upon deleting a wxNotebook's last (remaining) shown page there's no changing/changed event. Works as expected through the penultimate shown page, then barfs.
>
> Can be reproduced with samples/notebook without changing any code (w/out wxaui); just close pages one by one. Didn't come across a conspicuous reason from the code... though hardcoded zero page indices are puzzling. Trac has a couple of OSX patches that wouldn't affect me under Linux. Did I miss something obvious?
No, you didn't miss anything.
There is a ticket open already about that on Trac. Just search for it.
I don't remember the details unfortunately, but you can find it and
make some comments.
Thank you.
>
> thx & cheers,
>
> -- p
>
> --
> To unsubscribe, send email to wx-dev+un...@googlegroups.com
> or visit http://groups.google.com/group/wx-dev
>
On Thu, Jul 17, 2014 at 2:04 PM, petah <w...@laufenberg.ch> wrote:
> just built wx trunk on Debian Gtk2 x64, upon deleting a wxNotebook's last (remaining) shown page there's no changing/changed event. Works as expected through the penultimate shown page, then barfs.
>
> Can be reproduced with samples/notebook without changing any code (w/out wxaui); just close pages one by one. Didn't come across a conspicuous reason from the code... though hardcoded zero page indices are puzzling. Trac has a couple of OSX patches that wouldn't affect me under Linux. Did I miss something obvious?
There is a ticket open already about that on Trac. Just search for it.
I don't remember the details unfortunately, but you can find it and
make some comments.
Thank you.
>
> thx & cheers,
>
> -- p
>
> To unsubscribe, send email to wx-dev+un...@googlegroups.com
> or visit http://groups.google.com/group/wx-dev
>
Vadim Zeitlin
Jul 18, 2014, 7:35:40 AM7/18/14
to wxDev
On Thu, 17 Jul 2014 23:04:56 +0200 petah wrote:
p> just built wx trunk on Debian Gtk2 x64, upon deleting a wxNotebook's
p> last (remaining) shown page there's no changing/changed event. Works as
p> expected through the penultimate shown page, then barfs.
p>
p> Can be reproduced with samples/notebook without changing any code (w/out
p> wxaui); just close pages one by one.
I do see that no event is generated in the sample under GTK, but I also
see exactly the same behaviour under MSW, so I hesitate changing this. Or,
at the very least, if we do change it, we need to do it under both
platforms. It shouldn't be too difficult but we probably need to generate
the event ourselves as the underlying toolkit clearly doesn't think it's
useful to do it when there are no more pages.
Regards,
VZ
p> just built wx trunk on Debian Gtk2 x64, upon deleting a wxNotebook's
p> last (remaining) shown page there's no changing/changed event. Works as
p> expected through the penultimate shown page, then barfs.
p>
p> Can be reproduced with samples/notebook without changing any code (w/out
p> wxaui); just close pages one by one.
I do see that no event is generated in the sample under GTK, but I also
see exactly the same behaviour under MSW, so I hesitate changing this. Or,
at the very least, if we do change it, we need to do it under both
platforms. It shouldn't be too difficult but we probably need to generate
the event ourselves as the underlying toolkit clearly doesn't think it's
useful to do it when there are no more pages.
Regards,
VZ
Reply all
Reply to author
Forward
0 new messages