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 601738 - [StBoxLayout,StScrollView] handling scrolling in just one direction
[StBoxLayout,StScrollView] handling scrolling in just one direction
Status: RESOLVED DUPLICATE of bug 609015
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2009-11-12 20:00 UTC by Colin Walters
Modified: 2010-02-24 21:23 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Colin Walters 2009-11-12 20:00:21 UTC
I have a St.ScrollView() which contains a St.BoxLayout({ vertical: true }), which itself contains many St.Label({ text: "foooooooo" }).  Now St.Label ellipsizes at the end by default.

What I want is to have no horizontal scrollbar, and to get the labels ellipsized.  However, what I end up with is that the allocation given to the St.BoxLayout is the size of the scrollview, and then St.BoxLayout assumes it's scrolled horizontally.  But there is no horizontal scrollbar.

Owen and I discussed passing the knowledge of scrolling direction down into the scrollable child via the adjustments; i.e. the ScrollView _allocate would set up the adjustment min/max, then call the _allocate for the child.

Alternatively, StScrollable could have a special _allocate_scrollable function.  But this would need analysis for how it interacted with the clutter allocation handling.
Comment 1 Colin Walters 2009-11-12 20:03:18 UTC
Related to this is - we probably want an explicit API for scrollable policy like GtkScrolledWindow has?  Rather than hiding/showing the scrollbar, which won't really work if we ever want an _AUTO policy.
Comment 2 Thomas Wood 2009-11-12 21:14:08 UTC
I've tried to avoid an explicit policy property for ScrollView in Mx, because it is usually used to avoid fixing problems with the Adjustments.

With respect to the particular BoxLayout use case, I think this should be fixed by allowing BoxLayout to use it's minimum sizes to determine when to start scrolling.
Comment 3 Florian Müllner 2010-02-24 21:23:40 UTC

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