Terminal transparency in corefreq-cli

[leaty]

Largely unimportant, but I thought I'd ask anyway. Currently it looks like the following in urxvt:

While e.g. htop looks like this:

Is this already possible? Or could I at least achieve this with a custom corefreq-cli-rsc-theme-usr1.h?

I'm absolutely loving this regardless, but it could look nicer if it didn't override the background.

[cyring]

Hi, I'm still wondering about getting such transparency! I wish I would achieve that in future.

Sure you can customize corefreq-cli-rsc-theme-usr1.h. That's its purpose.

You can even create corefreq-cli-rsc-theme-usr2.h if you want me to make it part of the project as a second theme.

• Be prepare that a full theme will be a tedious task; something like:

  1. modify with your color choices
  2. fully rebuild the Client and UI

     make clean corefreq-cli

  3. test in various use-cases. ( scrolling, terminal resizing, menu, windows, etc )

• About the length of resources: it must be exactly the same as the original! In short, customization is just a replace action.

• There's a great chance you will need new color combinations (fg, bg), not provided yet by the macros: please let me know about all variations you need, I will provide them.

• Feel free to ask at any time.

[leaty]

I'm still wondering about getting such transparency! I wish I would achieve that in future.

Highly recommend it! It looks especially great with a smooth video background.

• There's a great chance you will need new color combinations (fg, bg), not provided yet by the macros: please let me know about all variations you need, I will provide them.

Actually, most terminal programs avoid setting any background colors, so as to use the default user preferences instead. Is this possible with a macro here as well?

[cyring]

• There's a great chance you will need new color combinations (fg, bg), not provided yet by the macros: please let me know about all variations you need, I will provide them.

Actually, most terminal programs avoid setting any background colors, so as to use the default user preferences instead. Is this possible with a macro here as well?

You mean altering the color palette ? Like changing the components {bg, fg, highlight and underline} of the current implemented macros ?

[leaty]

Yeah pretty much avoiding to set bg at all. Because if you do set it, it will override the global terminal settings.

Imagine two users with transparency, but each of them have different opacity and background colors configured. If you don't set bg at all, it should use their own configuration or the terminal defaults instead.

[leaty]

I read somewhere, that in ncurses, you use -1 to use the terminal default. I'm not sure if the same would work here but maybe. I'll give it ago!

[cyring]

Yeah pretty much avoiding to set bg at all. Because if you do set it, it will override the global terminal settings.

Imagine two users with transparency, but each of them have different opacity and background colors configured. If you don't set bg at all, it should use their own configuration or the terminal defaults instead.

Background of a zero value ?

There is a special value in CoreFreq UI which is zero in every components. Definition{.fg=0, .bg=0, .un=0, .hi=0} which translates to zero, informs the UI fuse function to continue without that character. https://github.com/cyring/CoreFreq/blob/ad622ca5e4cdb8a503da31a1049df609cd0545be/corefreq-ui.c#L1835

If transparency is based on zero then it's unfortunately not feasible.

[leaty]

After you showed me FuseAll, I got it to work by removing the following lines which are writing the background sequence :tada: https://github.com/cyring/CoreFreq/blob/ad622ca5e4cdb8a503da31a1049df609cd0545be/corefreq-ui.c#L1889-L1891

If transparency is based on zero then it's unfortunately not feasible.

I think I can still make this a theme with an if check in FuseAll, say if bg is -1, then skip those 3 lines. What do you think?

[cyring]

After you showed me FuseAll, I got it to work by removing the following lines which are writing the background sequence 🎉 https://github.com/cyring/CoreFreq/blob/ad622ca5e4cdb8a503da31a1049df609cd0545be/corefreq-ui.c#L1889-L1891

If transparency is based on zero then it's unfortunately not feasible.

I think I can still make this a theme with an if check in FuseAll, say if bg is -1, then skip those 3 lines. What do you think?

Oh ! Nice Let me handle this case. I have to evaluate all the drawing impacts, especially surface clearing, resetting and so on. I will also test with uxrvt

For latency reasons, I'm thinking about a new build directive to not compile the lines you are showing; rather than a runtime branch condition.

FuseAll is indeed the hot-spot of the Cli and UI call flow.

[leaty]

Alright sounds good, I'll configure a theme meanwhile and make a PR. Seems like the only changes I'd have to make basing off the original theme is to set white text for everything that previously had a white background (like the menus).

[leaty]

I know C is not my forte, but I can't seem to find the menu item color. I modified all lines which had bg = WHITE and replaced fg = BLACK with fg = WHITE, but it still looks like this:

[cyring]

I know C is not my forte, but I can't seem to find the menu item color. I modified all lines which had bg = WHITE and replaced fg = BLACK with fg = WHITE, but it still looks like this:

I will check tomorrow, but for now I suggest you first test your color without transparency.

EDIT: also note that:

1. Pure console rendering matters. Please also test in VT.
2. The console underline is forced to cyan. You'll have to compose with that.
3. No PR yet. I think about creating a development branch for the transparency enhancement.

[cyring]

Thanks to your tips, I'm adding the new branch develop-ui-transparency in which you can push your PR.

Like you, using urxvt -tr with Awesome DE, UI menus are fully blank except the dimmed braces These are among of the impacts I hope we will solve with just some color choices.

It's clear now that it's more appropriate to provide a second resources theme dedicated to transparency. I'm preparing this for next commit.

[cyring]

Please pull branch develop-ui-transparency, you now have a new file corefreq-cli-rsc-theme-usr2.h in which you can customize the transparency theme. FYI, this file is a copy/past/rename of the default color theme.

[leaty]

Awesome! I'll have a look after work, I really need to find the menu foreground though.

This is irrelevant but I thought I'd mention that -tr is not true transparency so it does not work with either a moving background, or if you have any floating windows behind it (tiling masterrace of course). Instead you can use e.g. *background: [80]#313842 in .Xresources, or if you use pywal like me- it has an option for both opacity and color bg. Since this is true transparency, it will require a compositor like picom or others.

EDIT: Don't forget xrdb .Xresources if you decide to try the above.

[cyring]

Awesome! I'll have a look after work, I really need to find the menu foreground though.

This is irrelevant but I thought I'd mention that -tr is not true transparency so it does not work with either a moving background, or if you have any floating windows behind it (tiling masterrace of course). Instead you can use e.g. *background: [80]#313842 in .Xresources, or if you use pywal like me- it has an option for both opacity and color bg. Since this is true transparency, it will require a compositor like picom or others.

EDIT: Don't forget xrdb .Xresources if you decide to try the above.

• Thanks for the tip. I have just tried rxvt-unicode for ArchLinux which works fine with Awesome. I will apply the background value for this class of Terminal in X resources and especially in the Awesome LUA config.

• To fully rebuild the UI with transparency:

  make clean corefreq-cli UI_TRANSPARENCY=1

• To apply the theme straight from start-up

  corefreq-cli -OE 2 -t

  in that order of options and with-t to invoke Top (optionally followed by a view name)

• At any time, you can switch theme from the Menu > Theme or using the keyboard shortcut [E] then select a theme.

[cyring]

Other things on the rxvt todolist:

• [F1], [Home] and [End] keys remain muted.
• [SHIFT] + Arrow keys don't move windows ( which can still be moved with [SHIFT] + {q/z/d/s} )
• [ALT] + Arrow keys don't resize the vertical height of windows.

[leaty]

* ( which can still be moved with [`SHIFT`] + {`q`/`z`/`d`/`s`} )

I see, qzds is like qwerty's wasd but for azerty right? What's your opinion on hjkl keys which is standard in many programs? Might be a nice addition.

[cyring]

* ( which can still be moved with [`SHIFT`] + {`q`/`z`/`d`/`s`} )

I see, qzds is like qwerty's wasd but for azerty right? What's your opinion on hjkl keys which is standard in many programs? Might be a nice addition.

I forgot to say wasd are also ready to play. I'm also an AZERTY user.

I made getkey to scan keys. The resulted scankey is a 64-bits value I will just have to add into the UI events loop.

[cyring]

OK, the RXVT keysym are now implemented in latest develop-ui-transparency

[leaty]

Oh nice, yeah I really thought you meant only qzds. Still, hjkl would be fancy. Unfortunately I have to retract my statement that I would attempt to fix the menu's today, I simply got no time for it I'm afraid. I'll get back to you once I got something.

[cyring]

Unfortunately h, k and l are already programmed as other shortcuts

[cyring]

Hello,

Thanks for your PR. This is what I'm getting (with my wallpaper)

[leaty]

Is that an inactive window getting the grey text? How do you open multiple windows?

Here is mine:

[leaty]

Oh I see, you have to use F keys to open menu again. Here's an equal view:

[leaty]

I suppose it will depend a little on your colorscheme and wallpaper/terminal background color and opacity settings, but 100% transparency like your example is often hard to pull off unless your colorscheme contrast is high enough on it's own to your wallpaper.

[leaty]

Yeah I double checked, the grey text on the inactive window does match a color which other cli programs seem to use. It just looked poorly in your example, so I'd say it's correct without modifying :+1:

Notice the percent signs and such:

[cyring]

Hi

• I have observed that some Linux distributions are altering the color palette. That's why you get yellow where I'm having magenta for the same color index encoded in your theme. Ubuntu is doing this whereas ArchLinux keeps the kernel definitions. I came to this conclusion by comparing the pure console and the XTerm rendering. Kernel source code of tty brings the truth of this issue.
• I created the main UI theme with this in mind. In addition, multiple tests were made across major distributions and X terminal emulators to define a coherent theme.
• Some emulators offer an option to toggle among palette; the native one is oftenly called linux or console
• To dim a color, like the percent character you mentioned, is obtained by a black highlighted foreground on a black background. Logically we should see nothing but if the emulator has the bright option enabled, you are getting the dimmed color. Console is doing it by default.

[leaty]

I have observed that some Linux distributions are altering the color palette.

Yes, some.

That's why you get yellow where I'm having magenta for the same color index encoded in your theme.

No, the colors you are seeing on my examples are custom. I grab one frame from video backgrounds and then I let pywal generate a color scheme based on the image.

In tty however, I am still using the default arch colors, and the inactive window in corefreq is definitely a little darker grey, but it still works fine because- of course it's a completely opaque black background.

I just meant that the grey color is typically bright enough to work with transparency, while the black color is often too dark (as seen previously in the menus). So, I think the grey color is reasonable, notably since other programs often use the same. After all if you do opt for transparency, there will always be a certain colorschemes that will not work well with certain backgrounds. It's up to the user to match them properly contrast-wise.

For instance, with the convenience of changing the color palette and wallpaper, live- using hotkeys. I can make this happen, and as you can see it doesn't really match very well.

[leaty]

What I think is best to pay attention to when it comes to transparency, is to use the more common color codes, which you have already done in corefreq's default theme. It was just the black (0) color that- as far as I have seen, is rarely if ever used in cli programs. Unless of course you have a background color, which the default theme had (white background on menus), only then the black foreground works.

But let me know if you find something you consider should be changed in the theme.

[cyring]

pywal is a nice piece of code and it confirms I should not touch the RGB palette. Things I thought about for the UI

I'm relying on your theme customization. That's the whole purpose of a user theme. If bug solving or enhancements are needed in the UI code, just let me know. Or, if job is done, I'm able to merge into master whenever you're asking me for it.

[leaty]

I should not touch the RGB palette

I agree, and you did it very well. I used magenta for select/focus to make the windows pop a little more, because it was the least used color in the interface. Since with transparency there is no background color to offset contrasts.

Everything I've tested so far works perfectly, I think it's ready for master :+1: