Combobox/Entry vertical padding
actionless opened this issue · 14 comments
Sorry - only just seen this and I can see you have reverted. I don't think it looked right having the combo boxes noticeably bigger than the buttons so agree with the revert.
however i did the same changes but for hidpi version of gtk2 theme (linked commit above)
and what was weird — everywhere except for awf-gtk2 button height is fine but particularly there buttons are like 20% smaller than needed, can't understand if that some bug in the theme itself or in awf
and noticed extremely funny thing while was tinkering those values in gtk2 and gtk3 themes — firefox renders button visual style from gtk3 theme but gets some of the dimensions from gtk2 theme...
🙀 🔫
This and this produce different results in awf for buttons but look identical in apps. What it does change in both apps and awf is column header size.
style "murrine-button" = "murrine-wider" {
xthickness = 10
ythickness = 10
style "murrine-button" = "murrine-wider" {
xthickness = 5
ythickness = 5
BTW - I think you introduced a little bug with 59d8c8b#diff-a27e52676f3db13e72f45663e727683a adding line 222 without deleting line 221.
Glad you looked at the combbox text colors - I'd come up with a slightly different and not fully working solution by creating a Combobox style class.
thanks, i'll try to resolve
when i'm setting it to 10 in awf it became normal but everywhere else larger than other controls (i tried nitrogen, obconf and gtk-parasite)
Hi,
I think I've got the bottom of why AWF is displaying the basic button size differently from apps in hidpi
Try removing GtkButtonBox::child-min-height = 52 or setting it to a lower value (26 or 0 work).
Revert to no xthickness ythickness declaration in murrine-button so it defaults to murrine-wider.
For me that results in the app buttons being the same size as the AWF buttons.
thanks! i'll try now
sorry for the delay, i had some other stuff to do + just following those changes was still not enough, i had to adjust couple more values and now finally in most of the apps button size stays more or less the same (but i still noticing some height variativity by like 2-3 pixels between some apps)
btw switching from naive oomox templates (%FG%, %SEL_BG%) to some real templates, like let's say jinja, would allow to do math outside scss (ie in gtk2 template in this case) so will be easier to make x/ythickness computed from oomox theme SPACING
cc @livanh who wanted to talk more on file formats
@smurphos hm, just noticed (in gimp) what minimal button size for some reason is not square, but rectangle:
btw switching from naive oomox templates (%FG%, %SEL_BG%) to some real templates, like let's say jinja, would allow to do math outside scss (ie in gtk2 template in this case) so will be easier to make x/ythickness computed from oomox theme SPACING
Googles jinja.......
That would be good. I added about 60 lines to a local copy of change_color.sh trying to get spacing to work in GTK2 reasonably well and managed to completely break hidpi in the process....
hm, just noticed (in gimp) what minimal button size for some reason is not square, but rectangle:
OK so I guess it does need that buttonbox minimum child height value set.
and managed to completely break hidpi in the process....
it could be because hidpi theme differs not only by spacing, and also those spacing-related values in gtk2 engines seems to be working not always as expected, so just straight multiplying of all the values to 2 will not really do the trick (actually, just see diff between those two files)
OK so I guess it does need that buttonbox minimum child height value set.
do you know what will be the difference here between adjusting xtickness, inner_border or setting minimum child height? 🦀
btw, also i think i need to clarify what spacing should be independent from pseudo-hidpi setting
ie spacing should be added to some base value, and next if pseudo-hidpi is enabled then the resulting value should be multiplied by 2