Request to merge a set of fix and improvements (done for our application) (Issue #24520)
JCYang
Hi, there.
We've developed a commercial cross-platform app using wxWidgets framework for windows/mac/linux, all three mainstream OS are targeted.
And it's a non-trivial app that utilize many features of the framework, we may be one of the most heavy users.
So on the way, we found so many bugs.
We were on rapid development cycles and didn't have the resources to share our fixes to the upstream project on a regular basis, but now we find that we can no longer maintain the fixes, considering the framework is far from mature enough to allow us to stay on one LTS like version, we'd like to request you, the project maintainers to merge in most of our fixes/improvements.
Because there's too many, and in the foreseeable future, more fixes are expected and coming, we'd like to unify the set of works here for the maintainers to review.
Each of the fixes are now in their own branch, created for the sake of the pull request.
- Fix wxRibbonButtonBar's layout overall size computation.
JCYang@a28b8db - wxGTK: Fix UI refreshing delay when dragging the header border of generic wxDataViewCtrl to resize column.
JCYang@381c608 - wxGTK: Fix improper wxEVT_LEAVE_WINDOW event
JCYang@9286889 - MacOSX: Change the two dummy messages to use systemUpTime as timestamp to fix CEF renderer process crash.
JCYang@af1f103 - MacOSX: Keep DoDragDrop() from re-entering to enable a proper working CEF.
JCYang@e998db7 - wxOSX: Fix wxPopupTransientWindow's mouse event handling.
JCYang@8d2ddec - MacOSX: Make wxWebviewWebkit capture hotkeys less eagerly.
JCYang@f4eb6c3 - wxOSX: Add support for wxDropSource icons.
JCYang@dca4ca3 - wxOSX: Relax DoDragDrop() constraints.
JCYang@71bf9d8
The 9 fixes/improvements mentioned above are meant to be merged into the master branch.
And the following is one optimization that seems work well in our app,
- wxMSW: Optimize AlphaBlt.
JCYang@78afe18
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Hello, thanks for the fixes but the usual process would be to open a single PR for each of them, so that they could be tested, discussed and applied independently and I think this would be very much preferable to this "unified" issue. Could you please open separate PRs for your changes?
For the bug fixes, it would be great if you could please explain how exactly the problem fixed by your changes can be reproduced (ideal is to add a test failing without the change and fixed by it, but I realize that this is not always easily possible).
Thanks in advance!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#24520)It looks like separate PRs/explanations are not coming, but at least some of the fixes look reasonable. @csomor Your thoughts about the Mac ones would be very welcome (and I'll try to deal with the rest of them myself).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#24520)Most of the commits here have been merged now. There are still 2 wxOSX ones that I'm leaving to Stefan.
The remaining wxGTK commit concerning wxEVT_LEAVE_WINDOW doesn't seem right: it says
Do Not emit wxEVT_LEAVE_WINDOW when GdkEventCrossing mode is GDK_CROSSING_GRAB or GDK_CROSSING_GTK_GRAB
in the commit message, but it actually adds generation of these events for the grab crossing modes. I'm not sure whether the message or the code is correct, so I won't apply it until we have some way of reproducing the problem.
wxMSW blitting optimization commit could be still worth applying but it needs to be tested to make sure it doesn't change the behaviour.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#24520)Oh, I've just tested the wxMSW optimization commit and it is broken, replacing minimal.cpp contents with the following code (see #23841) shows that the second bitmap is not drawn correctly when using it:
#include <wx/wx.h> class MyApp : public wxApp { public: bool OnInit() override { auto* frame = new wxFrame(nullptr, wxID_ANY, "wxTest"); wxBitmap bmp(250, 50); { wxMemoryDC dc(bmp); dc.SetBackground(wxColour(181, 211, 234)); dc.Clear(); } new wxStaticBitmap(frame, -1, bmp, wxPoint(5, 5)); { wxMemoryDC dc(bmp); wxImage::AddHandler( new wxPNGHandler ); wxBitmap bmpDay("../image/toucan.png", wxBITMAP_TYPE_PNG); dc.DrawBitmap(bmpDay, 18, 9); } new wxStaticBitmap(frame, -1, bmp, wxPoint(55, 115)); frame->Show(); return true; } }; wxIMPLEMENT_APP(MyApp);
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Closed #24520 as completed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#24520)The last 2 outstanding commits were cherry-picked now, so there is nothing remaining to apply here and it can be closed. If you can explain the problem with wxEVT_LEAVE_WINDOW that you had/tried to fix, please open a separate PR for it. Thanks in advance!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.