Creating a script for Yakuake at system startup brakes the global theme

Continuing the discussion from Dark theme not working in Dolphin after Manjaro update:

This a follow-up of the aforementioned topic.

@Fabby, I am currently installing Manjaro KDE in another laptop and preparing to follow your suggestion regarding backing up the system. Before creating a cold system backup, I am setting the themes in the Workspace and in the main applications, in order to prevent a full reconfiguration in case of need to restore a backup.
While doing so, I realised that if I use a script to control Yakuake using D-Bus messages at system startup, the problem of the theme comes up! :confused:
This is an important issue to me, because in my daily workflow I use several terminals, and having the possibility to start the computer with all of them already configured and to access and hide them by pressing one key is a great advantage.
I don’t know if the script I created is wrong or has some design flaw. Every time it is executed, there is a notification warning me of the risks of using D-Bus messages in Yakuake and the need to recompile it (I don’t know exactly what the message says, because I suppressed it).

The script I’m using in both machines has the following structure:


sleep 2

function runit {
cmd="qdbus org.kde.yakuake $1"
eval $cmd &> /dev/null
sleep 0.5

# change tab's name
runit "/yakuake/tabs setTabTitle 0 'Main'"
# split terminal
runit "/yakuake/sessions org.kde.yakuake.splitTerminalTopBottom 0"
runit "/yakuake/sessions org.kde.yakuake.splitTerminalLeftRight 0"
# run 'htop' in first terminal
runit "/yakuake/sessions runCommandInTerminal 0 'htop'"
# run 'Vimwiki' in second terminal
runit "/yakuake/sessions runCommandInTerminal 1 'nvim ~/.vimwiki/'"
# run 'TaskWarrior' in third terminal
runit "/yakuake/sessions runCommandInTerminal 2 'task'"

# start new session in new tab
runit "/yakuake/sessions org.kde.yakuake.addSession"
runit "/yakuake/tabs setTabTitle 1 'Extra'"
runit "/yakuake/sessions org.kde.yakuake.splitTerminalLeftRight 3"
runit "/yakuake/sessions runCommandInTerminal 3 'clear'"
runit "/yakuake/sessions runCommandInTerminal 3 'neofetch'"

Is there anything I can do to prevent these issues while being able to use Yakuake scripting at system startup? Or should I change my approach?
Thanks in advance for your help.

Here is the output of inxi -Fazy:

Kernel: 5.14.10-1-MANJARO x86_64 bits: 64 compiler: gcc v: 11.1.0
parameters: BOOT_IMAGE=/boot/vmlinuz-5.14-x86_64
root=UUID=7237cc4d-9ab7-410c-90c4-b8c90e2b10df rw quiet apparmor=1
security=apparmor udev.log_priority=3
Desktop: N/A wm: kwin_x11 dm: SDDM Distro: Manjaro Linux base: Arch Linux
Type: Laptop System: LENOVO product: 4180Q3U v: ThinkPad T420
serial: <filter> Chassis: type: 10 serial: <filter>
Mobo: LENOVO model: 4180Q3U serial: <filter> UEFI-[Legacy]: LENOVO
v: 83ET82WW (1.52 ) date: 06/04/2018
ID-1: BAT0 charge: 15.2 Wh (98.7%) condition: 15.4/56.2 Wh (27.4%)
volts: 12.4 min: 10.8 model: SANYO 45N1001 type: Li-ion serial: <filter>
status: Unknown
Info: Dual Core model: Intel Core i7-2640M bits: 64 type: MT MCP
arch: Sandy Bridge family: 6 model-id: 2A (42) stepping: 7 microcode: 2F
cache: L2: 4 MiB
flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 bogomips: 22338
Speed: 2201 MHz min/max: 800/3500 MHz Core speeds (MHz): 1: 2201 2: 2105
3: 802 4: 1811
Vulnerabilities: Type: itlb_multihit status: KVM: VMX unsupported
Type: l1tf mitigation: PTE Inversion
Type: mds mitigation: Clear CPU buffers; SMT vulnerable
Type: meltdown mitigation: PTI
Type: spec_store_bypass
mitigation: Speculative Store Bypass disabled via prctl and seccomp
Type: spectre_v1
mitigation: usercopy/swapgs barriers and __user pointer sanitization
Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional,
IBRS_FW, STIBP: conditional, RSB filling
Type: srbds status: Not affected
Type: tsx_async_abort status: Not affected
Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics
vendor: Lenovo ThinkPad T420 driver: i915 v: kernel bus-ID: 00:02.0
chip-ID: 8086:0126 class-ID: 0300
Device-2: Chicony integrated camera type: USB driver: uvcvideo
bus-ID: 1-1.6:5 chip-ID: 04f2:b221 class-ID: 0e02
Display: server: X.Org 1.20.13 compositor: kwin_x11 driver:
loaded: modesetting alternate: fbdev,vesa display-ID: :0 screens: 1
Screen-1: 0 s-res: 1920x2100 s-dpi: 96 s-size: 507x555mm (20.0x21.9")
s-diag: 752mm (29.6")
Monitor-1: LVDS-1 res: 1600x900 hz: 60 dpi: 131 size: 310x174mm (12.2x6.9")
diag: 355mm (14")
Monitor-2: DP-3 res: 1920x1200 hz: 60 dpi: 94 size: 518x324mm (20.4x12.8")
diag: 611mm (24.1")
OpenGL: renderer: Mesa DRI Intel HD Graphics 3000 (SNB GT2)
v: 3.3 Mesa 21.2.3 compat-v: 3.0 direct render: Yes
Device-1: Intel 6 Series/C200 Series Family High Definition Audio
vendor: Lenovo driver: snd_hda_intel v: kernel bus-ID: 00:1b.0
chip-ID: 8086:1c20 class-ID: 0403
Sound Server-1: ALSA v: k5.14.10-1-MANJARO running: yes
Sound Server-2: JACK v: 1.9.19 running: no
Sound Server-3: PulseAudio v: 15.0 running: yes
Sound Server-4: PipeWire v: 0.3.38 running: yes
Device-1: Intel 82579LM Gigabit Network vendor: Lenovo ThinkPad T520
driver: e1000e v: kernel port: 5080 bus-ID: 00:19.0 chip-ID: 8086:1502
class-ID: 0200
IF: enp0s25 state: up speed: 1000 Mbps duplex: full mac: <filter>
Device-2: Intel Centrino Advanced-N 6205 [Taylor Peak] driver: iwlwifi
v: kernel bus-ID: 03:00.0 chip-ID: 8086:0085 class-ID: 0280
IF: wlp3s0 state: up mac: <filter>
IF-ID-1: wwp0s29u1u4i6 state: down mac: <filter>
Device-1: Broadcom BCM2045B (BDC-2.1) type: USB driver: btusb v: 0.8
bus-ID: 1-1.4:4 chip-ID: 0a5c:217f class-ID: fe01 serial: <filter>
Report: rfkill ID: hci0 rfk-id: 3 state: up address: see --recommends
Local Storage: total: 1.36 TiB used: 1.06 TiB (77.9%)
SMART Message: Unable to run smartctl. Root privileges required.
ID-1: /dev/sda maj-min: 8:0 vendor: Samsung model: SSD 860 EVO 500GB
size: 465.76 GiB block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s
type: SSD serial: <filter> rev: 3B6Q scheme: MBR
ID-2: /dev/sdb maj-min: 8:16 vendor: HGST (Hitachi) model: HTS541010A9E680
size: 931.51 GiB block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s
type: HDD rpm: 5400 serial: <filter> rev: A7G0 scheme: MBR
ID-1: / raw-size: 65.37 GiB size: 63.84 GiB (97.67%) used: 35.11 GiB (55.0%)
fs: ext4 dev: /dev/sda1 maj-min: 8:1
ID-2: /home raw-size: 400.39 GiB size: 393.11 GiB (98.18%)
used: 309.63 GiB (78.8%) fs: ext4 dev: /dev/sda2 maj-min: 8:2
Alert: No swap data was found.
System Temperatures: cpu: 53.0 C mobo: N/A
Fan Speeds (RPM): cpu: 3174
Processes: 289 Uptime: 8h 47m wakeups: 12 Memory: 15.52 GiB
used: 5.38 GiB (34.7%) Init: systemd v: 249 tool: systemctl Compilers:
gcc: 11.1.0 clang: 12.0.1 Packages: 2108 pacman: 2100 lib: 442 flatpak: 0
snap: 8 Shell: Zsh v: 5.8 running-in: yakuake inxi: 3.3.08

What is the intended functionality of this?

TERMID00 doesn’t seem to return any value

TERMID00 seems to be assigned a value but the subsequent ref does not refer that variable but creates a new empty variable and adding a number - not logical to me - but one can never know.

Thanks for your reply, @linux-aarhus.
This is indeed unnecessary and I should have omitted it from this discussion. It was just an exercise/test I did with variables and I forgot to remove it.

Anyway, replying to your question, TERMID00 reads the number of the first session (0), and the following variables successively add 1 to it. So, TERMID01 becomes 1, TERMID02 is 2, and TERMID11 is 3. They are just identifiers.

:warning: I updated the code in order to prevent future confusion, so we cannot see those variables anymore.

I got confused there …

I am more confused now - what you are saying is: my script has negative impact on the global theme?

And this implies the why?

Scripting an application has no bearing on the theme _unlesss you specifically tells the theme engine to use a specific theme - I don’t recall the specifics here.

Thanks for your reply and interest on the topic, @linux-aarhus.
I’m going to try to be clearer.
As strange as it may sound, simply using a qdbus command in the script impacts the theme, even though I don’t mention the theme itself in the script.
I tried to debug the error and here is what I found:

  • Empty script or fully commented out script inside ~/.config/plasma-workspace — everything is fine.
  • Script with first lines up to "# change tab's name" — everything is fine.
  • Script with first runit line of code, i.e., with the command runit "/yakuake/tabs setTabTitle 0 'Main'", which is equivalent to qdbus org.kde.yakuake /yakuake/tabs setTabTitle 0 'Main' — the theme gets broken!

The conclusion is as soon as I use a qdbus command in the script, the theme gets broken.

Just to recall, “broken” means that the frame in the window of some applications launched by keyboard shortcuts, such as Dolphin or Spectacle (just to name a few), is shown in a light theme instead of the dark theme I’m using, and sometimes the icon theme gets also changed. But, if I launch any of those applications for instance from Application Launcher or Latte Dock, everything is fine.

I add here two more screenshots, that I got when I was debugging the issue, to illustrate it.

Fig. 1: This is Dolphin when everything is fine.

Fig. 2: This is Dolphin as I get it when I have a Yakuake script inside ~/.config/plasma-workspace/env/ and I launch Dolphin by issuing the keyboard shortcut. Note the light frame and the different icon set. If Dolphin is launched using Application Launcher or Latte Dock, it looks like as in Fig. 1.

:warning: Note that in order to replicate the issue we need to log out and log in again. If we just invoke the script from the terminal, we do not see the theme breaking.
Because of that, perhaps a workaround might be not to launch Yakuake at the start of the system and to run the script afterwords (I still have to test it, though).
Even if this workaround works, I think this issue deserves to be investigated.

This appears to be an upstream issue - but I have no idea where - as it implicates several components where none of them are Manjaro specific.

Let’s be clear on one thing - I am not a KDE user - I am simply curios.

I know one thing though (writing code for decades) - computers are stupid - if you get the wrong answer - then you asked to wrong question - but you likely know that.

One way to interpret that fact is when you get an unexpected result - distorted theme - when manipulating the session using qdbus - one could suspect and maybe draw the conclusion that the app - when launched from the menu system - is sent other information as well - e.g. the theme.

Maybe the message you send to the application is picked up by unintended recipients - something like the telegraph or the first telephone lines - everybody could listen - even the sneaky ears.

Somewhere in the flow - one could suspect qdbus - the signals and the receiving slots seems to completely disregard the theme.

The Arch Wiki contains an example on how to script Yakuake to it must be something else producing the warnings. See Yakuake - ArchWiki

Your observation on where your woes begin provides an excellent starting point.

Thanks for your insights, @linux-aarhus.

I had already seen this page. The warnings are produced only when I use qdbus commands in the script.

Anyway, I tried the workaround I proposed before and it works. So, for people facing the same problem and ending up here, this is what I did to circumvent the issue:

  1. Prevent Yakuake from autostarting: go to System Settings > Workspace > Startup and Shutdown > Autostart and click the “minus” button next to it;
  2. Create a Yakuake script and save it wherever you want;
  3. Got to System Settings > Workspace > Startup and Shutdown > Autostart;
    3.1 Click “+ Add…”
    3.2. Select “+ Add Application…”
    3.3 Click the folder next to the search field (when you hover over it, you get the hint “Open file dialogue”);
    3.4. Select the Yakuake script you created and saved before;
    3.5 [not sure is this step is necessary] Click in the Properties button, select the “Application” tab, and add sh before the command.

The script should autostart without distorting the theme. You will still see the warning about using qdbus commands with Yakuake, but I believe it is safe to ignore and mute it.

I will mark this as the solution, although this is not a true solution for the issue. Consider it as a workaround.

An update to include the aforementioned Yakuake D-Bus Warning message, in case it is useful:

“The D-Bus method runCommand was just used. There are security concerns about allowing these methods to be public. If desired, these methods can be changed to internal use only by re-compiling Yakuake. This warning will only show once for this Yakuake instance.”

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.