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.me...@suse.com <><, Pseudo Engineer, itinerant idiot
<<attachment: rtl-combo.png>>
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
