Vadim Plessky wrote: > On Friday 10 January 2003 03:26, Andreas Dieling wrote: >> Using a toolkit, for now, may make development faster. In the end, if the >> controls are few and simple, I might move towards programming directly to >> the GDI for the sake of performance. Since KHTML already runS on Mac and >> Unix, and extra portability layer will be unnecessary. > > Its faster to use mfc then to hack win32-api. Or are there .NET bindings for > c++ and visual studio6 ? Since .NET will replace win32 in the future, and i > think it bids more intuitive object orientation than mfc. > > I don't think you should buy idea of .NET from MS, at least for now and for > the next 3 years or so. While I run Linux/KDE almost exclusively, I still > have Windows partition for games (Heroes of MM, Diablo II, and some other > relaxation stuff). And that Windows is Win 98, not Win NT / Win 2000 or > latest-greatest Win XP. Reviewing statistics for web vistors on major > sites, I see that Win95/98 platform still dominates. > > Final point: it's better to hack using win32 and do not count .Net stuff > seriously in nearest future. No way do I use Not Yet. If I am going to do this it might as well work on all Win9x systems. The MFC is an MDI application framework. It is inappropriate for this endevour. It uses native GDI window objects for controls. It will not be to position elements over MFC edit controls. My recolletion of is MFC is that it mirrors the GDI almost exactly, except that it wraps the GDI handles in C++ classes. An MFC function is just a GDI function with one less argument. It doesn't buy much. The only reason I thought about toolkits is because Kwq is right on top of NextStep. I was jelous. I doesn't make sense though for reasons that are as obvious to me now (after two days with the code) as they are to all of you. I'll use the GDI to draw any controls not already drawn by the rendering logic in KHTML. There are only seven of them anyway (radio, checkbox, textbox, list box, scrollbar, button). Any toolkit that I use will limit by ability to properly apply CSS. This is off the top of my head. I'd rather we postpone discussion of graphics until we resolve the VC++ vs GCC compiler differences, which is where I am going to spend my free programming time this weekend. I'd like to have us all agree on how far (not far) we are willing to go to accomodate VC++. Thank you Mr Plessky for your arguments against toolkits. They will be unecessary, I agree. Alan Gutierrez