On Sat, Aug 19, 2006 at 01:59:12PM +0200, Harry Vennik wrote: > Op zaterdag 19 augustus 2006 13:09, schreef Philippe Valembois - Phil: > > Hi, > > I will try to reply to all mails in one... But Youness already did many > > replies. > > First when you proposed Python, I was sure that Youness won't be agree with > > that :p (By the way, you should maybe try Python once because I think it's > > a really good language). But it's clear I think it will be simpler to keep > > TCL... > > About all bindings you said Youness already replied, the only one binding > > required is DBus and Jonne was working on it... > Little correction: DBus is the only thing we'll need for sure. We'll probably > need some bindings for the GUI too, although we are doing something wrong if > we end up with complete wxWidgets bindings or something as huge as that. >
We'll need bindings for the GUi only if we code the GUI with Tcl, but my understanding is that the GUI will either be a C module that commmunicates with Tcl through : 1 - events being sent (dbus?) 2 - using the Tcl library for C (Tcl_GetStringFromObj(), Tcl_Eval()) or it will be a Tk module written in Tk, in which case, no need for 'bindings'... > > About wxWidgets, you are thinking we want to do a binding for that... But > > you misread the draft ! WxWidgets was only a proposal from Harry (which I > > refused for my part)... The better solution was to write an engine that > > transforms XML in widgets so it won't be a binding... It will only be only > > a library that takes XML as input and creates widgets with the library it > > is designed for... So it won't be a huge task... > Sounds nice, but the question is: is it really that simple? I'm afraid not... > How to bind the GUI events (e.g. the user pressing a button) to code? How to > handle all kind of widget options, which can be quite different on various > toolkits? How to make it not only look native, but also feel native? > that, I don't know.. that's where a proof of concept would come in handy... in theory, what I had in mind is that the XML for the GUI would contain a 'name' for each thing, and once you click on a button for someting, its name is sent to the GUI layer which knows what's its purpose.. if nothing needs to access protocol or change data, then it will process everything in the GUI module, if it needs to access protocol, it will send the appropriate/corresponding event... > > Maybe for GTK GUI use a aMSN2XML -> Glade converter and pass it to a binding > > for GTK+ QT has already a XML system so maybe it will be a converter too... > > The remaining thing is aMSN2XML -> Tk and aMSN2XML -> Win32 and IMO if the > > design for XML is well done won't be too hard... > Convert to Glade? You ever looked at GladeXML??? You could as well generate > the C code from our XML and compile it... I don't believe it is as simple as > you're saying. That is why I proposed wxWidgets as a possible solution, > because it will provide a single toolkit, which is implemented in native > widgets on various platforms, so there will be no need for us to care about > which platform we're on, and thus make coding the GUI layer much easier, > while still using native widgets. > ok, that's why wxWidget is wanted... I see, well, I don't know, Vivia gave us some good points, I never used wx or tried it or used a program that uses it, so I don't know anything about it.. and what vivia said might be 'outdated' ... a converter from our XML to another XML format is out of the question, it removes our modularity, simplicity etc... > And here we get exactly to where I was in my other mail when I accidentally > pressed the send button. We need to get that GUI thing set. It has been > discussed a thousand of times now, so it's time to get it in some direction. > To put it in a few questions: > > - What is our goal? XML2GUI, or nativeness on various platforms? (I.e.: If we > have another way to serve all platforms with native widgets, would we go > without XML?) > - What do we want to code, and what don't we want to code? > - How will we support plugins that want to add menu items and/ or buttons to > the aMSN GUI? (That appears to be the most overlooked thing) > - Do we want to implement de GUI module in Tcl or C/C++? > > Harry ok, this I started thinking about it earlier in your mail, but you go exactly to the point I wanted to say.... What is our goal ? nativeness on various platforms ? not even that! the goal was to stop people saying "why not QT ?" and "why not GTK?" .. and I think that maybe, if we choose one toolkit, which looks better than Tk, then people won't complain AT ALL... so I don't know.. the purpose was to please the users and stop receiving complaints... now it gives us two choices : 1 - use one toolkit and only one... 2 - wxwidgets which looks native to everyone 3 - many toolkits as many modules so everyone gets what he wants... more precisely, what I wanted to say is that our goal is indeed nativeness, NOT XML2GUI.. the whole XML2GUI was meant to be a solution to the nativeness, but the more I think about it, the more I see that it won't be such a full solution... maybe it can, but it will become a huge messy thing... I think that we should maybe develop a module that takes care of the GUI, using one toolkit, full, pure C code and that will only exchange 'ideas' with the Tcl core through events... If we want another toolkit, then it has to be rewritten as a new module... we 'could' start with a Tk-tile GUI module for those who want to keep Tk code... (Tk-tile has many nice themes, native in windows and native for qt with tile-qt theme, but no 'real' GTK+ support yet).. and I'm talking about directly using Tile, without any wrapping chameleon plugin or anything... the thing is that we can develop a module and any experienced user could work on another toolkit if they feel like it, the important thing is that it needs to be 100% modular, NOT mixed with anything else, not depending on anything, only EVENTS, no direct function calls, or else it will be a mess to create another GUI module... Now the cons of this, the big problem is that a 'new' GUI module will be specific, it won't look the same as another GUI module.. yes it's nice to be able to have the 'ok' button on the right on the win32 GUI module and not the left like the QT GUI module (just an example) so it looks and feels native... but what if a user says "hey, I can't create a custom away state, the option doesn't exist" answer "ohh, you have to use THIS other GUI module because it is more complete..." also, adding a new option/feature will require updating all the GUI module... KKRT > > > Phil > > > P.S. Philippe if the the code for DBus binding isn't on SVN is because we > > haven't any directory to put it... Organization of the repository is still > > in discussion > I propose to do the same as Sander did with libmsn. Commit it into a fresh > dir > in trunk, and we'll svn move it when the directory structure gets set up. > > > > > > > ------------------------------------------------------------------------- > > 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
