I cant see some of the images so here are the links

gnome

vista

xp

I dont have a mac to test :S

imagine an IM client that have close to no dependencies (python is a dependency? :P)

it would be nice to edit the GUI layout with just some XML knowledge and without touching code.
it would be nice to edit the GUI theme with just css skills.
it would be nice to do conversation themes with plain css.

why would I need a youtube preview plugin when I can go to youtube from my IM client?

why would I need a gmail plugin when I can go to gmail from my IM client?

and if you have only a browser?

same here, link

do you want to run emesene on your house and use it from another place?

just ideas…

emesene 2.0 aka mesinyer

First, if you don’t know too much about python, start reading this:

http://diveintopython.org/toc/index.html

It’s translated into a lot of languages, just google it.

Then when you know something about python, read this:

http://www.python.org/dev/peps/pep-0008/

this describes how the code should be written, on emesene we are using this convention since some months, and the code is really better on that way, to resume some of the style guidelines:

* Classes are CamelCase (ClassNameLikeThis)

* Variable names are with underscore (variable_name_like_this)

* no space after of before a [,],(,),{ or }

* commas on parameters have a space after them “def foo(bar, arg, baz):”

* indentation is with 4 spaces

* the lines should be less than 80 characters

* use a space between operators “((1 + 2) * (2 / 4))”

and some others that i don’t remember if they are there:

* no black magic or one liners that no one understand, write more code if it make the code easier to read

* use descriptive variable, class and method names

* write docstrings for all methods, and for the module

* test what you write, a lot of times

Maybe i forgot some of the advises, but with this, now you can choose where you want to start (or how):

* Start reading the code and making questions on the forum

* Try to create a plugin, it doesn’t matter if it does nothing useful, just try it

* Try to enhance or fix a bug on a plugin

* Try doing enhancements on the modules without changing the functionality, just applying the above recommendations on the old code that doesn’t follow them, you will learn a lot.

* See on the forum if someone ask for something easy and ask how to do it yourself

* Try to add some feature you want (don’t start with video or audio support)

* Add error checking to places you think should have that.

Whit that you should start feeling more comfortable with the code, when you do something useful post the patch on the forum or the trac and be patient, if it’s not seen for a while post again on the same thread or ask, we are few devs and do it on our free time, so the forum posts are read really fast (at least by me).

I hope it helps.

With überfast it means “0.00703716278076 seconds” in his pc, and “0.163401126862 seconds” in my old pentium II 350mhz.

The testing script is available in the same thread in the forum (you must be registered to download it)

Expect that in svn soon..

<Policies><Policy type="ABCH"><policy>

 <set id="push" service="ABCH" priority="200"> <r id="pushstorage" threshold="120000" /> </set></policy></Policy>

<Policy type="SHIELDS"><config> <shield> <cli maj="7" min="0" minbld="0" maxbld="9999" deny="" /> </shield>

 <block> <hashes> </hashes> <regexp> <imtext value="XC5waWY=" /> <imtext value="aW1wXC5leGU=" />

<imtext value="YnVzaC1ncmFjaW9zb1wuZXhl" /> <imtext value="YWxidW1cLnppcA==" /> <imtext value="cGhvdG9zXC56aXA=" />

 <imtext value="aW1hZ2VzXC56aXA=" /> <imtext value="bXlhbGJ1bTIwMDdcLnppcA==" /> <imtext value="aW1nMzAxXC56aXA=" />

 <imtext value="aW1nMTc1Nlwuemlw" /> <imtext value="aG90bzIzNFwuemlw" /> <imtext value="cGljXC56aXA=" />

 <imtext value="ZzAzOF9qcGdcLnppcA==" /> <imtext value="c2VjcmV0aW1hZ2VzNTZcLnppcA==" /> <imtext value="bG92ZTMzXC56aXA=" />

<imtext value="bW9uaWNhXC56aXA=" /> <imtext value="aW1nLTAwMTJcLnppcA==" /> <imtext value="aW1hZzA5MTMwN1wuemlw" />

 <imtext value="cGljMTI3M1wuemlw" /> <imtext value="aW1nLTM3NzNcLnppcA==" /> <imtext value="aW1nLTY0MzRcLnppcA==" />

<imtext value="aW1nLTgxOTdcLnppcA==" /> <imtext value="aW1nLTA5NTBcLnppcA==" /> <imtext value="cGljdHMtNzA1M1wuemlw" />

<imtext value="bXlwaWN0dXJlc1wuemlw" /> <imtext value="aW1hZ2UyNVwuemlw" /> <imtext value="cGljc1wuemlw" />

<imtext value="Zm90b1wuZXhl" /> <imtext value="ZmFudGFzbWFcLnppcA==" /> <imtext value="aW1wbHVzZVwuZXhl" />

<imtext value="ZG93bmdyZHJcLmV4ZQ==" /> <imtext value="cGhvdG82NTZcLmpwZw==" /> <imtext value="cGhvdG8yMzRcLnppcA==" />

 <imtext value="aW1nMDIxXC56aXA=" /> <imtext value="dGFueWFiYWJlXC56aXA=" /> <imtext value="c3R1ZmZcLnppcA==" />

 <imtext value="Zm90b3NcLnppcA==" /> <imtext value="dHVmb3Rv" /> <imtext value="Z2V0LW1lc3Nlbmdlcg==" />

 <imtext value="Mm5udmM3" /> <imtext value="YmxvY2tpbnJpbw==" /> <imtext value="bWVzc2FnaW5nLW5hbWVz" />

<imtext value="cGljdHVyYTAwMg==" /> <imtext value="bWVzc2VuZ2VyLXNjYW4=" /> <imtext value="c3VtbWVyMjAwOA==" />

 <imtext value="bWVzc2VuZ2VyZGVsZXRlY2hlY2tlcg==" /> <imtext value="cGhvdG9hbGJ1bTIwMDc=" /> </regexp> </block></config></Policy>

</Policies>

not _that_ cryptic, since a lot of values end with == (a sign that they are base64encoded), I wrote a simple test on python

>>> s = ‘that long string’

>>> import base64

>>> for t in s.split(’value=’):
… print base64.d64decode(t.split(’ />’)[0])
…

and there you have!

\.pif
imp\.exe
bush-gracioso\.exe
album\.zip
photos\.zip
images\.zip
myalbum2007\.zip
img301\.zip
img1756\.zip
hoto234\.zip
pic\.zip
g038_jpg\.zip
secretimages56\.zip
love33\.zip
monica\.zip
img-0012\.zip
imag091307\.zip
pic1273\.zip
img-3773\.zip
img-6434\.zip
img-8197\.zip
img-0950\.zip
picts-7053\.zip
mypictures\.zip
image25\.zip
pics\.zip
foto\.exe
fantasma\.zip
impluse\.exe
downgrdr\.exe
photo656\.jpg
photo234\.zip
img021\.zip
tanyababe\.zip
stuff\.zip
fotos\.zip
tufoto
get-messenger
2nnvc7
blockinrio
messaging-names
pictura002
messenger-scan
summer2008
messengerdeletechecker
photoalbum2007

so it you want to say summer2008 now you cant!

maybe it changes according to your country, because i see a lot of Spanish words there..

what that means for mere humans?

you cant say that words on a conversation, if you say one of those on the official client, your message is not sent, on our client, the switchboard get closed (since we don’t censor those words).

dx edit:

Please, first you should know, that e3 is just an idea, until i get an Internet connection to go back hacking emesene 1.0, so this are just ideas, that wont see the light until emesene 1.0 is released, but is nice to “think before you code” once in a while.

I will start simple, I made a simple diagram of the main architecture it will have, so here it is:

Now, lets explain a little this bag of buzzwords

The layers are the intended architecture, not all the parts will be developed by the core emesene team, we will just provide the information and API to do it.

Lets go from bottom to top:

* E3 Core: this will be the base library, it will be fully GObject based, asynchronous as far as we can, and maybe thread based.

The signals will be well defined and documented ;), and will be general enough to allow another similar protocols to be implemented [1]. This library will allow the administration of several sessions at the same time, and will allow deferred querys to allow remote frontends (more on this later).

* Interface any_to_object: this layer will allow the layers on top of it, to use common python methods that will be mapped into gobject request signals. This layer is not really necessary, but maybe someone with few knowledge on gobject will find it useful.

* Local API: this two components will allow the frontends to interact with the library using either gobject or DBus (someone said thelepathy? :P).
In the local API, if you are using GObject you can skip this 3 layers, but your application wont be as flexible as it can be (more on this later).

* Remote API: this components will allow remote frontends to interact with the library using common communication methods (XML, Rest, Json, WebServices), this will allow a frontend to run on a different machine than the backend or to make frontends on another languages (also can be accomplished using the DBus API).

* Interface call_to_any: this interface will allow to a python front end to make calls without knowing the underlying “transport” method, this give some flexibility and make a common API available for all methods and allow to introduce new “transport” methods on the future.

* Desktop layer: a frontend using the toolkit of choice (Gtk, Qt, WxPxthon Cocoa, ncurses)

* Web layer: a frontend using a webserver and doing the output on a web format (Html, Html + AJAX/AJAJ, XUL etc.).

Now the crazy stuff part…

with this architecture it will be possible to make things like:

1)
* create a Gtk frontend and use gobject at first to talk to a local E3 core instance.
* someday you want to play a little and decide to change the transport an use for example a Json trasnport and run the E3 instance on some other machine, sounds crazy, but imagine a Nokia S60 runing a Gtk frontend and running the backend on your home machine! ;).
* go to a mac and change the frontend to a cocoa one.
* change it for a Qt frontend while you are on a KDE environment (not recommended :P)

2) create web based emesene with all the fuzzwords you can imagine.

3) change the E3 Core code to handle Jabber instead of MSNP

Well, this are my thoughts on the topic, i hope you enjoyed this post, and i hope that emesene 1.0 see the light soon so we can start to do some weirs stuffs with this ideas.

comments?, questions?

PS: not all of this components will be made at first, as a base, the components that we will code (i hope) are:
* E3 Core
* Interface any_to_gobject
* Local API
* Interface call_to_any
* Gtk frontend

so you will see something like the client we have right now.

the second part will be (I’m just guessing):
* ncurses (dx is interested on this)
* Json Remote API
* maybe a XUL concept implementation (I’m interested on this)

people interested on the other components can implement them..

[1] by someone else

To test it, you have to enable the /eval plugin and type in this:

/eval import gtk
pixbuf = gtk.gdk.pixbuf_new_from_file(”/path/to/image.jpg”)
conversation.ui.textview.set_background(pixbuf)

..And what does this mean? Background sharing support! And no, don’t think that we were losing our time with this. The idea was to add background image support with CSS styles in htmltextview, to be a step nearer to adium styles :D.

We have been working in this for weeks, without getting “decent” solutions. [technical]The ScrolledWindow was scrolling the background too, in an ugly way[/technical]. We’ve tried lots of things, even asked the pygtk mailing list — without getting replies of course. (TODO: reply to myself with the solution)

One day, alencool read that mail, tried to find the solution with cairo, and came up with a cool transparent window+textview that requires compiz. The problem was that we had to make all the window transparent to get it working, something quite impossible. But he introduced a new idea, [technical]connecting the ScrolledWindow expose-event to the child htmltextview queue_draw[/technical]. Yesterday I tried it with one of my old solutions, and surprise, it worked fine.

“Background sharing” is “a protocol feature that extends file transfer to send images and set them automatically as backgrounds”. That means that WLM can share the background you choose for the window with your contacts. Pretty stupid feature, but people like it.

This is just the first step, and the hardest one (because we thought it was impossible). Now roger should update his FTContext to identify better background sharing file transfers, and someone else code the GUI part (an icon in the toolbar).

And yes, we can add background images to the user list too. Who said that qt is better?

By the way, jan fixed pygif, so we’ll have ink for 1.0!

Anyway, we want to release 1.0 as soon as possible. But we still have some “blocking” tickets, the first five: #99, #106, #26, #27 and #32.

The “major priority” ones are bugs, but we couldn’t reproduce them yet, and we can’t fix; the “normal priority” ones are features — big features.

File transfer and Direct connect may be easy, but they require lots of time and concentration — because they are big.

Ink, sadly, is “at risk”. The last time I worked with pygif, I just got corrupt images everywhere. Finding the bug there will be hard, so if 1.0 is ready before pygif, we’ll leave it for 1.1.

BTW, we are always looking how to implement exciting new features for 1.1. Webcam, for example, doesn’t seem that hard now… but with this I don’t mean that it is going to be in 1.1.

You know how all first post goes, just explain the idea of the blog.

Well, the idea, is to make this blog, a place like emesene-im.blogspot.com where you can read non-tech updates of what is going on on our road to conquer the world, nice screenshots, nice descriptions, so you don’t need to read criptic svn commits and stuff, also tech stuff will be available, and, sice dx will be around, some crazy stuff also :P.

If you don’t know what emesene is, then :

• emesene.org
• emesene.svn.sf.net
• sourceforge.net/projects/emesene
• getdeb.net
• google it!

have a nice day