KDE Programs Solved

Alexzee

Well-Known Member
Joined
Jun 1, 2019
Messages
3,829
Reaction score
2,053
Credits
22,991
A lot of the KDE programs that I have on my Slackware install are really helpful and I enjoy them.

However, my eyes don't tolerate the API's interfaces because they have bright white backgrounds.

Is there an argument or string I could add to the configuration files to make the backgrounds dark?
 


Without any recent experience of Slackware, I've also been interested in darkness. It varies with different programs. For firefox, I use the extension "Dark background and light text", which means I don't have to use the dark theme on this site, or any other site. My xterms are in reverse video, configured in an .Xdefaults file. There are a few other web browsers that have no dark theme, or just an experimental one like on brave that I use. If there is no dark background in the browser or other applications that I use, I make use of xcalib in a terminal to reverse the video for as long as I need, and then return to the original state by the toggling the same command:
Code:
xcalib -i -a
Not all video cards are susceptible to xcalib's magic, but most I've used have been.
 
Either install something like qt5ct - a standalone tool for setting QT/KDE applications look/feel.

Or install systemsettings - the KDE system settings application. I think it's possible to install it without installing a full KDE/Plasma session.
Whatever you choose, you should be able to set up a dark theme using one of those!
 
Thanks JasKainasis!

QT5ct wasn't installed--but it is now.

Code:
# This program allows users to configure Qt5 settings (theme, font,
# icons, etc.) under DE/WM without Qt integration.
#
#         Homepage: http://qt5ct.sourceforge.net
#
Executing install script for qt5ct-1.5-x86_64-1_SBo.tgz.
Package qt5ct-1.5-x86_64-1_SBo.tgz installed.
root@slackware64:/tmp#

The maintainer of the pkg, Alexandar Verbovetsky said:
For it to work, QT_QPA_PLATFORMTHEME=qt5ct must be set in the
environment.

How do I set it in the envirnment?





Maintained by: Alexander Verbovetsky
Keywords: qt5,qt,toolkit,qtconfig,config
ChangeLog: qt5ct

 
Do I need to edit /etc/envirnoment with nano or vim and ad this?

Edit /etc/environment as root by sudo nano /etc/environment and add the line QT_QPA_PLATFORMTHEME=qt5ct and save.


BTW, I don't think Breeze is installed (I have to check) so I'd have to go get it from the SlackBuilds repo.
 
How do I set it in the envirnment?

In LXQt, you'd make that change here:

rZ7fsh6.png


It'd be under Preferences > LXQt Settings > Session Settings

I don't have an answer for you - but that's where you'd make the change in LXQt/Lubuntu.

KDE is also Qt, so we can (and do) use some KDE software in Lubuntu. So, it might look similar to that on your end - which is why I am sharing.
 
I used to use qt5ct for theming KDE5 based applications for my dwm and 2wm sessions.
Without the following lines in my .profile, KDE applications like Dolphin just showed a blank window, with no icons for files, or buttons. No buttons in the toolbars etc.

So in ~/.profile I had the following lines:
Bash:
if [[ $XDG_SESSION_DESKTOP == "dwm" ]] || [[ $XDG_SESSION_DESKTOP == "dwm-jas" ]] || [[ $XDG_SESSION_DESKTOP == "2wm" ]]; then
    export QT_QPA_PLATFORMTHEME=qt5ct
    export QT_STYLE_OVERRIDE="breeze"
    export KDE_SESSION_VERSION=5
    export KDE_FULL_SESSION=true
else
    echo "qt5ct not set as theme engine"
fi
Above would set those environment variables if I was running a dwm, or 2wm session.
And then I used qt5ct to set a dark theme and KDE/QT applications would use the settings set up by qt5ct for their look/feel/theme.

You won't need all of those environment variables though. You'll probably just need the line:
Bash:
export QT_QPA_PLATFORMTHEME=qt5ct

You may, or may not need the KDE_SESSION_VERSION environment variable.
Likewise, the QT_STYLE_OVERLOAD variable just sets "breeze" as the default/fallback theme. So you probably won't need it.

And you shouldn't need the KDE_FULL_SESSION variable. But if you do, you probably only need to set it to false.
I ended up having to set that variable to true in order to trick my system into thinking it was running a full KDE session, in order for some KDE5 applications to work properly. But back then I used a lot of KDE programs.

I've since commented out all of those variables in my .profile, because I no longer use QT/KDE applications. The only one I do use is okular. But I'm not bothered about the theme of that!
 
I used to use qt5ct for theming KDE5 based applications for my dwm and 2wm sessions.
Without the following lines in my .profile, KDE applications like Dolphin just showed a blank window, with no icons for files, or buttons. No buttons in the toolbars etc.

So in ~/.profile I had the following lines:
Bash:
if [[ $XDG_SESSION_DESKTOP == "dwm" ]] || [[ $XDG_SESSION_DESKTOP == "dwm-jas" ]] || [[ $XDG_SESSION_DESKTOP == "2wm" ]]; then
    export QT_QPA_PLATFORMTHEME=qt5ct
    export QT_STYLE_OVERRIDE="breeze"
    export KDE_SESSION_VERSION=5
    export KDE_FULL_SESSION=true
else
    echo "qt5ct not set as theme engine"
fi
Above would set those environment variables if I was running a dwm, or 2wm session.
And then I used qt5ct to set a dark theme and KDE/QT applications would use the settings set up by qt5ct for their look/feel/theme.

You won't need all of those environment variables though. You'll probably just need the line:
Bash:
export QT_QPA_PLATFORMTHEME=qt5ct

You may, or may not need the KDE_SESSION_VERSION environment variable.
Likewise, the QT_STYLE_OVERLOAD variable just sets "breeze" as the default/fallback theme. So you probably won't need it.

And you shouldn't need the KDE_FULL_SESSION variable. But if you do, you probably only need to set it to false.
I ended up having to set that variable to true in order to trick my system into thinking it was running a full KDE session, in order for some KDE5 applications to work properly. But back then I used a lot of KDE programs.

I've since commented out all of those variables in my .profile, because I no longer use QT/KDE applications. The only one I do use is okular. But I'm not bothered about the theme of that!
I'll look in the profile in the morning and add the string and see how things go.
The good news is that I can bounce between KDE Plasma 5 and XFCE with Slackware.
 
Not needing all of those environment variables makes sense, thanks.
 
I looked and ~/.profile doesn't exist. Slackware is designed differently (doesn't have systemd) from Debian.

Code:
root@slackware64:~# cat ~/.profile
cat: /root/.profile: No such file or directory
root@slackware64:~# ls ~/.profile
/bin/ls: cannot access '/root/.profile': No such file or directory
root@slackware64:~#

I may have to add QT_QPA_PLATFORMTHEME=qt5ct" to my .xinitrc file according to this thread.


Any thoughts or ideas JasKinasis?
 
Yes, that’ll do it!

If .profile doesn’t exist, you can create it.
Though thinking about it, .profile is for the bourne shell clones (bourne, bash etc) - so I think the QT settings were added by me there, to ensure the environment variables were there when I started QT applications from the terminal.

I’ll check the rest of the configs on my laptop when I get home tonight and will see what I’ve got in there. I should have the old QT configs commented out in any config files that previously used them.

.xinitrc sounds like it should work though.
I may even have put them in the main xsession scripts for dwm and 2wm.
 
Last edited:
I'm not sure if this is the correct file as I'm not finding .xinitrc in /home-

Code:
bash-5.1$ cat /etc/X11/xinit/xinitrc
#!/bin/sh

########################################################################
##  Merge in defaults and keymaps                                     ##
########################################################################

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

if [ -f $sysresources ]; then
    /usr/bin/xrdb -merge $sysresources
fi

if [ -f $sysmodmap ]; then
    /usr/bin/xmodmap $sysmodmap
fi

if [ -f $userresources ]; then
    /usr/bin/xrdb -merge $userresources
fi

if [ -f $usermodmap ]; then
    /usr/bin/xmodmap $usermodmap
fi

########################################################################
##  Start xfce Desktop Environment                                    ##
########################################################################

exec /usr/bin/startxfce4

This may help you to understand.
 
Ok when you have time and can look on your laptop that would be good.

I think I found the right file this is an exact match to the one I pulled up in the konsole/terminal.
Not sure where to add the export 'QT_QPA_PLATFORMTHEME=qt5ct' in the file !?

 
Last edited:
I'm not sure if this is the correct file as I'm not finding .xinitrc in /home-

Code:
bash-5.1$ cat /etc/X11/xinit/xinitrc
#!/bin/sh

########################################################################
##  Merge in defaults and keymaps                                     ##
########################################################################

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

if [ -f $sysresources ]; then
    /usr/bin/xrdb -merge $sysresources
fi

if [ -f $sysmodmap ]; then
    /usr/bin/xmodmap $sysmodmap
fi

if [ -f $userresources ]; then
    /usr/bin/xrdb -merge $userresources
fi

if [ -f $usermodmap ]; then
    /usr/bin/xmodmap $usermodmap
fi

########################################################################
##  Start xfce Desktop Environment                                    ##
########################################################################

exec /usr/bin/startxfce4

This may help you to understand.
You don’t have a .xinitrc file in your home, so the system falls back/defaults to use the one in /etc/X11/xinit/xinitrc.

You could either edit that file as root and add the QT environment variables there.

Or, leave that file alone and create a copy of it in your home directory, but rename it .xinitrc and then add the QT variables.

E.g. cp /etc/X11/xinit/xinitrc ~/.xinitrc
Then edit ~/.xinitrc to include the QT variables. Leave the rest of the code that’s there.

Once you have a .xinitrc in your home directory, the system will load that instead of the fallback one.

Or you could just edit the fallback as root. Either will work.
Edit:
Though, it’s probably better to have the one in your home directory. Because when you update your system, the default version in /etc/X11/ might get updated and you’d lose the QT environment variables when the file is overwritten with a new version. So keeping your customised/personalised version in your home directory probably makes more sense.
/Edit

Whatever you decide to do, just make sure you add the QT environment variables anywhere before the line where xfce is started!
 
Last edited:
I would use the cp command.

Moving it will delete the original file.

You can cp it and give it the new name at the same time. Use the full path for the new file, eg /home/alexzee/.xinitrc

Wiz
 
I would use the cp command.

Moving it will delete the original file.

You can cp it and give it the new name at the same time. Use the full path for the new file, eg /home/alexzee/.xinitrc

Wiz

I now have xinitrc in my home directory.
Code:
-rwxr-xr-x 1 alex users  886 Feb  2 16:26 xinitrc
bash-5.1$
So now I can use the move command like this?

mv xinitrc /home/alex/.xinitric
 
Last edited:
/home/alex/.xinitric
typo there.

Do you still have an /etc/X11/xinit/xinitrc ?

If not, you may have to copy it back again.

I was simply trying to answer your question as to whether to us

mv

or not, but perhaps I confused you.

So along the lines of what Jas was saying, and with now knowing your userid

E.g. cp /etc/X11/xinit/xinitrc ~/.xinitrc

My suggestion would read as

Code:
sudo cp /etc/X11/xinit/xinitrc /home/alex/.xinitrc

Wiz
 
My suggestion would read as

Code:
sudo cp /etc/X11/xinit/xinitrc /home/alex/.xinitrc
No. No need for sudo with cp in this case.

If you use sudo cp to copy the file to the users home directory, the copy of the file will be owned by root, because cp was running as root.

So after copying the file using sudo cp, you'd also have to use sudo chown alex:alex ~/.xinitrc in order to give the user ownership of the file.

Whereas if you use cp on its own, without sudo:
Assuming the default 644 permissions are used on the file - the user has read access to the file. And as a normal user, read permissions are all you need in order to copy a file that is owned by root. And again, it will only succeed in copying the file if the destination the file is going to is a location that the user can write to.

In other words, as long as the directory the user is writing the copied file to is either directly owned by them, or they have write permissions via group membership, or perhaps even the other/world permissions (e.g. Perhaps they're copying to a shared directory that is readable/writable by anybody).

As long as the destination the copied file is going to is a location that the user can write to (e.g. /home/alex/.xinitrc), then the file will be copied. And the copy will be owned by the user.

If you try using cp to copy a file owned by root to a location that is only writable by root, then you'd definitely need to use sudo. Otherwise, it is NOT needed.

So to sum up - without using sudo:
Because the cp command is acting as a normal user AND the user has read permissions on the original file AND because the user has permission to write to the destination - then the original file (owned by root) will be copied and the copied file will be owned by the user.

So as I originally recommended, simply use:
Bash:
cp /etc/X11/xinit/xinitrc ~/.xinitrc
 
Last edited:
No. No need for sudo with cp in this case.

If you use sudo cp to copy the file to the users home directory, the copy of the file will be owned by root, because cp was running as root.

So after copying the file using sudo cp, you'd also have to use sudo chown alex:alex ~/.xinitrc in order to give the user ownership of the file.

Whereas if you use cp on its own, without sudo:
Assuming the default 644 permissions are used on the file - the user has read access to the file. And as a normal user, read permissions are all you need in order to copy a file that is owned by root. And again, it will only succeed in copying the file if the destination the file is going to is a location that the user can write to.

In other words, as long as the directory the user is writing the copied file to is either directly owned by them, or they have write permissions via group membership, or perhaps even the other/world permissions (e.g. Perhaps they're copying to a shared directory that is readable/writable by anybody).

As long as the destination the copied file is going to is a location that the user can write to (e.g. /home/alex/.xinitrc), then the file will be copied. And the copy will be owned by the user.

If you try using cp to copy a file owned by root to a location that is only writable by root, then you'd definitely need to use sudo. Otherwise, it is NOT needed.

So to sum up - without using sudo:
Because the cp command is acting as a normal user AND the user has read permissions on the original file AND because the user has permission to write to the destination - then the original file (owned by root) will be copied and the copied file will be owned by the user.

So as I originally recommended, simply use:
Bash:
cp /etc/X11/xinit/xinitrc ~/.xinitrc
Running

cp /etc/X11/xinit/xinitrc ~/.xinitrc worked and I have xinitrc in my home directory.

Any harm in renaming it .xinitrc2 ?
 


Top