Op zondag 23 juli 2006 07:05, schreef Youness Alaoui: > Humm.. ok, and with all the critics we had so far because of Tk, I think > it would be better if we choose something that really is > gtk/qt/native... > You say nothing else does support multiple toolkits.. maybe you just > didn't find the product that does it yet... so searching a bit more > might give you the result you're looking for... > anyways, the original idea was to write it ourself, so i think if we can > define a specific structure for the XMLs and write our own > reader/interpreter.. then we can easily get a Tk toolkit, and then we > could add the gtk, qt, win32, etc.. toolkits... What is easier about Tk?
Also, I think we should not make one for TK at all, and just support the native toolkits of Mac OS X and Windows, and GTK and Qt on Linux. If we have that, all our users will be happy, so no need to waste our energy on a TK backend. I'd suggest we start with GTK, because that is available on all three operating systems, so we have the possibility to run on all three platforms as soon as possible, then we should finish Win32 and Mac native support before aMSN2 reaches Beta state, and Qt can follow then (would be nice to have it complete before releasing the actual aMSN2, but I don't think that is a requirement). > The specs for the XML should do whatever we want to do, but we could > refer to existing solutions, if we can find an existing xml2gui project, > even if it has only one toolkit supported, if all of its xml specs are > perfect for us, then we could do as I said before, but using the > existing solution it would save us one implementation... I 100% agree to that. > don't forget, this ain't gonna be done overnight, so don't be afraid > either by the amount of work needed, we can always go gradually.. > maybe we'll always have Tk toolkit and support only Tk (I would rather > choose tile directly than Tk + chameleon), and maybe in many years, add > gtk support, but at least, if someone asks for gtk, it won't be "WE > CAN'T DO IT", it will be "we can, we just don't feel like doing it right > now"... that's the whole point of the xml2gui project, to not be limited > by our implementation... Indeed, being independent of the toolkit is the aim. Maybe we should begin to define: - What is common among all toolkits (behavior/widget set)? - What common practice is there in use of each toolkit, and to what extend do these match across different toolkits? - And are there any conflicts between the common practice for one toolkit and another? If so, will there be a way to follow the common praktice on all of them, with 1 XML definition? I'll look around for existing projects of course, but I do not expect much from that, because usually you will find the biggest ones first, and those will usually be closer to meeting our wishes than the small ones. And until now all of them are specific to one toolkit, with XULRunner being in a special position because its XML format is not targetted at a single toolkit, and thus can be implemented using any toolkit, even though Mozilla developers apparently preferred to have their own toolkit that can mimic others. Harry > > KKRT > > On Fri, Jul 21, 2006 at 08:29:34PM +0200, Harry Vennik wrote: > > Op woensdag 19 juli 2006 21:58, schreef Harry Vennik: > > > > Yeah if you like XULRunner why not... I don't try to force using of > > > > TkHtml but I think (as it was said some months ago) that a multi-GUI > > > > soft would be great as you could use XULRunner and we could use > > > > TkHtml and with that we don't force user to use GTK or things like > > > > that... They can use other things... Phil > > > > > > That is a very nice intention, I even share that intention, but we must > > > have one thing that will render the GUI using any toolkit, and > > > XULRunner is the only one I found that has support for multiple > > > toolkits! > > > > Bad news: The multiple toolkit support turns out to be FAKED!!! Still > > better than nothing, but I think widgets should just be native (for Linux > > at least GTK, and supporting Qt would be nice too). So I think, based on > > this new fact, that we should reconsider if XULRunner will really be the > > right thing, although it is still the best existing solution (nothing > > else has multiple toolkit support, neither real nor faked). > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > > your opinions on IT & business topics through brief surveys -- and earn > > cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Amsn-devel mailing list > > Amsn-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/amsn-devel > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Amsn-devel mailing list > Amsn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amsn-devel ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
