Box using scrollable property in Gtk3 fails

[zigbert]

The example-script should describe the issue.

When using scrollable="true", most other box properties fails (height works in example).
If hiding scrollbar with vscrollbar-policy="2", all properties seem to fail.

This occurs only in Gtk3. In Gtk2 everything works as expected.

export S='<vbox height-request="200" width-request="500" space-expand="false" space-fill="false">
  <text><label>GTK2 - scrollbar activated- 100px height</label></text>
  <hbox scrollable="true" height="100">
   <text><input>ls -l /</input></text>
  </hbox>
  <button ok></button>
 </vbox>'
gtk2dialog -p S -G +30+30 &

export S='<vbox height-request="200" width-request="500" space-expand="false" space-fill="false">
  <text><label>GTK2 - scrollbar hidden - No frame - 100px height</label></text>
  <hbox scrollable="true" vscrollbar-policy="2" shadow-type="0" height="100">
   <text><input>ls -l /</input></text>
  </hbox>
  <button ok></button>
 </vbox>'
gtk2dialog -p S -G +600+30 &

export S='<vbox height-request="200" width-request="500" space-expand="false" space-fill="false">
  <text><label>GTK3 - scrollbar activated - No frame - 100px height</label></text>
  <hbox scrollable="true" shadow-type="0" height="100">
   <text><input>ls -l /</input></text>
  </hbox>
  <button ok></button>
 </vbox>'
gtkdialog -p S -G +30+300 &

export S='<vbox height-request="200" width-request="500" space-expand="false" space-fill="false">
  <text><label>GTK3 - scrollbar hidden - No frame - 100px height</label></text>
  <hbox scrollable="true" vscrollbar-policy="2" shadow-type="0" height="100">
   <text><input>ls -l /</input></text>
   <height>100</height>
  </hbox>
  <button ok></button>
 </vbox>'
gtkdialog -p S -G +600+300 &

[step-]

If hiding scrollbar with vscrollbar-policy="2", all properties seem to fail.

Please try setting vscrollbar-policy="3" in the bottom right dialog. Do you get what you expect?
(You wrote "all properties" but I don't know exactly what those are; I can see the height is wrong).

The bottom left dialog doesn't show a scrollbar probably because it's using default GTK3 settings, which make scrollbars only display on hover. To make scrollbars display permanently - when enabled - set environment variable GTK_OVERLAY_SCROLLING=0 and add styles

*{
-GtkScrollbar-has-backward-stepper: 1;
-GtkScrollbar-has-forward-stepper: 1;
-GtkRange-slider-width: 13;
-GtkRange-stepper-size: 13;
}

Play out with those styles to find a minimum effective set - I think some styles are deprecated in subsequent GTK+ versions.

You can add the styles just for this window using gtkdialog option --styles or permanently for all GTK3 windows in $XDG_CONFIG_HOME/gtk-3.0/gtk.css.

[01micko]

@zigbert I think @step- has something there.

Still scrolls too. Of course a lot is dependent on the current system gtk3 theme too.

[step-]

Of course a lot is dependent on the current system gtk3 theme too.

Indeed some themes could cause further issues but not knowing which default theme a user has chosen, you can only throw in some defensive styles. I often add these two to the application stylesheet:

/* override theme */
.frame { border-style: none; } /* don`t frame boxes -- does not impact gtkdialog`s frame */
scrollbar.vertical slider { min-height: 0; } /* don`t make scrollable window taller than necessary */

[zigbert]

vscrollbar-policy="3" did the trick. Thanks a lot!

When it comes to frames on v/hbox, I tried the @step solution with his defensive css style, but it did not work here. At least not out of the box... I have to investigate further...

Most gtk3 themes in Puppy shows box-framing. Polished-Blue does not.

[dimkr]

@zigbert The Puppy GTK+ 3 themes are all based on raleigh-reloaded. Polished-Blue is special because it replaces big parts of it and has many images, while the other themes focus on buttons, scrollbars, etc' while leaving menus, frames, etc' intact, just like the old GTK+ 2 themes. It is perfectly possible that Polished-Blue has theme bugs, although I tested it very heavily and compared applications with dual GTK+ 2/3 support to ensure it's visually consistent.

I recommend Gradient-grey if you need a theme to test against, because it's very close to Raleigh and very consistent in sizing, spacing, etc'.

[step-]

When it comes to frames on v/hbox, I tried the @step solution with his defensive css style, but it did not work here. At least not out of the box... I have to investigate further...

Most gtk3 themes in Puppy shows box-framing. Polished-Blue does not.

@zigbert, I believe you can fix that issue directly in the themes. It's a different issue although confusingly it still involves frames. Take a look at this unmerged PR and see if it can help puppylinux-woof-CE/gtk3_flat_grey_rounded#6

@dimkr any comments?

[dimkr]

@step- I missed your PR for some reason 😊

I don't mind changes to the themes as long as these are small, safe and well-tested fixes for inconsistencies between GTK+ 2 and 3. GTK+ 3 themes can be very delicate, sometimes you fix something in one widget and end up breaking another because they inherit from each other: woof-CE just takes master, so the damage potential is non-zero.

If we start a theme bug fixing round, we should cherry-pick the same fix into 5 repos:

https://github.com/puppylinux-woof-CE/gtk3_gradient_grey
https://github.com/puppylinux-woof-CE/gtk3_polished_blue
https://github.com/puppylinux-woof-CE/gtk3_flat_grey_rounded
https://github.com/puppylinux-woof-CE/gtk3_stark_blueish
https://github.com/puppylinux-woof-CE/gtk3_buntoo_ambience

[step-]

I don't use those themes daily, so I can't vouch for spreading changes. I wrote that PR when I pushed gtk3_flat_grey_rounded to the fatdog repo but I don't use flat grey rounded myself. I remember that @jamesbond3142 was either using or testing that theme (or a derived one) and liked the change.