[Libreoffice] [PATCH] Fix rendering of GTK combobox in RTL

[Khaled Hosny]

Oops, the patches :)

On Fri, Dec 02, 2011 at 11:43:37PM +0200, Khaled Hosny wrote:
> 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