Don't blacklist UIs with an RTL direction

[Andrea Cimitan]

The guidance is to render scrollbars on the right irrespective of the RTL direction set by default in the application.

Was: we must blacklist rtl languages at the moment, because the proximity is hardcoded to be at the left of the scrollbar

[Christian Giordano (nuthinking)]

Because having the overlay scrollbar, as currently designed, on the left could have problems with other UI elements. For the time being we will force it on the left also for RTL languages. We will reconsider this strategy when more data will be available.

[Christian Giordano (nuthinking)]

Sorry, I meant "force it on the right".

[David Barth (dbarth)]

That means that the scrollbar should be positioned systematically on the right side of scrollable windows, disregarding the RTL direction set at the toolkit level. It is the case in our code, so we can remove the requirement to blacklist applications for which the direction is set to RTL and just position the scrollbars as we do now.

As for the thumb, I also interpret the guidance as: don't move them either, ie don't respect the RTL direction indication from the toolkit.

@Cimi: can you remove the blacklist please and mark the bug fixed once done. THanks

[Andrea Cimitan (cimi)]

For natty, RTL will use native scrollbars (I don't want to require a
FFe for something we are not completely sure of and that might expose
new issues we should really avoid since we are in beta freeze).
For oneiric, we might need to patch gtk+ to force the new positioning.

Cheers

On Thu, Mar 24, 2011 at 12:14 PM, David Barth <email address hidden> wrote:
> That means that the scrollbar should be positioned systematically on the
> right side of scrollable windows, disregarding the RTL direction set at
> the toolkit level. It is the case in our code, so we can remove the
> requirement to blacklist applications for which the direction is set to
> RTL and just position the scrollbars as we do now.
>
> As for the thumb, I also interpret the guidance as: don't move them
> either, ie don't respect the RTL direction indication from the toolkit.
>
> @Cimi: can you remove the blacklist please and mark the bug fixed once
> done. THanks
>
>
> ** Changed in: ayatana-scrollbar
>       Status: Fix Released => In Progress
>
> ** Changed in: ayatana-scrollbar
>     Assignee: (unassigned) => Andrea Cimitan (cimi)
>
> ** Summary changed:
>
> - blacklist RTL languages
> + Don't blacklist UIs with an RTL direction
>
> ** Description changed:
>
> - we must blacklist rtl languages at the moment, because the proximity is
> - hardcoded to be at the left of the scrollbar
> + The guidance is to render scrollbars on the right irrespective of the
> + RTL direction set by default in the application.
> +
> +
> + Was: we must blacklist rtl languages at the moment, because the proximity is hardcoded to be at the left of the scrollbar
>
> --
> You received this bug notification because you are a member of Ayatana
> Scrollbar Team, which is subscribed to ayatana-scrollbar.
> https://bugs.launchpad.net/bugs/741071
>
> Title:
>  Don't blacklist UIs with an RTL direction
>
> Status in Ayatana Scrollbar:
>  In Progress
>
> Bug description:
>  The guidance is to render scrollbars on the right irrespective of the
>  RTL direction set by default in the application.
>
>
>  Was: we must blacklist rtl languages at the moment, because the proximity is hardcoded to be at the left of the scrollbar
>

--
Andrea Cimitan - http://www.cimitan.com
Software Engineer | Desktop Experience Team
Product Strategy | Canonical Ltd

[Andrea Cimitan (cimi)]

This bug has no reason to exist now, as it depends on the specific gtk+ patch.
Later someday, we might decide to explore a different solution for proper gtk+ scrollbars/scrolled windows etc etc... and we might decide to open a new bugreport