Good News for Korora

While the Korora team is still taking a break the Korora community has stepped up. There is a community provided Korora 28 ISO now available for testing thanks to Korora user JMiahMan.

At this stage Xfce is available and Gnome is being prepared. The other desktops are planned to follow. See this news item on the Korora site for details.

Advertisement

A Fix for Korora Xfce in KVM

There has been an issue where Korora Xfce running in a VM using KVM was pausing for a short time. It seems I wasn’t the only one experiencing this issue. During a discussion on the Korora IRC channel I was experimenting with different settings and suggested a possible fix. It worked for me and others too. This may work for other distros too particularly Fedora and other Fedora remixes.

Thanks to bgstack15 for testing and documenting it, see his article here. But the short answer is to disable “Sync Drawing to the vertical blank”.

Using the Super Key in Xfce

Update: Ksuperkey is in the Korora repo now and included in Korora Xfce 24.

One of the restrictions in Xfce is that you can’t use a key as both a shortcut key and a key modifier. I have often seen questions about this particularly as regards the Super (aka Win) key. It is often set to open the menu whether the default menu or WhiskerMenu is used. If it is also used as a modifier, i.e. in a combination with another key as a shortcut, the menu will be opened as well as the action called by the shortcut.

A question from another Korora team member reminded me of Ksuperkey and looking at the Github page for the project I noted a comment that while it was written for KDE it should work in other Desktop Environments including Xfce. That sounded like it was worth checking out.

Unfortunately Ksuperkey is no longer packed for Fedora 23 so can’t just be installed in Korora. However it is simple to build. I followed this guide, replacing yum with dnf, and it worked without any issues.

If used without any options Ksuperkey calls alt + F1 which in Korora opens the menu by default. I removed that shortcut as I use whiskermenu. In Korora the Super key is used to open WhiskerMenu so in Settings – Keyboard – Shortcuts I edited that to use Alt + F1. Next I ran ksuperkey from alt + F2 and tested. I had previously configured some shortcuts to open applications using Super + other keys so I could easily test. The applications opened and the menu didn’t appear. When used by itself the super key opened WhiskerMenu. Exactly what I hoped to achieve and what was promised.

Lastly I added ksuperkey to Settings – Sessions and Startup – Application Autostart so I didn’t need to run it manually each session.

Ksuperkey adds useful and needed functionality to Xfce and probably other Desktops and is a worthy addition. It has a number of options that can tailor its operation to different situations, see the Usage section on the project page. Don’t be misled by the name, Ksuperkey doesn’t have a bunch, or even any, KDE dependencies that will be added to your system. Its name merely reflects it’s heritage.

Road to Xfce 4.14

It is rare that there is a post on the Xfce blog so when there is it is worth taking notice. Today there was a status report on the Xfce development. Those of us who use Xfce know that development is slow. It is probably an open secret that the next version will be ported to GTK3.

Today’s post clarifies what is happening and the current progress. There are some interesting comments such as no new features. Can we expect that 4.14 will be indistinguishable from 4.12 for most users? It appears so. Also there is no mention of Wayland so it appears that too will be pushed back.

It is good news that Xfce development is continuing and it is great to hear what is going on because communication with users is probably one area Xfce handles poorly.

Source: Road to Xfce 4.14

Update to the Touchpad Script

Some time ago I posted a script that turned the touchpad on and off as needed. This script disabled the touchpad when I using a mouse. After using it for sometime I found that occasionally the device numbers changed after a reboot. So I modified the script to use the device name in place of the ID.

The original post, now updated, is here.

A New Xfce Utility

A new utility has been made available for Xfce in Fedora. It is xfpanel-switch and has been packaged by nonamedotc who you may recognise as a busy contributor of Xfce on Fedora. His past efforts have certainly added to my enjoyment of running Xfce on Korora.

xfpanel-switch is a simple utility that can back up and restore your panel configuration. It includes a couple of different configs you can try out but use its backup option to backup your set up first. There are full details about it here.

I’ve been testing it for couple of days and it works well for me. It will be included in future versions of Korora Xfce but if you want to try it on 23 it is currently in updates-testing. You can install it with ‘sudo dnf –enablerepo=updates-testing install xfpanel-switch’.

Kdenlive Appearance in Xfce

The KDE video editor Kdenlive is one of the best Linux video editors available for general users. I’ve used it for many versions both in KDE and other desktops like Xfce. Recently it was updated to version 15.12.2 in Fedora. One of the changes from the former 9.10 version was the conversion to Plasma 5 / QF5. This means it defaults to using the Breeze style.

Unfortunately Kdenlive doesn’t detect or use the GTK settings or even the QT5 setting. The style used is set within the application. I’m not sure why it does this but in my experience it is the only KDE application that does it.

I use a dark theme in Xfce and kdenlive looked way out of place. I tried to set it to use the GTK theme but that meant some elements were dark and some not. it looked a real mess. I needed to install the Breeze theme and then set Kdenlive to use Breeze Dark. ‘dnf install plasma-breeze’ is all I needed to do. Then select Breeze in Settings – Style and Breeze Dark in Theme and in that order too. It still isn’t exactly the same colours as other applications but it is close and that seems to be the best I can do.

Disabling Touchpad when using a Mouse

After using this script for a while I found a problem when occasionally after a reboot the device numbers had changed. So I have changed the script to use the device name in place of the ID. This has solved the problem. I’ve also added icons to the notification output.

There is a common feature on current Linux desktop that allows the touchpad to be disabled while typing. This is a useful feature but it has its limitations. The delay before the touchpad starts working can be set to a long time to reduce accidental movement but then the delay becomes irritating. I find I still occasionally brush the touchpad and cause an issue with what I am typing particularly when I pause to review what I have written.

As I normally use a bluetooth mouse I would prefer that the touchpad is completely disabled or preferably disabled when the mouse is in use. There are several scripts around which do this using synclient. I have found a few of these and tested them and none worked for me. I could see that the setting was changed but the touchpad was still active.

After a fair bit of research I found mention of using xinput and the commands needed to use xinput to disable the touchpad. Xinput has an advantage over synclient in that it completely disables the touchpad, buttons and all whereas synclient just stops any cursor movement.

I have tested this on my Thinkpad running Korora 23 Xfce but it should work on any recent version of most distros and with most desktop environments. It isn’t needed in KDE which includes this as an option in the touchpad settings. The script should also work with a USB mouse, in fact any sort of mouse, as well as the Bluetooth mouse it was tested with. The script uses xinput to check if a mouse is present. If your mouse is listed there and the name includes the word “mouse” it will work. Type “xinput –list” (without the quotes of course) with your mouse attached and check it is there.

There are a couple of steps needed to get xinput to work. The first is to identify the id of the touchpad. To do this run the command “xinput –list”. It will show a list of all the devices xinput controls. One of these is clearly marked as the touchpad. Looking along that line there is an ‘id=’ field. Make a note of this number, mine is 11 but yours may well be different. Looking along that line also make a note of the exact title of the touchpad, mine was “SynPS/2 Synaptics TouchPad” which seems to be common.

Next you need the id of the touchpad off setting for that device. Run “xinput –list-props 11” substituting the device number you found earlier for 11. This gives a long list of properties for that device. Look for “Device Enabled”, for me this was first on the list and so I had to scroll up to see it. That line will have a number in brackets, the property id, mine is 139 but again yours will probably be different.

With both those numbers recorded we are ready to test the xinput command. There is no point making a script if the command doesn’t work. Test with the command “xinput set-int-prop 11 139 8 0” (replacing my 11 with the device number you found and the 139 with the property number you found). If the command works your touchpad will be disabled. Run the command “xinput set-int-prop 11 139 8 1” (yes replace my numbers with yours again) to enable it again.

Once that is working we can create a script. My script is copied from several I found that used synclient but with the appropriate command replaced. Don’t forget to put the correct numbers in your script. We will also use the exact name of the touchpad in place of the number.

First as root or using sudo open /usr/local/bin/touchpad in your favourite text editor. It should be a new file. Copy and paste the script below and then edit the lines with the xinput command.

#!/bin/bash
sleep 1
list=`xinput --list | grep -i 'mouse'`
if [ ${#list} -eq 0 ]; then
xinput set-int-prop 'SynPS/2 Synaptics TouchPad' 139 8 1
notify-send -i touchpad-indicator "No Mouse found" "Your touchpad is set to ON"
else
xinput set-int-prop 'SynPS/2 Synaptics TouchPad' 139 8 0
notify-send -i preferences-desktop-peripherals "Mouse connected" "Your touchpad is now turned OFF"
fi

Save the file. Make it executable, “chmod +x /usr/local/bin/touchpad”. Note the sleep on the first line isn’t strictly needed but occasionally the script fails to run without it.

Now it should work. Test by running the script as a user. If your mouse is connected you should see a notification and the touchpad should be disabled. Next disconnect the mouse and check the touchpad again. I use a bluetooth mouse and it takes some time for the system to recognise that the mouse is off. I’m guessing it thinks there is a temporary break in communication. But with a usb mouse it should react much faster. I normally don’t need to run the script again.

However the exception is after a reboot or very occasionally upon returning from a suspend I find I need to run it. I use a dropdown terminal so it isn’t a problem to open it and run the script. However you may prefer to create a keyboard shortcut so that you can run the script quickly and easily as needed. In Xfce go to settings – Keyboard – Application Shortcuts and put the full path to the command as the application, press the key(s) and it is set. Test it.

One interesting result of this script is I can still move the cursor on my Thinkpad using the Trackpoint but none of the buttons work. I could disable the Trackpoint too but it isn’t easy to accidentally bump the Trackpoint, at least I’ve never done it so I don’t think it is necessary.

Xfce Screen Locking without XScreensaver

If like me you dislike XScreensaver and its ugly unlock screen there is an easy alternative that is actually better integrated into Xfce. Korora like most distros includes Xscreensaver with Xfce. Xscreensaver provides both the screensaver graphics and screenlocking for security. Screensaving isn’t needed these days with modern monitors. It is a relic from the distant past of CRT monitors. However for laptops that can be taken anywhere and for desktops in public areas, screen locking is an important part of your security set up.

You can disable the screensaving so it just blanks the screen. But you still have the ugly Xscreensaver screen to type your password. There is a better way.

I remove xscreensaver, this isn’t strictly necessary but as it isn’t being used there is no point keeping it. ‘dnf erase xscreensaver*’ takes care of that.

Next I install light-locker. Light-locker works with LightDM which is the default Display Manager for Xfce in Korora and many other distros. Actually LightDM is used in Korora for other Desktop Environments too so this applies to them too. However it is well integrated into Xfce. ‘dnf install light-locker’ is all that is needed. I did a restart but I’m not sure if that is really needed.

Now Xfce’s Power Manager settings has gained an additional “Security” tab which allows you to configure Light-locker. Not that much needs configuring. On my laptop I enabled “Lock when Going to Sleep”. This enables me to put the laptop to sleep and lock the screen simply by closing the lid as I have set that as the default action elsewhere in the Power Manager settings.

Now when I open the laptop rather than the unlocked desktop or the ugly XScreensaver window appearing I get the LightDM login screen. That looks much better particularly as I have customised it but that is a subject for another day.

Desktops, Drivers and Other Stuff

Over the last couple of weeks I’ve spent some time switching back and forward between Xfce (my preferred Desktop Environment) and KDE. I once ran KDE almost exclusively but for various reasons I’ve been using Xfce for the last couple of years.

One of the reasons was the frequency of KDE to lock up. It would just stop running. I have long suspected it was a graphics problem but had no proof. I have  a nVidia GT240 video card and had been using the open source nouveau driver. After a recent lock up I was forcing a shutdown when the screen filled with nouveau errors. Although I prefer to use open source drivers where possible I decided to install the nvidia drivers from RPMFusion using Korora’s PharLap application.

All went well with the installation and it did solve the lock up problems. Doing a bit of research I found an old bug which has been kept current. As far as I can see there has been no action on it. Anyhow problem solved and now I have working Xfce and KDE desktops and can and do switch between them as I feel like it.

Speaking of old bugs a long time I reported a problem with landscape printing and after much investigation by many people it was narrowed down to cups-filters and an update provided which fixed the problem. Now some months later those packages were updated and the problem returned. I commented on the bug and straight away another update was provided along with an apology. Well done Jiri Popelka. I tested and provided karma to the update so hopefully it is making its way through the update system now.

I’ve been testing installations on a uefi system the last couple of days. I was surprised how simple it was with Korora and so also with Fedora. More details later but if you want a linux system on an uefi computer either as a single installation or a dual boot Korora is the way to go.