> > > 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. > 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
