- time
- cia.vc
- weather
- dict
- hardware announcements (solid)
- system monitoring (sysguard)
- power management (solid)
- network interfaces (solid)
- akonadi
not bad. and i know of at least a few more than will be coming for sure as well. each of them, except for the first two, have been written by different people who aren't me. i really need to get those tutorials written...
update: a chemical information engine landed in svn while i was sleeping last night. it uses data from the kdeedu project to provide access to information on various chemicals. this makes it the second engine by sebas (his first being the power management engine).
and when i read success stories like this one from the latest commit digest it makes me so very very happy (emphasis mine):
On the 18th June, Summer vacation started for me so I suddenly received a large amount of free time. The week before I had read that KDict was not going to be in KDE 4. As I had used KDict before and found it useful, I thought that replacing KDict would be a not-so-hard project to start developing on KDE with. At the same time, I also wanted to work on Plasma, the new, cool thing, so I decided to merge the two and write a dictionary Plasmoid. My friend, Jeff Cooper also wanted to get into KDE development so I asked him to help me.
On Monday, we easily wrote the plain text version of the Dict engine in a few hours after figuring out how to do TCP sockets in Qt. We were surprised at how easy it was to get working.
i can only imagine the explosion of plasmoids for these engines that will occur when we start offering script bindings through kross and expose the packaging creation and loading system to the outside world.
and that's just four concepts at work in plasma right now (engines, plasmoids, kross, plamagik packages) ... which is why when i look at other attempts to make "little desktop widgets" i tend to cringe and think, "they really don't get it, do they?" this is just the first set of steps to be able to really do what i want with the desktop. what we're seeing now is just the beginning to bigger and better things, and it really seems like we're already past the design and thought put into pretty much anything else out there.
i'll also be blogging on plasma progress at least daily during akademy. hopefully the hacking goes well so i have something to talk about ;)
11 comments:
Its really great to see Plasma getting so much attention and developer man power.
I'm now waiting for the missing engines which are necessary for a kicker replacement: system tray, window bar and maybe menu.
Future compatibility.
Just curious, are there any rules set out for "binary compatibility" across KDE releases. I just noticed this cool applet today (http://vizzzion.org/images/blog/battery-plasmoid.png) an started thinking: what if you want to change some keys provided by the data engine? This will break backwards compatibility. Are there plans to review the data engines before releasing KDE 4.0?
system monitoring, does this also cover a list of running tasks/windows? Or will there be another engine for this?
Hi Aaron,
I have a doubt about plasma.
In kde3 we have a window (frame/frameless) for:
kdesktop,kicker,kmenu and avery running software so
when I launch kmenu I can see that it is able of to overhang
the window of konsole or other running software.
In kde4 I understand that kdesktop has been replaced with qgraphicsview
where in it there will be a lot of qgraphicsitem aka plasmoid.
Kicker will be replaced with a plasmoid as kmenu and other
Now I don't understand as plasma will make a plasmoid to overhang
an other window of a running software.
P.S.
Sorry for my bad english and thanks
for all.
Vincenzo
@liquidat: until we get a chance to redesign the system tray, it won't be fred by a DataEngine; it just doesn't make much sense to do so.
the menu will also not be driven by a DataEngine though it may reference some of them for certain features.
@Diederik: we're not committing to compatibility for 4.0. for 4.1 we'll be getting stricter. this is true for the engines themselves as well as the libplasma API itself. in practice idon't think it will be a big issue with engines, but we will want to have guidelines/commitments at some point.
@anonymous: tasks will be a separate engine
@06labs: it's the same as for panels themselves, and how menus are currently handled: they are separate top level windows. it's not a problem to have various QGVs in separate windows, or if more appropriate "regular" widgets.
as for kicker being replaced "with a plasmoid" that's a common misunderstanding (the origin of which i'm not sure?); the panels will be graphicsviews that contains plasmoids, exactly like the desktop. no different.
Panels are not only a plasmoid? Can people still write a new panel if they don't like the default one?
@emp3ror: this was already possible in kde3 and will be even easier and more flexible in kde4.
the two things (panels being coronas that contain plasmoids rather than plasmoids themselves) and being adjustable/customizable are completely unrelated facts.
I'll be looking forward to make datasources and plasmoids in Python with Kross :)
Hopefully it will be possible soon.
@Henning: "I'll be looking forward to make datasources and plasmoids in Python with Kross :)"
datasources, not likely. plasmoids, certainly.
i'm not sure writing datasources in languages other than c++ is a good thing, to be honest. it isn't that hard to do, keeps overhead down and keeps the language binding count at runtime lower. maybe i'll have my mind changed on this at some point, but for now that's my take on it.
"Hopefully it will be possible soon."
yes, it will =)
i'm glad you stick to your promise of blogging at least daily during akademy :P
Judging from a post to kde-core-devel, they don't have internet at Akademy at the moment.......
Post a Comment