Metalworks for UPnP devices at Tokamak4

As Kevin, KDE’s Solid master, already reported, the Tokamak 4 opened the possibility of the fusion of more particles into Solid (yet without turning it into Plasma, too 😉 ).

I had been working for two days mainly on porting the service and status framework of Khalkhi to the KDE 4 Platform including a proper Plasma widget, which will take some time to be completed, but I miss it very much now that my workspace is based on Plasma where the Kicker applet does not work. Three years ago I even started such a port already, but intermixed it with my personal ideas about a contact/person API to the Akonadi system. Now this port is of no use, so I have to redo the porting. Huh. Four years old code which I could not even remember/follow why I did its design like I did. Fun, not.

Just, the opportunity of having Kevin sitting directly on the other side of the table here at Tokamak 4 and him, other than planned, already having added the support for multiple backends to Solid the day after the meeting, also my wish to do something different yesterday, resulted in a first working prototype for a UPnP backend for Solid, at the same time providing a proof-of-concept work for the multiple backend solution.

I simply relied on my UPnP work started at the second Coherence/KDE sprint last october. Coherence is a Python-based server which… does a lot of UPnP related stuff, e.g. caching all information about the UPnP devices present on the local network and making this information accessible via D-Bus. Kind of like what Avahi does for DNS-SD/Zeroconf, with regard to this.
While the Coherence-driven backend for the network:/ kio-slave did not make it for KDE SC 4.4, I recently pushed the code into trunk, so it doesn’t bitrot and gets a final brush for 4.5, now that there is a released version of Coherence available which has the needed D-Bus interface as developed during that Coherence/KDE sprint. There is only a run-time dependency, and it is optional. It will fail silently if no Coherence server with a compatible version or one at all can be started/reached.
Currently the private wrapper lib named KUPnP is simply duplicated between kdebase/runtime and now kdelibs/solid, need to find out a solution. And like KDNSSD does not expose what backend it uses, KUPnP is not bound to Coherence, so it could be adapted if there are proper solutions, without any problems.

KUPnP, both as backend for Solid and the network:/ kio-slave, needs Coherence v0.6.5 at least (including the D-Bus service file, some packages miss this, e.g. the default one for OpenSUSE 11.2, instead use the Coherence package “python-coherence” from obs://build.opensuse.org/GNOME, from software.opensuse.org).

See here a screenshot of solidhardwarebrowser listing the UPnP devices found in the local network next to the ones provided from the HAL backend for the built-in hardware. The Coherence upnp-inspector at least shows the same 😉

Spoiler: Currently there is not anything you can do with the Solid devices from
the KUPnP backend, besides getting them listed in solidhardwarebrowser. But
it’s a start and might inspire other people to join efforts, hint… hint…

E.g. think about if you want to tackle a GSoC project for Amarok to work on a kio-slave to access the content of UPnP MediaServers.

Advertisements

Just listening to Spandau (Ballet), not going to

However it turned Thursday so quickly, it did, and so I had to leave again from the Kate-KDevelop sprint, which is continuing till Sunday. I am glad that I decided to go there. It learned a lot about the inner workings of KDevelop and Kate, both by querying the developers and listening to their discussions.
As planned I started a KDevelop plugin for embedding Okteta and got it pretty far with their help, so it might be completed and available once both KDevelop 4.0 and KDE SC 4.5 are released (mid-2010 perhaps). As the framework KDevPlatform/Sublime which KDevelop is built upon is quite elaborated, documented and stable I even had time to give another plugin a start which is supposed to manage UI strings (e.g. with a tool view like there is for classes or code-completion on entering of UI strings from a glossary formed out of the words, also help with the semantic markup or context tags). It’s only in a very early state and might progress only slowly, your cooperation is welcome, see for it in playground/devtools/kdevelop4-extra-plugins/uistrings.
In addition I learned how to make better use of all the tools already available in KDevelop. I have had been developing like in the bronze-age before 🙂
There was just nothing done for any cooperation of Kate and Okteta, except for the possibility of a discussion if some Okteta plugin could be used as the fallback view/editor for binary data files, instead of just displaying the data as far as possible in the text view like now. If Okteta perhaps moves to the kdesdk module, where Kate now resides, this discussion might be executed.

It was also nice to see a snowy Berlin, which I do not remember to have ever seen before despite many stays there (and KDEPIM developers perhaps should better not risk a snowball incident with Kate/KDevelop developers). And finally I also could give my laptop some time at it’s real destination, being on top of my lap. Seems I really have never before used it sitting in a couch chair. And surprisingly this works for many hours. But I also never ever before had been sitting with up to ten other people around a small table in a living room, all hacking away on their computers 😉

So once again thank you Milian for organizing this sprint, the Physics faculty of the FU Berlin and the KDE e.V. (and their supporters) for supporting it, and all the developers present for some nice and interesting days. Good food, good internet connection, good accomodation, nothing was missing and all well prepared. And thanks to Christoph (and ?) for GtingtheHNS from the bakery every morning, made a good start into the day.

Sprints are really a great time. I should just go to the next one, right tomorrow. Is there one? 😉

PS:
When my bus back arrived in Dresden, the driver turned the radio a little bit louder. What did I hear playing? Spandau Ballet. A funny little message from the lucky guys still staying at the Kate-KDevelop sprint and tonight going for some mini brewery in Berlin-Spandau. And we even shortly talked about the band when those staying were planning the evening 🙂

Okteta going for KDevelop (and Kate?)

While there already is a KPart from the hex editor Okteta, which can be embedded e.g. into Konqueror, but also KDevelop, it is only used Read-Only. More, the KPart system does not enable mulitple views on the same document, so in KDevelop having two views opened for a file, like with a splitted view area, also means two copies of the document in the working memory. Which also results in synchronisation problems, if you do (if you could) changes in each of the views. All this is part of my motivation for the Kasten framework. But until that is done, real life demands pragmatical solutions. Like manually writing plugins for the individual frameworks, e.g. for Sublime/KDevPlatform, if going for KDevelop integration.

And having good integration of Okteta in KDevelop, with all tools and whistles, has been something I often wanted to have. What better can I do than joining a bunch of KDeveloper developers for some days, for first-class coding support? Like at the current Kate-KDevelop sprint in Berlin? Organized by Milian Wolff, and with support from the KDE e.V. and the Physics faculty of the FU Berlin, I am now happy to sit between the Kate and the KDevelop code crunchers (“Let’s remove this!”, “Yeah”, “No”, …) since three days.

Being attached to a big network first shortly distracted me, because there are a lot of devices with a lot of unknown services announced in the service description systems like zeroconf/DNS-SD. Just look at the number of printers:

It also gave me an idea for a new heuristic to guess the type of device: One with a lot of unknown services must be an iPhone, as each iPhone app seems to invent a new custom network service, with a custom protocol. I do not think the network:/ kio-slave will ever be able to and should support all of them.

After being distracted I returned to my initial target, and with the help of Alexander (adymo) , Niko (nsams) and Aleix (apol) the Okteta plugin for KDevelop is already at the state of the Okteta KPart and better. Just the tools need some more work, as the Kasten framework does not match the KDevPlatform/Sublime framework here, so the wrapper for the tools are a little more complicated to be done. But look doable. Screenshot at last:

And yes, Okteta as a stand-alone program is going to stay.