On Wed, Nov 30, 2011 at 01:12:08PM +0000, Michael Meeks wrote:
> 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 :-)
OK, someone will have to remember fixing them when GTK3 is the default :)
> > 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.
That is too complex for me :p so I'll keep doing what seems to work.
On a, not so, different note, I found that setting LibreOffice language
to one different from system language, e.g. LO in Arabic but LANGUAGE is
set to "en" and vice versa, GTK will be using the directionally of the
system language, so stuff that get reversed in RTL will not, while it is
reversed in LibreOffice resulting in the reverse of the bugs being
fixed. GTK takes the directionally from its translation catalog, so it
seems the gettext domain used by GTK is the one from system language
regardless of the actual LibreOffice language, may be there is a way to
fix this?
> 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 ?
No idea, those control are broken in different way in my machine. I'm
attaching two new patches now really fixing compoboxes (in your
screenshot, what I fixed earlier with the one with entry box) and spin
buttons.
This is really a huge improvements in the RTL UI, and case I didn't say
it before, LibreOffice is really the best thing that happened to OOo
since it was leashed upon the world (and I like the name, BTW).
Regards,
Khaled
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
