AFAIK there are some tools that automatically generate C code for binding any function from a C library, this can be used in order to quickly generate the bindings... I don't think it's a huge issue anyways... also, I think Jonne (or was it someone else) was already working on the DBUS bindings and I think the work was in progress (but not completed). About the GUI, the Tcl code won't need to interact with wx or whatever, all it will do is send events to the GUI layer which will do all the GUI stuff.. there is no need for bindings or little work to do on that matter... Maybe I'm wrong... it would be good to sum up everything that was previously said about the different layers/structures we'll be using.. a high-level design as well as a more low-level design should follow...
p.s: sorry Harry, didn't have time to read your design, so if you already did so in your draft, then forget it, we'll only need the low level design (did it talk about the Tcl Data layer and the need for it ?) KKRT On Fri, Aug 18, 2006 at 09:24:59PM -0400, Philippe Khalaf wrote: > On Sat, 19 Aug 2006 03:01:37 +0200 > Harry Vennik <[EMAIL PROTECTED]> wrote: > > > > The last serious issue is with the choice of using TCL. TK is > > > getting dumped, so might as well dump TCL. Why? Your proposal involves > > > writing a lot of bindings! Bindings for D-Bus and bindings for > > > wxWindows. These will take a lot of time and energy to complete. > > > Imagine all the time saved working with something that already has > > > those bindings. If you guys want to keep the high level language thing > > > going for aMSN, then we need to think of Python. It has good D-Bus > > > bindings as well as wxWindows bindings. It is better and more popular > > > than TCL. It seems like the logical and correct solution to take. > > > People who don't know it can learn it, new developers who already know > > > it will be interested/join, and those who are unable to learn it can > > > still work on aMSN1. Added avantage is easy porting to another toolkit. > > > If someone decides he wants a GTK+ aMSN2, he can fork the Python core > > > and write his own UI. > > Hmmm, I won't say TCL should be kept by all cost, but if it would be > > dropped, > > I won't vote for Python as the replacement. Anyway, I think that kind of > > thing has been discussed enough already. Not many people here would like it > > to see TCL dropped. Just read the thread about the first design draft, and > > it > > is very clear (and I did not even propose to drop Tcl there!). > It's not that I don't want TCL. The problem will be with the D-Bus TCL > bindings. That will be one hell of a b**ch to do. > > I know there has been a lot of talk, but the truth is most of the people > are doing a lot of talking and don't want to switch from TCL. But > they are also not doing anything about what is required to keep TCL. > They are just sitting around and waiting for something to happen. > Whoever in this list said they want to keep TCL, then start writing > bindings!!! If you can do it and prove me wrong then I'll be very > happy. We have all known for a long time that keeping TCL in aMSN2 == > writing bindings for D-Bus. But nothing written. I urge all those > people who want TCL to stay to start working on it. > > > > > So I think it's set that Tcl stays. Indeed that involves developing some > > bindings, but that isn't too bad. It can be much, but not really difficult. > > Also it is not sure yet how the GUI thing will be bound to the rest. We > > might > > not even need complete bindings for that... > It is bad to have tons of bindings. They will need to be maintained as > separate projects. If they are not maintained and distributed properly > they will not end up on any distribution. aMSN2 will be useless > because it won't work for anyone. aMSN will end up doing what it already > does to much of; distributing every dependency inside aMSN. This is > horrible for a lot of reasons. Compilation issues will be non-ending > and all of the advantages of TCL will disappear in a second (they did > as soon as we started distributing pre-built binaries for webcam). > > In the end it's pretty simple. If you guys are really eager on keeping > TCL, then you need to define some serious hackers who are willing to > rigorously develop and maintain both D-Bus bindings and wx bindings. > There is no more searching to do, there are no toolkits we don't know > about. It's either wx or tk. Also, these have to be done before any > other development can happen. > > My point is, those bindings are a bigger deal than you make them out to > be. > > Regards, > Philippe > > > ------------------------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job > > easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > Amsn-devel mailing list > > Amsn-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/amsn-devel > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Amsn-devel mailing list > Amsn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amsn-devel ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
