Win32 Port of Safari

[Alan Gutierrez]

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