Ok I see... Please consider what was said in the previous ML thread (I think the thread was named 'gtk/tk/qt' or something like that, you'll find it in the archives of the ML. the 'id' idea thing was already said in the thread, but as 'name', and yes, not mandatory.. in the thread, there isn't a complete design, but there a lot of ideas, a lot of discussion on different possibilities and problems that might happen, as well as possible solutions to them, you'll also find some xml code as example... it is far from being a design, but it could be considered a design by some people. at least, it's a good starting point to help you get all the facts before building the final design to use... Good luck!
KKRT On Thu, 08 Jun 2006 15:09:33 -0400, Harry Vennik <[EMAIL PROTECTED]> wrote: > Which design? None yet! Just a set of ideas that I should become a design > soon. When it gets a bit more clear, I will publish it on the wiki, and > send > an email so everyone knows it is there. > > Of course I considered that the widgets need to be accessible. Especially > event bindings are important. But getting and setting properties at > runtime > is also needed. This is very simple however: any widget that is assinged > a > name (xml:id) will be accessible by that name through the API. (It will > however not be mandatory to assign an xml:id to every widget. Frames for > example may not need to be accessible from code). > > About glade: glade2tk will not be easy, because glade it completely > fine-tuned > for use with Gtk. In fact, it is just a one-to-one mapping of the Gtk > widget > classes to XML, which is not so strange, because glade is originally > designed > as the data storage format for a Gtk based GUI design tool. > > To the contrary of that, XUL is designed as a portable way to describe > the > layout of a GUI. However, unfortunately it depends completely on > JavaScript > for anything else, so it's not usable for us. > > With those 2 being the best I could find, I think we'd be best off if we > just > build what we and probably a lot of others can use, taking the good > points in > existing technologies as examples of how to do it. > > Harry > > > Op donderdag 8 juni 2006 16:31, schreef Youness Alaoui: >> Yes, anything that uses xml to create a GUI should be considered, not >> only >> the Tk alternatives... if glade is 'perfect' for our needs, then create >> a >> glade2tk implementation, so we could use the glade2gtk for gtk, it makes >> it for a lot less of work and we'll have something already ready for the >> GUI. >> I don't know though if it fits our needs... iirc I talked about naming >> each widget with a custom name and reference it somehow with an API, as >> well as having proc names in the xml... r u considering that ? which >> design do you have ? >> >> KaKaRoTo >> >> On Thu, 08 Jun 2006 09:55:44 -0400, Max <[EMAIL PROTECTED]> wrote: >> > I don't really know if it worth the look but the xml files glade2 >> > generates >> > (.glade) could be a start for the xml's format rules of xml2gui... >> > >> > On 6/8/06, NoWhereMan <[EMAIL PROTECTED]> wrote: >> >> ----- Original Message ----- >> >> From: "Harry Vennik" <[EMAIL PROTECTED]> >> >> To: "Mailing list for developers and everyone helping AMSN" >> >> <amsn-devel@lists.sourceforge.net> >> >> Sent: Tuesday, June 06, 2006 10:49 PM >> >> Subject: Re: [Amsn-devel] XML2GUI (was: aMSN2 and Telepathy) >> >> [...] >> >> >> >> > Also I looked at some not Tcl-related implementations, but they're >> >> >> >> simply >> >> >> >> > not >> >> > the way I'd like it. In fact, XUL gets most close on syntax, Glade >> >> >> >> gets >> >> >> >> > close >> >> > in implementation/API. >> >> > I am trying to make a nice crossing between the two, as well as >> adding >> >> > some of >> >> > my own ideas. If it will work the way I think of now, the code >> needed >> >> >> >> to >> >> >> >> > do >> >> > this won't be so much. Most will be done using existing libraries >> >> >> >> (e.g. >> >> >> >> > GLib, >> >> > Gtk, libxml). >> >> >> >> Sounds cool :) >> >> I'm looking forward it :) >> >> >> >> >> >> >> >> _______________________________________________ >> >> Amsn-devel mailing list >> >> Amsn-devel@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/amsn-devel > > > _______________________________________________ > Amsn-devel mailing list > Amsn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amsn-devel -- KaKaRoTo _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
