Hello - I would like to ping this bug as I would like the same functionality. 
 
To reiterate: The gnome-terminal (like the konsole) has an option to put 
scrollbars on the LHS rather than the RHS. 
 
This is very useful for left-handed people, especially using input devices that 
resemble a pen, and particularly those with touch screens / tablet PCs, where 
scrolling on the RHS actually means you have to obscure the window. 
 
I would like to see the generic functionality for LHS/RHS scrollbars lifted 
from gnome-terminal (i.e. app-specific) and put into the general GTK toolkit 
(so its environment-specific), possibly with an entry in the accessibility 
section of the control centre. Then we could have all apps with LHS scrollbars 
w/o the authors having to write it in explicitly :) 

GtkScrolledWindow has a "window_placement" property, but unfortunately it is not
a style property.  If it were a style property, you could set it in your .gtkrc-2.0.

It would be easy to write a patch to add a style property for that.  Would you
like to give it a try?

Absolutely!

Created attachment 35299 [details]
captures calls to gtk_scrolled_window_new and sets policy to LHS scrollbars

Hi - not sure what progress you are making on this. I've had a stab at  
wrapping that call via LD_PRELOAD as an intermediate step. Someone may find  
this interesting!  
  
Hope you all had a good festive season. 

Created attachment 35300 [details]
to build the wrapper and test program

Created attachment 35301 [details]
a test program demonstrating gtk_scrolled_window_new

Created attachment 45112 [details] [review]
patch to change window_placement into a style property

Hi - the patch I've just attached applies to gtk+-2.6.2 (just testing 2.6.5
now). In brief, it changes window_placement from a gobject property into a gtk
style property, adds an accessor function and uses it in place of reading the
value directly (based on the method used by the existing style property
scrollbar_spacing). There is still some tidying up to do.

I'd *REALLY* appreciate some feedback on the following points:

a) changing the property from gobject to gtk/style: what would this potentially
break, how can I check to see things do?
b) via a find/grep combination it appears that nothing reads the property
directly from outside of gtkscrolledwindow.c, but if that was a 'valid' thing to
do in the past, it would break things now (in the same way reading
scrollbar_spacing directly could)

Still to do: remove some unnecessary commented out code, check initial value of
the property, change the new accessor function so it doesn't call an rc function
on each access (again in the fashion of scrollbar_spacing).

Created attachment 45113 [details] [review]
patch for gtk 2.6.5

Created attachment 45673 [details] [review]
sets window_placement to -1 (invalid); wraps all internal calls; checks style property on initial read

Hello. I've realised the other style property is a class var, not an instance
var, and that has changed the approach a little. I've used a similar '-1 is
invalid' thing which many people may not like - however with an enum -1 is
definitely invalid so it's safer than a straight integer. I've set the wrapper
static so nobody else uses it.

The get_style_property is now only called once rather than once per
window_placement access so this patch should be more efficient than the last.

Was busy these past two weeks hence slow speed getting this out :) please
comment.

Created attachment 46258 [details] [review]
use a GtkSetting instead of style property

Owen Taylor recommended on IRC that it should be a GtkSetting. This patch is
for 2.6.7. Comments please! :)

I chatted with Federico on IRC on 10th May about this and there was two things
that came up: 

1) removing the gobject property to implement the style property might break
programs that already use the former
2) there was some thought that this could be a useful xsetting

I've written a test program verifying the former. As for the xsetting, I am
looking into bringing this up on the xdg list (there are similar bugs filed
against kde, mozilla, etc.)

Created attachment 47003 [details]
proof-of-concept that my patch here potentially breaks things

$ gcc `pkg-config --libs --cflags gtk+-2.0` lhs-gobject.c
$ ./a.out 
the property thinks it's called: window-placement
$ LD_PRELOAD=<patched gtk>/gtk/.libs/libgtk-x11-2.0.so ./a.out
there is no window_placement property

Created attachment 47004 [details] [review]
the GObject setting is preserved; GtkSetting in addition

Here I don't remove the GObject setting, just add the GtkSetting as well. Now
that test-case program works:

$ ./a.out 
the property thinks it's called: window-placement
$ LD_PRELOAD=gtk+-2.6.7/gtk/.libs/libgtk-x11-2.0.so ./a.out 
the property thinks it's called: window-placement

(P.S. I wonder if the Nokia 770 will mean more left-handed people being
interested in a patch like this? I'm certainly tempted to buy one :-) )

Hello. Rather embarrassing, but I've just tried these patches against 2.6.8 and
everything since the first one to initialise the class var to -1 is broken (i.e.
the property is fixed at '3', which corresponds to bottom-right placement). I
believe this must have always been the case, and I have not noticed it since
I've only been paying attention to the orientation of the vertical scroll bars.
Work continues!

Jon: Thanks for your efforts.
On the -1 issue: I think you should check for inequality of the XSetting and the
"window-placement" object property, and if that's the case return the XSetting.
Thus, the g_param_spec_enum'ed property will never have an invalid value.

Also, you should namespace the XSetting to "gtk-scrolled-window-placement" and
change the nick/blob to
"Scrolled Window Placement"/"Where the contents of scrolled windows are located
with respect to the scrollbars"

It would be absolutely amazing for left-handed people if you could pick up work
on this patch again :).

> On the -1 issue: I think you should check for inequality of the XSetting and the
> "window-placement" object property, and if that's the case return the XSetting.
> Thus, the g_param_spec_enum'ed property will never have an invalid value.

Unfortunately, this doesn't work properly.

We can't distinguish whether a g_object_set is called for the default value, or
whether it was overridden. (g_object_new (GTK_TYPE_SCROLLED_WINDOW,
"window-placemnt", ... )). While we could set an internal
override_window_placement flag, which would be set if the setter is called with
a value different from the default XSetting value, we still can't react properly
to XSetting changes, because we can never know whether the last g_object_set was
done by the default or with custom code. If we provide a feature (overriding
default XSetting) which doesn't work all the time, we could have left it out in
the first place.

I'd rather deprecate gtk_scrolled_window_get_placement and
gtk_scrolled_window_set_placement and just make the scrolled window obey the
global XSetting. If we insist on being able to modify this on an individual
widget basis, we should IMHO provide a style property.

Owen: Why exactly do you prefer an XSetting over a style property?

It make no sense to me that these is an attribute of the theme. The
elements that come into play here are:

 - User-interface flipping for right-to-left languages
 - User preference
 - Possibly the application

An XSETTING is generally the right way to do User preferences. Style properties
cannot be set conveniently except by the theme, and asking users to switch
the entire appearance of their desktop to get the scrollbar in a different
place is silly.

Owen: Do you think that it makes sense to just ignore the application's request
(deprecating set_placement/get_placement, that is, and ignoring the value of
"window-placement") and always use the XSETTING? I can't think of any reason why
this behavior should be inconsistent among multiple scrolled windows on screen,
except if they're run in different contexts (RTL vs. LTR)?

I'm accepting this bug. I hope this is OK with you, Jon.

if you move bugs away from gtk-bugs@gtk.org, please add that as the QA Contact.
(We don't usually pay attention to the assignee, but if it's helpful to you
feel free to do it. As long as you add the QA Contact.)

Created attachment 52030 [details] [review]
Proposed (untested) patch

The attached patch contains an XSETTING implementation. The window's settings
are only obeyed if its "window-placement-set" property is TRUE. I've copied the
screen_changed handler from GtkButton (btw. excellent code :D).

Created attachment 52031 [details] [review]
Proposed (untested) patch #2

This one actually compiles.

Ping.

I haven't tested the patch in comment #24, but it looks more or less sane.

1. Are there apps (in the GNOME CVS) that explicitly set the placement?

2. Would they break if your patch by default doesn't obey that placement unless
they get modified to use the placement-set property?

3. What if you make the default be "obey the XSETTING unless the app has set the
placement explicitly"?

> 1. Are there apps (in the GNOME CVS) that explicitly set the placement?

[1] just lists gturing. The rest seem to be bindings.

> 2. Would they break if your patch by default doesn't obey that placement
> unless they get modified to use the placement-set property?

According to [2], gturing just displays a canvas in a scrolled window. I don't
know what you mean by break.

> "obey the XSETTING unless the app has set the placement explicitly"

That's exactly what the patch does, see gtk_scrolled_window_set_placement_set.
Obviously, I should replace the call with a g_object_set_property, so that a
change notification can take place.

[1] http://tinyurl.com/bdpez
[2] http://cvs.gnome.org/viewcvs/gturing/src/graph_editor.c?annotate=1.4

It turns out that my implementation of gtk_scrolled_window_set_placement_set
already emits "window-placement-set". I wonder whether it is emitted twice when
gtk_scrolled_window_set_placement_set is invoked from
gtk_scrolled_window_set_property.

Oh!  If it's just GTuring, don't worry about it :)

You are getting two emissions because GObject automatically emits the
"notify:foo" when you change an object property through g_object_set(). 
Normally you need to split your internal setters into this:

static void
setter_internal (GtkFoo *foo, int value, gboolean notify)
{
  foo->frob = value;
  if (notify)
     g_object_notify (foo, "frob");
}

void
gtk_foo_set_frob (GtkFoo *foo, int value)
{
   setter_internal (foo, value, TRUE);
}

static void
gtk_foo_set_prop (GObject *object, guint prop_id, const GValue *value,
GParamSpec *pspec)
{
   switch (prop_id) {
      case PROP_FOO:
         setter_internal (object, g_value_get_int (value), FALSE);
         break;
   }
}

Patch looks good. 
Have you tested it, Christian ?

At some point, we should probably look into consolidating the various
run-over-the-widget-hierarchy-on-screen-change instances into a callback
mechanism that iterates only once over the tree...

*** Bug 320618 has been marked as a duplicate of this bug. ***

Patch needs some more work. 
I'll attach a screenshot of testgtk after setting

gtk-scrolled-window-placement = top-right

Created attachment 61247 [details]
screenshot

Created attachment 61617 [details] [review]
Proposed (tested) patch #3

It was as simple as replacing more occurences of scrolled_window->window_placement  by priv->real_window_placement. Seems to work like a charm with all sizing and text direction combinations.

2006-03-20  Matthias Clasen  <mclasen@redhat.com>

        * gtk/gtk.symbols:
        * gtk/gtkscrolledwindow.h:
        * gtk/gtkscrolledwindow.c: Add a window-placement-set property
        and a gtk-scrolled-window-placement setting.  (#157025, Christian
        Neumair)

This bug is marked as fixed; how can I implement it?  Say I want all my GTK apps to put the scrollbar on the left; is there something I can enter in ~/.gtkrc-2.0?

gtk-scrolled-window-placement = top-right