hard things simple

Solid gives us the ability to easily react to hardware events. With the large number of DataEngines that use the network, this made an almost-too-obvious target. Since I'm still tickled fluffy bunny pink by the weather wallpapers, I figured I'd hit that first.

So I tucked into the weather DataEngine and even though it's one of the more internally complex engines out there, it was only ~10 lines of code:

0. Query the state of the network when it starts out.


1. Connect to the statusChanged signal from Solid::Network::notifier()


2. When the network is not available: create entries on request with empty data, return "it's coming" (aka false) from updateSourceEvents


3. When the network comes up, set m_networkAvailable to true and call updateAllSources

What's neat about the way the async support built into DataEngine is implemented is that visualizations that are set to update every N minutes, if they don't get data right away they go into a queued state. Whenever data does finally appear (say, when the network comes up) they will instantly update. Of course, if the network goes down and then back up within their update interval, they won't needlessly update. (I do have a patch to allow that to be overridden at the discretion of the DataEngine ... but I'm still contemplating the implications of that API-wise.)

As for the network "fluttering" the minimum update interval in the engine will keep the engine from hitting the network constantly just because the connection comes and goes every 30 seconds (or whatever). I may have to eventually introduce some additional event compression safety, but so far it looks OK.

I'd like to put this into Plasma::DataEngine itself so any of the network using DataEngines can get this magic "for free". Well, with one line of code to turn it on, anyways.

The dilemma is, as usual in libplasma, one of API: just turning it on or off doesn't strike me as quite good enough. If a DataEngine plain doesn't work without networking, we probably want to queue updates as is now done for weather and let release the flood gates (excuse the pun) when the network is available again. But for DataEngines which only use the network when it's there but don't really require it (geolocation on a device with both GPS and wifi/3G as an example) they may want to get a kick in the pants when there is suddenly network but they still want to process requests normally even when the network isn't there.

There's also the issue of bandwidth availability, cost, etc.. I'm not sure how much we care about those things as first level concerns in laptop and desktop land, but I can think of use cases and devices where this will matter.

So I'm trying to consider what an appropriate API would be in DataEngine without going over the top with too much detail but also not hitting too low and making it harder when we do hit these more fine-tuning-desirable situations. As usually, the thread is on plasma-devel at kde.org.

In the meantime, I can log in and even if plasma-desktop starts faster than NetworkManager can connect I still get a pretty wallpaper (and a weather plasmoid that isn't spinning it's busy wheel) as soon as the network is there.

Thank you Solid, thank you NetworkManager / HAL / etc, thank you India, thank you terror, thank you disillus... omg. I can't believe I just broke out into an Alanis Morissette song mid-blog. How embarrassing.

;-P

Aside #1: there's now a small library the various weather Plasmites are putting together to share things like configuration, location switching, etc. It already uses the geolocation DataEngine too, though there is a granularity disparity between the resolution of the geolocation results (fine grained) and the weather services we currently have which don't have a lot of small towns in them. Something to figure some sort of solution to.)

Aside #2: A fellow came online yesterday to say he had gotten permission from wetter.com to start using their data, so our coverage of Germany and various other locations in Europe should see a sharp uptick when he's done with that weather plugin (Ion).

Aside #3: There have been a couple of really interesting geolocation based ideas floated by new (to Plasma) developers on the mailing list. I think this whole "finding where you are with whatever happens to be at hand and then make awesome things happen in the applications" is going to take off nicely for us this year. :)

Aside #4: Am I the only one who's disappointed with this season's netbooks? They've settled in at $400 a pop and are now quite happy being the smaller, slower, uglier siblings of "real" laptops. Holy missing the boat or what? Now we have a $350-400 entry point (netbooks) and a $6-700 entry point (low end notebooks) but the $200-300 range is still empty and the "OMG poniez!" interfaces that might make me actually want to buy one of those $400 playmobile versions of a real laptop are nowhere to be seen on the store shelves. *sigh*

Aside #5: As a commenter pointed out in my previous blog, the log out process is not very pretty, fast or .. well .. "KDE4". It does indeed need work, and I think we ought to replay the splash screen in reverse instead of showing all those windows blinking out of existence, which is really ugly; though we need to handle the "uh-oh .. this app wants to know if you want to save that document" situation gracefully too. Tricky.

Aside #6: Speaking of splash screens, the splash screen started centering itself properly on my laptop recently which was really nice. I think it needs a little spinny wheel on it though. As at least one bug reported has noted, there are moments when nothing is moving and you wonder if it's frozen up or something.

Aside #7: I think asides have taken over this entry. *sigh*