My blog has been rather empty lately. It’s not because I haven’t had
anything to report, but due to the fact that many things have happened
and all sorts of cool things in Plasma Active’s “Activity world” started
appearing that I didn’t have the time to write about them.
Today, I’m going to write about one of the smallest things I’ve done
lately that will change the world :)
startkde
startkde script had served us quite well for a long time now, and it
is still the best way to start your Plasma session. But it has some
downsides that we needed fixed in Plasma Active, and some features that
Plasma Active doesn’t need.
So, this post is about an alternative approach to start Plasma, a new
application called startactive. It is NOT a
replacement of startkde, but an alternative. Meaning that it doesn’t do
all the things startkde does, while it does some work that startkde
doesn’t.
The design
The main goal of startactive’s design was to create a
dependency-based system that starts various workspace components.
You can see the dependencies of various systems that startactive
invokes in the following graph.
Dependency graph
The blue items are meta-modules - they don’t start anything but they
make it possible to keep the organization manageable.
Waiting and starting
The system starts all the free modules (modules that don’t depend on
anything) at the same time (makes a nice performance boost on both
single and multi-core systems), and then waits for some of them to
finish until a new module becomes free. When it does, it is
automatically started.
There are two ways to see when a dependency has finished its job -
1st - the usual - wait for the process to finish; and 2nd - wait for the
program to register its D-Bus service.
(org.kde.nepomuk.services.nepomukqueryservice for Nepomuk,
org.kde.plasma-desktop for regular Plasma etc.).
Splash screen
Now, when you’re making something that doesn’t need to provide any
compatibility with existing systems, you have the freedom to do the
things as you see fit. So, I felt free to abandon the old splash screen
engines that KDE Workspace used, but to focus only on the QML one I blogged about some
time ago. It is now run in-process avoiding dirty ways of
communication via X-events and such.
The missing features
startkde does a lot of things, from the initialization of the user’s
.kde directory, to fonts, mouse cursors etc.
startactive doesn’t for one simple reason - all of that should be
already set up on your Plasma device. All environment variables, Qt
plugin locations, directory infrastructure…
Don’t try it
The code is currently located in kde:scratch/ivan/startactive and you
shouldn’t use it. Unless you are a really brave soul who doesn’t care if
startactive jumps out of the system and start killing kittens in your
neighbourhood.
For me, it killed only two older felines, and now it has returned and
manages my system with only a few smaller issues. So, if you are brave
enough, then continue reading.
To test, you’ll first need to compile it and install with the same
prefix as the rest of your kde system, which in turn needs to be in your
PATH. Otherwise it will not work.
Then, you’ll need to adapt the module files to fit your setup and
finally start the application in an empty X session.
An ordinary startactive will do - it will, by default,
start the plasma active module, but if you want to run a desktop
session, and change the splash screen theme, you can do something like
this:
Published
in the Prog C++ section,
on 2 August 2011
Qt Functional
A teaser, again. This time with std:: stuff instead of Qt. Why?
Because I can :)
list <string> inputList;
// ... do something to the inputList ...
string first, second;
list <string> outputList;
(QfTuple | first, second, outputList)
= inputList.begin();
// or just (and it is safer)
(QfTuple | first, second, outputList)
= inputList;
// now, the variables first and second contain
// the first two elements of the inputList, and
// outputList contains the rest
This is not really a KDE post, but rather something that happened and
took away two days from me. So, you’re free to skip it :)
Intro
Insanely enough, I decided to completely wipe out my current system
and after quite some time reinstall Debian. I completely forgot how
tiresome is reinstalling everything from scratch - all the packages
needed by KDE SC, all the packages needed by me, and everything else.
Even more, I’m used to installing the minimal system, and then
installing xorg, …
So, when the initial installation was over, I decided to make a clean
KDE build (like I haven’t lost enough time already) - and after a few
attempts I managed to install just enough dependencies so that the stuff
I want (or work on) works without a glitch.
eeePC as a graphics card
At the time I started to get pleased by my newly refreshed and
cleaned system, my screen just went blank, and after a reboot, the
computer made quite a few beeps before starting to boot the OS while
leaving the screen blank.
One of the capacitors on my graphic card went crazy and had blown up.
Since I needed to do some work, I couldn’t allow myself to be without
access to the system, and using a much slower (eee)PC with a much
smaller screen while my main system lies incapacitated (or
incapacitor-ated) was a no-go.
The first solution was to do an ‘ssh -X’ from eeePC and connect my
big screen to it. And this worked quite well except that VGA connector
didn’t want to allow the full resolution of my screen so the picture was
a bit blurry.
The is in a nutshell, the power of Linux and X11.
ATI
After I finished the things I needed to do, I hurried to the last
open computer-store to get a new card. The last one left in the store
was ATI’s HD6450, so I didn’t have any doubts which card to get.
I have to say that I was thrilled I’m getting rid of NVidia driver
problems (although I didn’t really have any :) ) and getting into AMD’s
world (after all I haven’t bought a single Intel’s CPU since 80286).
But, as per Murphy’s law, while KWin worked with all fancy effects
(via the openGL backend), all openGL programs decided to claim that this
driver doesn’t support openGL - at all. Even the simplest examples from
the ‘Computer graphics’ course I teach.
After seeking the solution on the intertubes, and trying each and
every one, I almost decided to quit and leave it like that. Fortunately,
after a while, I /decided/ it was the problem with the fact I need
fglrx-glx package which I can’t install because it would break quite a
few other packages (and thus apt would uninstall them) including some
qt4 stuff which required mesa-glx.
Then I decided to do the dirty thing - to simply overwrite mesa’s
libGL.so* stuff with those from fglrx. Usually, this is not really a
safe thing to do, but since openGL is a C library that has to conform to
a few well-defined standards, all implementations need to be binary
compatible, which in turn means those can easily be interchanged.
This and a few radeon.modeset=0 sprinkled in a couple of places made
my system fully functional.
Outro
This morning I even decided to tear apart all the components from the
case, clean them and resemble the system (cleaning the body as well as
the soul - it’s a chán/zen thing :) )
Now I have something that works and feels as a completely new
system.
Ok, it is the time for me to blog from Randa and KDE Platform 11 and
Nepomuk sprints.
KDE and Gnome collaboration
Share-Like-Connect
One of the side effects of the /usage tracking/ is that we now know
what document is currently being viewed/edited, so the Aaron’s S-L-C
concept can finally come to life without using the fake dummy data.
Tasks Documents applet
This doesn’t exist yet, but when applications start reporting which
documents they are showing, we’ll be able to make a fully
document-oriented workspace for those that like that kind of stuff.
Zeitgeist integration
We (Nepomuk - Trueg and myself) and Zeitgeist people (Seif and
Trever) had quite a few hours spent deciding the best way for the two
systems to collaborate and I think we have done well. Apps that support
Zeitgeist will automatically support us as well, and vice-versa. So,
whether you are using a Gnome application in KDE, or KDE application in
Gnome, it will just work(TM).
As you probably already know, I’m a sucker for fall-backs, so I still
intend to make this work even if you disable one of the services. And it
will work, but badly if you disable both of them.
Contour and Plasma Active
The thing worth mentioning is that I’m now a part-time member of the
Contour team at basysKom, so you can expect these things to be finished
faster than it was when I had to give focus to other non KDE-related
projects.