After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 726795 - regression from gtk2 behaviour when sharing adjustments
regression from gtk2 behaviour when sharing adjustments
Status: RESOLVED DUPLICATE of bug 730730
Product: gtk+
Classification: Platform
Component: Widget: GtkScrolledWindow
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2014-03-20 20:18 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2014-10-05 03:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
standalone bug repro (5.99 KB, text/x-csrc)
2014-03-20 20:25 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
  Details
log from irc discussion (7.02 KB, text/plain)
2014-05-27 20:35 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
  Details
update the api docs (1.45 KB, patch)
2014-05-27 20:49 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
reviewed Details | Review
update the api docs (1.47 KB, patch)
2014-06-13 19:32 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
committed Details | Review

Description Stefan Sauer (gstreamer, gtkdoc dev) 2014-03-20 20:18:29 UTC
I am attaching a standalone test. This worked fine with gtk+2. The example is putting two treeview widgets left-right into a scrolled-window each. It shares the adjustment of the right one with the left one. The point of the exercise is to have a sticky left column. In order to not have the scrollbars duplicated in both views, the code sets GTK_POLICY_NEVER on the left view.

In gtk3 this effectively makes the widgets as large as the content. That is the scrollbars never show up on the right side and when the treeview gets new rows, the windows grows instead of showing scrollbars. This is pretty bad, as when loading large project files, the window grows beyond the screen size.
Keeping the scrollbars set to GTK_POLICY_AUTOMATIC works, but looks ugly.

I hope we can find a work around as well as a proper fix. Imho the scroll-bar policy is not related to the size calculations at all.
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2014-03-20 20:25:14 UTC
Created attachment 272517 [details]
standalone bug repro

gcc -Wall -g syncviews.c -o syncviews `pkg-config gtk+-3.0 --cflags --libs`
# expose bug: GTK_POLICY_NEVER
./syncviews
# GTK_POLICY_AUTOMATIC
POLICY_AUTO=1 ./syncviews
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2014-03-21 07:14:33 UTC
The issues is in gtk_scrolled_window_size_allocate()
https://git.gnome.org/browse/gtk+/tree/gtk/gtkscrolledwindow.c#n1878

I haven't yet found the commit that introduced the bug, let alone a sensible workaround. I'll probably have to patch the vmethods in my app :/
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2014-05-25 19:41:59 UTC
See a first patch for the scrolling issues in bug #730730.

A work around for this issues is to show the scrollbar and manually hide them. I have to re-hide them every now and then though. It would be nice if anyone could atleast confirm that there is a bug or tell me what I am doing wrong here :/
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2014-05-27 20:35:48 UTC
Created attachment 277343 [details]
log from irc discussion
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2014-05-27 20:49:04 UTC
Created attachment 277344 [details] [review]
update the api docs
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2014-05-27 21:57:25 UTC
Lets discuss the api to control the visibility scrollbar:

gtk_scrolled_window_set_scrollbar_visibility(GtkScrolledWindow *scrolled_window, gboolean hscrollbar_visible, gboolean vscrollbar_visible);
and two boolean gobject properties "{h,v}scrollbar-visible"

Or can we add another enum-value to GtkPolicyType? E.g. GTK_POLICY_SYNCED (or _SLAVED). This way we could avoid combinations of hscrollbar_visible and hscrollbar_policy=NEVER.
Comment 8 Tristan Van Berkom 2014-06-12 20:51:17 UTC
Review of attachment 277344 [details] [review]:

This docs patch looks good to me, however if we're going to change it, please also change the reference to GtkCList for a reference to GtkTreeView or GtkTextView ... as the GtkCList has been obsolete for over 10 years.
Comment 9 Stefan Sauer (gstreamer, gtkdoc dev) 2014-06-13 19:32:02 UTC
Created attachment 278425 [details] [review]
update the api docs
Comment 10 Matthias Clasen 2014-10-05 03:51:06 UTC
I've put a patch for GTK_POLICY_EXTERNAL in bug 730730, lets discuss things over there.

*** This bug has been marked as a duplicate of bug 730730 ***