This is ABSOLUTELY NOT the place to be having this discussion. Ogsim uses Qt because that's how Nicolai wrote it. He wrote it, therefore he gets to say how it's written. If you want to rewrite what he did to use GTK or something else, go right ahead. That's what free software is all about. But in the mean time, I suggest you install Linux and Qt if you want to use it.
If you want argue with people about off-list, that is also up to you. But trying to convince someone to rewrite their program just for a minority of users isn't likely to be fruitful. Furthermore, we are going to be working on a way of splicing the model into Mesa and that should be toolkit-agnostic (since it doesn't require a UI, we can just use Xlib directly). On Thu, 3 Feb 2005 12:24:44 -0500, Cody Brocious <[EMAIL PROTECTED]> wrote: > I do agree that Qt is nice, but I don't think that it's neccesarily > the right tool for this, or at least it's not the _only_ right tool > for this. Ogsim is not a UI-heavy system. If the backend were to be > seperated entirely from the front-end in that we pass in what we would > to a video card and get the result back over a unix socket the > front-end could be designed in python and wxPython/pygame if we really > wanted, and I think that's what I may do. Qt is nice, but it's > definitely not the only thing capable of running this sort of > software, especially at the level it's at now. > > (Sorry about sending this directly to you, Nicolai, the first time. > Sometimes gmail does the recipient right, sometimes it doesn't. I'll > have to check by hand next time) > > > > On Thu, 3 Feb 2005 17:41:10 +0100, Nicolai Haehnle <[EMAIL PROTECTED]> > > wrote: > > > On Thursday 03 February 2005 16:56, Cody Brocious wrote: > > > > I've taken a look at ogsim and I'm quite impressed. The problem is, I > > > > don't use Qt (it doesn't like to build on my system for some reason). > > > > I'm wondering how hard it'd be to latch into the backend with a custom > > > > client written in something a bit more lightweight (perhaps even more > > > > portable, since Qt for win32 costs quite a bit) > > > > > > > > I don't want to do anything that might be construed as trying to take > > > > over your project, either, as I know how much it sucks when someone > > > > does that. > > > > > > > > If you have any input on this, I'd love to hear it. I'm out of school > > > > for quite a while due to getting my appendix out, so I've got nothing > > > > but time to work on stuff :P > > > > > > Well, Qt/KDE is the right tool for the job. We could get into a toolkit > > > war > > > here, but the fact is that I've written programs in all of the major C++ > > > GUI toolkits, and Qt really the only one I'd consider when licensing > > > issues > > > aren't a problem. Or, to put it another way: I really don't like writing > > > UI > > > code on a normal day. I *hate* writing UI code in toolkits that suck (i.e. > > > basically everything but Qt). > > > > > > Having said that, the simulator core, which consists of simulator.h, > > > simulator.cpp and render.inc as well as the Python script to generate the > > > register header are all very UI-agnostic. They do use Qt core classes for > > > threading. > > > > > > cu, > > > Nicolai > > > > > > > > > > > -- > ... And not to pull your halo down around your neck and tug you from > your cloud... > - Maynard James Keenan - A Perfect Circle- "The Noose" > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
