Having found a little spare time I've attempted to use what I learned writing the original SystemMonitor, combined with the various requests for extensibility etc. and tried to design something new with much improved flexibility allowing for a much broader range of possibilities for what gets stacked up in a given Monitor desklet. I have managed to produce a provisional design that fulfills a lot of what I'm looking for: It should be trivial to build far more than basic meters (like a weather display, a clock, mailbox status, hostname readout... whatever you want really), and more flexibility in meters themselves. Adding new widgets to be available to stack up is as simple as dropping an appropriate script in a "plugins" directory. The downside is that, as one might expect as the price for flexibility, the result is significantly more resource hungry.

I was hoping to gather opinions as to whether this is going to be a fruitful path to pursue, and possibly some help trying to squeeze some optimizations out (there is likely a bit of space right now, it's a provisional design - just enough to prove the concept). Any thought or ideas would be appreciated.

provisional proof of concept code can be found at
http://jedidiah.stuff.gen.nz/NewSystemMonitor.tar.bz2
Please excuse a few of the hackier parts at the top level - I just wanted to quickly get enough of a frontend built to try out the core underlying work.

A provisional test for a new SystemMonitor desklet is available at:
http://jedidiah.stuff.gen.nz/NewSystemMonitor.tar.bz2

This desklet provides a modular configurable vertical stack of "Monitors". Each monitor type is provided as a script in the plugins directory and has its own conifg file which keeps track of multiple monitor instances within the desklet. So, for example, to configure the MailMonitor check the MailMonitor.config.txt which supports multiple mailmonitors (for different mailoxes for instance) just as adesklets does. Monitors provided for demonstration include Clock, Weather, CPU, Memory, Swap, DiskIO, NetworkIO, and Mail.

Building new monitors is relatively straightforward with all the complex positioning and rendering code farmed out to VBox and HBox widget packing containers (think Tk).

Widget packing etc. is fairly flexible, and entirely dynamic. To see this in action, go to the CPUMonitor.py plugin and uncomment the line in the "update" function. The desklet and all the monitors should now resize and reposition themselves dynamically - note that centered and right justified text behaves accordingly as well.

In terms or resource use this system is currently still more expensive than the old SystemMonitor, but I'm hoping further optimizations can be made. Dynamic resizing is quite expensive, so it's only really acceptable as something that happens occasionally (the variable sized CPUMeter icon being simply a demonstration), but should be fine in such cases. I'm still not happy with the actual resizing (is there a way to resize the buffer image? Does "resize_window" do that if I set the image context properly?) which is currently a bit of a memory grabbing kludge to escape the image id problem when freeing images. Suggestions are more than welcome.

I would appreciate any testing people can provide, and some advice on whether this project should become the new SystemMonitor, or a different desklet in its own right. In favour of the former is that it currently replicates most of the functionality of SystemMonitor. In favour of the latter is that it may gain other more interesting plugins, and the fact that I expect it will always be more resource intensive: it would be nice to keep the existing SystemMonitor as an inflexible but efficient desklet. Any advice, suggestions, or plugins people would care to provide are more than welcome.

Hopefully I can do code cleanups and begin the task of decently documenting soon.

Thank you, any suggestions would be appreciated.



I must admit I hadn't looked at doityourself, and looking at it now perhaps I should have. A lot of what I've done is similar to your work in many ways. There are some differences due to slightly different goals in terms of how we wanted things to behave, but alos much commonality, and some interesting ideas that I may well exploit.

Perhaps we should try and put together a standardised widget library for adesklets in general to save people this sort of hassle in the future. Yours is obviously more developed than mine currently, so that's probably the way to go.

Hopefully Sylvain can provide some feedback when he gets back.

It's good to have you back. I hope the trip was enjoyable.



Thank you!



To be honest such a situation simply hadn't occurred to me, but yes, I should be checking available screen dimensions. Luckily that's easy enough to fix.



You're right that packing and repacking are the expensive operations now (though the redraws are also more expensive as they have to be separated into clearing and rendering macros). I do have an older less ambitious version of awidgets kept aside that has much stricter geometry requirements, and it does indeed run much lighter (in a large part due to the ability to combine clearing and rendering) , but has issues of it's own (various things I would like to be able to do but haven't fully implemented yet will be impossible). If the generic version proves to be too expensive in the long run I may go back to the other code and try and bring it up to shape. I'd prefer to try and make the generic version work though, as it really is a better system all around.



Well I'm certainly willing to bring what I have up to standard for redistibutability - there are a few more features to be added (mouse click actions and "show/hide" functionality) for the widgets library, but mostly what it needs is vast amounts of documentation - which was on the books anyway.

The problem is that with the break over I have considerably less time now, so development has gone from fast paced to absolutely crawling. I'll work toward a solid documented version, but I can't promise any time frame on that. If Diego is interested in doing something I expect he could get there faster - though I don't know what his time is like currently.

For now put it in the "I intend to do so, but don't know when it will be done", and if Diego manages something before me all the better for having a widget library available faster.

It certainly was: it's always nice to take a break from the continental winter.



As you know, the trouble with adesklets is that you really cannot expect a higher-level interface based on the Python package to be very responsive, since the processor resources used increase very fast with the number of emitted commands, and such interfaces typically do need to emit quite a few in more dynamic cases.

This said, I would definitively prefer something generic too... As for switching back later on, I would appreciate if we could avoid it -- one of the reason I wrote adesklets in the first place was because I was tired of unstable APIs in similar softwares.



...A multi-lines text widget would be nice too. ;-)



I depends what you see as vast amounts of documentation - personally, I think a single new chapter in adesklets manual plus one or two code samples under test/ would do just fine.



I appreciate that -- we all have our contingencies. Good luck to both of you with your school work. Just let me know by email should you need anything or should you have some content ready for provisional inclusion. Regards,

I was thinking of the first alternative (text that wraps within a fixed size box)... I know it is somewhat harder if you consider glyphs with variable kerning, but it seems to me it can be optimized relatively easily if you just fix an upper bound for per-character width and that you rely on the textwrap module internally.

This said. since you mentioned it, a special textbox widget built around your vbox that would automatically instantiate single-line text widgets from some sequence of strings would also be nice. ;-)