Jedidiah,
there is abolutely nothing wrong distributing your deslet code for peer review - In fact, it's a very good idea... But whenever you'll think you desklet is usable, please take the time to prepare and send a submission email for inclusion on main page.

It will not take too much of your time, and it will help both your desklet having more visibility (you will therefore receive better feedback), and adesklets gaining a broader audience and a stronger community.

Thanks for your work on this. I hope hearing again from you soon. :-)

Looking good!

Very good implementation of various modules....sometimes its good to have everything in one display like that...perhaps a duplication of work, but theres nothing wrong with that, right? ;)

I like the customizability already involved....the background isnt too changeable, so that might be something you want to add. The current image you have as background works, but you might want to look at other monitors to see what they're doing as well...I actually like your method as it uses three images for the background and one could create a more unified concept for the background instead of little pieces. More modules coming up is good...the more the merrier. I like how it works so far!

I'm glad to see you're working on more optimization...I was a little worried when the desklets started sucking up 7% of my CPU (yeah I have a little processor)...then it settled down to 3.4% so far. It's still the highest desklet by far but hopefully the first release will be slimmer. :) Keep working on it.

Well, to be fair, I have an itty bitty processor (Pentium II 400MHz). Now SystemMonitor has settled to about 4%...still too high (I like to use X as my benchmark....anything higher than it and its not something I want running all the time), but it should get better with the next release.

A tips and tricks section would be nice to have in the forum....that way new desklets can start off with tried and true protocols and be already streamlined. I'm not saying lets use cookie-cutter desklets (far be it for me to discourage innovation), but since we're all using each others' code for ideas, why not outline what works and how and why.

Is there a certain type of system we're using as a baseline? For instance, obviously we're not all 1000Ghz Pentium 5's with 6 Gig of RAM (and if you are...;)). I know Sylvain is aiming for platform independability, but is there perhaps a least common denominator we're aiming at? I've got a PII 400 with 440 RAM, so while I'm not exactly low man on the totem pole....I'm close. I'm not advocating a 'Minimum Requirements' kind of system, but where does optimization end? Should it end? Ideally, I don't even want to see any desklet show up on my top 10 processes list, but I don't know if thats reasonable.

I wrote an exemplification of that two weeks ago for ZeroDivide... So you might want to look at test/widgets.py from adesklets' base package.

There's only so much something like this can be optimized. On my system the current build uses less CPU either X or gkrellm. If I just load up the CPU portion (rather than a stack of monitors) it is identical in CPU use to acpumon. Naturally the more actively changing meters you have, the more CPU tends to get burned. My machine is relatively high spec however, so all these numbers are crunched to the low end of the scale, and differences are hard to percieve - on a low spec machine it may show up more.

If performance is still seen to be an issue I guess I could try and create a low spec version. In the meantime people seem to be interested in theming and text fields, so if I get some time I will add that in. I am away for easter though, so don't expect results soon.

In the meantime I've submitted what I've got so far. Consider text modules (for hostname, time, uptime etc.), theming, and a low spec version as possible features for the next version.

I had some spare time today so I converted SystemMonitor over to using a pluggable theme system (it still looks the same by default, but you can now create "theme packages" and specify a theme to use in the config file).

I also had a look at Torsmotoy to see if I could get any ideas for further optimizations. I've made a few improvements, and changed the update rate to be alterable. If I set the update speed to update every 5 seconds (as with Torsmotoy) CPU use is now considerably less than Torsmotoy on my machine. Of course, it may not be that way for everyone - perhaps hardware acceleration via my graphics card (a GeForce4) is coming into play.

Regardless, it is now fully themeable and low on resource use.

I'm off for Easter now.

I just wanted to mention that the the current version of acpumon has a bug where it draws the whole window twice per update. ( dont ask )
It will be fixed in the next release.. hopefully soon



I recently added something similar to the network monitor ive been working on. Maybe we can use the same theme format so we can share themes.

ZeroDivide

I do understand that Torsmotoy is more interested in flexiblity (my system, in its turn, is more interested in pure eye candy). It is worth noting that SystemMonitor does allow for dynamic placement of meters into any order or arrangement you like.

I was mostly using Torsmotoy as a CPU gauge as I presumed you had optimized it to at least be close to meeting your requirements.

I've beefed up the flexibility of throttling the meters (individual meters can now having differing update speeds - the CPU meter updates every 2 seconds, but the Memory meter only updates every 10 seconds etc.) so it is quite possible to get low CPU use by adjusting everything downward accordingly yet still getting timely updates on those statistics that need it. If you adjust CPU, Network and DiskIO to 5 second updates, and Mem, Swap and DiskSpace to minute updates it runs fairly frugally.



That would definitely be nice, but may be tricky - I construct my meter backgrounds a little differently than you (I think). We'll see I guess - perhaps we can converge towards an agreed standard.



Interesting you should say that. I was contemplating rewriting things a little using Hbox and Vbox widget packing to organise things (instead of my current crude push and shove method). I do think a base library of some standard bits and pieces is a very good idea indeed. I look forward to what comes from it.

Well, I sat down and tried to wring every last bit of performance I could out of my code, and have a new version (already submitted) that does make significant gains. The problem is that there's only so much you can do with these monitors: in the end you are drawing a lot of data to screen on a very regular basis. That's going to be expensive. I think the best that can be done is to set some realistic expectations on performance. I decided that gkrellm would make a reasonable performance benchmark for me - it's a popular system monitor, so if I can beat that, then I should be doing okay. Here's how it pans out on my system (2.2 GHz P4) with SystemMonitor configured to be slightly more expensive than the default setup:



The gains mostly come from trying to everywhere minimize any drawing and using little localized buffers. I'm unsure if there's much you could do to make such code easier to write really. At best we could try and write a short guide to writing such desklets.

(And yes, I'm well aware that gkrellm does more than SystemMonitor. I think SystemMonitor looks a lot prettier though, and it does what it does more cheaply too (now), so it makes an acceptable replacement for me)

Yes, I was rather surprised about X, but that seems to be anomolous - a consequence of other stuff running, as X CPU use has in general been much lower than that particular figure (despite the adesklets running). I am honestly not sure why it was running as high as that at the time.