Re: [Amsn-devel] aMSN2 and Telepathy
Hello guys, Just wanted to say ... I really don't like this. Not because of the use of DBUS, or the multiprocess or not, but because i really think that if we do that, aMSN won't be aMSN no more. It would just be another multi protocol client, like there are tons of. I really think aMSN should stay a msn-only client, that's how it can be the best at it. Besides that, i can't really have an opinion about that dbus and telepathy stuff, cause i don't know enough about that, but i can't understand why making amsn2 able to switch FE would need a client daemon structure. Why couldn't we just keep the same structure as now and add to the core the ability to kill a front end, then launch another one ? Of course we would need to implement a lot of stuff, like that the core should not only pass all the messages to the FE but also keep them to be able to re send them to the potential new FE.. That would be simpler than rewriting almost the whole protocol abstraction layer to make it compatible with a telepathy backend, wouldn't it ? Le 27 août 2010 à 02:23, Alaoui kakar...@kakaroto.homelinux.net a écrit : On Thu, Aug 26, 2010 at 8:45 AM, Boris 'billiob' Faure bill...@gmail.com wrote: 2010/8/26 Stéphane Bisinger stephane.bisin...@gmail.com: I think that if we want to split daemon/client, telepathy is an eccelent option since we would basically do the same thing with an implementation of our own. So the question is: would it be a good idea to split aMSN2 in a client/daemon structure? that's the goal. The way we use views is a bit like client-dæmon anyway. Well, aMSN2 has always been a telepathy-like framework, with small difference... first, it's uni-process, secondly, you don't give UIs any information they don't need, you just tell them what to draw where as telepahy tells the UI all the information and the UI decides what to do with it (which is important for their use case). So the real question is since we're doing pretty much what telepathy does.. should we drop our uniprocess requirement? Based on what I see from the centerim project, a LOT of people use a similar functionality, where you can start centerim in the background and do things from the command line. This is very much like having a daemon and a client which is only command line. With the described structure we would be able to do more and do it better! And if the client can not contact the daemon, it should be able to start it. With dbus it just works, you request a service, and the dbus daemon will spawn the process for you.. same when the process dies, the dbus daemon will respawn it automatically for you if you still want it. @Stephane: About the dbus requirement, well that's not really the issue.. yes, now pretty much every computer has it.. oh look, even my headless server! And even if you don't have it.. once you apt-get install amsn, it would just be brought along with it... Also, GNOME now has empathy as its default IM client. So that means that every GNOME user already has telepathy. Anyways, the size doesn't matter, the dependencies don't matter.. the only reason (for me anyways) to say not like the dbus dependency is because I don't like dbus itself, not because of the dependency... There was also an issue of would it work on windows but afaik, it's windows-compatible (TM). Finally, I'd like to point out that even though dbus is a bitch to work with, we'll be using python.. and python-dbus is JUST AWESOME! Very easy to use actually.. and as luck would have it, a few months ago, I wrote a big python framework to make the use of telepathy/dbus as easy as possible. Have a look here : http://gitorious.org/teamgeist/teamgeist/blobs/master/tp_classes.py Basically.. you want a Channel, then do : class Channel (BaseChannel): you want to listen to the 'HandleChannel' dbus signal, then do : method HandleChannel ( ... ) that's it.. the base classes will look for the method names, and automatically do introspection on the objects and connect the signals, or send the dbus methods when you call a local method, etc... so, actually dbus + python.. I don't mind that dependency that much... -- Boris 'billiob' Faure -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this
Re: [Amsn-devel] aMSN2 and Telepathy
On Sun, Aug 29, 2010 at 6:01 AM, Arantes arantes...@gmail.com wrote: Hello guys, Just wanted to say ... I really don't like this. Not because of the use of DBUS, or the multiprocess or not, but because i really think that if we do that, aMSN won't be aMSN no more. It would just be another multi protocol client, like there are tons of. I really think aMSN should stay a msn-only client, that's how it can be the best at it. Yes, we know that, we already do, and that's why we always wanted aMSN to stay MSN specific, and I don't think we plan on stopping that! the multiprotocol is a 'bonus', but we'll stay MSN-centric, we'll continue to support the MSN protocol as much as possible, the UI will stil keep the WLM lookfeel, etc... we'll just change the protocol backend/technology, which itself allows us to go multi proto... Besides that, i can't really have an opinion about that dbus and telepathy stuff, cause i don't know enough about that, but i can't understand why making amsn2 able to switch FE would need a client daemon structure. Why couldn't we just keep the same structure as now and add to the core the ability to kill a front end, then launch another one ? Of course we would need to implement a lot of stuff, like that the core should not only pass all the messages to the FE but also keep them to be able to re send them to the potential new FE.. Because you can't.. if you launch the process somewhere for the GTK/QT frontends, then connect through ssh then you can't just ask it to start sending the curses front end on your terminal... That would be simpler than rewriting almost the whole protocol abstraction layer to make it compatible with a telepathy backend, wouldn't it ? nah, the 'whole protocol abstraction' is quite small and simple, we're not rewriting the whole protocol, just the protocol layer. Look at amsn2/protocol/client.py ( http://github.com/amsn/amsn2/blob/master/amsn2/protocol/client.py ).. that's pretty much all we need to rewrite... there are some files in events/ subdir, but look at them.. not much.. so when you say rewriting almost the whole protocol abstraction layer I don't think it's too much of an issue compared to the gain. An advantage of telepathy, is for example when you said we need the core to save the messages in order to pass them back to the new FE.. there's no need for that.. we could use the telepathy-logger! amsn2 itself doesn't need to be saving logs, because telepathy has its own 'logger' process which acts as an 'observer' on the channels.. so if you wish to switch front-ends, you can just ask it to re-print it the last X lines of conversation or something. (and btw, it gives us the advantage that the logs will be in the same format and compatible with empathy, etc.. ) Le 27 août 2010 à 02:23, Alaoui kakar...@kakaroto.homelinux.net a écrit : On Thu, Aug 26, 2010 at 8:45 AM, Boris 'billiob' Faure bill...@gmail.comwrote: 2010/8/26 Stéphane Bisinger stephane.bisin...@gmail.com: I think that if we want to split daemon/client, telepathy is an eccelent option since we would basically do the same thing with an implementation of our own. So the question is: would it be a good idea to split aMSN2 in a client/daemon structure? that's the goal. The way we use views is a bit like client-dæmon anyway. Well, aMSN2 has always been a telepathy-like framework, with small difference... first, it's uni-process, secondly, you don't give UIs any information they don't need, you just tell them what to draw where as telepahy tells the UI all the information and the UI decides what to do with it (which is important for their use case). So the real question is since we're doing pretty much what telepathy does.. should we drop our uniprocess requirement? Based on what I see from the centerim project, a LOT of people use a similar functionality, where you can start centerim in the background and do things from the command line. This is very much like having a daemon and a client which is only command line. With the described structure we would be able to do more and do it better! And if the client can not contact the daemon, it should be able to start it. With dbus it just works, you request a service, and the dbus daemon will spawn the process for you.. same when the process dies, the dbus daemon will respawn it automatically for you if you still want it. @Stephane: About the dbus requirement, well that's not really the issue.. yes, now pretty much every computer has it.. oh look, even my headless server! And even if you don't have it.. once you apt-get install amsn, it would just be brought along with it... Also, GNOME now has empathy as its default IM client. So that means that every GNOME user already has telepathy. Anyways, the size doesn't matter, the dependencies don't matter.. the only reason (for me anyways) to say not like the dbus dependency is because I don't like dbus itself, not because of the
[Amsn-devel] bugfix - SearchContact: CL is not updated if we remove a filter
Hi
Bug:
SearchContact loaded
Select a filter: Show only those i removed
Deselect that filter
CL is not updated
Bye =)
*Giuseppe Square87 Bottiglieri*
Index: plugins/SearchContact/searchcontact.tcl
===
--- plugins/SearchContact/searchcontact.tcl (revisione 12169)
+++ plugins/SearchContact/searchcontact.tcl (copia locale)
@@ -662,7 +662,15 @@
if {!$::contactlist_loaded} { return }
variable clblocked
- if { $event eq filterChange || $event eq historyScroll } {
+ if { $event eq filterChange } {
+ if {$::searchcontact::config(filter_blocked) == 0
$::searchcontact::config(filter_removedme) == 0 [getInput] == } {
+ set clblocked 0
+ set ::guiContactList::external_lock 0
+ ::guiContactList::organiseList .main.f.cl.cvs
[::guiContactList::getContactList]
+ } else {
+ set clblocked 1
+ }
+ } elseif { $event eq historyScroll } {
set clblocked 1
}
Index: plugins/SearchContact/plugininfo.xml
===
--- plugins/SearchContact/plugininfo.xml(revisione 12169)
+++ plugins/SearchContact/plugininfo.xml(copia locale)
@@ -9,7 +9,7 @@
description_huA partnerek szűrését teszi lehetővé egy keresősáv
segítségével, szabadon megadható keresőszöveggel./description_hu
description_nlDeze plug-in voegt een zoeken-terwijl-u-typt-zoekbalk
onder de contactenlijst toe voor het filteren van contacten./description_nl
amsn_version0.97/amsn_version
- plugin_version0.9/plugin_version
+ plugin_version0.9.1/plugin_version
plugin_filesearchcontact.tcl/plugin_file
plugin_namespacesearchcontact/plugin_namespace
init_procedureInit/init_procedure
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d___
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] bugfix - SearchContact: CL is not updated if we remove a filter
On Sun, Aug 29, 2010 at 15:02, square87 squar...@gmail.com wrote: Hi Bug: SearchContact loaded Select a filter: Show only those i removed Deselect that filter CL is not updated Bye =) Giuseppe Square87 Bottiglieri in svn :) thanks. -- Boris 'billiob' Faure -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
