Freshly switched to KDE 4 or Plasma 5, and unable to Browse Network Shares using Dolphin?

I just installed Plasma 5 from the package-manager, on my tower-computer named ‘Plato’, only to find that for some time, I was unable to browse Windows File Shares – i.e. ‘SMB Shares’ – casually, just using the ‘Dolphin’ File Manager. Yet, I was able to mount these shares using ‘Smb4K’, making them visible in my local folders as though there.

Dolphin was showing me an essentially empty set of icons when displaying the Network.

As it turns out, we need to install a package named:

‘kio-extras’

Which will give Dolphin the additional plug-ins it needs, to recognize ‘smb://’ URIs. If our Plasma 5 desktop manager was set up professionally, then the person doing so would know about such details. But when individuals set up KDE or Plasma for the first time, we need to learn such details first-hand.

screenshot_20171017_074924

screenshot_20171017_075006

 

As an added note, we might find that when we click on the Trash widget in our Panel, which I left just at the right-most end, we may get the error-message to the effect that ‘trash:/’ was a corrupted URL. Yet, from within Dolphin, the trash bin displays just fine.

In my case this was happening, because I did not have Dolphin set up as my default File Management application, in my Plasma 5 Settings, where instead I had an application selected which would have been appropriate to an LXDE desktop, and which does not recognize URIs that begin with ‘trash:/’. Switching this setting to make Dolphin my Default File Manager, fixed this problem.

Dirk

 

Lessening my Criticism of OpenShot

In this earlier posting, I criticized a non-linear video editor named ““, stating that it was unstable. I think I need to both lessen, and pinpoint my criticism of this software.

At the time I was mainly having problems with the Windows version of , which its developer worked long and hard to port to Windows. But the actual problem with under Windows has to do with an environment variable named ‘‘. When we install certain Linux-centric software under Windows, we are often instructed to set our ‘‘ variable to point to it. But with Qt-libraries, there is an additional variable named ‘‘, which states what folders the Qt-libraries are to be found in. This is a global variable under Windows, even though we may have different examples of software installed, that use different versions of the Qt-libraries.

The way it is with me, I have ‘‘ installed, which is also a Qt-based application which has been ported to Windows. Normally, a Windows executable will look in its own folder first, for an .DLL Files it needs, before looking in other directories.

But is an application that comes with many Qt-library-files, located in its own directory or directories. And so to point the executable to these libraries, the installer sets this environment variable.

The problem becomes, that when I next try to run , its Qt-executable respects this variable, and starts to try loading the Qt-libraries that shipped with . does this, even though the developers of Qt have apparently forgotten that this variable exists, because its observance is built-in to Qt.

The problem here is not strictly the fault of developers. With Qt applications, the slightest mismatch between the Qt version the application was linked against, from the shared libraries it will ink to again, when it is run, will cause typical error messages. This problem has already happened to many users, who install Qt-based applications under Linux, that were not compiled and linked in-stream with the packaged version of Qt. In fact, when we install certain Qt-based applications that are out-of-tree in this way, we often need to do something like this:

 


rm -f libQt*.so*


 

In the folder of the software in question, to force that software to link to the Qt-libraries we have installed globally, instead of linking to its own version of these libraries, before the software will run.

So in my case, when the time came for to ask me for my passphrases, in order to unlock my private keys, this library-mismatch prevented the software from working. At first this might sound like some sort of malware-problem, but is really just a library-incompatibility-problem.

And so the only way I was able to clean up this problem on my Windows 7 machine ‘‘, was to uninstall the Windows version of , which its authors provided so carefully, and to delete this environment variable as well. Apparently, if this variable is set and the folder empty – or nonexistent – this is not enough to convince a Qt-application to link to its own Qt-libraries. in my case I needed to delete this variable as well, before became stable again.

Now, if a user only feels that he will be running software on his Windows computer, that uses one, global Qt-version, this could all look very different. But in my usage-scenario,

  • The way I set up my Windows machine is different, and
  • I have access to on my Linux machines, for which reason I do not need this software under Windows.

I think that I had the additional problem on the machine I name ‘‘, that once crashed my X-server, when instructed to play back a corrupted video file, in its preview window, but at full quality. Yet, I have already learned that ‘‘ has a weak, fragile instance of the X-server running… So this may also not strictly be the fault of developers.

Dirk