Guy Harris wrote:
On Feb 5, 2004, at 10:29 PM, Ulf Lamping wrote:
a) make the preference setting "Vertical scrollbar placement" take
effect for every scrolled window, not only the ones where currently
our function is used.
So is there some GTK+ or GNOME preference to let users select where
they want their scrollbars (in which case we should honor it - if
it's GNOME, presumably we'd do so only if GNOME is being used), or
is that purely left up to the application?
This setting is in "our" Preferences dialog, I don't know if there is
such a one in the common GTK+ / GNOME preferences. What are you
thinking of here exactly?
I was wondering whether there was some notion in GTK+ or GNOME of
scrollbar placement being a global preference that a user should be
able to set for all {GTK+,GNOME} applications.
Sun's OpenWindows had such a setting - I don't know whether it
affected only XView applications or also affected other OPEN LOOK
toolkits such as OLIT (it probably didn't affect non-OPEN LOOK toolkits):
http://docs.sun.com/db/doc/806-2901/6jc3a4m10?a=view
Motif appears to have X resources to control scrollbar placement, at
least for text widgets:
http://www.ist.co.uk/motif/books/vol6A/ch-18.fm.html
"The XmNscrollLeftSide and XmNscrollTopSide resources take Boolean
values that control the location of the ScrollBars within the
ScrolledWindow. By default, XmNscrollTopSide is set to False, which
causes the ScrollBar to be placed below the ScrolledWindow. The
default value of XmNscrollLeftSide depends upon the value of
XmNstringDirection. These two resources should not be set by the
application, but left to users to specify themselves."
so presumably the user would either tweak their X settings manually to
choose where scrollbars should be put, or might have some nice
preferences editor to control that (although I suspect not).
I don't see anything obvious in the KDE documentation for any class
with "scroll" in its name specifying either APIs or preference
settings to control the location of scrollbars (in fact, I don't see
any kdeui library classes with "scroll" in their names at all), or do
I see anything for QScrollView in the Qt documentation; the pictures
in the documentation for QScrollView show only scrollbars on the right
and bottom.
Well, as a Win32 user, I'm not used to tweak such GUI things like the
scrollbar, but that's ok for me.
For Win32 I'm pretty sure that there's no such global setting, although
I'm not doing much GUI programming at all.
I don't know how other platforms handle this, but as I read your mail
now, there usually seems to be no global way to get such a setting.
However, I changed the implementation of the sources (as described in
the CVS commit mail):
a) replace every gtk_scrolled_window_new() by our scrolled_window_new()
b) put a gtk_scrolled_window_set_policy(AUTOMATIC, AUTOMATIC) into
scrolled_window_new() to have a reasonable default
c) removed all gtk_scrolled_window_set_policy(AUTOMATIC, AUTOMATIC) and
such, at all the places existing
d) added GTK2 only gtk_scrolled_window_set_shadow(GTK_SHADOW_IN) at all
places appropriate
To b) this might already be the default setting after a
gtk_scrolled_window_new()?
To c) there were some gtk_scrolled_window_set_policy(ALWAYS) which
wasn't not very clever, as it's usually not a good idea to
show a scrollbar where nothing is to be scrolled
Td d) as there are lot's of scrolled_windows (espacially gtk/xy_stats.c)
where only the GTK1 clist is used, it would appear a double shadow
around these, if the gtk_scrolled_window_set_shadow() would be used as a
default
Guy asked, if the shadow style GTK_SHADOW_IN is the default for
GTK2/GNOME, well I just don't know. But as the current shadow (NONE) is
looking quite ugly in my eyes,
I need some response if the changes where ok.
BTW: the shadow is the small border around an "inside" window, letting
it look like it's carved in (like a passepartout) or coming out of the
parent window.
Regards, ULFL