Due to some fortunate events, I got my hands on a small (miniITX)
all-in-one board based on AMD Geode, which you can see in the picture.
It is a low-power thing without any coolers (not even passive ones).
AMD Geode MB
My job was to install Linux on it. And I did just that - Debian
GNU/Linux with KDE 4.1 beta which is in Debian’s experimental
repositories. I hooked the system to my screen so that you can see what
it looks like (although it was a bit odd to hook something like this to
a 19” screen). It behaves surprisingly well - the system is responsive
and works very well (with all fancy Plasma animations)
KDE on Geode
The ultimate goal is to create an environment for systems that will
have the ability to run only a limited set of predefined applications
(for example a web browser, mail client and office suite). For this,
there will be some changes to the screen you have in the screenshot, but
I’ll talk about that a bit later.
Well, this is one of the Aaron-style “explain to the unbelievers why
they are wrong”. This is in response to http://blog.kov.eti.br/?p=19 (or
you can see the translated
version)
Disclaimer: I have nothing against Gnome, I am
mentioning it since it was used as a comparison in the original
post.
Well, as all trolls on the internet, you have a couple of things
obviously not clear to you.
Delusion 1. KDE is vapourware because Lancelot is not
finished
First of all, Lancelot is project in the late phase of development
(like amarok2) - usable but not finished. See the definition of
vapourware if you don’t see where you are mistaken.
And, not to mention, that Lancelot was not intended to be a part of
KDE’s base packages. It’s like saying that Gnome is vapourware because
Gimmie is not finished.
Delusion 2. KDE is copying Windows (again, example is
Lancelot)
Well, as I see it, you either haven’t used the Windows’ menu, or you
haven’t used Lancelot (I bet on the later). Apart from being a /menu/,
what are the similarities? Comparing Lancelot to Kickoff or Gimmie (for
Gnome) would be more accurate… although still incorrect.
Besides Lancelot’s “copying” Windows what arguments do you have that
other parts of KDE’s desktop are copying it?
Delusion 3. KDE stopped focussing on the desktop, and went
to develop frameworks
Developing a complete desktop environment (with a lot more high
quality applications than Gnome has for instance) have to begin with
building a solid set of frameworks so that later development of actual
applications would be easier, and that applications reach new levels of
integration. (compare the so called Gnome Office with KOffice)
KDE 4.0 had most of the frameworks finished, and 4.1 is being built
on that. If you are saying that KDE is still ignoring the desktop after
the improvements in Plasma that will be in 4.1, than you’re either blind
or just don’t want to see.
Conclusion: I was hoping that Aaron will be the only
one that has to deal with persons like you, but, apparently (and
unfortunately), I was not right.
It is time to admit it - Lancelot will not be ready for 4.1. (like
you didn’t see that coming)
I know I promised that it will be in a working shape by 4.o, and
finished for 4.1, but there were a couple of obstacles for that
goal.
First, there is the fact that Decibel and Akonadi are not finished
yet so Lancelot is not able to show the Contacts section. This was the
main reason L was not released for 4.o, and still is a show-stopper.
Unfortunately it is not the only one.
Another thing are the problems introduced by the migration to WoC.
It took me a lot of time to port everything to /new Plasma/ and there
still are some glitches (mostly in the applet, not in the application)
that I’m trying to fix.
Well, that is really all…
So, where are we?
The current state of L is not at all that bad when I come to think of
it. I have started using it as my main ALI again, and I even use it
instead of KRunner for most of the time. Most of the things that worked
before WoC transition, work now as well - the application browser,
system and documents sections and the KRunner integration.
Lancelot 4.1 State
(Currently) Known issues
It crashes sometimes when browsing through the applications -
currently under investigation
It is uglier than before (lowest priority problem at the
moment)
It is not configurable (except for applet)
Contacts section doesn’t work - under construction
I had encountered a blog on Troll’s website (can not recall where
exactly it was, and who posted it… if you find it, please notify me)
about creating Java objects from C++. More precisely, creating Qt Jambi
widgets and using them in a C++ program.
It gave me an idea. How about a Java-based Plasmoid? We have Python,
JavaScript (ECMAScript) and what not, but no Java.
There still are no Java bindings for Plasma, but that doesn’t mean
that there can not be Java Plasmoids. If you think that I’m talking
gibberish, just look at the following screenshot. As you can see, there
are a couple of plasmoids that say Java (to be exact, there are 4 of
them).
Java in Plasma
No, they are not C++ plasmoids that just write ‘Java’ to fool you,
those are applets written in Java. You have the code in Plasma’s
playground (/trunk/playground/base/plasma/applets/java).
The main problem is setting up the environment.
First you have to install Java SDK (tested with SUN’s, it should
also work with IcedTea),
then, you have to install (or compile) Qt Jambi which is a bit pain
in the neck if you have Qt with debug symbols included.
And, once it is all installed, you need to set the environment
variables both for compiling the applet, and running it in Plasma
afterwards. You can use the environment.sh that is included with the
source, and modify it to your needs. You also need to change the Jambi’s
path in CMakeLists.txt.
Well, that should be all. When I find the time to try to generate
Plasma bindings for Java, you will be notified :) (To be honest, I hope
that someone will beat me to it)
