Widgets demo:
widgets_rtl.png (view on web)
Grid demo:
griddemo_rtl.png (view on web)
AUI demo:
auidemo_rtl.png (view on web)
https://github.com/wxWidgets/wxWidgets/pull/25822
(12 files)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Amazing!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@AliKet pushed 10 commits.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@vadz commented on this pull request.
Thanks, this looks good and could be merged AFAICS, I'm not sure why is this in the "draft" state yet?
Also, unfortunately I have no idea why did SliderTestCase start consistently failing with Qt 6.8 just recently, but this is unrelated to this change.
> @@ -117,6 +122,14 @@ class WXDLLIMPEXP_CORE wxQtDCImpl : public wxDCImpl
virtual void* GetHandle() const override { return (void*) m_qtPainter; }
+ // LRT/RTL related functions
Typo:
⬇️ Suggested change- // LRT/RTL related functions + // LTR/RTL related functions
> @@ -3478,11 +3478,13 @@ wxRect wxAuiManager::CalculateHintRect(wxWindow* pane_window,
m_frame->ClientToScreen(&rect.x, &rect.y);
+#ifndef __WXQT__
I was always suspicious of this piece of code, if it's not needed for wxQt, it seems to confirm that it shouldn't be necessary for the other ports as well... Do you have any idea what could be wrong in/with them to require it?
In src/qt/dc.cpp:
> @@ -462,10 +496,10 @@ void wxQtDCImpl::Clear()
int width, height;
DoGetSize(&width, &height);
- m_qtPainter->eraseRect( DeviceToLogicalX(0),
- DeviceToLogicalY(0),
- DeviceToLogicalXRel(width),
- DeviceToLogicalYRel(height) );
+ const wxPoint pos = DeviceToLogical(0, 0);
Just to confirm: this doesn't really change anything, does it? I.e. DeviceToLogicalX() etc work too?
> + // For correct result in RTL layout, the drawing is done in a non-mirrored + // DC and the mirroring is done in paintEvent() above.
Sorry, I feel dumb, but I don't really understand why do we need to do this. I.e. what is wrong with using RTL layout for the DC itself instead of mirroring it later?
> + default: + wxFALLTHROUGH; +
I'd remove this to get a warning in the (unlikely) event of more elements being added to this enum.
In tests/graphics/clippingbox.cpp:
> @@ -1033,9 +1033,9 @@ static void OneDevRegionRTL(wxDC& dc, const wxBitmap& bmp, bool useTransformMatr
return;
}
-#ifdef __WXGTK__
+#if defined(__WXGTK__) || defined(__WXMSW__)
Could we perhaps add a check for __WXMSW__ below instead of disabling this test entirely for it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@AliKet pushed 19 commits.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@AliKet pushed 12 commits.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@AliKet commented on this pull request.
> @@ -3478,11 +3478,13 @@ wxRect wxAuiManager::CalculateHintRect(wxWindow* pane_window,
m_frame->ClientToScreen(&rect.x, &rect.y);
+#ifndef __WXQT__
This code is also not needed when this PR is complete. see this commit
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@AliKet commented on this pull request.
> + // For correct result in RTL layout, the drawing is done in a non-mirrored + // DC and the mirroring is done in paintEvent() above.
If we don't do this (i.e.: forcing LTR on the DC) the rubberbanding is not drawn correctly, i.e.: the rubberband is missing near the right side of the window (image 01) and is drawn over the vertical scrollbar (image 02):
Image 01:
drawing_1.png (view on web)
Image 02:
drawing_2.png (view on web)
I haven't found the reason for this problem. I'll add a comment stating that this is to correct drawing the rubberband on a scrolled window.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@AliKet commented on this pull request.
In tests/graphics/clippingbox.cpp:
> @@ -1033,9 +1033,9 @@ static void OneDevRegionRTL(wxDC& dc, const wxBitmap& bmp, bool useTransformMatr
return;
}
-#ifdef __WXGTK__
+#if defined(__WXGTK__) || defined(__WXMSW__)
The test is enabled for both wxMSW and wxGTK3 in this PR (see 4f49395 and 403e9f2)
I think I should merge the changes done here in that PR and close this one! what do you think ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@AliKet commented on this pull request.
In src/qt/dc.cpp:
> @@ -462,10 +496,10 @@ void wxQtDCImpl::Clear()
int width, height;
DoGetSize(&width, &height);
- m_qtPainter->eraseRect( DeviceToLogicalX(0),
- DeviceToLogicalY(0),
- DeviceToLogicalXRel(width),
- DeviceToLogicalYRel(height) );
+ const wxPoint pos = DeviceToLogical(0, 0);
DeviceToLogical{X,Y,...}() return different values than their counterpart in the other ports (i.e.: wxMSW and wxGTK3), which makes OneDevRegionRTL test case in wxQt fail!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@vadz commented on this pull request.
In tests/graphics/clippingbox.cpp:
> @@ -1033,9 +1033,9 @@ static void OneDevRegionRTL(wxDC& dc, const wxBitmap& bmp, bool useTransformMatr
return;
}
-#ifdef __WXGTK__
+#if defined(__WXGTK__) || defined(__WXMSW__)
Yes, probably, but whatever you decide please let me know how do you want me to process them, i.e. in which order to merge them if you don't combine them both. TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@vadz commented on this pull request.
In src/qt/dc.cpp:
> @@ -462,10 +496,10 @@ void wxQtDCImpl::Clear()
int width, height;
DoGetSize(&width, &height);
- m_qtPainter->eraseRect( DeviceToLogicalX(0),
- DeviceToLogicalY(0),
- DeviceToLogicalXRel(width),
- DeviceToLogicalYRel(height) );
+ const wxPoint pos = DeviceToLogical(0, 0);
Hmm, but which one is correct?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@AliKet pushed 20 commits.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@AliKet pushed 20 commits.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@vadz Should I completely remove the code in 55f5433 because it seems unnecessary at least under wxMSW, wxGTK3 and wxQt?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Ideal would be to check if this code is needed under Mac and, if it is, and assuming the bug can't be fixed in wxOSX itself, replace the preprocessor condition with a check for __WXOSX__. TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Ideal would be to check if this code is needed under Mac and, if it is, and assuming the bug can't be fixed in wxOSX itself, replace the preprocessor condition with a check for
__WXOSX__. TIA!
I don't have a Mac device to test this on it. so I'll leave the check as is then.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
FWIW we have a wxMac which is specifically there to be used for testing by people without access to a Mac. Please contact Stefan to get access to it.
In the meanwhile, let me know what do I need to do to test for it myself and I could do it here.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
In the meanwhile, let me know what do I need to do to test for it myself and I could do it here.
1- Just hardcode the wxAppBase::GetLayoutDirection() return value (for testing purposes) in src/common/appcmn.cpp
wxLayoutDirection wxAppBase::GetLayoutDirection() const { return wxLayout_RightToLeft; }
2- Run the auidemo and see if the hint rectangle is correctly position in RTL layout.
aui.png (view on web) aui2.png (view on web)TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
wxOSX doesn't seem to be affected by changing the return value of wxAppBase::GetLayoutDirection() at all, i.e. everything still shows up the same. Unsurprisingly, removing the code in question doesn't affect it either.
I think you should remove it and when/if anybody fixes RTL support in wxOSX, they could fix the bug that this worked around, if it's still there by then.
Thanks!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@vadz pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Merged #25822 into master.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()