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…
Bars below the text (like in dolphin) will not be
implemented:
I’m trying to keep everything in Lancelot generic enough with a
complete model-view separation, so introducing a widget just for a
specific model is not an option. Comment by Ivan Čukić — 7 February
2010
Bars as a part of the icon
This one would be allowed when concerning the above statement. But I
don’t really see the point in doing it. When the usability is concerned,
bars are more desired when comparing multiple statistical variables
(national growth per year), while when percentages are concerned, pies
are the way to go (and to increase the usability even more – these are
color coded – from blue, through yellow to red). Introducing a new
feature just for the sake of it is not something I’m willing to do. If
you can convince me that bars* are better** than pies, I’m ready to
listen.
bars that can fit into the icon itself like the current pies do. **
better as in “should replace the pies” - having a configuration option
for something this insignificant would be a waste of space.
