There were two main problems with the Lancelot Part applet.
The first was the name. The name, although it does represent what the
applet is technically, it doesn’t really say what the applet is meant
for and what it does.
So, it is problematic when you see it in the applet browser, and it
isn’t any better to see it when you drag and drop a folder onto the
desktop and get the options to show it in the “Folder View” or “Lancelot
Part”.
Configuration
]
The second problem was that a lot of users thought that Lancelot Part
does nothing (aka doesn’t work) because when you add it by using the
widgets browser, it is just an empty applet. (nobody really bothers
reading the instructions
these days).
Now, you can use the configuration dialogue to choose what you want
to be shown in the applet.
Ideas
Shelf
I’m currently having some problems wording a couple of things and I
would appreciate any help you can give.
The first problem is what to put as a description for the Shelf
applet. “Generic list which can hold various types of items” sounds
really bad :)
The second is the title for the section of the configuration dialogue
shown in the image above - the section below “show the search box”
option where you can choose which /sublists/data models/ to show in the
applet.
Internals
The ‘internal’ name of the applet (as seen in plasma*rc files) hasn’t
changed to keep the back-compatibility without the need for hooks in the
configuration system to tell plasma about the rename. The other thing I
had to watch out while redoing a few things was to keep the old applet
configuration structure intact. Surprisingly, I managed it somehow.
The applet’s source code is still located in
kdeplasma-addons/applets/lancelot/parts but it will be moved to
kdeplasma-addons/applets/shelf soon enough.
Lancelot (the menu) was not really designed to run on mobile devices
(although it could be used on such devices as a full screen application
quite well), but the Lancelot Part applet proved to be a rather good
fit.
I wasn’t involved in any mobile-related developments at Tokamak 4 (I
had too much to work on krunner and activities) but I found some time to
test the KDE/Plasma enabled Jax 10 devices.
Placing a Lancelot Part inside the newspaper activity that showed
favourite applications and a search box was a breeze and it worked quite
well. Marco did a really good job of adapting the plasma-netbook edition
to mobile (touch screen) devices so the Parts applet required no changes
at all to fit in the new environment.
Here is an obligatory blurred screenshot:
Lancelot Mobile
I’m planning to make a screencast about using Lancelot in Plasma
Netbook, but I’m not finding the time. I hope I’ll be able to make it
soon.
This one will be short, I don’t really have the will for writing - it
is half past midnight here.
The activities infrastructure is mostly finished - now only polishing
is left to be done.
The new organization goes like this:
The core activity-related features are placed into a kded module
which doesn’t depend on anything but Qt and the core kde libraries. The
class for writing the clients of this service (any program that wants to
be able to react to activity changes etc.) will be in kdelibs. The API
is minimal and very easy to use - it took me only a couple of minutes to
patch KWrite to be able to use activities.
The second part is the revamped Nepomuk Activities service (I already
blogged about it - the changes made at T4 were mainly related to make it
fit the new arhitecture). If it is running, the above class passes all
the info to it. Running the service enables the access to extra
meta-data regarding documents and activities.
The third, and last part is the manager class which will be in
kdebase/workspace (most probably) because it is only intended to be used
by kwin and plasma. Normal programs shouldn’t use it.
Until now, drag and drop and some other things in krunner based
launchers (lancelot, kickoff, and maybe SAL?) are based on a small hack
- manual detection whether the result is in fact a .desktop file of an
application provided by the service runner, and if it is, then we can
use it.
So, the first thing I decided to make is some way of allowing
serialization of the search results. I decided that the best way is to
allow the results to have mime data assigned to them. Naturally, since
most of the time you don’t need the mime data, it doesn’t load by
default - it is loaded only when requested and only for the specific
search result.
That is all for now from T4… I’m sleepy and I can’t really write
more…
]
