blue-submarine: Use procedural adaptive-sized icons

[cwendling]

This makes the Blue-Submarine icons (close/maximize/restore/minimize) resize with the size of the titlebar. It is most useful for people with low vision that will use a large font, and for some kind of consistency when using that large a font. I imagine something like this could also improve experience on HiDPI setups as the icons are currently 10x10, which might be very small on those setups (or get blurry if scaled up).

Is dynamic icon sizes a change that would be welcome inside the Blue-Submarine theme? If so, is it OK like that, or are there adjustments I should be doing?

Here are the before/after with various font sizes:

11pt (default): 9pt: 20pt: 32pt:

Arguably look could possibly gain from the thickness of the lines growing when the size grows. It's a real pain to do with Metacity themes (I don't know of any ifs, so it's a game of making lines overlap or not depending on the size -- and even that requires a pretty convoluted set of instructions), but it's doable if wanted. Here's an attempt (which was needlessly painful, could even get thicker lines, and I didn't bother yet adjusting the outlines):

This said, very large font sizes are probably unlikely on most user's setups, so the look would stay mostly the same for most users.

[raveit65]

Amazing that you did this painful job. Editing metacity themes is real awful. LGTM, can you please do the same for the other themes from this theme family? It should just be copy&paste.

• Blue-Submarine-border
• Green-Submarine
• Green-Submarine-border

[cwendling]

@raveit65 Done, this part was indeed trivial (I just had to adjust colors for Green version, but apart from that it was just applying the same patch).

[lukefromdc]

Ths could be a real problem solver for compiz-reloaded, whose devs have decided NOT to use a partial HiDPI fix for gtk-window-decorator. Anything that can be fixed there for hidpi should be doable in themes, and if the SAME theme works in all screen resolutions that problem goes away.

I have NOT found a way to do with with image file icons that works the same at all screen resolutions, and works the same in marco (supports hidpi) and compiz-reloaded's gtk-window-decorator (does not resize for hidpi) so I ended up using a forked version of gtk-window-decorator for now.

If I can find a way in my own theme to make this work with image icons (or to define in the theme image icons that contain circles) I can dump that forked version of gtk-window-decorator. Looks from the changed file like I would have to define the image in the metacity-theme file, and my UbuntuStudio-Legacy theme uses circles etc. Is this coding same as or similar to what an SVG file uses?

[lukefromdc]

We DO get a problem with 4K and window-scaling=2 in marco or any WM/window decorator whose behavior is consistant with marco in supporting window scaling. Icons are reduced in size and thicker:

Here is green-submarine at 4K with marco (or my forked gtk-window-decorator-hidpi) and window-scaling = 2 Here is green-submarine at 4K with compiz-reloaded's non-hidpi supporting gtk-window-decorator, and the text size alone opening up the title bar to a reasonable width (as normally occurs with most themes):

[cwendling]

We DO get a problem with 4K and window-scaling=2 in marco or any WM/window decorator whose behavior is consistant with marco in supporting window scaling. Icons are reduced in size and thicker:

Bummer. Could we have a look at the 4K version with the icons? Also, what is your titlbar font size? Because one thing that looks odd to me is that looking at the icons and the scrollabr, they seem similar to what I'd get on my non-HiDPI screen if I select a font size of 8.5 or so. At such super small sizes, the previous icons would take more space relative to the area given to them compared to larger sizes, as they would always take up 8px (+outline), no matter what area is given to them. I could make the padding depend on the available size (that would be a little painful, but doable), but it still seem odd to me the titlebar would be so small relative to scrollbars and such. Almost like scaling to HiDPI was not done all the way -- or just maybe you use a super tiny font?

Again, an odd thing to me is that both your screenshots have the same pixel size for the titlebar: if the one on top is adapting to HiDPI and the one on the bottom isn't, I would have expected the top one to be twice as big.

Also, how do other themes work regarding that? An obvious non-image-based one is HighContrast, and Clearlooks also (and Clearlooks seems very smart at adapting to size, maybe I should look at how it does it).

[raveit65]

@cwendling Any chance to increase the button-size in relation to font-size? For me it looks a bit to small, especially when window is maximize. Here the restore button looks undefined for me. Screenshot with HIDPI and 10px fontsize, which is my normal setup.

Sadly, the gtk-windows-decorator from compiz-reloaded doesn't start any more in fedora, in result i see only the old cairo-decorator (fallback) when using a gtk-decorator theme. So i cant test this. I stopped maintaining compiz-reloaded 1.5 years ago in general and fedora, and now it is broken :/

[alexarnaud]

@raveit65 Just to let you know, a new Compiz Reloaded has been published and bring many fixes. You can contact me off if you have any issues regarding Compiz Reloaded. I really care about it maintained in distros because it is the only one way for a low-vision people like me to use Mate. The screen magnifier is part of Compiz.

Otherwise, I confirm the fix proposed by @cwendling works with gtk-window-decorator (I don't have a HiDPI display).

[cwendling]

@raveit65 Hum I see your titlebar is super small as well. I'm wondering if there's not an issue in HiDPI in that regard.

Anyway, yes, I can make the images take more available room, and you can actually test it super easily: change the value of the IconPadding constant so something smaller. I used a value that seemed to get results similar to the images at the default font size without HiDPI (as I don't have any HiDPI displays to play with), but I can change that to whatever seem best.

[raveit65]

Found the issue with compiz-reloaded, Building with marco was disabled by new fedora compiz maintainer. I guess because of build problems with development of marco-1.23. Any way, i am just rebuilding compiz stack to newest 0.8.18 at my box.

[raveit65]

Blue-Submarine-compiz-10px-non-hidpi

Blue-Submarine-compiz-10px-hidpi

Blue-Submarine-compiz-20px-non-hidpi

Blue-Submarine-compiz-20px-hidpi

Still wondering what should be wrong with gtk-decorator from compiz-reloaded-0.88.18 ?

Only that buttons on maximize windows (10px) looks a bit squashed with HIDPI, same as with marco VM. Or the height of the tilebar itself looks too small for maximize windows?

[cwendling]

Only that buttons on maximize windows (10px) looks a bit squashed with HIDPI, same as with marco VM.

You mean the middle button? That is the "restore" button (i.e. "unmaximize") and it's supposed to be smaller than the "maximize" one -- this was the same with the images, although possibly less accentuated than at those sizes.

I still feel there's a problem with HiDPI: I don't understand why the titlebar should be smaller. I understand how it could (if no scaling is applied to the actual dimensions), but that looks wrong, as it means it doesn't look the same on a HiDPI and non-HiDPI monitor (the titlebar look a lot smaller).

[raveit65]

Only that buttons on maximize windows (10px) looks a bit squashed with HIDPI, same as with marco VM.

You mean the middle button? That is the "restore" button (i.e. "unmaximize") and it's supposed to be smaller than the "maximize" one -- this was the same with the images, although possibly less accentuated than at those sizes.

No, i mean all 3 buttons when window is maximixed.

I still feel there's a problem with HiDPI: I don't understand why the titlebar should be smaller. I understand how it could (if no scaling is applied to the actual dimensions), but that looks wrong, as it means it doesn't look the same on a HiDPI and non-HiDPI monitor (the titlebar look a lot smaller).

I think you're right, with the smaller titlebar all 3 buttons are looking a bit squashed for me. Let me play a bit with the IconPadding.

[raveit65]

OMG, honestly, i don't understand this syntax :/ eg.

<line color="rgba(0, 0, 0, 0.28)" x1="IconPadding - 1 -(1)" y1="height - IconPadding + 1 -(1)" x2="width - IconPadding + 1 -(1)" y2="height - IconPadding + 1 -(1)" />

[cwendling]

<line color="rgba(0, 0, 0, 0.28)" x1="IconPadding - 1 -(1)" y1="height - IconPadding + 1 -(1)" x2="width - IconPadding + 1 -(1)" y2="height - IconPadding + 1 -(1)" />

• <line/> well, I guess you know what that is :)
• color="rgba(0, 0, 0, 0.28)" that's the color, in rgba() notation, here it's black with 28% alpha.
• x1="IconPadding - 1 -(1)" the X coordinate of the starting point of the line. IconPadding is a constant defined above (search for <constant name="IconPadding"), so effectivly a plain integer (it should be 5 if you didn't touch it yet). -1 is because I don't include the outline (which is what this <line/> instruction is about) in the padding, i.e. the padding is around the light shape, and the outline is around that shape. -(1) is just meaning -1 in a way that stands out visually (maybe I could introduce a constant here like IconOffset or so, which could be clearer). You can look above, there is a comment:

  BEWARE: all those weird "-(1)" at the ends is to offset 1px to the top left because somehow otherwise we look off to the right. A proper fix would probably be to move it at an upper hierarchical level, but that way it works nicely with the existing state (including pressed framing)

• y1 is basically like x1, but obviously in Y.
• Ditto for x2 and y2 which are the end position of the line. height and width reference the size of the area where the icon can be drawn, e.g. the dimensions of the button.

From there, well, you'll have a hard time checking all instructions because it's a so dumb and needlessly complex syntax, which doesn't even allow for operations inside constants or so, so I can't wrap anything in a more contained fashion. Also, I don't know of a way of separating the colors from the shape (as the color is on each drawing operation), so I couldn't factorize for the different states, hence some copy & paste.

Also for example drawing the cross is actually 6 lines (not counting the outline), because the corners can't be done with a thicker line, so each "line" of the cross is actually 3 perpendicular 1px lines next to each other. And I'm not even talking about the outline, which is well, the outline of the cross shape, so 16 ops (and not really obvious ones, even).

[raveit65]

All with marco. Blue-Submarine-icon-padding-4

Blue-Submarine-icon-padding-4-hidpi

Blue-Submarine-icon-padding-3

Blue-Submarine-icon-padding-3-hidpi

With or without HIDPI my favorite is iconpadding 3.

[lukefromdc]

The issue with compiz-reloaded's gtk-window-decorator and hidpi is simple: it does NOT implement window-scaling, the only reason the titlebar is not even smaller is the font holding it to a minimum size. You can see this with very narrow borders around the rest of each window, as they are in native window-scaling=1 size even if the contents of the window are at window-scaling=2.

I wrote somewhat rough initial support for window-scaling in gtk-window-decorator https://gitlab.com/lukefromdc/compiz-core/-/tree/hidpi-autoscale but compiz-reloaded devs decided not to use it unless I could get compiz-core supporting window scaling as well (which would help many plugins) and have decided that hidpi support is not really on their roadmap. Thus, I have chosen to keep that fork for my own use. As gtk-window-decorator.c is the only changed file, it can be built inside compiz-reloaded from current master, manually renamed, and used as a separate hidpi decorator without disturbing your normal compiz install or being overwritten by updates. I name it gtk-window-decorator-hidpi but have not gotten around to renaming it in the source, and creating a standaline build system that just depends on having compiz-reloaded installed rather than building inside the compiz-core build directory.

[alexarnaud]

@lukefromdc Could you please give the link of the Compiz merge request where you propose it?

[raveit65]

The issue with compiz-reloaded's gtk-window-decorator and hidpi is simple: it does NOT implement window-scaling, the only reason the titlebar is not even smaller is the font holding it to a minimum size. You can see this with very narrow borders around the rest of each window, as they are in native window-scaling=1 size even if the contents of the window are at window-scaling=2.

Ok, but what does the narrow border to do with windows buttons from this PR? See my screenshots with latest compiz-0.88.18. The window buttons are displayed well with or without HIDPI, and different front-sizes.

Your screenshot of green-submarine looks complete different than my results from PR. Results with PR and greensubmarine, HIDPI and compiz-reloaded-0.88.18 10px Window title:

20px Window title:

It looks like that you are using icon-images from mate-themes master branch in your screenshot., or not? With BlueMenta which use icon-images too, i see the problems with HDPI-scaling.

[raveit65]

The issue that you described affects only metacity themes which use icon-images for the window-controls, eg BlueMenta. So this isn't related to PR, because PR replaces the icon-images.

[lukefromdc]

I had replaced the metacity theme file but left the images in the directory, they should not have been used. (EDIT: just verified this by removing them and retesting, same results) The compiz-reloaded PR is at https://gitlab.com/compiz/compiz-core/-/merge_requests/156

[lukefromdc]

Remember also that with compiz-reloaded as currently shipped, this PR works perfectly with hidpi and the buttons look good in my tests (gtk-window-decorator --replace using the normal gtk-window-decorator). It's with marco and with compiz-reloaded with https://gitlab.com/compiz/compiz-core/-/merge_requests/156 applied (same behavior as marco) that we get the small, thick images

[raveit65]

@cwendling Can you change iconpadding? Than i am fine with PR and i will approve it. Personal i can't reproduce an issue with compiz-reloaded (which i don't use normally), and i don't understand why i should use a closed MR from compiz-reloaded which seems to break this PR, like Luke said.

After that you guys should decide to merge this PR or not......

[lukefromdc]

Note that what https://gitlab.com/compiz/compiz-core/-/merge_requests/156 does is to match as closely as I could the behavior of compiz-reloaded's gtk-window-decorator to the behavior of marco, in my tests of this the behavior was identical between the two of them. Thus, anything that works in marco should also work with that.

[cwendling]

@raveit65 Updated with IconPadding=3

@lukefromdc what I don't get is that @raveit65's Marco HiDPI tests do not show the same results you reported… or maybe again, you use a very small font size (8.5 or so), I don't think you answered that question I had to try and understand what you saw.

All in all, I really think that HiDPI should not affect the look of a theme if the WM properly support HiDPI; that's kind of the point of the whole scaling thingy. And IIUC that's what happens to @raveit65, his results are basically identical in HiDPI or not (minus the HiDPI ones are twice as big pixel-wise).

[lukefromdc]

Font size I use with this hidpi monitor is 9.0 so that may be the difference

[cwendling]

@lukefromdc that's probably it indeed, as smaller font sizes mean smaller icons now, whereas with the images they always had the same size (which I believe was larger than "expected" using small font sizes). Could you check with the new IconPadding values? It should look nicer in smaller font sizes, so it might improve on your end.

[lukefromdc]

Out of time today, about to head out the door

[lukefromdc]

Was able to do it fast: indeed icons look a lot better now: still a little thick but reasonably scaled:

[raveit65]

@cwendling Blue-Submarine/Blue-Submarine: Use 3px for icon padding

This commit message is weird :)

Can you change it? Or better move that in commits for GreenSubmarine and BlueSubmarine. Having 2 commits, one for each gtk-theme seems the best.

[raveit65]

@lukefromdc Do you like to approve it or are concerns open?

[lukefromdc]

Good enough

[cwendling]

@raveit65 oops, that was a typo. It's fixed and split into one commit for each pair of themes.

[raveit65]

I squashed the commits for each theme, in result we have only 2 commits.

[cwendling]

Makes sense, thanks!