There are several gdesklets available on gdesklets.gnome.org, which do not have ebuilds. Ebuilds for gdesklets are incredibly easy to write, it's a matter of tweaking one or two settings (and that's only because the gdesklet developers don't seem to stick to any one format). I've made ebuilds for the following gdesklets: desklet-cornerxmms (http://gdesklets.gnomedesktop.org/categories.php?func=gd_show_app&gd_app_id=53) desklet-deskquote (http://gdesklets.gnomedesktop.org/categories.php?func=gd_show_app&gd_app_id=62) desklet-desktao (http://gdesklets.gnomedesktop.org/categories.php?func=gd_show_app&gd_app_id=58) desklet-xmms (http://gdesklets.gnomedesktop.org/categories.php?func=gd_show_app&gd_app_id=42) (A note, this desklet really doesn't work that well. It seems to rewrite pyxmms itself, and badly at that. But for completeness sake, and it's a good demonstration desklet, easy to understand.) desklet-sysinfo (http://gdesklets.gnomedesktop.org/categories.php?func=gd_show_app&gd_app_id=56) desklet-imapmail (http://gdesklets.gnomedesktop.org/categories.php?func=gd_show_app&gd_app_id=49) In addition, I wrote three ebuilds for the LTVariations gdesklets (http://gdesklets.gnomedesktop.org/categories.php?func=gd_show_app&gd_app_id=46), and I've just seen the desklet-ltvariations ebuild already in portage. I still think it's more logical to split it into three ebuilds, but that may just be me. I'll include my ebuilds, anyway, they're the desklet-ltcandy, desklet-ltothersensors, and desklet-ltvsensors ebuilds. Finally, the author of the Recently Used gdesklet provides his own ebuilds, although I never really got it to work. His page is at http://www.clarkson.edu/~clarkbw/desklets/
Created attachment 18460 [details] ebuild for desklet-cornerxmms Here's the cornerxmms ebuild.
Created attachment 18461 [details] ebuild for desklet-deskquote And the deskquotes ebuild.
Created attachment 18462 [details] ebuild for desklet-desktao And the desktao ebuild, which depends on deskquotes.
Created attachment 18463 [details] ebuild for desklet-imapmail Ebuild for imapmail. WHy can't you do multiple attachments?
Created attachment 18464 [details] ebuild for desklet-sysinfo Ebuild for sysinfo
Created attachment 18465 [details] ebuild for desklet-xmms *sigh* Ebuild for desklet-xmms
Created attachment 18466 [details] ebuild for desklet-ltcandy Ebuild for ltcandy, the nice-looking part of ltvariations
Created attachment 18467 [details] ebuild for desklet-ltvsensors The Sensors provided by the LTVariations guy.
Created attachment 18468 [details] ebuild for desklet-ltothersensors And finally, other sensors that the LTVariations desklets rely on.
The following sensors/displays have been tested by me (really, i have looked at them) and they won't be going in at this point in time. The reasons for this are largely stability/maturity/featurability(?) reasons: xmms, desktao/deskquotes (same thing) Secondly, the ltvariations are allready in portage This leaves the following sensors which I have/am considering: cornerxmms (top of the list, come along way in terms of features/maturity) sysinfo (new version looks much better) And lastly imapmail could make it in, but i dont use imapmail and cant test it, so perhaps i can enlist you as a tester? So in summary, cornerxmms/sysinfo are most likely to be included. Need info on imapmail. And lastly, thanks for sticking to my gdesklets ebuild style, which makes things easier for me to look at.
I'm actively using imapmail, and it seems to work perfectly. i.e. it sits on my desktop and accurately reports how much mail I have on my IMAP server. If the server goes down, it just changes into an unhappy icon, and doesn't do anything like kill my X server. I quite agree that the xmms one is horrendous, I thought I'd throw it in because it was reading that that taught me how to write desklets, but I suppose that's not the greatest reason. Desktao and Deskquotes, though... I'm running them on my desktop, too, and it seems to work perfectly? I've had no worries at all, and that's not just because I'm reading the soothing extracts from the Tao Te Ching. What were you referring to? Cornerxmms is very very nice, and sysinfo is, too (although it's a bit big for me, takes up too much desktop real-estate). Both are stable for me, and do what they're supposed to. While we're on the subject, I have patched Cornerxmms so that you can click on the time-display and toggle it between time-remaining and time-elapsed. However, my patch depends on another patch which I wrote for pyXMMS, and submitted to the author, who says he'll review it soon. Should I submit my two patches to you and whoever is in charge of pyXMMS, or just leave it? Erm, in summary: imapmail works fine, but I'd review the judgement on deskquotes/desktao.
cornerxmms: patch sounds like a good idea, however i dont think we'll be patching pyXMMS, not without upstream review anyway. so my advice would be to post both the pyXMMS patch upstream (which you've done) and the cornerxmms one upstream as well (although if the pyXMMS one makes it in, i can look at incorporating the cornerxmms one here), but cornerxmms development seems quite active, so upstream is probably your best bet there. sysinfo: it's big, and sys information is provided (better, or so it seems to me) by both the desklet-*info ebuilds as well as ltvariations (i think im going back on what i said before about sysinfo here arent i?) imapmail: thanks for the feedback deskquotes: i can take another look at them, sure.
I'll wait for Mr pyXMMS to get back to me before pursuing my patches ;-) Sysinfo has its disadvantages, yes, but it also has one major advantage in that it is one desklet, and not seven. I'm not happy with the seven python images that my use of all the *info desklets create. I think it's up to the users to decide which tradeoff they want, and sysinfo is likely to win enough times to be worth including, I think? Thanks.
Okay, I've decided to include both cornerxmms and sysinfo, and they're both available in portage from now. This leaves deskquotes/tao and imapmail out at the moment. I've stuck to a policy with gdesklets of only adding a few at a time, and ensuring all the desklets I add are of a certain quality/usability. This is necessary for several reasons, the first of which is that I'm the only one actively looking after gdesklets (my own fault that one). It's also that by adding them slowly and after consistent testing we can hope to ensure their quality. So far this seems to have worked as we/I haven't recieved any bugs about gdesklets breaking. So at the moment I'm sticking to that policy. I've put quotes/imapmail on my Desklets-TODO list (which does actually exist and is the order I consider them for inclusion), so there's a chance they'll end up in portage, but not just yet. Thanks for your time and effort with the ebuilds, just a couple of things I noticed. The permissions inside the gfx/ dir in CornerXMMS need to be 644 on all the images or the display wont load. And the SysInfo-0.21.2.tar.bz2 is actually a gzipped tar archive, which is why it requires a src_unpack( ) and some work to get it going. These small fixes are in the ebuilds in portage. Thanks for your time and effort, and please be assured that I am watching quotes/imapmail, it's just that I'm actively delaying their entry. Final comment(s) ?
Your policy of few-but-stable seems sensible. I think I may have noticed the b0rkage with cornerXMMS's permissions, but forgot to fix that ebuild. I wish the Gnome people would standardise their packages. I'll keep an eye on gdesklets (I notice they've got a new RSS reader desklet now, it's still a bit featureless, though), and submit any that I think are worth it. Thanks, Cheers, -Jonathan
>I'll keep an eye on gdesklets (I notice they've got a new RSS > reader desklet now, it's still a bit featureless, though), > and submit any that I think are worth it. Please do. Yeh I also really wish they could fully standardise the gdesklets methods of packaging, I think there are about 2 or three main ones, and then very poorly packaged ones such as SysInfo. Thanks for your time, suggestions, and understanding. Mike.
*** Bug 30192 has been marked as a duplicate of this bug. ***
The imapmail depends on an IconButton sensor which I don't believe is part of the desklets-core package for Gentoo. When I was doing my imapmail ebuild I had to write an ebuild for IconButton as well for it to work. Gentoo's current LTVariations includes IconButton, but if you don't have it installed imapmail won't work. I created some seperate packages for senors in bugs 30193(IconButton) and 30202(ExternalInterval), but it might make sense to include those senors in the core gdesklets package or a desklet-extra-sensors package. Alternatively you can have imapmail depend on LTVSensors or just install IconButton with the imapmail package. I don't know how you want to handle all these 3rd party sensor dependencies.
*** Bug 30922 has been marked as a duplicate of this bug. ***
Hi, I've been having a problem recently with my new mail not being noticed by various applications: mutt doesn't automatically change to the mailbox, and newmaildir doesn't detect any new mail in the Maildir. This befuddled me for ages until I realised that it was because the imapmail gdesklet was marking it as seen every time it polled the imap server. Or, not "seen" as such, but the imap server was moving it from $MAILDIR/new to $MAILDIR/cur, while still leaving it marked unread, which was what was confusing all my applications. As a result, I've stopped using the imapmail gdesklet - I like irssi and mutt to know about my new mail. As far as I can see, this is not a problem with the desklet itself - I looked at the sensor code, and it clearly says: imap.select("INBOX",readonly=1) So, either the imaplib python library doesn't respect its own 'readonly' parameter, or my IMAP server (Courier) doesn't respect it properly. I'm going to fiddle a little more, but I'm not sure what you think about this? Maybe test it with a different IMAP server, if you've got time? Otherwise, I don't know if you think that this is critical enough to pull the ebuild. It is irritating, but the ebuild does what it claims to do. (As a side note, the PyXMMS feller says he thinks my patches should actually rather be implemented as part of a much larger fix to PyXMMS, doing a complete interface to libxmms. I may help him on this, or not, but my CornerXMMS twiddle will have to wait.) Cheers, -Jonathan
