Le Saturday 19 August 2006 23:24, Harry Vennik a écrit : > > > > 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... > > > > Euh.... Why don't you like XML2GUI ? We could create some templates > > supported by GUI modules (ie one template with an OK and a Cancel button, > > one with only a OK button) and add our widgets in a frame in the center > > of the window... This way, if you want to create a new window, no need to > > upgrade GUI modules... > > It is not about liking XML2GUI or not, it is about: what is the important > thing. I raised the question because I felt that over time XML2GUI has > become the goal, instead of a way to realize a goal. And that is not to get > rid of the XML2GUI idea. We may still decide to do it, but it should get > back to the proper place in the overall picture. > > But anway, I think you are wrong in saying 'This way, if you want to create > a new window, no need to upgrade GUI modules.' They will need to be updated > to include a command to show the new window, as well as to handle events > from the window when it is shown. No ! You don't see what I mean... The GUI module will export a function CreateWindow(string XMLdata) and when an event will occur it will do a Tcl_exec(fireevent, theevent) So when we will want to create a new window we will simply create a new XML data with all widgets we want described in it... Phil
> > > Hum, I just thought about something : each window has a name and a class > > and if a GUI module wants to modify some widgets properties it could > > detect this name and/or this class and act in consequence like inverting > > two buttons etc... > > By the way I agree totally to the fact that we need to throw events to > > not call directly the core... > > Wait a minute... > > Should the core handle GUI events? - No! > Should the GUI layer handle events from the core? - Yes! > > So: > The core fires an event -> the GUI uses the data passed with the event to > update the visible data. > The user does something that requires action from the core -> in response > to the GUI event triggered by the user's action, the GUI module calls a > method in the core (which is a call to another context, that will need one > extra command in the runtime...) > > Why? Because: > - Events are fired if something has happened > - Method calls tell that something should happen > > Please note that this also make the code better maintainable. A module must > not depend on an event to be handled a certain way, but a module may depend > on a method call to cause a particular action. Of course the calling of > methods must be limited to a set of API methods, not just any proc. This > can easily be enforced by requiring that procs be declared global some way > to make them callable from other modules. > > > Phil > > ------------------------------------------------------------------------- > 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
