"Screenlets" v0.0.10 (like OSX Dashboard)

[RYX]

Hi everybody! Another release of the screenlets is out :D ...

Screenlets are small owner-drawn applications (written in Python, a very simple object-oriented programming-language) that can be described as "the virtual representation of things lying/standing around on your desk". Sticknotes, clocks, rulers, ... the possibilities are endless. The goal of the Screenlets base-class(es) is to simplify the creation of fully themeable mini-apps that each solve basic desktop-work-related needs and generally improve the usability and eye-candy of the modern Linux-desktop. Screenlets can be used together with compiz' widget-plugin to create a Dashboard-like feature as seen on OSX tiger.

Screenshot:
http://www.ryxperience.com/storage/screenlets-0.0.8_thumb.jpg (http://www.ryxperience.com/storage/screenlets-0.0.8.jpg)

Download here: screenlets-0.0.10.tar.bz2 (http://www.ryxperience.com/storage/screenlets-0.0.10.tar.bz2)

NOTE: Check the new graphical screenlets-manager under System/Settings/Screenlets!

CHANGES in v0.0.10:
- brand new screenlets icon (still a bit ugly in bigger sizes)
- new screenlets-manager
- some new option types
- CopyStackScreenlet
- several fixes and optimizations
- more info in changelog ...

CHANGES in v0.0.9:
- new tabbed layout in Properties-dialog (e.g. new Themes-tab)
- improved MailCheck (now uses keyring to store passwords, NOTE: passwords are only stored for the current session yet)
- improved Launcher (now supports drag&drop of menu-entries from Applications-menu)
- improved CPUMeter (including new theme)
- improved Notes (far better, yet still buggy, keyhandling)
- new "protected"-options (not accessible through dbus)
- faster startup and resizing (hopefully)
- improved theme-system, most themes can now be created from _either_ PNG _or_ SVG images (except the Clock), I hope to see some more themes now ;)
- many more details in changelog ...

CHANGES in v0.0.8:
- new session-system: screenlets are now intended to be launched separately and support multiple sessions (the screenlets-daemmon is still supported to ensure backwards compatibility with third-party screenlets, but shouldn't be used anymore and will get removed sooner or later)
- screenlets not run within one process anymore, each screenlet-type has its own process and automatically handles multiple instances within that process
- all screenlets now have own dbus-services and can easily interact with other applications and/or offer custom services (like org.screenlets.Clock or org.screenlets.Notes), this offers very amazing possibilites for the developer
- new PicframeScreenlet, FlowerScreenlet and StorageScreenlet (some of them still quite unfinished)
- added drag&drop support to baseclass and some of the screenlets (Picframe can receive images through drag&drop, Notes can receive text, ...)
- separated code into several modules
- various bugfixes and optimizations
- ... see changelog in package for a full list of changes (there are quite a few ;) ...)

INSTALLATION:
See file README in package ...

NOTES:
I strongly recommend that developers read the CHANGELOG to get a detailed list of what is new and what changed. If there are any questions, please post them in the new Screenlets/Widgets-forum (http://forum.compiz.org/viewforum.php?f=19).

INFO:
The Screenlets are all inherited from the Screenlet-class, which contains a gtk.Window, a gtk.Menu and some data. Screenlets are owner-drawn and undecorated and entirely invisible by default by using an rgba-colormap and erasing the window-background during the expose-event. Subclasses of the Screenlet have to implement a "draw" and a "draw_shape" method to draw/shape their own visual output. The present Screenlets all use SVG- or PNG-files, rendered through librsvg. The Screenlet supports a very simple theming-mechanism that allows easy use of files within the current theme and fully automated theme-switching/-loading. This way the developer can focus on the functionality while the user can theme the Screenlet to his/her likings and supply the developer with new designs right from the start. The framework automatically handles saving/restoring options and managing of multiple instances.

FEATURES (only a rough list of some features):
- Screenlet-baseclass (needs a lot of improvement)
- automated theming-abilities (SVG)
- fully scalable - unlimited resizing
- controllable through customizable DBus-service
- embedded drag&drop-support
- ClockScreenlet (cairo-clock-compatible)
- NotesScreenlet (with suport for Pango-Markup-Language (http://www.pygtk.org/docs/pygtk/pango-markup-language.html))
- ControlScreenlet (to control other screenlets)
- basic WindowlistScreenlet
- CPUMeterScreenlet
- very basic RulerScreenlet (serves as example)
- new LauncherScreenlet (quite similar to a desktop-icon)
- MailCheckScreenlet
- (PagerScreenlet)
- FlowerScreenlet
- PicframeScreenlet
- StorageScreenlet

TODO:
See file TODO in package for open tasks (file TODO-0.1.0 contains a brief overview of upcoming features and long-term plans).

HISTORY:
It all started with a python-version of MacSlow's cairo-clock which now has evolved to a "Screenlet"-engine that is aimed at simplifying the creation of small, widget-like applications that can serve as Screen-Applets ("Screenlets").

FUTURE:
I still believe that, if we can work out a shared codebase, Shelf/nzjrs(desklet-engine), Stuart Langridge(Jackfield Project) and me will (hopefully) merge/combine our projects and create the most ass-kicking Desklet/Screenlet-framework ever seen. I especially hope for a JackfieldScreenlet which builds the missing part between the common HTML/JS-based widgets and the Screenlets' python-oriented approach.

If you find bugs or have corrections/suggestions, please post them in the new "Screenlets/Widgets"-forum (http://forum.compiz.org/viewforum.php?f=19) ... thanks for testing and enjoy the Screenlets!

Thanks to everyone (Sorcerer, robgig1088, RAOF and all others) for their contributions and help!!! A selection of "third-party" Screenlets will be officially included in the 0.1.0-release once the core and basics are in a "non-draft" state ...

:)

[mikedee]

It looks very cool :)

Python is very nice once you get over the initial hurdles. Awful documentation though :(

I think it should be easy to convert the widget plugin to run these apps as widgets. You could possibly manually set the X hint yourself or you could get the widget plugin to launch the app itself and when it receives a create request it can set the windows widget hint (it can compare the PID against the newly created window to check it is 'one of ours').

It should be easy to also get the widget plugin to launch when the cube settles on top, actually painting it on the top of the cube is hard, but it can show when the cube settles on top. The widget plugin could have a key combination which rotates the cube to the top and then displays once it settles.

Modifying cube could also be possible to show the widgets on the top of it, but I'd like to avoid this for the short term.

Code is always nice :)

[nightfrost]

wow, this looks nice. I need to be on this thread to see how it progresses. Keep up the good work! :D

[iznogood]

i really like it, keep it up :lol:

[delphinen]

This looks very interesting, reminds me of SuperKaramba :P

[MacSlow]

Gee at last! RYX, you have no idea how long I waited for someone to pick up cairo-clock or cairo-dock to base a more generic "widget/desklet/thing"-engine on. I always thought the people driving gDesklets would jump right at the new compositing stuff offered on modern X11. Nice to see you were able to beat them to it.

Your stuff looks very promising already! I wonder if it could be used or merged with the Jackfield-project (http://kryogenix.org/code/jackfield) from Stuart Langridge.

But despite your efforts here I will stick to my own boilerplate-code for the new cairo-clock, as I'll do more with animations and OpenGL :)

Oh btw, if you want more robust text-rendering take a look at glitz-test over here (http://people.freedesktop.org/~macslow). I made it use pango/cairo for the font-rendering, thus allowing to render text in any kind of language. I bet people from e.g. asia would love that sticky-note thing of yours working with their native letters.

Best regards...

MacSlow

[RYX]

Thanks for all your replies! :D

The Screenlets are now quite stable and the state gets saved on quit and loaded on start (when launched through the ControlScreenlet). There are a few small things to do, but I think I'll release an initial sneak-preview-version this weekend ...

mikdee: Setting X-hints which get recognized by the widget-plugin would be close to what I thought of - that way the widget-plugin could take care for fade-in/-out effect of widgets via a certain key-binding. Do you know if it is already possible?

MacSlow: I had this in mind since when I first saw cairo-clock and the "real" shaped-windows (with alphamask). The Jackfield-project is new to me, so thank you for the link - I had a short look at their sourcecode and it looks like they use another way of shaping their windows. Maybe I can create some wrapper/host for Jackfield-widgets (or Jackfield's widgets become children of my Screenlet-class). I think it's easier to write "Widgets" in Python than in HTML/JavaScript (and requires less code) but a wrapper for Apple/Yahoo/*-"Widgets" would be a great thing to have.
(btw: The text on the sticky-notes is rendered through cairo.show_text, doesn't that use pango, too? )

:)

[mikedee]

mikdee: Setting X-hints which get recognized by the widget-plugin would be close to what I thought of - that way the widget-plugin could take care for fade-in/-out effect of widgets via a certain key-binding. Do you know if it is already possible?

As far as I can tell, you will just need to set the _COMPIZ_WIDGET hint to true for your window(s), it looks like the widget plugin would handle everything else. There are a few bugs I have just seen but they would only affect performance a bit.

It appears that as soon as the widget plugin is notified that your window has the hint set, it will map it and then unmap it. You might get a flash when you start the application, only a real world test will know for sure ;) It is certainly built to handle the fading and keybinding (in fact that is its only purpose).

The Jackfield-project is new to me, so thank you for the link - I had a short look at their sourcecode and it looks like they use another way of shaping their windows. Maybe I can create some wrapper/host for Jackfield-widgets (or Jackfield's widgets become children of my Screenlet-class). I think it's easier to write "Widgets" in Python than in HTML/JavaScript (and requires less code) but a wrapper for Apple/Yahoo/*-"Widgets" would be a great thing to have.

I had a quick look at Jackfield the other day and it is a python wrapper over a gtkmozembed widget. It then has the Apple widget javascript objects. I didnt look too deeply but I think it should be possible to remove his wrapper and replace it with yours. I think his wrapper code deals with the fading and flipping of windows. It didnt work with my version of gtkmozembed, I think you need a very recent version which normally means compiling your own (and we all know what compiling mozilla is like)

If the screenlets can listen for the signals of windows moving and being grabbed then they can respond to them. ie the notes could move out of the way of windows or bend if a window is placed near them.

Looking forward to the preview release :)

[MacSlow]

The Jackfield-project is new to me, so thank you for the link - I had a short look at their sourcecode and it looks like they use another way of shaping their windows. Maybe I can create some wrapper/host for Jackfield-widgets (or Jackfield's widgets become children of my Screenlet-class). I think it's easier to write "Widgets" in Python than in HTML/JavaScript (and requires less code) but a wrapper for Apple/Yahoo/*-"Widgets" would be a great thing to have.

I pointed Stuart Langridge, Jackfield's maintainer and original author, to this thread here. Maybe he'll pay us a visit.

(btw: The text on the sticky-notes is rendered through cairo.show_text, doesn't that use pango, too? )

No, cairo_show_text() is part of cairo's "toy"-API for text. The real deal is pango/cairo. In glitz-test for example I made use of pango's markup-language feature to get the subscript going for the fps- and frame-time display.

Best regards...

MacSlow

[sil]

MacSlow: I had this in mind since when I first saw cairo-clock and the "real" shaped-windows (with alphamask). The Jackfield-project is new to me, so thank you for the link - I had a short look at their sourcecode and it looks like they use another way of shaping their windows. Maybe I can create some wrapper/host for Jackfield-widgets (or Jackfield's widgets become children of my Screenlet-class). I think it's easier to write "Widgets" in Python than in HTML/JavaScript (and requires less code) but a wrapper for Apple/Yahoo/*-"Widgets" would be a great thing to have.
Jackfield (speaking as the author here :)) uses Gtk's alpha-masking stuff to make shaped windows. I've had quite a few people say that they'd really like to see Jackfield taking advantage of Compiz or Beryl -- I myself haven't looked at it because I don't have accelerated 3d (stupid ATI cards). Jackfield doesn't do anything all that complicated with Gtk itself; most of the complexity is in JavaScript in the gtkmozembed widget inside each window, so having compiz handle the Gtk bits of Jackfield would just carry on working fine, I think.

sil

[RYX]

It's great to see these things evloving ... :)

Jackfield (speaking as the author here Smile) uses Gtk's alpha-masking stuff to make shaped windows. I've had quite a few people say that they'd really like to see Jackfield taking advantage of Compiz or Beryl -- I myself haven't looked at it because I don't have accelerated 3d (stupid ATI cards). Jackfield doesn't do anything all that complicated with Gtk itself; most of the complexity is in JavaScript in the gtkmozembed widget inside each window, so having compiz handle the Gtk bits of Jackfield would just carry on working fine, I think.
Welcome to the forums, sil! I am very happy to see that you joined this discussion. I think the big (and maybe only) difference between our approaches is that you use 8-bit (or 2-bit?) alphamasks, while I use 32-bit ones (which is only possible under a composited environment). The way our windows are created/handled is very similar. Maybe we can work out a unified class-base to build our projects on? I also had some PM with nzjrs who works on a very similar project (http://forum.go-compiz.org/viewtopic.php?t=210) together with Shelf (actually Shelf started it) and he agreed to combine and/or work together with me/us. We all have slightly different ideas but, I think, could all profit from a shared codebase and class-layout - in the end its all about shaped gtk-windows, right?

The real deal is pango/cairo. In glitz-test for example I made use of pango's markup-language feature to get the subscript going for the fps- and frame-time display.
OK, now I understand :D - my sticky notes now use a pango-layout and the pango markup-language. Also solves the problem of how to wrap text within a certain rectangle. Thanks a lot for the info (yes - if you'd always got a Euro when I said that ...).


I have to do some fixes to the clock, but will release my code today's evening ... (girlfriends are life's overhead - only consuming your money and time without producing much fun at all ... mostly ;))

:)

[sil]

It's great to see these things evloving ... :)

Jackfield (speaking as the author here Smile) uses Gtk's alpha-masking stuff to make shaped windows. I've had quite a few people say that they'd really like to see Jackfield taking advantage of Compiz or Beryl -- I myself haven't looked at it because I don't have accelerated 3d (stupid ATI cards). Jackfield doesn't do anything all that complicated with Gtk itself; most of the complexity is in JavaScript in the gtkmozembed widget inside each window, so having compiz handle the Gtk bits of Jackfield would just carry on working fine, I think.
Welcome to the forums, sil! I am very happy to see that you joined this discussion. I think the big (and maybe only) difference between our approaches is that you use 8-bit (or 2-bit?) alphamasks, while I use 32-bit ones (which is only possible under a composited environment).
Er. 8-bit, I think. Dashboard widgets supply a PNG with transparent background, and I use gtk.gdk.Pixbuf.render_pixmap_and_mask to get the mask.
The way our windows are created/handled is very similar. Maybe we can work out a unified class-base to build our projects on? I also had some PM with nzjrs who works on a very similar project (http://forum.go-compiz.org/viewtopic.php?t=210) together with Shelf (actually Shelf started it) and he agreed to combine and/or work together with me/us. We all have slightly different ideas but, I think, could all profit from a shared codebase and class-layout - in the end its all about shaped gtk-windows, right?
Absolutely. The problem with using the masking as I do it at the moment is that it's a hack; I don't *really* want to use a shaped window for it, because if the "window" (i.e., the displayed bit) changes shape afterwards, I don't know that it has and so the mask doesn't change. This is obviously a problem. What I'd really like to do is make the actual Gtk window a size that's definitely big enough to display everything, and then make the background of the gtkmozembed actually be transparent (not the hacky pseudo-transparency that people used to do with eterm and so on). I don't know if you can do this with compiz, but I do know that you can't do it *without* compiz.

[MacSlow]

Greetinsg RYX, sil!

The real deal is pango/cairo. In glitz-test for example I made use of pango's markup-language feature to get the subscript going for the fps- and frame-time display.
OK, now I understand :D - my sticky notes now use a pango-layout and the pango markup-language. Also solves the problem of how to wrap text within a certain rectangle. Thanks a lot for the info (yes - if you'd always got a Euro when I said that ...).

Always glad to be of help, and I won't stop here... see further below :)

Absolutely. The problem with using the masking as I do it at the moment is that it's a hack; I don't *really* want to use a shaped window for it, because if the "window" (i.e., the displayed bit) changes shape afterwards, I don't know that it has and so the mask doesn't change. This is obviously a problem. What I'd really like to do is make the actual Gtk window a size that's definitely big enough to display everything, and then make the background of the gtkmozembed actually be transparent (not the hacky pseudo-transparency that people used to do with eterm and so on). I don't know if you can do this with compiz, but I do know that you can't do it *without* compiz.

About a year ago I wrote a test for cairo-clock that is likely to solve your problem. It offers shaped windows, which adjust their shape to the size and rendered contents. Have a look here...

http://macslow.thepimp.net/?p=26

... the code is available here...

http://macslow.thepimp.net/projects/input_shape_test.c

The requirements are that your graphics need to be drawn with cairo (thus you can use the same render() function for your expose-events and the generation of the new input-mask in the configure-event handler). And you should be using a compositing manager (so the edges look smooth and not jagged). I believe my C-code easily translates to python. It's pretty straight forward.

Best regards...

MacSlow

[RYX]

Hello everyone! I have updated the first post and added the 0.0.1-release of the "Screenlets".

What I'd really like to do is make the actual Gtk window a size that's definitely big enough to display everything, and then make the background of the gtkmozembed actually be transparent (not the hacky pseudo-transparency that people used to do with eterm and so on). I don't know if you can do this with compiz, but I do know that you can't do it *without* compiz.
I don't really know if you can make a (non-owner-drawn) gtk-widget transparent by default (I wasn't able to do it yet except within a sluggishly "hacked" gtk-engine). The main requirement for it is to assign it an rgba-colormap, then you can simply fill its bg with a color that has alpha set to 0. If you compile the mozilla-widget yourself, you should be able to erase its background before it renders its contents (though I don't know for sure). Maybe we can create a base-class with support for both - if running in a composited environment it should use the rgba-method, otherwise it should use the "old" way. That way people with no compositing can still have shaped windows (instead of seeing a black area where it should be transparent) ...

Maybe you (nzjrs/Shelf and sil) can have a look at my code, while I'll have another look at yours - then we can discuss our impressions and our basic goals and see how we can build upon one base while still working in our own "directions" ...

:)

[mikedee]

I have been having a look on the web and unfortunately the python rsvg bindings seem to be part of the gnome-python-desktop package. This isnt good for us poor KDE folks :(

I would have thought pygtk would be a better place but on this bug report it was assigned to gnome-python-desktop

http://bugzilla.gnome.org/show_bug.cgi?id=329978#c8

librsvg is part of hte GNOME desktop => assigning to gnome-python-desktop

Double :(

Otherwise it looks great and Im looking forward to trying it once everything has emerged ;)

[baze]

all those gnome deps aren't that great for xfce users either :/

[RYX]

Hmmm - that's not nice ... Shouldn't there be "general" bindings for such a library? I thought it is the replacement for cairo's svg-features. Isn't there some tool that automatically creates python-bindings from C-libraries (something starting with an S and 4 or 5 letters - I can't remember the name ...)?

I am using gtk-windows anyway, but depending on gnome-desktop isn't really cool ...

:?

[mikedee]

I think it might be possible to distribute just the rsvg bindings in your application directory.

[RYX]

There is "librsvg-ruby" in the Ubuntu repos, but the python-bindings belong to gnome? I still find that's quite strange. I think that should be changed for logical reasons and interoperability ... I generally hate gnome-dependancies, especially if I don't even use a single gnome-feature.

More strange is this:
locate rsvg
...
/usr/share/pycentral/python-gnome2-desktop/site-packages/gtk-2.0/rsvg.la
/usr/lib/python2.4/site-packages/gtk-2.0/rsvg.so
/usr/lib/python2.4/site-packages/gtk-2.0/rsvg.la
/usr/lib/python2.5/site-packages/gtk-2.0/rsvg.so
/usr/lib/python2.5/site-packages/gtk-2.0/rsvg.la
...


Doesn't that mean the bindings are installed twice?

And yes, I could include the bindings until those issues are solved - do I have to choose a special license in that case? I didn't think about licensing yet ... it's just free and open-source, obviously.

:)

[mikedee]

And yes, I could include the bindings until those issues are solved - do I have to choose a special license in that case? I didn't think about licensing yet ... it's just free and open-source, obviously.

I just looked at the source files and there is no license on them, I would assume they are LGPL so you can choose any license you like, you shouldnt have any distribution worries, maybe just mention it in your README.

[RYX]

What do I have to include? Only the rsvg.la and rsvg.so? Does anyone know a good tutorial about creating python-bindings? I have no clue where python saves/searches the installed extensions and which files I have to include into my release ...

[RYX]

Isn't there some tool that automatically creates python-bindings from C-libraries (something starting with an S and 4 or 5 letters - I can't remember the name ...)?
OK, I remembered the name - it was SWIG (the Simplified Wrapper and Interface Generator). Maybe it isn't too difficult to create "pure" python-bindings for librsvg ...

[mikedee]

Isn't there some tool that automatically creates python-bindings from C-libraries (something starting with an S and 4 or 5 letters - I can't remember the name ...)?

You might be able to use this instead

http://docs.python.org/dev/lib/module-ctypes.html

[MacSlow]

Download here: screenlets-0.0.1.tar.gz (http://www.ryxperience.com/storage/screenlets-0.0.1.tar.gz)

Argl... RYX, please make a top-level directory for this next time. I just spilled the tarballs contents all over my desktop :)

The dependency of librsvg should only be cairo and libxml2 afaik (at least for C). It's probably a packaging error, if the python-bindings depends on gnome-stuff.

BTW, working nicely here. Good work sofar! Inplace text-editing for the notes would rock, but I'll be patient :)

Best regards...

MacSlow

[RYX]

Argl... RYX, please make a top-level directory for this next time. I just spilled the tarballs contents all over my desktop :)
I simply zipped with right-click in nautilus - sorry. You think it's better to create an absolute install-path like /usr/share/screenlets and then extract as root? I didn't do much releases yet so I am a little unfamiliar with packaging ... :)

BTW, working nicely here. Good work sofar! Inplace text-editing for the notes would rock, but I'll be patient :)
Thanks - glad to hear that it works! The inplace-editing is on my list, I first wanted to have some more or less stable base before adding more stuff. I also thought of a feature to glue notes to another (by making them one window), but maybe that could be done by compiz'/beryl's group-plugin ...

:)

[MacSlow]

Argl... RYX, please make a top-level directory for this next time. I just spilled the tarballs contents all over my desktop :)
I simply zipped with right-click in nautilus - sorry. You think it's better to create an absolute install-path like /usr/share/screenlets and then extract as root? I didn't do much releases yet so I am a little unfamiliar with packaging ... :)

No worries, I wasn't expecting an easy to digest ready-to-go package. A simple tarball is just fine for such a young project. Just do something like this for your next tarball...

tar jcvf screenlets-0.0.1.tar.bz2 screenlets-0.0.1

Best regards...

MacSlow

[RYX]

Hi everybody!

I have just released the 0.0.2-version of the Screenlets. See the first post for the package, a new screenshot and more info on the changes. Still at a very early state and still missing useful settings/options-editor (will come soon).

I am kinda proud of the WindowlistScreenlet. It uses child widgets and I (tried to) follow the gtk-style (so using child widgets instead of fully owner-draw everything). It will eventually replace the gnome-panel on my desktop ... on yours, too?

@all-KDE-users: Sorry, I still have no clue of how I can package the libs for wnck/rsvg into the archive. If someone can tell me which files are needed and how to install them, I will put them into the package.

@MacSlow: Sorry, no in-place editing yet, but please let me know if the package is ok now ... :D

:)

[amgeex]

Hey, I think I'll make a page on the wiki for this, and update it as new versions come out! What do you think RYX? :D

[RYX]

It doesn't really belong to compiz, but it is somehow related ... so why not? If nobody has a problem with that. Thank you!

:)

[amgeex]

Alright! I'll put it under Tips & Tricks, and I guess it doesn't belong to Compiz itself, but its nice! :D

UPDATE: Done! Check it at: http://www.go-compiz.org/index.php?title=Desktop_Screenlets

[RYX]

Man, that looks cool ... :D

Thank you very much!

(its 5:30AM here - gotta go to bed now ... good night everyone ... c u tomorrow)

:)

[wfarr]

These work great!

Any estimated timeframe until they work natively with Widget plugin? :D

[Sorcerer]

Thanks to Sorcerer for his contributions, his Screenlets will be included in the next release (if he wants)
Thanks, that would be great! :)
Meanwhile, the screenlets can be found here:
http://hendrik.kaju.pri.ee/#RssScreenlet
and here:
http://hendrik.kaju.pri.ee/#SearchScreenlet

[RYX]

These work great! Any estimated timeframe until they work natively with Widget plugin? :D
Cool - glad to hear that. I don't know much about the widget-plugin's state (is it in the extras-package?) ... As far as I know, it always worked but there were no Widgets to use with it. If someone has a working version of the plugin. maybe he can post a link - then I can make Widgets/Screenlets play together ...

@Sorcerer: Thank you. It would be great if your RSS-Screenlet could use a timeout and check for news after a certain interval of about 1-15 minutes (you can look into the CPUMeter for an easy example on how to do that ...). And we have to think about some dependancy-check (the Screenlet should check if certain libs are available instead of simply crashing when it can't find e.g. python-feedparser) ... however - that should go into the base, not only into your screenlet.

I still wait for any news from nzjrs/Shelf and sil about merging/combining our three projects and/or build a shared codebase to allow standardized configuration-/managing-tools for Screenlets/Desklets/Widgets. So I hope I didn't scare you all away with my early release ... it is only for demonstration and to allow you looking into what I have so far. I still hope we can work out some unified settings/core concepts for our projects.

:)

[mikedee]

These work great! Any estimated timeframe until they work natively with Widget plugin? :D
Cool - glad to hear that. I don't know much about the widget-plugin's state (is it in the extras-package?) ... As far as I know, it always worked but there were no Widgets to use with it. If someone has a working version of the plugin. maybe he can post a link - then I can make Widgets/Screenlets play together ...

As far as I know it works too, there are a few minor bugs but nothing too bad. The only problem before that I could see was that there were no widgets and those that did exist (ie cairo clock) had to be helped with the state plugin, this is where most of the problems were.

If you can you should set the _COMPIZ_WIDGET window attribute to true, if you cannot then it should be easy enough to patch the widget plugin to launch your widgets and set the attribute for you.

Here is the most upto date version, if it doesn't work, let me know it will be something simple :)

http://www.anykeysoftware.co.uk/compiz/plugins/widget.tar.gz

[stjepan]

Also set window type of widgets to 'utility', not 'normal'.

[RYX]

Thanks for the info, mikedee and stjepan. I got the plugin to work and was able to set the _COMPIZ_WIDGET-property (surprisingly the gtkgdk.Window.property_change-method also sets the value). It works with a single Sticknote (fading in/out widgets with transition) but launching the whole set using the ControlScreenlet brought it to its knees (compiz segfaults). I think there's some conflicting window-property somewhere ... I'll check that.

But it basically works ... and that's great! Somebody interested in improving the widget plugin? :D

:)

[Sorcerer]

@Sorcerer: Thank you. It would be great if your RSS-Screenlet could use a timeout and check for news after a certain interval of about 1-15 minutes (you can look into the CPUMeter for an easy example on how to do that ...). And we have to think about some dependancy-check (the Screenlet should check if certain libs are available instead of simply crashing when it can't find e.g. python-feedparser) ... however - that should go into the base, not only into your screenlet.


OK, I will look into that. :)

[mikedee]

But it basically works ... and that's great! Somebody interested in improving the widget plugin? :D

Can you post your new version which sets the hint, I think I have a rough idea what causes the slowness, Ill try to see if there are any other crashes I can track down.

What improvements would you like? Other than putting them on the cube top ;)

[RYX]

Can you post your new version which sets the hint, I think I have a rough idea what causes the slowness, Ill try to see if there are any other crashes I can track down.
I don't really want to add it to the release unless it's stable. To make the Screenlet behave as a widget, add this function to the Screenlet-class in screenlets.py:
def realize_event(self, widget):
widget.window.set_type_hint(gtk.gdk.WINDOW_TYPE_HI NT_UTILITY)
widget.window.property_change("_COMPIZ_WIDGET",
gtk.gdk.SELECTION_TYPE_WINDOW,
32, gtk.gdk.PROP_MODE_REPLACE, (True,))


And add this line to Screenlet.__init__ (somewhere around the other connect-calls):self.window.connect("realize", self.realize_event)


What improvements would you like? Other than putting them on the cube top?
I have only a first impression about this, you should give it a try and see for yourself. I think there can be done some improvement in the usability of the widgets. Maybe some more options (some things are already avilable I think):
- (optionally) hide all other windows while the widgets are shown
- (optionally) saturate/desaturate screen when showing/hiding widgets (or darken/lighten/set_alpha)
- ability to use widgets and windows at the same time without any difference, pressing the hide/show button should then simply hide/show the widgets that are currently open
- don't "auto-remove" widgets after focus-changes
- always keep widgets above everything else

Thanks for your help :D

:)

[mikedee]

I made the changes you suggested and got it running with the widget plugin. I have fixed a crash (maybe not all of them ;)) and removed some excessive code. I have it running almost perfectly now :)

http://www.anykeysoftware.co.uk/compiz/plugins/widget.tar.gz

- (optionally) hide all other windows while the widgets are shown

I think this may confuse users or be a bit jarring

- (optionally) saturate/desaturate screen when showing/hiding widgets (or darken/lighten/set_alpha)

Seems sensible and probably fairly easy.

- ability to use widgets and windows at the same time without any difference, pressing the hide/show button should then simply hide/show the widgets that are currently open

Some of your widgets are not applicable for the widget layer, they seem more like screenlets rather than widgets if you understand what I mean :) Maybe you should give some thought on splitting them up?

- don't "auto-remove" widgets after focus-changes

I think this is a feature, if you mean when you click on anything but a widget it goes out of widget mode.

- always keep widgets above everything else

You can do this just by setting the on top hint (which I think you already do) :?

ATM the widget plugin puts all widgets on a different layer, your way of thinking seems to be just to have the widgets appear and disappear ? Maybe this can be incorporated into the plugin, I think it was how it originally worked anyway. The blocking layer and the separation were IIRC user requests.

[RYX]

Ok, what I really expect the widget-plugin to do is the opposite of what it does now. I want to press a key and then all widgets disappear, hit the key again and all widgets are back (and not only see widgets after I initially pressed a key). But the widgets should be fully usable and restackable while they are not hidden. It's best to try it out to understand what I mean ... it's kinda hard to describe.

But maybe that's only my personal taste, so more options can't be bad.

Edit: Didn't see your previous post ... :)

:)

[RYX]

I tried it and it works far better - great work. Blending in the widgets looks still ugly but I think that's a gtk-issue (or maybe comes from my bad knowledge of cairo). Maybe on fade out, the pixmap can be saved and then used for the blend-in effect? Just a thought ...

Some of your widgets are not applicable for the widget layer, they seem more like screenlets rather than widgets if you understand what I mean :) Maybe you should give some thought on splitting them up?
I think I understand what you mean - e.g. the Windowlist shouldn't be treated as widget because it's quite essential while the Sticknotes are better hidden as widgets and only used from time to time ... that makes sense.

ATM the widget plugin puts all widgets on a different layer, your way of thinking seems to be just to have the widgets appear and disappear ?
Yes, but I think make the widget-attribute optional is the better way.

Again, big thanks for your help.

:)

[mikedee]

First bug report :)

The text for the notes accepts html, which is cool, problem is that it chokes on unescaped &'s and <'s

[RYX]

Yes, that should be easy to fix. Thanks! Actually it's no html but pango-markup-language which is a very small set of html-like tags and attributes and only meant for font-rendering (yet).

I also made some progress with the widget-thing. Screenlets now have a Window-submenu in their right-click menu where you can set Sticky/Widget/KeepAbove/KeepBelow-attributes. That way everyone can set the attributes to his likings ... (will come with 0.0.3 release, needs some more testing).

:)

[QuinnStorm]

Looks like its time I resume development on the widget plugin. Screenlets looks really cool. I'm gonna look into trying it out myself.

[flargen]

This is coming along very nicely! Some things that I think would be cool are:- a standardised config/attribs system, widgets on top of the cube (how is this going mikedee?), and a window list screenlet that works as a taskbar, maybe with previews? - shouldn't this be possible soon with the proposed plugin that exposes window textures to apps?

Congratulations!

[RYX]

Some things that I think would be cool are:- a standardised config/attribs system, widgets on top of the cube (how is this going mikedee?), and a window list screenlet that works as a taskbar, maybe with previews? -
The settings-system is the number one on my TODO-list. Widgets on top of the cube should be possible, only a question of time. And did you notice the WindowlistScreenlet in v0.0.2 - it is exactly what you mean (I think) ... :)

Looks like its time I resume development on the widget plugin. Screenlets looks really cool. I'm gonna look into trying it out myself.
The widget-plugin that mikedee has posted and modified works quite well. There are problems when opening more than one widget, after reloading compiz all widgets are displayed fine. Would be great to see you and mikedee working together on this plugin :) ...
And you're welcome to create some new Screenlets and give suggestions to improve the class-base - of course.

I am currently trying to create a xml-driven menu with an underlying action-system that allows fully xml-based menus for all Screenlets. The goal is to provide full (and I really mean full) customization for the Screenlets - menu and theme should be customizable without touching the python-files.
That way the Control-button could become the ultimate "one-button-for-everything"-navigation and replace the system-menu in the panel.

:)

[QuinnStorm]

Screenlets sounds like a project that needs to be in a code repository somewhere, either with compiz-extras, on sourceforge, or somewhere. I'd love to contribute, especially as I am fairly fluent in python.

As for the widget plugin, I had planned to start a new widget plugin from scratch, one that (hopefully) more properly handled things like stacking order and window(widget) placement. If anyone has any requests for this, or advice, please let me know. I'd be glad to help make it work on both compiz and beryl (and it would as all my code be GPL).

[RYX]

Screenlets sounds like a project that needs to be in a code repository somewhere, either with compiz-extras, on sourceforge, or somewhere. I'd love to contribute, especially as I am fairly fluent in python.

I was (and still am) waiting for a reply from nzjrs who had a similar idea to host the project on google-code. If we merge the two desklet/screenlet engines, they'll get a repository there - if we don't merge, it gets one as well (but will take some more time). So you're happily invited to contribute (and maybe review my code a little bit as I am not _that_ fluent in python).

As for the widget plugin, I had planned to start a new widget plugin from scratch, one that (hopefully) more properly handled things like stacking order and window(widget) placement. If anyone has any requests for this, or advice, please let me know.
That's great news. I already wondered about the "unusual" stacking of the widgets and some misplacing (so it's not related to my code :) ...). After playing with the existing plugin for some hours, I got used to the way the plugin works. If the stacking/placement would work, it'd be fine (from my pov). There are some crashes but they shouldn't be too hard to fix (when adding widgets and switching windows from/to widget-state).

:)

[imnotpc]

When I was working on the git repository, David indicated that he was interested in using git.compiz.org for other compiz related projects that were not plugins per se. If you're interested in a repo for this you should ask David and I'm sure he'll help you set it up.

[mikedee]

I would recommend git too, it has lots of features above svn which make it very nice for distributed development. People will be able to work independently on projects and merging the changes is trivial. Plus things are closer to compiz which makes it easy for packagers and hopefully things like screenlets could go in compiz-extra.

[mikedee]

That's great news. I already wondered about the "unusual" stacking of the widgets and some misplacing (so it's not related to my code :) ...). After playing with the existing plugin for some hours, I got used to the way the plugin works. If the stacking/placement would work, it'd be fine (from my pov). There are some crashes but they shouldn't be too hard to fix (when adding widgets and switching windows from/to widget-state).

What do you mean by the unusual stacking order?

Do you mean the widgets in relation to each other? I hadn't noticed anything strange there but maybe I wasn't looking hard enough ;) They all seem to stay placed where I left them too...

I occasionally lose widgets, I am not sure if they are crashing or if the widget plugin is just losing them. Also the widget layer disables if you remove a screenlet. I will need to make another quick change so that the menus of the widgets are not faded out.

I had a quick look at the brightness code and it seems deeply hard coded to fade in the widgets and darken the others, I should be able to make it an option so that you can choose which effect and the parameters for it.

Hopefully all the plugins will be in git soon so anyone can checkout the latest copy and send a patch

[QuinnStorm]

Not intending to start any sort of controversy here, but I'm sure we could gladly offer space for a project like this at svn.beryl-project.org too, should that better met your needs.

I hope to start looking into a widget plugin in the next day or so here, once the push for 0.1.5 dies down and I have a little bit of time.

[RYX]

What do you mean by the unusual stacking order?
Try adding a few Sticknotes, then hide all widgets and bring them back by pressing F9 a few times - you'll notice that the stacking order doesn't remain the same.

Do you mean the widgets in relation to each other? I hadn't noticed anything strange there but maybe I wasn't looking hard enough ;) They all seem to stay placed where I left them too...
Some widgets are losing their original position and are displayed at 0,0. I wasn't able to track down the real source of that problem yet ... (but it only occurs to windows with the widget-attribute)

I occasionally lose widgets, I am not sure if they are crashing or if the widget plugin is just losing them.
The config-file ($HOME/.screenlets.conf) can sometimes contain negative values for positions (e.g. when you quit the Control on a viewport > 1) - then widgets can disappear or act strange ... will be fixed in next version.

Also the widget layer disables if you remove a screenlet. I will need to make another quick change so that the menus of the widgets are not faded out.
I meanwhile like the fade-out behavior, but it would be good to have widget's child-windows (like menus) appear in front (I guess that's what you mean).

I had a quick look at the brightness code and it seems deeply hard coded to fade in the widgets and darken the others, I should be able to make it an option so that you can choose which effect and the parameters for it.
That would be great :)

Hopefully all the plugins will be in git soon so anyone can checkout the latest copy and send a patch
Yes, the widget plugin (once stable) should definetly go into official git (no, not because of the Screenlets, really ... :D).

:)

[RYX]

Not intending to start any sort of controversy here, but I'm sure we could gladly offer space for a project like this at svn.beryl-project.org too, should that better met your needs.
Thank you very much for the offer. I'd first like to hear nzjrs's opinion on that because we basically agreed to hosting a (possible) combined project on google-code (that was his proposal). I have no further experience in working on svn/cvs projects, so I don't care much where to host it ... :)

I hope to start looking into a widget plugin in the next day or so here, once the push for 0.1.5 dies down and I have a little bit of time.
Great. And no need to hurry, it will take a few days for the new Screenlets-release anyway ...

:)

[mikedee]

What do you mean by the unusual stacking order?
Try adding a few Sticknotes, then hide all widgets and bring them back by pressing F9 a few times - you'll notice that the stacking order doesn't remain the same.

Its OK, I notice now :) The widget plugin reorders the stacking of widget windows so I assume that could be fixed with time.

The config-file ($HOME/.screenlets.conf) can sometimes contain negative values for positions (e.g. when you quit the Control on a viewport > 1) - then widgets can disappear or act strange ... will be fixed in next version.

This sounds like the problem :)

We should probably sort out who's responsibility positioning of the widgets is. I think it should probably be the widget plugin, once there are other widget engines it may become messy. It looks like at the moment you are remembering positions between instances of your app. I think this should be the responsibility of the window manager.

Hopefully all the plugins will be in git soon so anyone can checkout the latest copy and send a patch
Yes, the widget plugin (once stable) should definetly go into official git (no, not because of the Screenlets, really ... :D).

The reason many of these plugins are not included in core is not because they are unstable, its because they do not have maintainers. One of the criteria for getting a plugin included in core is that it must be maintained. I cannot do that myself for all (or any really ;)) of the plugins so the extra package was born where the plugins are 'community maintained'. I also like the idea that we can add to compiz whilst still leaving the core plugins under Davids control where they can be kept relatively stable.

I would like to see screenlets distributed with extras and the widget now enabled by default. We can then continue to work on improving the screenlets. Hopefully once widget is enabled and distributed then we will get some more feedback on what we need to work on :)

[mikedee]

And did you notice the WindowlistScreenlet in v0.0.2 - it is exactly what you mean (I think) ... :)

I think you would be interested in this plugin idea from David, it would mean that you could get compiz to draw the thumbnails instead of getting python to do it (which would be hard).

http://lists.freedesktop.org/archives/compiz/2007-January/001231.html

I suggest that we add a plugin and a simple interface that allows any application to request that a set of client windows should be composited on top of a different client window.

I thought it may be of interest if you were not aware of it (not that it exists yet :))

[RAOF]

...It looks like at the moment you are remembering positions between instances of your app. I think this should be the responsibility of the window manager.
...

That's certainly not the opinion of the Metacity devs. I think there's a "window position" library for making applications remember their positions, but I can't remember what it's called.

Might be an idea to ask whether or not David thinks this is a responsibility of a window manager :).

[mikedee]

...It looks like at the moment you are remembering positions between instances of your app. I think this should be the responsibility of the window manager....

That's certainly not the opinion of the Metacity devs. I think there's a "window position" library for making applications remember their positions, but I can't remember what it's called.

I think I might be confusing it with something else :) I think you are right.

[mikedee]

I was thinking that there are possibly 4 different types of widget, they are:

* desklets - they are fixed to the desktop and can be input and output
* screenlets - they are stuck to the screen, like benchmark, output only
* widget layer - like the ones here :) They can be input and output but are apps which need to be quickly accessible without interrupting your current task too much (calculator and notes are good examples)
* cube top - these would probably be output only and include stats and meters, if using plane, these could be on the back of the desktop or could fade through or some other effect. This one would probably need to be done by the cube plugin itself rather than a widget plugin.

I think these could all be controlled by the app itself, in the same way as now but with some extra attributes.

I think that somehow the widget plugin should be responsible for the loading of each widget, that way any configuration can remain constant for the user. I think in the long run there are likely to be a few options for loading widgets and we should aim to make things as easy as possible.

What do you think?

[RYX]

I don't think we should force the user into our (or anyone else's) way of thinking (that's what I hate most in gnome). The highest goals of the Screenlets should be usability and customizability, so I'd like to keep everything as an option (widget/sticky/keepAbove/keepBelow...). The upcoming version allows to set all four attributes individually for each Screenlet - that way anyone can decide what to place where.

We could implement new window-properties like _WIDGET_STICK_SCREEN and _WIDGET_STICK_CUBE_TOP (only examples) and then let the widget plugin handle widgets with different attributes in a different way (draw to screen, draw to cube top). That approach would fit better with the standards, I think. We could then add two new attributes to the screenlet, e.g. stick_screen and stick_cube_top which could then be set through the right-click menu ... That way the user could stick/place whatever, wherever he likes.

I also don't really want the widget-plugin or the WM to load/save the positions. I think it should be up to the application itself to store window positions (that's what cairo-clock does, too).
Currently, the ControlScreenlet loads/saves all exported_settings (including x/y/width/height) for all Screenlets opened through the Control and it works good so far (not the 0.0.2 release :)).
It will make more sense once there are user-definable settings for each Screenlet which will be stored by the ControlScreenlet, too ...
Maybe it would be better to have a settings-daemon to take care of save/restore settings, but I can live with the Control for now (basically, it's much like a settings-daemon with a gui and a right-click menu).

(Or maybe I just need some sleep and time to overthink this?)

:)

[mikedee]

I don't think we should force the user into our (or anyone else's) way of thinking (that's what I hate most in gnome). The highest goals of the Screenlets should be usability and customizability, so I'd like to keep everything as an option (widget/sticky/keepAbove/keepBelow...). The upcoming version allows to set all four attributes individually for each Screenlet - that way anyone can decide what to place where.

We could implement new window-properties like _WIDGET_STICK_SCREEN and _WIDGET_STICK_CUBE_TOP (only examples) and then let the widget plugin handle widgets with different attributes in a different way (draw to screen, draw to cube top). That approach would fit better with the standards, I think. We could then add two new attributes to the screenlet, e.g. stick_screen and stick_cube_top which could then be set through the right-click menu ... That way the user could stick/place whatever, wherever he likes.

This is roughly what I was thinking, but some widgets will be limited because they require input (ie. calculator) so they shouldn't be on top of the screen (ie like benchmark). Rendering to the top of the cube would also probably not be recommended for widgets that require input.

I also don't really want the widget-plugin or the WM to load/save the positions. I think it should be up to the application itself to store window positions (that's what cairo-clock does, too).

I agree, but I think that the widget plugin may be useful to actually launch controlscreenlet which would take standardized parameters which other widget engines could use. I have a feeling it does this already.

I think now that my disappearing widgets problem is possibly related to the plugin side rather than the screenlet side. They were disappearing between widget show/hide not between screenlet processes.

Currently, the ControlScreenlet loads/saves all exported_settings (including x/y/width/height) for all Screenlets opened through the Control and it works good so far (not the 0.0.2 release :)).
It will make more sense once there are user-definable settings for each Screenlet which will be stored by the ControlScreenlet, too ...

I was thinking that the settings for each widget could be drawn in another window which would have _COMPIZ_WIDGET_SETTINGS and _COMPIZ_WIDGET_ID set, the main window could then render a settings button which sends a signal to the plugin to transition between the 2 windows.

[Sorcerer]

Hi! I have updated the RssScreenlet. It now shows an error message if it can't find the feedparser module. I also included feedparser.py in the tarball. Changes and download @ http://hendrik.kaju.pri.ee/#RssScreenlet
One quick question: how can I add buttons to my screenlets?

[RYX]

One quick question: how can I add buttons to my screenlets?
Quick question - but needs a long answer :)

I have created the screenlets.ShapedWidget-class for that purpose (though I don't like the name and it doesn't use the shape yet). Create a subclass of the ShapedWidget and within your drawing handler (draw) you can then handle the "self.mouse_inside"-attribute to easily know which state to be drawn (no mouse_down-attribute yet, but will come) ... Look at screenlets.TestWidget and the Windowlist's "TaskIconWidget" for examples on how I've done it so far.
It offers the advantage that you have "real" gtk.Button-objects and can use them within a gtk.Container (extremely simplifies the alignment and placing of buttons).

Alternatively you could owner-draw the buttons in your Screenlet's draw-handler but I had problems with getting motion-notify-events on a Screenlet and was unable to determine the correct position of the mouse (but that's likely happened because of the missing shape).

:)

[RYX]

I was thinking that the settings for each widget could be drawn in another window which would have _COMPIZ_WIDGET_SETTINGS and _COMPIZ_WIDGET_ID set, the main window could then render a settings button which sends a signal to the plugin to transition between the 2 windows.
If I get you right, you mean to have something like the "settings-on-the-backside"-effect from the OSX-dashboard? So to treat the widget's settings-window as another special window-type and hide the widget when the settings-window is shown and vice-versa? Sounds really good ... maybe a little too much for now (since we don't even have settings-windows yet), but a good idea.

I currently have crashes of compiz when I do one of the following:
- start the ControlScreenlet which then opens other Screenlet(s) (i.e. start a Screenlet when another one is already open)
- switch a Screenlet to/from Widget-state (needs 0.0.3 to see)
- (sometimes) when in widget-state and click on the titlebar of a normal-window and immediately start dragging

In all cases, after restarting compiz everything is fine and the Screenlets work. So I'll try to get a 0.0.3 out this evening, maybe you can look into the widget-plugin and see what you can do against the crashes.

:)

[mikedee]

If I get you right, you mean to have something like the "settings-on-the-backside"-effect from the OSX-dashboard?

Yes something like that ;)

I currently have crashes of compiz when I do one of the following:
- start the ControlScreenlet which then opens other Screenlet(s) (i.e. start a Screenlet when another one is already open)
- switch a Screenlet to/from Widget-state (needs 0.0.3 to see)
- (sometimes) when in widget-state and click on the titlebar of a normal-window and immediately start dragging

In all cases, after restarting compiz everything is fine and the Screenlets work. So I'll try to get a 0.0.3 out this evening, maybe you can look into the widget-plugin and see what you can do against the crashes.

I have just put an updated widget plugin on my site, the main changes are that it allows you to change the type of fade out and how far it fades. I have also made it so the menus do not fade out. Can you check that version for crashes, I cannot see any of those things here.

[RYX]

Didn't check out the options yet, but all crashes are fixed (as far as I can say after five minutes of testing). Thumbs up! Great work ... :)

[wfarr]

Didn't check out the options yet, but all crashes are fixed (as far as I can say after five minutes of testing). Thumbs up! Great work ... :)

1. Any estimate until a systray applet is available?

2. Have you considered moving the control applet to a tray icon for usability reasons?

[RYX]

1. Any estimate until a systray applet is available?
I was thinking about that - I want one, but I currently have no idea of how to write one that works with gnome and KDE. Maybe someone has more experience in that ... However - it is a planned feature.

2. Have you considered moving the control applet to a tray icon for usability reasons?
That would be against my dream of getting rid of the panel/taskbar - so I am (still) trying to find a way of integrating Tray/Notification-Area with the Screenlets ... (current ideas are either make the Tray a free-moving mini-app like the Windowlist or wrap it into the Control ... somehow)

Everybody should expect more features starting with the 0.1.0-release (which has no date yet). Until then, I want to work on the base and settings and make everything stable and looking good ...

:)

[lagorgy]

is there a way to change the windowlist screenlet position? and can it be set NOT to behave as a widget so it doesnt hide with de widget plugin?

[RYX]

is there a way to change the windowlist screenlet position?
You can drag the Screenlet around using compiz' window movement feature (by holding <Alt> and dragging the window).

...and can it be set NOT to behave as a widget so it doesnt hide with de widget plugin?
The next version will include a submenu in the right-click menu where you can set the window's options like Sticky/KeepAbove/Widget/...

I am planning a release for tomorrow, but I haven't much time recently so I cannot say for sure (customers suck :) ...).

:)

[Sorcerer]

I am planning a release for tomorrow
Hi, glad to hear that. If you are going to include RssScreenlet, please get the newest version from http://hendrik.kaju.pri.ee/#RssScreenlet. I added a few important features. Thanks!

[brokencrystal]

Will this work with KDE or Kubuntu?

[mikedee]

Will this work with KDE or Kubuntu?

It works fine with KDE, you just have to install a few more dependencies than you should because of the way the python rsvg bindings are packaged.

I use screenlets and the widget plugin under KDE.

[RYX]

Screenlets 0.0.3 release is online - see the first post for the download. I am a little unhappy with this release because it contains nothing big that is really finished yet. However - I don't want to let you wait any longer for the Widget-option ...

Most time-consuming new feature is the XmlMenu-module, which offers a way to dynamically define the right-click popup's entries and structure. It is very experimental and will maybe get dropped in the coming versions - tell me what you think about it. It is only used by the ControlScreenlet for now ... (to edit the menu's structure, edit the file control/menu.xml)

I still have no response from nzjrs and/or sil about a combined project (ok, I've never asked outside this thread) so I am about to implement my own settings-system and options-editor - that's sad, but I need a settings-backend for being able to continue. If someone has an idea, any suggestions are welcome ...

Sorcerer, I haven't included your Screenlets yet - mainly because of the new metainfo - but I'll have a look at your new versions. Sorry, but I had very little time this week ... again thanks for your help!

:)

[Sorcerer]

I've updated RssScreenlet and SearchScreenlet. Added XML menus and 0.0.3 compatibility.
http://hendrik.kaju.pri.ee/#RssScreenlet
http://hendrik.kaju.pri.ee/#SearchScreenlet

[kejar31]

I'm not a programer so I am unable to do it myself. Althouth I am still curious on whether or not it would be possible to port Liquid Weather to Screenlets. I took a look at it and is writen in python. You can see it here

http://www.kde-look.org/content/show.php?content=6384

It would also be nice to have a memory usage screenlet to go along with that cpu one.

[QuinnStorm]

I'm still hoping to hear about source control for screenlets soon. I would love to help out, but without that it becomes a bit hard. The offer still stands to get some space in beryl's svn, as this is a closely related project.

Eventually I'll even install it and try it out :-P

[RAOF]

I'd also like some source-control loving. I probably won't be hacking on this in the immediate future, but I like python. And collaboration really requires source-control. Also, it can help you in your development.

Among your apparent options are: 1) Beryl SVN
2) Google-code SVN
3) Launchpad.net BZR
4) Waiting for the go-compiz.org GIT additional repository to actually get set up.

I'd suggest Launchpad.net. You get easy bzr hosting and a bugtracker. Plus, I think bzr is better than SVN (you can do all of your work offline, and then publish it; it's easy to branch and merge; it's written in and knows about python),

[kejar31]

I modified the cpu meter for my own need hers a screen shot and the file.

http://forum.beryl-project.org/download.php?id=451&f=38

http://forum.beryl-project.org/download.php?id=452&f=38

[imnotpc]

4) Waiting for the go-compiz.org GIT additional repository to actually get set up.
The git repo on compiz.org has been set up for several weeks now: http://git.compiz.org/. I mentioned it on the list http://lists.freedesktop.org/archives/compiz/2007-January/001210.html but didn't get any feedback so I didn't make an official announcement. If it checks out OK I'll go ahead and announce it now so everyone knows.

You can also browse it with gitweb: http://go-compiz.org/gitweb.cgi

Anyone who wants to use it for a plugin or Compiz related project should contact David davidr_at_novell.com and he'll help you set it up and give you upload access.

[robgig1088]

Hey, RYX, I made a little memory screenlet. Basically, I just modified your cpu meter with my kiba-dock memory plugin added on. I ended up changing the get_cpu_load() function and the drawing function (so alot of the code is mine.... I hope you dont mind..) anywho, here it is! I hope you like it and its worthy of being in a release!

http://forum.beryl-project.org/download.php?id=459&f=38

[lagorgy]

is there a way to NOT include the screenlets in the scale plugin type of windows?

[RYX]

I'm not a programer so I am unable to do it myself. Althouth I am still curious on whether or not it would be possible to port Liquid Weather to Screenlets.
I think that would mean some work, but shouldn't be too hard. Though maybe the better way would be to create a "superkaramba-host"-screenlet that is able to display superkaramba-themes ... "Superduperkaramba".

:)

[RYX]

I'm still hoping to hear about source control for screenlets soon. I would love to help out, but without that it becomes a bit hard. The offer still stands to get some space in beryl's svn, as this is a closely related project.

Eventually I'll even install it and try it out :-P
You're still invited to look, install, try and give suggestions any way you like. I again thank you for your hosting-offer, but I think for "diplomatic reasons" it is better to host the project neither on beryl-svn, nor on compiz-git ... I guess I'll choose google-code or sourceforge (I don't trust google but sourceforge is soooo slow). I hope everyone can understand this decision ... (and I still appreciate all your kind offers).
I need about one (maybe two) week(s) to implement the missing features to have a 0.1.0-version - once that is ready, the code will go into some public repository ...

:)

[RYX]

Hey, RYX, I made a little memory screenlet. Basically, I just modified your cpu meter with my kiba-dock memory plugin added on. I ended up changing the get_cpu_load() function and the drawing function (so alot of the code is mine.... I hope you dont mind..) anywho, here it is! I hope you like it and its worthy of being in a release!

http://forum.beryl-project.org/download.php?id=459&f=38
Hi robgig1088! The CPUMeter is very simple, so no problem if you base your Screenlet on it - it's more an example anyway. Just keep my copyright notice/comment within the sourcecode - you can set the metainfo to your data and add your copyright-note to the header.

I was thinking about adding additional options to the CPUMeter to show things like network-traffic, memory-usage, ... That way there would be a single Screenlet for all monitoring-needs and it would mean less (and better organized) code ...

So - thanks for helping ... if you have suggestions for improving the base or other parts of the project - please let me now.

:)

[RYX]

is there a way to NOT include the screenlets in the scale plugin type of windows?
Honestly - I don't know. I don't use many plugins ... But it shouldn't be very difficult to implement, I think.

:)

[RYX]

I've updated RssScreenlet and SearchScreenlet. Added XML menus and 0.0.3 compatibility.
http://hendrik.kaju.pri.ee/#RssScreenlet
http://hendrik.kaju.pri.ee/#SearchScreenlet
Thanks Sorcerer! These work much better for me. I am working on a settings-backend that should allow easy configuration of the feeds - I think you'll like it ...

:)

[Sorcerer]

Thanks Sorcerer! These work much better for me. I am working on a settings-backend that should allow easy configuration of the feeds - I think you'll like it ...
Glad to hear that. If there is anything in your TODO list for 0.1.0 I could help with, just let me know.

I have also created AppStartScreenlet for displaying icons using Screenlets. It's a first release, so don't expect much. I'll work on it when I get more time.
Info and download @ http://hendrik.kaju.pri.ee/#AppStartScreenlet

[RYX]

I have also created AppStartScreenlet for displaying icons using Screenlets. It's a first release, so don't expect much. I'll work on it when I get more time.
Info and download @ http://hendrik.kaju.pri.ee/#AppStartScreenlet
That's good - I also started a similar Screenlet, but I have enough to do already so I'll delay mine for now. With an AppStarter it's up to everyone himself whether one wants to use nautilus/xfdesktop/kde as desktop-window or simply use AppStarters as icons.
On the long run, the AppStarter should be able to receive icons via drag&drop and then display that icon/app instead of the current one ...

With the next release there will be many things to discuss because the core parts are ready and we (the people who are using and developing Screenlets) have to think about what's good and what could be done better ... Then everybody is invited to give suggestions and help improving the base.

Thanks for your help :)

[Devport]

Screenlets are great !

Now my questions / ideas :

- I wonder if it would be possible to write a screenlet that shows something different on every side of the cube ( e.g. side number ). I am sure that a screenlet could be written that displays the number of the current cube side, but to have it on every side of the cube it would have to be launched on every side... so the question is if one screenlet could create / draw e.g. 4 separate windows - one for each side.

- Would it be possible to add a function to the controlscreenlet to hide / unhide all other screenlets on mouse hover / click ? That way screenlets would be useful for every window manager even without compositor ( with themes that have no transparency ) or beryl which doesn't have the widget plugin yet.

[RYX]

Screenlets are great !
Thanks :)

I wonder if it would be possible to write a screenlet that shows something different on every side of the cube ( e.g. side number ). I am sure that a screenlet could be written that displays the number of the current cube side, but to have it on every side of the cube it would have to be launched on every side... so the question is if one screenlet could create / draw e.g. 4 separate windows - one for each side.
Screenlets can be simply set to be sticky, like any other window - that way they show up on all workspaces. Using the libwnck, the Screenlet could check for viewport_changed-events on the current WnckScreen and update the viewport number whenever the viewport changed. A good and useful idea - I always confuse which viewport I am on when my panel is hidden and I have no pager.

Would it be possible to add a function to the controlscreenlet to hide / unhide all other screenlets on mouse hover / click ? That way screenlets would be useful for every window manager even without compositor ( with themes that have no transparency ) or beryl which doesn't have the widget plugin yet.
Yes, it's possible. as far as I can remember it already has such a feature which I disabled because of the widget-plugin. (That's why some of the Control's themes have a "hidden"-state)

:)

[Devport]

Screenlets can be simply set to be sticky, like any other window - that way they show up on all workspaces. Using the libwnck, the Screenlet could check for viewport_changed-events on the current WnckScreen and update the viewport number whenever the viewport changed. A good and useful idea - I always confuse which viewport I am on when my panel is hidden and I have no pager.
Yeah, but that sticky single screenlet would show the number of the current desktop on all desktops. I think to show the number of each desktop respectivley the screenlet would have to create / draw four ( one for each side of the desktop ) windows seperatly - is that possible ? ( But you are right, even a simple screenlet showing the current desktop number will be useful anyway )

Yes, it's possible. as far as I can remember it already has such a feature which I disabled because of the widget-plugin. (That's why some of the Control's themes have a "hidden"-state)

:)
Would you like to enable that functionality again ? It would ease the use and development of screenlets because if they are visible all the time for e.g. a beryl user ( I currently use it without having an opinion with regards to beryl vs. compiz ) they are too enoying. If its possible to hide them one could run them in a useful way. If a single click on the control-screenlet would toggle visibility that would be nice.

Related to this I would like to ask if you know why screenlets are using full cpu when started under e.g. metacity ? Otherwise screenlets will be usable even under metacity ...

[RYX]

I think to show the number of each desktop respectivley the screenlet would have to create / draw four ( one for each side of the desktop ) windows seperatly - is that possible ? ( But you are right, even a simple screenlet showing the current desktop number will be useful anyway )
There's really no need for more than one - the desktop number could simply be updated whenever the Screenlet receives an event that the desktop/viewport has changed (That's what it would need libwnck for).

Related to this I would like to ask if you know why screenlets are using full cpu when started under e.g. metacity ? Otherwise screenlets will be usable even under metacity ...
No, I didn't know - thanks for telling me. I'll check that (though it's kinda surprising) ...

Concerning the hide/show: With the next release, I will re-enable the hide/show function as a hidden feature through the XML-based menu. Whoever wants to have the hide/show functionality can simply uncomment a line in the menu.xml for the ControlScreenlet.

:)

[delfick]

hello :D
(excuse me for coming in from nowhere :D

I have also created AppStartScreenlet for displaying icons using Screenlets. It's a first release, so don't expect much. I'll work on it when I get more time.

will it be possible to eventually use png's as the icons ??
or does the screenlets only allow svgs ??

There's really no need for more than one - the desktop number could simply be updated whenever the Screenlet receives an event that the desktop/viewport has changed (That's what it would need libwnck for).

what happens when you rotate the cube though ??
if they all show the same thing, then it'll be like with the gnome-panel.......(so basically when you can see more than one side of the cube, the number on those sides you can see will be the same ......(i think))

[RYX]

hello :D
(excuse me for coming in from nowhere :D
Hi delfick :D ... nice to see you here.

will it be possible to eventually use png's as the icons ??
or does the screenlets only allow svgs ??
The theme currently only supports svgs because they can be scaled to any size (as the name implies) without looking unsharp and pixelated ... but I'm sure cairo can render png, too.

There's really no need for more than one - the desktop number could simply be updated whenever the Screenlet receives an event that the desktop/viewport has changed (That's what it would need libwnck for).
what happens when you rotate the cube though ??
if they all show the same thing, then it'll be like with the gnome-panel.......(so basically when you can see more than one side of the cube, the number on those sides you can see will be the same ......(i think))
Yes, you're right ... So maybe simply (manually) putting 4 Sticknotes on the desktops (with the numbers 1-4 on them) is the easiest way. One could design a cool-looking theme for that purpose and then use a big fontsize to draw the number ...

:)

[robgig1088]

Hey, RYX, I have an idea to make theming a little simpler... Why not allow the theme to supply its own draw() function. That way themes could be more versatile and flexible. What do you think?

[RAOF]

I still think you should set this up in some form of source-control, now rather than at 0.1.0. People are using it, which means it's good enough for people to hack on. I'll even set up a launchpad project for you, if you like :).

Then I wouldn't have to post a url to my patch to make it use Freedesktop.org XDG spec config directories (http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html) :)
http://raof.dyndns.org/xdg-spec.patch or, if you want to, the bzr branch http://raof.dyndns.org/code/Screenlets

[RYX]

Hey, RYX, I have an idea to make theming a little simpler... Why not allow the theme to supply its own draw() function. That way themes could be more versatile and flexible. What do you think?
Hmm ... sounds interesting ... you mean by placing a python-file (which contains a draw-function) within the theme-directory? I was thinking about some theme-config-file anyway (where settings can be easily read from), the draw-function could go in there. Maybe it could be an optional feature for Screenlets that want to use it (could make sense for the CPU-Meter).

I still think you should set this up in some form of source-control, now rather than at 0.1.0. People are using it, which means it's good enough for people to hack on. I'll even set up a launchpad project for you, if you like :)
Thank you for the offer - launchpad is a good alternative - it's "neutral territory". I will decide about that question within the next days (need to read some more) and will put the 0.0.4 release on some public repository once it's ready (so no delay til 0.1.0).
And thanks for your patch - seems to be a very good addition - I'll try it later. I don't really understand what xdg does - does it care for loading config-files from standard places (like $HOME/.screenlets/)? If yes, where does it look in case of your patch?

:)

[delfick]

Hi delfick :D ... nice to see you here.

:D :D :D

The theme currently only supports svgs because they can be scaled to any size (as the name implies) without looking unsharp and pixelated ... but I'm sure cairo can render png, too.

awsome :D....thought so....

on a side note, is it possible to convert a png to a svg ??

[RAOF]

...
And thanks for your patch - seems to be a very good addition - I'll try it later. I don't really understand what xdg does - does it care for loading config-files from standard places (like $HOME/.screenlets/)? If yes, where does it look in case of your patch?

:)

The xdg package is just a python library to make being spec-compliant easy.

My patch makes it read the config from the first existing XDG config directory (which is controlled by environment variables, etc). On Ubuntu, this means that it'll first look for /etc/xdg/RYX.Screenlets (this means that packagers can ship a good default config if they choose to), then for ~/.config/RYX.Screenlets. If neither are found, it'll return None. The patch also make it write config to the XDG user-config directory, which again on Ubuntu is ~/.config/RYX.Screenlets

[robgig1088]

[
Hmm ... sounds interesting ... you mean by placing a python-file (which contains a draw-function) within the theme-directory? I was thinking about some theme-config-file anyway (where settings can be easily read from), the draw-function could go in there. Maybe it could be an optional feature for Screenlets that want to use it (could make sense for the CPU-Meter).


yep thats exactly what I mean. Like an overloaded function or something. That way, we can have lots of wildly different themes for the same raw backend code!

also, I wrote a calendar screenlet, if anyone is interested. Soon, I hope to add the ability to make it interact with the sticky note plugin (maybe create a sticky note based on tasks for the day :D ) So here it is in its raw form! Enjoy!

http://forum.beryl-project.org/download.php?id=484&f=38

edit to RYX: as always, add it to the next release if you like it :D

edited again: see below. bug fix =)

[Sorcerer]

Found a bug with the CalendarScreenlet. It should be Tuesday.
Screenshot:
http://hendrik.kaju.pri.ee/screenlets/calendarbug.png

[RYX]

My patch makes it read the config from the first existing XDG config directory (which is controlled by environment variables, etc). On Ubuntu, this means that it'll first look for /etc/xdg/RYX.Screenlets (this means that packagers can ship a good default config if they choose to), then for ~/.config/RYX.Screenlets. If neither are found, it'll return None. The patch also make it write config to the XDG user-config directory, which again on Ubuntu is ~/.config/RYX.Screenlets
OK - that's what I thought ... thanks for the explanation. Sounds good and will go into 0.0.4 (being compliant with freedesktop-standards can't be bad).

@robgig1088: I really like your calendar (another thing I don't have to add myself :) ...). Didn't try it yet, but the screenshots look great (checked on beryl-forums). It shouldn't be difficult to create Notes for certain tasks, the only thing is - we have to work out how they can be saved (maybe as a Screenlet-List-type for the calendar's settings ... would be useful for the Control as well).

The new settings-dialog is partly ready and working and the 0.0.4 release is getting closer - my web-design-customers keep quiet so I have some time to spend on the Screenlets this evening ...

:)

[toma222]

Hi.

I'm trying to get Screenlets working under Debian (Testing or Sid), but I can't find rsvg. Any ideas ?

Thanks.

[RYX]

Hi.

I'm trying to get Screenlets working under Debian (Testing or Sid), but I can't find rsvg. Any ideas ?

Thanks.
Hi, toma222. On Ubuntu, the python-bindings for rsvg are part of the package "python-gnome2-desktop" ... I don't know if its the same for debian, but you could give it a try.

:)

[flargen]

A quick look at packages.debian.org suggests the package has the same name that RYX posted.

[toma222]

Thank you for your answer.
Unfortunately I have already tried it with no luck. Could it be because there is only Gnome 2.14 on Debian Testing/Unstable ?

[RYX]

I guess it can be that python-rsvg became part of gnome-desktop with 2.16 ... do you maybe have a separate package "python-rsvg" or "librsvg-python"? It should be somewhere because gnome itself uses it, too (as far as I know).

What does "apt-cache search rsvg" give you?

[toma222]

No I don't have any librsvg-python or python-rsvg.

thomas@PC-Thomas1:~$ apt-cache search rsvg
gnome-themes-extras - various themes for the GNOME 2 desktop
libgnome2.0-cil - CLI binding for GNOME 2.12
libimage-librsvg-perl - Perl binding for librsvg
liblablgtk2-gnome-ocaml - runtime libraries for OCaml bindings to Gnome
liblablgtk2-gnome-ocaml-dev - OCaml bindings to Gnome
librsvg2-2 - SAX-based renderer library for SVG files (runtime)
librsvg2-bin - command-line and graphical viewers for SVG files
librsvg2-common - SAX-based renderer library for SVG files (extra runtime)
librsvg2-dev - SAX-based renderer library for SVG files (development)
librsvg2-ruby - RSVG renderer bindings for the Ruby language
gtk2-engines-spherecrystal - A blue vector theme for GTK+ 2.x

:?

[toma222]

I have updated python-gnome2-desktop to 2.16 (using the experimental repository) and it looks ok for rsvg but I have this :

thomas@PC-Thomas1:~/screenlets-0.0.3$ ./ControlScreenlet.py
Traceback (most recent call last):
File "./ControlScreenlet.py", line 308, in ?
screenlet = ControlScreenlet(200, 200)
File "./ControlScreenlet.py", line 50, in __init__
is_widget=False, is_sticky=True)
File "/home/thomas/screenlets-0.0.3/screenlets.py", line 193, in __init__
self.alpha_screen_changed(self.window) # TODO: call on screen_changed
File "/home/thomas/screenlets-0.0.3/screenlets.py", line 321, in alpha_screen_changed
map = screen.get_rgba_colormap()
AttributeError: 'gtk.gdk.ScreenX11' object has no attribute 'get_rgba_colormap'

[robgig1088]

Thanks, Sorcerer for that bug catch :D I owe you one. Apparently I had accidentally retrieved the current day instead of the day of the first of the month :p. Anyway, heres the updated file. Enjoy!!

http://forum.beryl-project.org/download.php?id=484&f=38

[RYX]

Toma222, it looks like you've also installed an older version of pygtk (package should be "python-gtk2"). Recommended version is 2.10 ...

[kkellner]

first off, I'd just like to say that screenlets are amazing, and thanks to everyone who has helped. I have a question:

when I run the RssScreenlet made by sorcerer via the gnome-terminal, it works perfectly. It also runs perfectly if I run the ControlScreenlet via the terminal and then add it to my active screenlets.

however, when I run it by a script, by double-clicking on RssScreenlet.py or by adding it via the ControlScreenlet, it never loads the fed and eventually crashes screenlets.

I should mention that I'm behind a proxy.

I apoligize if this post isn't in the right place, feel free to move it.

[robgig1088]

another plugin! :wink: This time i modified the CPU plugin to support dual core and single core processors. Im marginally satisfied with it. Heres the file. Tell me if you like it/ what i could improve :D

http://forum.beryl-project.org/download.php?id=489&f=38

[toma222]

Thanks for your help RYX, but I don't manage to get it work (using experimental repository seems to be a bad idea, I broke lot of things). I have finally get my packages back to Testing/Unstable.
I will get an other try to Screenlets when Gnome 2.16 will be at least in Unstable repository.
But keep your good work, it seems to be very amazing.
And sorry for my English :wink: .

[Sorcerer]

when I run the RssScreenlet made by sorcerer via the gnome-terminal, it works perfectly. It also runs perfectly if I run the ControlScreenlet via the terminal and then add it to my active screenlets.

however, when I run it by a script, by double-clicking on RssScreenlet.py or by adding it via the ControlScreenlet, it never loads the fed and eventually crashes screenlets.

I should mention that I'm behind a proxy.
I think that the problem is that you are not running Screenlets in the right directory when right-clicking. Open a text editor and copy-paste the following in it:

#!/bin/sh
PWD=pwd
#Change this to your "screenlets" folder
cd ~/Desktop/screenlets/
./ControlScreenlet.py
cd $PWD

Now make it executable and always run screenlets from this script. If you only want to run RssScreenlet, change ./ControlScreenlet.py to ./RssScreenlet.py :)
If the problem still remains, make sure that you are not viewing a feed with images in it because it may crash RssScreenlet.

[RYX]

Hi everybody - I am a little busy with the next release so sorry for taking slightly longer to answer.

another plugin! :wink: This time i modified the CPU plugin to support dual core and single core processors. Im marginally satisfied with it. Heres the file. Tell me if you like it/ what i could improve :D

http://forum.beryl-project.org/download.php?id=489&f=38
I only looked at it yet - I have no dual-core so I cannot really try it ... but support for multiple cpus is a great improvement ... good work :)
Maybe it can be extended to support any number of cpus?

:)

[RYX]

Thanks for your help RYX, but I don't manage to get it work (using experimental repository seems to be a bad idea, I broke lot of things). I have finally get my packages back to Testing/Unstable.
I will get an other try to Screenlets when Gnome 2.16 will be at least in Unstable repository.
But keep your good work, it seems to be very amazing.
And sorry for my English :wink: .
Thank you and never mind. :)
Sorry that it doesn't work for you ... but it isn't finished anyway, so no need to worry.

:)

[melalcoolique]

I just gave it a try and this is very nice. I dream since a long time to remove the gnome-panel. I don't know how hard it is to get a notification area and a menu screenlet but hopefully this day is near. Keep up the good work.

Best regards

[kkellner]

when I run the RssScreenlet made by sorcerer via the gnome-terminal, it works perfectly. It also runs perfectly if I run the ControlScreenlet via the terminal and then add it to my active screenlets.

however, when I run it by a script, by double-clicking on RssScreenlet.py or by adding it via the ControlScreenlet, it never loads the fed and eventually crashes screenlets.

I should mention that I'm behind a proxy.
I think that the problem is that you are not running Screenlets in the right directory when right-clicking. Open a text editor and copy-paste the following in it:

#!/bin/sh
PWD=pwd
#Change this to your "screenlets" folder
cd ~/Desktop/screenlets/
./ControlScreenlet.py
cd $PWD

Now make it executable and always run screenlets from this script. If you only want to run RssScreenlet, change ./ControlScreenlet.py to ./RssScreenlet.py :)
If the problem still remains, make sure that you are not viewing a feed with images in it because it may crash RssScreenlet.

Thanks for the reply - this is essentially the script I was running. It still doesn't work with yours, and I've found that even when I run it in the terminal and it works it still crashes eventually. I guess it could be due to my terrible internet here at college.

[RYX]

Hi kkellner.

Currently Screenlets need to be started in the directory where screenlets.py is located. Within the next few releases I will change the structure of the folders and let it install the core-files into some global path. Then it will be easier to launch Screenlets from outside their directory and modularize them.

You can maybe workaround that by adding the screenlets-dir to your $PATH-variable like this: "export PATH=$PATH:/path/to/the/screenlets". To permanently set it for your session, add it to your .bashrc ...

:)

[kkellner]

Thank you both for helping me. I'm not sure I understand what you mean - I am starting the RssScreenlet from within the screenlets directory (I use nautilus to get into the directory, in my case /home/ken/screenlets) and then just double click the RssScreenlet.py file. The actual screenlet starts fine, but as soon as I try to add a feed via the right click menu it crashes. If I cd to the directory in the terminal and then start the screenlet in the terminal, feeds work. It seems like a script like the one Sorcerer gave me in which the script moves into the screenlets directory and then launches the python file would do the same thing, and yet it doesn't work.

I'm sorry I'm so confused. I hope I'm not missing something really obvious here :)

[RYX]

I just gave it a try and this is very nice. I dream since a long time to remove the gnome-panel. I don't know how hard it is to get a notification area and a menu screenlet but hopefully this day is near. Keep up the good work.

Best regards
Thank you, melalcoolique. We share the same dream ... :)
It is not really easy to create a notification-area from what I know, but I am sure someone will do it sooner or later. Maybe I'll try myself, but it requires some days of reading and trying ...

[RYX]

Thank you both for helping me. I'm not sure I understand what you mean - I am starting the RssScreenlet from within the screenlets directory (I use nautilus to get into the directory, in my case /home/ken/screenlets) and then just double click the RssScreenlet.py file. The actual screenlet starts fine, but as soon as I try to add a feed via the right click menu it crashes. If I cd to the directory in the terminal and then start the screenlet in the terminal, feeds work. It seems like a script like the one Sorcerer gave me in which the script moves into the screenlets directory and then launches the python file would do the same thing, and yet it doesn't work.

I'm sorry I'm so confused. I hope I'm not missing something really obvious here :)
It is a problem of the current way the Screenlets are installed - that will change in the near future. You should run the ControlScreenlet.py directly from a terminal (with "./ControlScreenlet.py" inside the screenlets-directory) ...

:)

[kkellner]

I understand now. Thanks for your help. I'm excited about this project! :)

[RAOF]

Hey, RYX. I'm moderately familiar with python-distutils and co. Would you like me to create a setup.py and publish it in my bzr branch?

[lagorgy]

hi ryx,

im having a problem with the screenlets settings,

everytime i restart screenlets it doesnt seem to keep my last settings (screenlets i added, keep above/below settings, themes)...

thx for this great app, really lovin it ;)

[RYX]

Hey, RYX. I'm moderately familiar with python-distutils and co. Would you like me to create a setup.py and publish it in my bzr branch?
If you can briefly explain me what python-distutils is and what the benefit of a setup.py is I can give you an answer ... :)
(Sorry, but I am totally unfamiliar with that things ... :D ...)

everytime i restart screenlets it doesnt seem to keep my last settings (screenlets i added, keep above/below settings, themes)...
That's strange but can be related to the current way the settings are stored. If you choose "Quit" from the right-click menu of the ControlScreenlet, it should save all settings. When you then start the Control again, it should restore the settings. Sometimes it helps to delete the file $HOME/.screenlets.conf - it can contain errors that cause strange behavior.

[lagorgy]

That's strange but can be related to the current way the settings are stored. If you choose "Quit" from the right-click menu of the ControlScreenlet, it should save all settings. When you then start the Control again, it should restore the settings. Sometimes it helps to delete the file $HOME/.screenlets.conf - it can contain errors that cause strange behavior.

so i have to choose ¨quit¨ for it to save the settings? if i just turn off my computer it doesnt save?

ill delete my .conf file and see if it works,

thx for ur answer ;)

[RYX]

so i have to choose ¨quit¨ for it to save the settings? if i just turn off my computer it doesnt save?
Exactly :) ... No real-time saving yet. I will try to implement a sigkill-handler for now (to save the state when the control is killed). But I don't know if that works in python (because python is killed, not the script) ...

The settings-backend is next on my list ... I first needed some settings to work with ... :D

[lagorgy]

so i have to choose ¨quit¨ for it to save the settings? if i just turn off my computer it doesnt save?
Exactly :) ... No real-time saving yet. I will try to implement a sigkill-handler for now (to save the state when the control is killed). But I don't know if that works in python (because python is killed, not the script) ...

The settings-backend is next on my list ... I first needed some settings to work with ... :D

ok, no prob, still´s a great app, good work ;)

[iznogood]

hey guys,

i just want to say that you are doing a fantastic job, keep it up :lol:

[robgig1088]

bwahahaha i finally finished the weather plugin. Couldn't get weather for more than 2 days in advance but hey, who looks that far in advance anyways? Anyway, I would like to stress that this is VERY beta and there WILL be bugs. Just tell me what they are and I will do my best to fix 'em! I have a bit more work to do (like allowing you to set a zipcode. kind of important =p). If its not posted tonight, I'll post it after school tomorrow =)

*crosses fingers* here it goes! I would appreciate any feedback i can get on this (its my hardest one yet ^_^)

http://forum.beryl-project.org/download.php?id=505&f=38

[Sorcerer]

Hi robgig1088. Very nice screenlet, great job. One bug, though. It doesn't remember your zip code. You forgot to add
self.exported_settings.append("ZIP")
so that "ZIP" would be saved as a setting.

[RAOF]

Hey, RYX. I'm moderately familiar with python-distutils and co. Would you like me to create a setup.py and publish it in my bzr branch?
If you can briefly explain me what python-distutils is and what the benefit of a setup.py is I can give you an answer ... :)
(Sorry, but I am totally unfamiliar with that things ... :D ...)

Oh, it's the python equivalent of Autotools (configure, Makefile, etc). Basically, you run the "setup.py" instead of "make && sudo make install".

It's the way to install python programs :).

[RYX]

Thanks for the info - so if it is an equivalent to make, a setup.py would be very cool ... thank you! I am yet unsure where to install what. I think screenlets.py and options.py should go into some global path and all the screenlets into some folder (like /usr/lib/screenlets).

I am very close to getting 0.0.4 ready - once it is released, we can think about an installation if you like to help ... it will make some things easier :)

:)

[robgig1088]

Hi robgig1088. Very nice screenlet, great job. One bug, though. It doesn't remember your zip code. You forgot to add
self.exported_settings.append("ZIP")
so that "ZIP" would be saved as a setting.

Thanks!

EDIT: version 0.2 is now uploaded. Includes some new things that I was too tired to think of last night. Here it is! tell me what needs to be done on it :D

http://forum.beryl-project.org/download.php?id=509&f=38

[bluebyt]

Hi robgig1088,
the weather screenlet work great for me!

Although I like to have weather screenlet that fit with the rest of the screenlets.

Here take a look:
http://widgets.yahoo.com/yahooweatherwidget/

http://www.apple.com/macosx/tips/dashboardweatherwidget01.html

[bluebyt]

Is there a way to when I click show desktop the screenlets stay on the desktop?

[mikedee]

Is there a way to when I click show desktop the screenlets stay on the desktop?

RYX : There are 2 ways to do this, you can set the type to be desktop, this will make the screenlets stick to the desktop but they will not hide on showdesktop. Setting it to type dock would do the same thing. This method would force them to never hide.

The other way (bluebyt) is to uncheck this option in gconf, you have to use the compiz showdesktop keybinding for it to work.

/apps/compiz/general/allscreens/options/hide_skip_taskbar_windows

[RYX]

Yes, I think I will set the window-type to dock ... (though utility fits better).

:)

[bluebyt]

Is the