pavpanchekha said:
Thanks. I took a look at your branch. Its great to have a place to put commonly used functions, since there are a lot of them. For now you have C files there only though, right? This is in python, so it'll need a separate build system (or so I'm guessing).

The build system stuff is not my strong point :-)

I'll have a chat with malept and see what he thinks is the best way to add in a python only module.

malept said:
The last thing I want to do is confuse people - having an AWN module *and* an awn module would bring about so many unneccessary support questions, e.g., "Why doesn't AWN.xyz work?!" (Answer: it's actually awn.xyz)

I see. It could be renamed to AWNLib. I just don't see that it should necessarily be "extra" to the awn module. That would imply that the awn module is prefered, where on the other hand it is probably better if AWNLib is used, since it'd be easier for applets to stay usable.

Case in point: aparently, it is now incorrect to use set_temp_icon. And a while back, it became necessary to manually scale applet icons. In both cases, if an abstraction layer like AWNLb was used, the applets would continue to be fairly consistent.

In other words, awn.extras seems like some miscellanious functions you dip into once per applet or so. AWN or AWNLib (or AWNApplet or something else similar) seems like an actual module you'd use as a base.

moonbeam said:
Looks useful. If only I used python :-)

You know, its not too hard to learn. And GTK is supposed to be more or less exactly the same, so the GUI-building is similar.

If you want, go look at a few applets. Hell, look at the example I posted and play around.

pavpanchekha said:
Yep, that's right, AWNLib now handles settings (this applet creates a dummy key with a random value, then checks if its there) and timing (the applet should show the "gtk-about" icon 10 seconds after it is started)

Hmmm, Forgot to mention that icon.pixbufFromSurface(surface) now does the expected. Anyone who needs text (or more) on their icon should now be happy.

Also, dialog.new("main") (or "secondary") auto-registers the dialog, focus-out and all.

pavpanchekha said:
Hmmm, Forgot to mention that icon.pixbufFromSurface(surface) now does the expected. Anyone who needs text (or more) on their icon should now be happy.

how are you copying from surface to pixbuf? the png hack or something else?

moonbeam said:
how are you copying from surface to pixbuf? the png hack or something else?

Whatever mosburger posted on his blog aka what blingswitcher & weather use

pavpanchekha said:
Whatever mosburger posted on his blog aka what blingswitcher & weather use

ah ok. the png hack. It works but it's nasty.

We'll have a much faster implementation for python to use some time real soon. At this point in time there doesn't seem to be any better solution for python that the method you're using.

moonbeam said:
We'll have a much faster implementation for python to use some time real soon. At this point in time there doesn't seem to be any better solution for python that the method you're using.

I personally have never needed this, and have a rusty knowledge at best of cairo. Thus, I'm not completely sure that the code works/is the right way to do things. Having a function built in will probably be nicer, but again I'm not to judge.

pavpanchekha said:
I personally have never needed this, and have a rusty knowledge at best of cairo. Thus, I'm not completely sure that the code works/is the right way to do things. Having a function built in will probably be nicer, but again I'm not to judge.

For infrequent updates it seems to work fine. And at this time it seems to be the only choice. But there's definitely some real overhead involved when it is used for frequent updates. Essentially what happens is the surface gets written out as a png (so there's the encode) and then gets decoded when it gets read into the pixbuf. My understanding is that some of the python implementations of this at least do it all in memory but still...

The implementation that will be pushed out in libawn-extras is a fairly fast, in memory, cairo surface -> pixbuf transfer. It's essentially the abiword code (that's been mentioned a few times) modified for this very specific task.

malept said:
What's confusing about it? It's mostly modeled after gconf, so if you think AwnConfigClient is confusing... :)

How do I find out what type the key is? In gconf, you can client.get() the key and then do key.type.value_nick to get the name. That way, I don't need the user to pass the type of key, since I can just find out.

Looking good.

pavpanchekha said:
Notify:
notify.sent(subject, body) is all you need to do. I'd like to note that this implementation does not use the python module because:
* There is not documentation
* I can't even figure out what the module is called or how to install it (there's not module notify or libnotify after you install python-notify)
Instead, AWNLib just calls the notify-send command. The applet checks that you have it installed.

there's a notify function in libawnextras that you can use once the bindings are done (the current implementation is synchronous but I'll probably doing an async one also). notify-send works well... but, as you know, it doesn't seem to be on some systems by default (so it's good that you're checking)... I had been using it one of my applets and I found this out the hard way.

malept said:
* You should use 4 spaces per indentation instead of tabs, per PEP8.
* You need to import the StringIO class for Icon.pixbufToSurface().
* In Modules.visual(), you don't declare dlog anywhere, to my knowledge.
* In Dialogs.__context(), it should be self.menu.popup(...), I think.
* The naming of method Dialogs.new() strikes me as a little odd.
* The API docs should also be inline with the classes/methods. It's rather difficult to see what everything does without it.
* I noticed that there were several methods with optional arguments that weren't used anywhere. That confused me a little.

1: Yep, I've already changed that
2: Same
3: Wierd. Must have deleted that at one point, since I did test the modules part a bit and the dialog did appear.
3: Thanks for catching that.
5: Why? Creates a new dialog, (optionally) registers it, and returns it. Is there another name you think fits better?
6: In other words, I need more comments. I know, I'm working on it.
7: Blame GTK. x, y are widget, error. I rarely need them, so they just hang around there. They're optional so that I don't have to worry about them in case I ever called the function myself

malept said:
In general, I'm not really a fan of putting all of the applet code into the "main()" block, so to speak. It just doesn't look very clean and maintainable.

It is split into separate classes, which I find is better (specially since I can ask the text editor to just straight to one)

Also, there is a new bug fix release soon, no new things, but keyring was completely rewritten, and gconf was fixed a bit.

malept said:
What I meant about the main() block was that the resulting new wrapped applet code (for example, a slideshow applet) would be just a bunch of procedural statements, which in my view is not ideal for maintaining.

Oh, I see. If you take a look at the GMail applet, it is broken into classes. Though I may rewrite it to be procedural. Personally, I dislike using objects for no reason other than to wrap code inside, eg: if you're using an object to communicate with a web service, that's alright, you may want more than one at a time or, say, you may want to be able to dynamically choose the object you're going to use. But you're only making one Applet instance, ever.

Still, the fact that the test applet s procedural does not mean that using an object-oriented style is bad, or even harder. Just personal preference.

malept said:
I just looked over the Keyring class; don't you want to use the network password type instead? I would say that based on the current applets in awn-extras, the common use case is storing/retrieving passwords for website-related things like google-based services, meebo, websites' feeds, etc.

The new Keyring class allows for that. You can ask for a network type key when you create one.

moonbeam said:
If I understand your description of cPickle it allows the storing of arbitrary objects in gconf?

cPickle allows converting arbitrary objects to strings and back. I then store the string to gconf. Its a C version of pickle, which was a native python module. I use that instead of pickle because of the performance boost.

pavpanchekha said:
New release (1.4): http://www.mediafire.com/?bg91k0tg2ym

good stuff. I'll put a copy into my branch some time tonight. And I know some thought needs to go into how this can actually be integrated into awn-extras.

pavpanchekha said:
Latest cool feature: Will use awn.Config automatically, so you get free brownie points with your applet working on xfce :D

Very good.

bmario said:

class Icon:
def getTheme(self, name):
try:
self.theme = gtk.IconTheme()
icon = self.theme.load_icon (name, self.height, 0)
except:
self.theme = gtk.icon_theme_get_default()
icon = self.theme.load_icon (name, self.height, 0)
return icon

Will add. I'll fix it to be for 1.5, but other than that, i'll add your fix. Thanks for noticing the bug - I use the default tango theme, so I didn't have a chance to notice.