Hi Khaled, Thanks for your patch ! :-) On Wed, 2011-11-30 at 09:11 +0200, Khaled Hosny wrote:
Here is a little patch that fixes a rendering buglet that annoyed me since ever. Native GTK applications swap the position of the button and editing area of comboboxes in RTL and themese expect that, but LO does not.
:-)
The same issue happens with spin buttons and other similar widget, I'm just making sure I'm doing it right before sending other patches.
Sure - it'd be great to have this all fixed up.
Also I'm not sure how GTK3 relates to this (is it affected/need to be fixed separately etc.) since I can't build with it here.
Sadly it'd be need to be fixed separately, that is one bit of code that cannot be shared; but gtk3 will be highly experimental for 3.5 so ... don't worry :-)
BTW, Application::GetSettings().GetLayoutRTL() is now used in several places (and may be more will come), would it be more rideable/save a few microsocends to have a
Ho hum; that method is a bit distressing, I'd hope that it would cache the value itself, and get notifications when / if it changes.
bool isLayoutRTL = Application::GetSettings().GetLayoutRTL()
Updating that can be a pain if/as/when the user tweaks it in the settings; clearly if we can do this at the top of the method, or (better) accelerate the GetLayoutRTL impl. itself ;-) Having said that we hsould prolly be using: inc/vcl/outdev.hxx: sal_Bool IsRTLEnabled() const { return mbEnableRTL; } on the OutputDevice if we have one around to improve efficiency. Another minor nit; it looks like the combo doesn't join up very elegantly with the drop-down in some themes [ cf. the attached image ] when in LTR mode - any thoughts on that ? Anyhow - I pushed the nice improvement :-) Thanks, Michael. -- michael.meeks@suse.com <><, Pseudo Engineer, itinerant idiot
Attachment:
rtl-combo.png
Description: PNG image