In my previous post I talked about how libferris now has a Plasma DataEngine which lets you get at the entire virtual filesystem (on demand) from plasmoids.
I've since extended things so that the DataEngine now includes a Service object, allowing plasmoids to write data too. Instead of tracking an XWindow, this time around I'll track a Google Spreadsheet and update it through the plasmoid. Doing this makes a mounted web service like GSpreads into a pastebin with access control applied. So you can share your clipboard with anyone in your "group" or company and stop others getting at it.
The two plasmoids show two spreadsheet cells, the top one is the top coloured cell and the bottom plasmoid is the lower, purple cell. The purple cell in the spreadsheet is the sum of the three cells in the column around the peachy cell above it.
First, updating the spreadsheet through the browser is reflected in the plasmoid. Towards the end I copy and paste a number into the top plasmoid, which updates the peach cell in the spreadsheet, which in turn causes the purple cell to update and so the lower plasmoid shows this updated sum. Of course, these two plasmoids don't have to be on the same machine. For tracking sums or other formulas, the ferris_graph might be more interesting if you are more interested in the trends than the current value.
In a previous post I mentioned that libferris can now mount Plasma DataEngines. Of course, the opposite would have to follow; you can now access the entire virtual filesystem of libferris as a Plasma DataEngine. For those who are unfamiliar with libferris, it is my little virtual filesystem project which can mount xml, isam files, relational databases, flickr, vimeo, google spreadsheets, Firefox, XWindows, and shall we say one or two other things :)
To play around, I now have a DataEngine that ships with libferris itself (which exposes libferris to plasma), and a few custom plasmoids which basically ask the libferris data engine to "cat" files and metadata.
One of the things that libferris can mount is the XWindow system. This lets you see all your windows and their size and location. This data is exposed in xwin://localhost/window and the Extended Attributes (EA) x,y show the x and y position of each window. For example, the below command will show you the name and location of the window "foo" on your local X: fls --show-ea=name,x,y xwin://localhost/window/foo
The libferris data engine makes "sources" on demand. You ask for a source by supplying the URL you want to read, the data engine makes the source for you and the content key contains the contents of that URL. If you want to get at metadata through the EA interface, just use @attribute in XML fashion.
The two plasmoids I made are libferris_cat and libferris_graph. The former just shows you text of the URL you have configured, the latter allows up to four files to be read and graphed. Obviously the latter plasmoid is meant for numeric data.
So to see the location of a window with ferris_cat set the URL to: xwin://localhost/window/foo@x
Which is what I've done in the below video. Notice that there are two plasmoids so I can track the X and Y ordinates of the window as I move it.
Libferris can also mount postgresql and other relational databases. For postgresql you can run SQL and execute database functions through the filesystem as well as interact with the base tables. Lets assume you have a simple database like the one shown in the below setup:
drop database testplasma; create database testplasma; \c testplasma
create table folks ( name varchar, salary int, id serial ); create view stats as select min(salary) as min, max(salary) as max, avg(salary) as avg from folks;
insert into folks values ( 'Fred', 15 ); insert into folks values ( 'Mary', 17 ); insert into folks values ( 'Henry', 21 );
select * from stats; min | max | avg -----+-----+--------------------- 15 | 21 | 17.6666666666666667 (1 row)
To get at this with libferris you might start by probing around the pg:// or postgresql:// URLs:
Because the view has no primary key, libferris has used the values of the whole tuple to form a unique file name. This is less than optimal for our needs when using the DataEngine because we want a stable filename. The solution is to leave out the name and just use "*" to have libferris expand it for us! So the below URL will have ferris_cat track the "min" value in the view: pg://localhost/testplasma/stats/*@min
The below video shows ferris_cat on the left viewing the min, the ferris_graph in the center shows min, max and average, and the avg is shown in the ferris_cat on the right. I add and remove a few folks from the table to see the effect on the plasmoids.
Of course, for a production PostgreSQL server you would use a scratch table and triggers to update it so that aggregates are not computed over mid to large sized tables all the time. Another advantage of triggers and a scratch table is you can easily handle rolling averages and delve into more advanced statistics while keeping the overhead known.
In short, if you can ferrisls and fcat something interesting, you should be able to drop it onto your desktop and monitor it now too :) All I need now is to get plasma onto my n810 :/ I have a feeling I'll be playing with tracking facebook and online spreadsheets using plasma+ferris soon ;p
After digging into KDE4's plasma a little bit it smelt a bit like an old friend. In Plasma you have one or more data engines, and each engine can have many sources. Each source offers a list of key-value pairs, which are updated at a nominated interval.
Normally folks think of filesystems as directories and files. But these days, you have to consider the Extended Attribute (EA) interface that filesystems offer as well. This makes a filesystem much closer to a large XML repository than just a collection of files accessible through a tree namespace (the directories). In libferris, each EA key-value pair can also tell the developer/user what schema that value has. This closes the gap between what a filesystem is and what a plasma data engine is just a little bit more. In fact, one might think of a plasma data engine as a virtual filesystem with a touch of extra stuff to allow a plasmoid to poll the data engine easily. This is not to detract from plasma at all, saying its "just a filesystem" means it is like postgresql, xml, or emacs to me ;)
For example, to see some current weather using my ABOMiNation plasma data engine and libferris (dev trunk), I can see the wind and also what type of value that EA or data engine key-value is:
One major upshot of looking at plasma in this way is the major upshot of everything being a filesystem. I can "cat" values directly from a data engine and also use fls to inspect data engines and their values from the command line while developing. plasmaengineexplorer is very nice, but its a bit of a pain to use a GUI tool to test out if the data engine is working when you are in a compile, run test cycle. It is also really easy to pluck out data from plasma with libferris, for example, the above fls with a --xml on the command line will do what you imagine. And if you are a nepomuk fan, using fls --rdf will give you an RDF/XML file to enjoy.
I found a few of the data engines would crash if they are started with a QApplication that forces GUI to off. So I black list s == "tasks" || s == "mouse" || s == "keystate" in order to mount plasma at the moment. Also, I'm using the signal/slot callbacks to get at the source key-value hash because the immediate mode methods don't seem to want to work for me :/
