In article <3DCAE940.28777.424D5A@localhost>, Tim Wegner <twegner@swbell.net> writes:
c. Separate the GUI from the underlying engine as Rich suggested a long time ago. But beware, some features, such as orbits and inverse julia windows, assume a frame buffer and will take some creative disentangling.
I haven't looked at the code for a long time, but IIRC, these "assumptions" are still layered through things like setpixel and getpixel. There are ways to hide the details of a "no frame buffer imeplementation" behind these functions.
d. Separate GUI projects could be done on different platforms. Maybe this could be merged in with manpwin on Windows. Or ...
d'. Make a portable GUI using WxWindows. Then we could target many platforms with ONE source base. I am not opposed to option d., but I personally prefer d'. I am personally willing (even enthusiastic) about learning ONE GUI development environment, so without knowing anything about it, I prefer WxWindows. :-)
OK, my philosophy on this is... while the idea of "one GUI from one source base" sounds great, in practice it ends up being a least common denominator GUI between all the platforms. The programs I've seen with this approach have a GUI that has quirks on every platform and the GUI never "feels" native. It always feels foreign. I haven't looked at WxWindows, but I don't know that this holy grail approach to GUI design results in a great GUI on every platform. The layer I created could work either way. Put another way, if MS has abandoned the idea of writing a single GUI between Mac and Windows for things like Excel, and they have -many- more programmers and programmer hours available for their projects, why do we think it would work for us, with few programmers and few available hours for each programmer? With the proper layer separating GUI from application code, there is no need to try and shoehorn every platform into a single GUI source base. Each platform can have the GUI that works best for it -- on the Mac this means Toolbox, on Windows this means Win32 (and maybe even MFC), on X11 this means Motif, and on DOS it probably means Allegro with a 32-bit extender. I also know its tempting to believe that you can learn one API for GUIs and remain ignorant of the platform. I've worked on projects where this was done (and again, we got a lowest common denominator GUI and the GUI never felt "natural" on any of the platforms). The end result is that remaining ignorant of the platform isn't a useful skill, IMO. It also means that people who -are- experts at coding GUIs on all the various platforms are alienated from your source base because they have to go learn this other layer that just gets in the way of what they already know. I know that if fractint gets ported to "WxWindows", the end result is that I'll probably never work on improving the Windows GUI or the X11 GUI in fractint. Learning WxWindows would be a dead-end for me; it has no market payoff and with my limited amount of time available for fractint coding, I would probably put the effort in elsewhere. -- Ask me about my upcoming book on Direct3D from Addison-Wesley! Direct3D Book <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>