JGPICOM in development. updated config

[muzqs]

Sneak preview of a tweaker for Picom for jgmenu.

pic 1 ; full function.
pic 2 ; some settings disabled (not showing).

[napcok]

Wow
This is one of the things on my idea list that I never found time for.

Looks good

[muzqs]

Update: Added symlink save function to active config.

Default behaviour is when changing settings it’s just changes setting in picom.conf,
till you change to another config. The settings get lost.
Save values, if you want to keep them for next time.

Picom.conf is a symlink to the original. Thats how Mabox works.

• also translations for Es,Pl,En (deepl)

Next todo is a help section.

Need some more testing…

[muzqs]

JGPICOM Ready for testing. (community)

M bird / mabox_jgpicom · GitLab

Samenvatting

I adapted jgpicom-pipe because compton-toggle was not working properly. I changed the name to jgpicom_pipe

I removed greyscale from the pipe. No idea what it does. Something with Shaders.
Picom
Shaders
(easy to put back)
What is the difference with disabling picom.
Error (bug) unrecognized option '–glx-fshader-win. `

$ greyscale 
picom: unrecognized option '--glx-fshader-win'
picom v12 (~/.cache/yay/picom-git/picom revision fcb4a2d)
Standalone X11 compositor
Please report bugs to https://github.com/yshui/picom

[muzqs]

Last update:

• look a feel
• remove old code
• updated readme

M bird / mabox_jgpicom · GitLab

[muzqs]

@muzqs

Last update: 5 dec

small changes…

• look a feel
• translations
• remove old code
• updated readme

M bird / mabox_jgpicom · GitLab

[muzqs]

update to version : v0.0.1

M bird / mabox_jgpicom · GitLab

Im learning how to version my scripts.

• v0.0.1 marks the first version after a brief testing phase—it seems like a good starting point.

• As I dive deeper into the process, I keep discovering more possibilities for additional settings and features. (like windowtypes)

• This version primarily focuses on quick visual adjustments.

The documentation can be a bit confusing at times, with old and new styles (Compton vs. Picom) mixed together.

With the Picom config, it’s easier to fine-tune values for specific classes, etc. I need to study that further.

Currently, Mabox seems to use the older Compton-style configuration (if I’m not mistaken).
I’m considering switching to the Picom-style setup to modernize and align with current standards.

@napcok What are your plans for switching from the Compton to the Picom setup?

[napcok]

Hi @muzqs
At the moment I’m working on fixing the problem reported by @nekromancer and also improving the switching script (super +P).

When I finish the fixes I’ll take a closer look at your script

Thinking about the future…
I don’t really see how the format of the picom config file has changed with the last version. The old configs generally work.
It seems like a good idea to stick close to the sample config file provided by Picom → picom/picom.sample.conf at next · yshui/picom · GitHub

[muzqs]

@napcok

It seems like a good idea to stick close to the sample config file provided by Picom → picom/picom.sample.conf at next · yshui/picom · GitHub

Absolutly!

I think i am mistaken then and used the old mabox-conf.

Iam now using the sample config as template.
The only diffrence is the use of rules for me.
Probably i was still using the old config

New to me are the rules.

To be continued…

[muzqs]

@napcok I am a bit confused.

The default skel picom configs are different from the sample you gave.

@napcok

picom/picom.sample.conf at next · yshui/picom · GitHub

I guess the default for Mabox are still the ones in the skel dir.

Anyway i am working with the new config.

I think with both versions jgpicom and jgpicom-testing are fine to try-out, play with.

To be continued…

[napcok]

I’m talking about future…
I think that by creating a picom configuration tool like yours it will be easier to focus on current files like the example from the Picom repo.

Default from skel are probably few years old compton configs … when picom doesn’t even exist in Arch/Manjaro repositories.

Mabox in its current form - based on scripts started in 2016 - will not be developed for much longer and will go into maintenance phase with the next Herbolth release.

[muzqs]

@napcok

current files like the example from the Picom repo.

Thats the plan indeed. I was using the skel versions.

A good practice for the next one.

:BIIRD:

[muzqs]

@napcok

Thinking about the future…
I don’t really see how the format of the picom config file has changed with the last version. The old configs generally work.
It seems like a good idea to stick close to the sample config file provided by Picom → picom/picom.sample.conf at next · yshui/picom · GitHub

Ah, I see where the confusion lies now. I think.

I’ve been using the configuration files that come with Mabox.
However, the Picom GitHub config template differs significantly from the sample configuration in Mabox, particularly in the use of rules.

When starting using rules, Picom generates a warning popup, indicating that certain value expressions are no longer valid.
However, once those warnings are addressed and the invalid expressions are removed or corrected, the configuration works smoothly.

To address this, I incorporated the rules I’m currently using into the older configuration.
When you do this, Picom will display on-screen error messages that help guide you on what adjustments are needed. Here’s an example:

rules = (
  {
    match = "focused";
    opacity = 1.0;
    fade = true;
  },
  {
    match = "!focused";
    opacity = 0.95;
    fade = true;
  },

  {
    match = "window_type = 'utility' || window_type = 'notification'";
    #shadow = false;
    opacity = 1.0;
  },

  {
    match = "class_g = 'i3-frame' || class_i = 'i3-frame'";
    opacity = 1.0;
animations = (
      {
        triggers = [ "close", "hide" ];
        preset = "slide-out";
        direction = "down";
        duration = 0.1;
      },
      {
        triggers = [ "open", "show" ];
        preset = "slide-in";
        direction = "down";
        duration = 0.1;
      },
    )
  },

  {
	match = "window_type = 'dock'";
	shadow = true;
	opacity = 1.0;
animations = (
      {
        triggers = [ "close", "hide" ];
        preset = "slide-out";
        direction = "up";
        duration = 0.1;
      },
      {
        triggers = [ "open", "show" ];
        preset = "slide-in";
        direction = "up";
        duration = 0.1;
      },
    )
  },

  {
    match = "class_g = 'Dunst'";
    shadow = false;
    animations = (
      {
        triggers = [ "close", "hide" ];
        preset = "slide-out";
        direction = "right";
        duration = 0.1;
      },
      {
        triggers = [ "open", "show" ];
        preset = "slide-in";
        direction = "right";
        duration = 0.1;
      },
    )
  },
  { match = "class_g = 'Screenkey'"; shadow = false; },
  { match = "class_g = 'screenkey'"; shadow = false; },
  { match = " name = 'vistransparent'||
		name = 'cavatransparent'||
		name = 'quakeradio'||
		name ?= 'Glava'||
		name = 'xfce4-notifyd'||    
		name *= 'Conky'||
		name ~= 'Mabox Polaroid Widget'||
		name ?= 'org.nickvision.cavalier' ||
		window_type *= 'dock'||
		window_type *= 'toolbar'||
		window_type *= 'menu'	";
@include "terminator.conf"
},

  {
    match = "window_type = 'dropdown_menu' || window_type = 'popup_menu' || window_type = 'menu' || window_type = 'tooltip'";
    opacity = 1;
    fade = false;
    full-shadow = true;
  },

  {
    match = "class_i = 'rofi' || class_g = 'Rofi'";
    fade = true;
    opacity = 1;
    full-shadow = true;
  }
)

	animations = (
  {
    triggers = [ "geometry" ];
    preset = "geometry-change";
    duration = 0.1;
  },
  {
    triggers = [ "close", "hide" ];
    preset = "disappear"
    duration = 0.1;
  },
  {
    triggers = [ "open", "show" ];
    preset = "appear";
    duration = 0.1;
  }
)

jgpicom-testing uses rules.

Rules are quite nice i think.

It can make use of @include config files

In these files are the values set like

shadow = true;
opacity = 1;
etc

When you keep values in rule ({ },), jgpicom can get confused with other shadow values. To avoid multiple same output a @include can be usefull.
Picom encourage the use of rules above general settings.

I hope i explain it it bit ok.

To be kontinjoet…

[muzqs]

5 years or so ago i started to learn Arch (switching from debian).

My learning distro was Arcolinux from one of the devs and teacher Erik Dubios. (great video tuts)
In that time i learned about the skel folder.

Long story short i got confused with the function of skel and how it is used.

Anyway I learned the default path for Picom config.

etc/xdg/picom.conf.example

Video preview picom slide effect

[napcok]

The /etc/skel is a skeleton directory. It is used by useradd to create the default settings in a new user’s home directory.

Some info about how Picom currently works in Mabox and about recent updates and short-term plans

How Picom is used in Mabox?

Mabox uses own way to handle picom (start, restart, select config).
The goal was to have a mechanism to easy switch between different configs.
Just put your new config into ~/.config/picom/configs then select it easily from menu.

3 scripts are involved:

1. compton_toggle - toggle compositor quickly by super + P

2. mabox-compositor - wrapper script used to start, stop and restart picom

3. jgpicom-pipe dynamic pipemenu currently hooked into: Mabox Config → Compositor.Used to start/stop/restart, select rendering backend and so on… also for quickly select which config file for Picom you like to use.
   (After choosing config you like it is symlinked to ~/.config/picom.conf)

All above scripts were updated yesterday to fix problem reported recently.

Currently I’m working on pipemenu to make it work also as standalone dynamic menu (similiar to Colorizer modules for Openbox, Menus, Conky and Fonts)

---

picom-conf GUI

Picom-conf is a GUI for configuring picom. Added to Mabox repo yesterday…
Fork of well known compton-conf.

yay picom-conf-git

I did not tested it very well but basic functions seems to work fine. Might be worth to include it in future ISOs by default.

[muzqs]

@napcok

Currently I’m working on pipemenu to make it work also as standalone dynamic menu (similiar to Colorizer modules for Openbox, Menus, Conky and Fonts)

WOOWW… I think i need some time to see what has changed.
Very nice… Need to have a look at the restart toggle etc.
Discovert the change very quick after the update.

@napcok

picom-conf-git

I think i tested picom-conf with the old configs. That does’t work.
Will have a look at that with the updated config.

---

This Addon jgpicom-testing works for the time being.
creation de la enthausjashtico

Jgpicom testlab migrated to mabox_jgpicom

jgpicom testlab @ gitlab. Step by step (learning) converting from compton to picom structure. I renamed it for the time-being to: jgpicom-testing [Mabox_20241208-16-05-51] [giphy-251124714]

[muzqs]

It looks like it is partly using the old style config. Without rules.

After some testing, I am not convinced.

---

There are errors related to the previous config fashion.

Config after launching `Picom-conf` for the first time

shadow = true;
shadow-radius = 7;
shadow-offset-x = -7;
shadow-offset-y = -7;
shadow-exclude = [ “name = ‘Notification’”, “class_g = ‘Conky’”, “class_g ?= ‘Notify-osd’”, “class_g = ‘Cairo-clock’”, “_GTK_FRAME_EXTENTS@:c” ];
fading = true;
fade-in-step = 0.03;
fade-out-step = 0.03;
inactive-opacity = 0.8;
frame-opacity = 0.7;
inactive-opacity-override = false;
focus-exclude = [ “class_g = ‘Cairo-clock’” ];
corner-radius = 0;
rounded-corners-exclude = [ “window_type = ‘dock’”, “window_type = ‘desktop’” ];
blur-kern = “3x3box”;
blur-background-exclude = [ “window_type = ‘dock’”, “window_type = ‘desktop’”, “_GTK_FRAME_EXTENTS@:c” ];
backend = “xrender”;
vsync = true;
mark-wmwin-focused = true;
mark-ovredir-focused = true;
detect-rounded-corners = true;
detect-client-opacity = true;
detect-transient = true;
use-damage = true;
log-level = “warn”;
wintypes :
{
tooltip :
{
fade = true;
shadow = true;
opacity = 0.75;
focus = true;
full-shadow = false;
};
dock :
{
shadow = false;
clip-shadow-above = true;
};
dnd :
{
shadow = false;
};
popup_menu :
{
opacity = 0.8;
};
dropdown_menu :
{
opacity = 0.8;
};
};
active-opacity = 0.99;

[napcok]

Yes, I see that picom-conf overwrites the config file, removing all comments.

The question is: does it also break something in the process?

If it doesn’t break anything, it seems like a valuable tool

I’m looking for some config file in the “new syntax” to test this out, but I can’t find any.
Honestly, I don’t really understand what this new syntax is all about yet.

From picom-conf github repo
the list of compton options compared with the ones implemented in the configurator and in the new picom one

[muzqs]

@napcok

The question is: does it also break something in the process?

It gives an error every time you have used a value that is not supported.

when you know from the start what not to click it is ok.

@napcok

I’m looking for some config file in the “new syntax” to test this out, but I can’t find any.

Thats the picom.example.conf. Otherwise i don’t understand.

I test this with jgpicom-testing. You need terminator.conf from include folder. Thats for no shadow for cava etc.

muzlabz/testlab/-/blob/main/.config/picom/configs/TESTCASE.conf?ref_type=heads

I copied parts of the from someone else. Thats why dunst etc is in it. Not important for now.

[muzqs]

@muzqs

You need terminator.conf from include folder too. Thats for no shadow for cava etc.

edit

Location @include configs : ~/.config/picom/include