<ensonic> hi, I have a patch in #730730, anyone a minute to review?
<mclasen> ensonic: I don't think the patch is sufficient - there's more places where we look at h/vscrollbar_visible
<ensonic> mclasen: not in this file, the other gtk_widget_get_visible() calls are regarding the child
<mclasen> and this needs a more general fix to support this use case - like an 'external-control' property or somesuch
<ensonic> mclasen: the size calculation are still wrong, I was planning to fix this next
<ensonic> mclasen: what do you mean by external-control?
<mclasen> currently, the gtkscrolledwindow code assumes: no scrollbar -> no scrolling
<ensonic> I think the code is simply confusion the scrollbar policy with the presence of the adjustments
<ensonic> mclasen: the scrollbar is only the view, the adjustment is what matters
<mclasen> grep for hscrollbar_visible - it is i used all over the place
<tristan> mclasen, I can't recall exactly what was the rationale, but that limitation happened while doing height-for-width on scrolled window, I know I'm somewhat responsible for the limitation
<tristan> it may have to do with the GTK+3 rule: Thou Shalt Not Allocate less than the request, Ever.
<tristan> which was not a rule in GTK+2
<tristan> there could be a "mode" added to scrolled window to allow this, essentially a scrolled window without scroll bars must request it's real child width, unless it knows that it has a way to scroll content
<ensonic> mclasen: I know, it still needs to be fixed for the layout, but I don't want to have this in a single patch
<mclasen> its not just layout
<ensonic> tristan: the scrolled window does have an adjustment, it just does not have a visible scrollbar for it
<mclasen> the gesture handling code looks at it to decide which gestures to claim, etc
<ensonic> tristan: if I set the scrollbar to be AUTO or ALWAYS and just manually hide the scrollbar (notify::visible) "things work fine"
<ensonic> which is what I have to put into my code to be able to ever release my app since I ported it to gtk3 :/
<tristan> ensonic, in fact they do no "work fine"
<tristan> ensonic, when you add wrapping content to your scrolled window, inside that hbox with the other content on the left, and you have no horizontal scroll bar, then you need the scrolled window to report the minimum/natural request of the child
<tristan> ensonic, so that the parent hbox can "do the right thing" when negotiating size for it's child scrolled window and ${other} sibling
<tristan> allowing the hscrollbar to be present (even if you forcefully "hide" it), will result in a width request of either 0 or 1 pixels wide
<ensonic> tristan: what has the scrollbar to do with it?
<tristan> if the policy is NEVER, then the scrolled window will request the child minimum/natural widths
<ensonic> tristan: instead of the adjustment with the lower/upper/page-size
<tristan> ensonic, you lose that context if the policy is !NEVER
<tristan> ensonic, imagine a scrolled window with wrapping content, it has a minimum width and a maximal natural request
<tristan> it means "make sure it's at least this wide, and stop competing for space after 'natural' width"
<ensonic> tristan: nope, from the docs: "GTK_POLICY_NEVER: The scrollbar will never appear." & "GtkPolicyType : Determines when a scroll bar will be visible."
<tristan> i.e. it's got a vertical scrollbar but horizontal = NEVER
<tristan> ensonic, bare with me
<ensonic> okay, go on
<tristan> you *want* the vertical-only swindow to request it's child's minimum/natural as requests
<tristan> you don't get that if the horizontal policy is !NEVER
<tristan> the docs may fail to mention that enabling/disabling a scrollbar has the very real effect of enabling the child's request
<tristan> and it might not work the way you want it to for some other context (scrollable but no scrollbars, which currently does not exist in GTK+3)
<ensonic> tristan: bth, you reinterpret the semantics here in a new way, in gtk+2 and according to the docs GtkPolicyType controls when to show the scrollbars and not when they would be needed
<tristan> however the reason why it is this way, as far as I can recall, is so that the child's natural/minimum request is actually meaningful
<tristan> sure
<tristan> ensonic, that was done around 3 or 4 years ago, yes, and perhaps the docs need to reflect that, yes.
<ensonic> tristan: why would one otherwise share adjustment, if not for making one scrollbar affect multiple views
<mclasen> ensonic: that reinterpretation happened a long time ago
<ensonic> tristan: well, the docs should be updated, but for me the ultimate quetion is how to implemnt my usecase now, any suggestions?
<tristan> ensonic, that does not mean that it is not possible to create a semantic to do that explicitly, however the default is to report child sizes
<ensonic> out of curiosity, whats the usecase left for gtk_scrolled_window_new() to pass existing adjustments?
<tristan> ensonic, well
<tristan> ensonic, I would imagine one of those fancy code editors which gives you a preview on the right - show position in file - is a good case ?
<tristan> even both adjustments, those little navigator windows (show the whole surface inside a 200x200 box and drag the window around to position the main view)
<ensonic> tristan: but then you can already call gtk_scrolled_window_new(NULL,NULL) and set the adjustments it creates
<tristan> or you can call the constructor with the adjustments which are already built in your app, yes.
<ensonic> anyway, I really need to undersand how one is supposed to implement a scrolled-window now where the scrollbars are not shown, the notify hack is not a solution in the long run,
<tristan> ensonic, basically both cases are important - and only an explicit semantic can allow the swindow to behave one way, or the other
<tristan> ensonic, when we did height-for-width, we would have lost a lot of request context by always requesting the minimum/natural of the child - it was important then
<tristan> ensonic, and now, years later, we have a couple of people missing that functionality that *you* want
<tristan> so if it's a requirement, let's make it a requirement and add some kind of "mode" to the scrolled window, right ?
<tristan> seems pretty straight forward to me
<ensonic> tristan: sorry to be a bit stubborn, why would one use a scolled-window in the first place, if you set GTK_POLICY_NEVER?
<ensonic> to limit scolling in either x or y?
<ensonic> tristan: I mean using a scrolled_window with GTK_POLICY_NEVER for both x and y is not useful, right?
<ensonic> tristan: also can you update the docs in this regard, or should I try a patch and you review it?
<tristan> ensonic, in the way which I described above, actually I regularly disable horizontal scrolling in scrolled windows
<tristan> but sure, I'll put myself on CC for that bug and when I get a chance over the week I'll try to cook up a good phrase, or review the one you propose
<ensonic> now that '{h,v}scrollbar-policy' properties are taken for the layout, we'd need the new properties to be called '{h,v}scrollbar-visibility' and make them booleans?
<mclasen> thats what I meant with 'external-control', more or less
