Carbon Themes (beta version)

johnraff · 2025-04-28 00:31:36

micko01 wrote:

I suppose I did create a mime-type

Seems so. I haven't been able to find any references to it on the web. I guess mimetypes are mostly used to help associate files with apps, but this case of setting an icon looks reasonable enough.
---
I forgot to re-run the tests I did to try to find an installed "application/linux-kernel" mimetype, this time after adding the xml file under packages/ and running update-mime-database:

john@boron:/usr/share/mime$ grep -ri kernel .
./application/linux-kernel.xml:<mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="application/linux-kernel">
./application/linux-kernel.xml:  <comment>Linux kernel vmlinuz file</comment>
grep: ./mime.cache: binary file matches
./types:application/linux-kernel
./globs:application/linux-kernel:vmlinuz*
./globs2:50:application/linux-kernel:vmlinuz*
./packages/bunsen-configs.xml:  <mime-type type="application/linux-kernel">
./packages/bunsen-configs.xml:    <comment>Linux kernel vmlinuz file</comment>
john@boron:/usr/share/mime$ find . -iname '*linux*'
./application/linux-kernel.xml
./application/x-font-linux-psf.xml
./application/x-gz-font-linux-psf.xml

So it's definitely there now.
Also, note that linux-kernel.xml has been created under application/ presumably by 'update-mime-database'.

And, if you right-click the vmlinuz file in Thunar and look at "Properties", whatever has been put inside the xml <comment> tag appears under "Kind:". That's a plus even for people who are using an icon theme that doesn' support "application/linux-kernel" (probably most of them).

But it raises the question of what happens if there are two xml files under packages/. I could imagine the magic and glob conditions just adding up as OR conditions, but what about the comment? Another thing to test...

micko01 · 2025-04-28 01:22:28

^As you were likely typing this I fired in the PR : https://github.com/BunsenLabs/bunsen-configs/pull/140

Just a quick summary:

changed the comment to "linux kernel image"
in the main tree I created the dir mime/packages and placed the application-linux-kernel.xml file in there.
added
```
mime usr/share
```
to {bunsen-configs,bunsen-configs-base,bunsen-configs-lite}.install files

micko01 · 2025-04-28 01:35:22

johnraff wrote:

But it raises the question of what happens if there are two xml files under packages/. I could imagine the magic and glob conditions just adding up as OR conditions, but what about the comment? Another thing to test..

There are several xml files in /usr/share/mime/packages. I think it's a non-issue.

johnraff · 2025-04-28 01:47:14

^^Thanks!
Looks perfect, and merged.

johnraff · 2025-04-28 01:55:01

micko01 wrote:

johnraff wrote:
But it raises the question of what happens if there are two xml files under packages/. I could imagine the magic and glob conditions just adding up as OR conditions, but what about the comment? Another thing to test..
There are several xml files in /usr/share/mime/packages. I think it's a non-issue.

Yes there are many xml files there, but I meant two xml files referring to the same mimetype, eg if some future Debian package installed something configuring "application/linux-kernel" under a different filename. Anyway, I tested and the result seemed to be that one of them was ignored, but didn't explore what the priority was. As you say, probably not something to worry about.

micko01 · 2025-04-28 03:36:24

hhh wrote:

A new thread focusing on the default desktop items and their themes.
Here's where I'm at now (with big-clock conky, that won't be the default config). Themes in the neofetch, this uses xfce4-panel instead of tint2...
https://i.imgur.com/qdyVWx4m.png
https://i.imgur.com/hPL8U5em.png
Note that the OS is boron, I don't have carbon installed yet. Waiting for the transitional freeze in mid-March.
Also note that I spelled my host name incorrectly.

So wayland/labwc/xfce4-panel on Carbon isn't much different visually

Note that I have a 3px left only margin set in ~/.config/labwc/rc.xml to get the floating appearance.

Also pnmixer is a no go in wayland so using the xfce pulse-audo-plugin. BT and NM are in the systray as per normal. Rounded corners are begat by ~/config/gtk3/gtk.css

/* xfce4-panel settings */
.xfce4-panel {
  border-radius: 10px;
}

johnraff · 2025-04-28 04:17:49

^Looks very promising.

micko01 wrote:

pnmixer is a no go in wayland so using the xfce pulse-audo-plugin

In that case let's look at replacing pnmixer with xfce4-pulseaudio-plugin for carbon X11 too.

Is that OK with pipewire BTW?

PS It's a pity the icon is so huge. Throws the panel right out of balance.

EDIT: a fix of sorts is to put this into ~/.config/gtk-3.0/gtk.css:

#pulseaudio-button image { -gtk-icon-transform: scale(0.6); }

and then run xfce4-panel -r

https://forum.endeavouros.com/t/graphic … 6/10681/21
https://forum.xfce.org/viewtopic.php?id=11626

Last edited by johnraff (2025-04-28 04:52:17)

PackRat · 2025-04-28 09:46:05

johnraff wrote:

Is that OK with pipewire BTW?

Yes, the plugin works with pipewire.

johnraff · 2025-04-29 02:05:24

^Thanks for confirming that!

So switch from pnmixer to xfce4-pulseaudio-plugin, both X11 and Wayland?

One disadvantage is that it is tied to xfce4-panel, unlike traditional systray apps like pnmixer which should work in any panel. It's a pity there doesn't seem to be a Wayland-compatible equivalent...

DeepDayze · 2025-04-29 02:34:53

johnraff wrote:

^Thanks for confirming that!
So switch from pnmixer to xfce4-pulseaudio-plugin, both X11 and Wayland?
One disadvantage is that it is tied to xfce4-panel, unlike traditional systray apps like pnmixer which should work in any panel. It's a pity there doesn't seem to be a Wayland-compatible equivalent...

Perhaps a bug report to the developer of pnmixer to consider adding Wayland support?

johnraff · 2025-04-29 04:20:31

I wouldn't hold out too much hope for an upgrade of pnmixer. The last release 0.7.2 came out in 2017.
https://github.com/nicklan/pnmixer/releases
https://bugs.debian.org/cgi-bin/bugrepo … ug=1093842

johnraff · 2025-04-29 06:22:29

Sorry @micko01 I'm afraid that mime type issue still needs a little attention.

All my testing above was done on a Debian Bookworm system, but the utilities have changed a bit in Trixie.

tl:dr I think the mime type we set in the xml file should be application/x-linux-kernel ( note the x- ) to maximize harmony with other utilities. (And rename /usr/share/mime/packages/application-linux-kernel.xml to /usr/share/mime/packages/application-x-linux-kernel.xml)

Here's the evidence:

On Bookworm

john@boron:~$ file -i /boot/vmlinuz-6.1.0-34-amd64
/boot/vmlinuz-6.1.0-34-amd64: application/octet-stream; charset=binary

On Trixie:

john@trixie-tester:~$ file -i /boot/vmlinuz-6.12.21-amd64 
/boot/vmlinuz-6.12.21-amd64: application/x-linux-kernel; charset=binary

Either the kernel has added a new header and/or the magic data that 'file' uses has changed. The latter seems to be true:
On Bookworm

john@boron:~$ strings /usr/lib/file/magic.mgc | grep linux-kernel

On Trixie:

john@trixie-tester:~$ strings /usr/lib/file/magic.mgc | grep linux-kernel
application/x-linux-kernel
application/x-linux-kernel

(magic.mgc is a binary file that stores all the "magic" data related to file headers - that I didn't look at earlier.)
And this: https://github.com/file/file/blob/maste … gdir/linux

But we still have to add the xml file anyway because xdg-mime hasn't caught up, and that (or something related) seems to be what Thunar and probably the icon setting mechanisms use:
On Trixie:

john@trixie-tester:~$ xdg-mime query filetype /boot/vmlinuz-6.12.21-amd64 
application/vnd.microsoft.portable-executable

On Bookworm it was "application/x-ms-dos-executable" but whatever.
Anyway we still need to link the vmlinuz* filenames with the mimetype, but I would suggest making it application/x-linux-kernel so that any utilities using the magic data will be in agreement.

johnraff · 2025-04-29 06:55:10

micko01 wrote:

Rounded corners are begat by ~/config/gtk3/gtk.css
/* xfce4-panel settings */
.xfce4-panel {
  border-radius: 10px;
}

Tested
Just take out the panel's rounded corners in picom.conf rules: to avoid clashes, and it looks good.

Uh-oh, it looks fine on Wayland, but for some reason on X11 that GTK rounding rounds different parts of the panel separately. See the bottom left corner, around the volume icon and systray?

(Picom rounds the corners correctly.)

EDIT: this fixes it on X11 (yet to test Wayland) - makes the CSS selector more specific:

.xfce4-panel#XfcePanelWindow {
  border-radius: 10px;
}

https://gitlab.xfce.org/xfce/xfce4-pane … note_85830

Theming guide:
https://docs.xfce.org/xfce/xfce4-panel/theming
and
https://docs.xfce.org/xfce/xfce4-panel/start

Last edited by johnraff (2025-04-29 07:29:57)

micko01 · 2025-04-29 23:19:50

johnraff wrote:

Sorry @micko01 I'm afraid that mime type issue still needs a little attention.

No problem

johnraff wrote:

All my testing above was done on a Debian Bookworm system, but the utilities have changed a bit in Trixie.
tl:dr I think the mime type we set in the xml file should be application/x-linux-kernel ( note the x- ) to maximize harmony with other utilities. (And rename /usr/share/mime/packages/application-linux-kernel.xml to /usr/share/mime/packages/application-x-linux-kernel.xml)
Here's the evidence:
On Bookworm
john@boron:~$ file -i /boot/vmlinuz-6.1.0-34-amd64
/boot/vmlinuz-6.1.0-34-amd64: application/octet-stream; charset=binary
On Trixie:
john@trixie-tester:~$ file -i /boot/vmlinuz-6.12.21-amd64 
/boot/vmlinuz-6.12.21-amd64: application/x-linux-kernel; charset=binary
Either the kernel has added a new header and/or the magic data that 'file' uses has changed. The latter seems to be true:
On Bookworm
john@boron:~$ strings /usr/lib/file/magic.mgc | grep linux-kernel
On Trixie:
john@trixie-tester:~$ strings /usr/lib/file/magic.mgc | grep linux-kernel
application/x-linux-kernel
application/x-linux-kernel
(magic.mgc is a binary file that stores all the "magic" data related to file headers - that I didn't look at earlier.)
And this: https://github.com/file/file/blob/maste … gdir/linux
But we still have to add the xml file anyway because xdg-mime hasn't caught up, and that (or something related) seems to be what Thunar and probably the icon setting mechanisms use:
On Trixie:
john@trixie-tester:~$ xdg-mime query filetype /boot/vmlinuz-6.12.21-amd64 
application/vnd.microsoft.portable-executable
On Bookworm it was "application/x-ms-dos-executable" but whatever.
Anyway we still need to link the vmlinuz* filenames with the mimetype, but I would suggest making it application/x-linux-kernel so that any utilities using the magic data will be in agreement.

I get the same on trixie/carbon.

I'll fix it.

Interestingly, I must have known that in the back of my mind because the mime-icon is already there.

mick@dellhome:~/Github/labbe-min-ng/labbe-min-arrongin/scalable/mimetypes$ tree
.
├── application-kernel.svg
├── application-linux-kernel.svg -> application-kernel.svg
├── application-vnd.efi.img.svg -> application-x-raw-disk-image.svg
├── application-x-img.svg -> application-x-raw-disk-image.svg
├── application-x-linux-kernel.svg -> application-kernel.svg
├── application-x-qemu-disk.svg -> application-x-raw-disk-image.svg
└── application-x-raw-disk-image.svg

I uninstalled my tester package, rebuilt fixed, reinstalled and the icon (to my initial surprise) showed my tux take correctly in /boot and / (for the symlink).

Side note: apt must detect when fiddling with mime-types becuase there is definitely no postinst in the package.

Output:

mick@dellhome:~/Misc/kernel-mime/2$ sudo apt install ./kernel-mime-type_0.2-1_all.deb 
Note, selecting 'kernel-mime-type' instead of './kernel-mime-type_0.2-1_all.deb'
Installing:
  kernel-mime-type

Summary:
  Upgrading: 0, Installing: 1, Removing: 0, Not Upgrading: 18
  Download size: 0 B / 2,252 B
  Space needed: 13.3 kB / 21.6 GB available

Get:1 /home/mick/Misc/kernel-mime/2/kernel-mime-type_0.2-1_all.deb kernel-mime-type all 0.2-1 [2,252 B]
Selecting previously unselected package kernel-mime-type.
(Reading database ... 368876 files and directories currently installed.)
Preparing to unpack .../kernel-mime-type_0.2-1_all.deb ...
Unpacking kernel-mime-type (0.2-1) ...
Setting up kernel-mime-type (0.2-1) ...
Processing triggers for shared-mime-info (2.4-5+b2) ...

johnraff · 2025-05-01 04:48:50

micko01 wrote:

apt must detect when fiddling with mime-types because there is definitely no postinst in the package.
Output:
mick@dellhome:~/Misc/kernel-mime/2$ sudo apt install ./kernel-mime-type_0.2-1_all.deb 
...
Setting up kernel-mime-type (0.2-1) ...
Processing triggers for shared-mime-info (2.4-5+b2) ...

Ah yes, dpkg triggers! I'd forgotten about those.
See the content of:

less /var/lib/dpkg/info/shared-mime-info.postinst
less /var/lib/dpkg/info/shared-mime-info.triggers

https://stackoverflow.com/questions/152 … se-trigger
https://web.archive.org/web/20111022012 … ers-howto/
https://wiki.debian.org/DpkgTriggers
https://raphaelhertzog.com/2011/05/30/t … s-painful/

Last edited by johnraff (2025-05-06 04:39:16)

johnraff · 2025-05-01 05:12:19

@micko you've been doing a lot of work on these labbe-min and Material-Solarized icon themes recently - do you think the time is approaching when we make them available from the regular BL Carbon repo?

micko01 · 2025-05-01 09:02:47

johnraff wrote:

@micko you've been doing a lot of work on these labbe-min and Material-Solarized icon themes recently - do you think the time is approaching when we make them available from the regular BL Carbon repo?

For sure! Do you want to build them from source? That way you can peruse the flavours and decide what's in and what's out. As stated, simple matter of deleting $flavour.install and editing control.

johnraff · 2025-05-05 06:14:11

As a basic principle, I think it's good that all the source repos for packages in the BL apt repo can be found in one place, clearly under our control and responsibility, and that our packages are built from that source.

In this case, I'd say there are two options:
1) You make a "Carbon" branch on your repo, which you maintain as you see fit. We would clone that branch and sync it with your branch before building BL packages from it. So the package contents would be under your control.
or
2) We (BL organization) clone your repo and fork the BL "Carbon" branch on our side, editing in the way you suggest above, before building. Of course, with your BL dev hat on, you could be part of that work anyway.

I'm fine with either way. The main difference would be in where the git commit log is for the $flavour tweaking.

micko01 · 2025-05-05 12:32:13

Option 2 is my preference. You've heard of "the bus factor" right?

hhh · 2025-05-05 16:30:56

Just stay out of the street! Handle it how you prefer, my 2 cents.

#81 2025-04-28 00:31:36

Re: Carbon Themes (beta version)

#82 2025-04-28 01:22:28

Re: Carbon Themes (beta version)

#83 2025-04-28 01:35:22

Re: Carbon Themes (beta version)

#84 2025-04-28 01:47:14

Re: Carbon Themes (beta version)

#85 2025-04-28 01:55:01

Re: Carbon Themes (beta version)

#86 2025-04-28 03:36:24

Re: Carbon Themes (beta version)

#87 2025-04-28 04:17:49

Re: Carbon Themes (beta version)

#88 2025-04-28 09:46:05

Re: Carbon Themes (beta version)

#89 2025-04-29 02:05:24

Re: Carbon Themes (beta version)

#90 2025-04-29 02:34:53

Re: Carbon Themes (beta version)

#91 2025-04-29 04:20:31

Re: Carbon Themes (beta version)

#92 2025-04-29 06:22:29

Re: Carbon Themes (beta version)

#93 2025-04-29 06:55:10

Re: Carbon Themes (beta version)

#94 2025-04-29 23:19:50

Re: Carbon Themes (beta version)

#95 2025-05-01 04:48:50

Re: Carbon Themes (beta version)

#96 2025-05-01 05:12:19

Re: Carbon Themes (beta version)

#97 2025-05-01 09:02:47

Re: Carbon Themes (beta version)

#98 2025-05-05 06:14:11

Re: Carbon Themes (beta version)

#99 2025-05-05 12:32:13

Re: Carbon Themes (beta version)

#100 2025-05-05 16:30:56

Re: Carbon Themes (beta version)

Board footer