> Correction, it seems despite first appearances the project was never
> born. Its CVS tree is empty. Suckage.
>
> Rereading Enders email I can't quite decide if he stubbed Qt out in
> order to get it running on Win32 or not if we were to track KHTML
> CVS, stubs would be the only solution, but
> Mozilla is going to be the way to go if Demi can get the gecko to build
> and work as a WINElib app now that it can be built with Mingw. Once that
> is done we will know what needs to be fixed in WINE to support it as
> either a elf or PE binary. Plus it will save us on the ReactOS side some
> wo
> Date: Wed, 28 May 2003 14:46:36 -0700
> From: Paul McNett <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Wine folks interested in a CHM spec?
>
> Mike Hearn writes:
>
> > > Anyway, that's all rather off-topic... we can already build a CHM
>
Quoting Paul McNett :
"Yes, even if its just plain-text for the time being, any CHM viewer is
better than no CHM viewer."
We have some "NYI" in Wine code, no problem with that.
> The problem with that approach is that many CHM files rely on some
> IE-only extensions and/or quirks. Gecko seems t
Mike Hearn writes:
> > Anyway, that's all rather off-topic... we can already build a CHM
> > viewer, it's displaying the HTML/JS that's the problem :)
>
> Good to know you're still around! Simply getting a super-basic
> WebBrowser implementation up and running, in Wine, no matter how it's
> built/
Le mer 28/05/2003 à 16:30, Steven Edwards a écrit :
> > b) it'd be based on either khtml or mozilla. not starting a new
> > rendering engine.
>
> Mozilla is going to be the way to go if Demi can get the gecko to build and work as
> a WINElib app
> now that it can be built with Mingw. Once that is
> b) it'd be based on either khtml or mozilla. not starting a new
> rendering engine.
Mozilla is going to be the way to go if Demi can get the gecko to build and work as a
WINElib app
now that it can be built with Mingw. Once that is done we will know what needs to be
fixed in WINE
to support it
> And yeah, that would be sadly true if we start yet another browser
> project, when we already have Mozilla and KHTML... :/
It's hardly a new browser project.
a) It wouldn't be about developing a browser. Who gives a monkeys about
browseui, favourites etc. We only care about the rendering engine
On Wed, 28 May 2003, Shachar Shemesh wrote:
> Oh no - you open software developers are off your head! Next thing you
And yeah, that would be sadly true if we start yet another browser
project, when we already have Mozilla and KHTML... :/
--
Dimi.
Mike Hearn wrote:
Anyway, as to maintainership, this is a good question. But how comes
adding a clone of IE is nuts, but the rest of Wine is sane, hmm? :) This
whole thing is completely crazy to some extent, but here we are in 2003
with two companies working on Wine and many volunteers it woul
Mike Hearn wrote:
Unfortunately, it seems KWQ is mostly MacOS specific. It's written in
Objective C++, a language I didn't even suspect the existance of until I
read the sources. Example:
...
As if C++ wasn't hard enough to read already!
On a 100% unrelated note, and since this list does no
On 28 May 2003, Mike Hearn wrote:
> Rereading Enders email I can't quite decide if he stubbed Qt out in
> order to get it running on Win32 or not if we were to track KHTML
> CVS, stubs would be the only solution, but as it might need to be forked
On 28 May 2003, Mike Hearn wrote:
> Unfortunately, it seems KWQ is mostly MacOS specific. It's written in
> Objective C++, a language I didn't even suspect the existance of until I
> read the sources. Example:
>
> QListBox::~QListBox()
> {
> NSTableView *tableView = [(NSScrollView *)getView()
On 28 May 2003, Mike Hearn wrote:
> Running through 3 translation layers is going to suck though.
>
> KHTML -> KWQ -> Wine -> Linux
I don't think it's all that bad. Currently we have:
KHTML -> WebCore -> Cocoa
or
KHTML -> QT -> Linux
I don't think KWQ will add much overhead, it's going t
The AtheOS guy de Qt ised KTHML a while back:
http://www.atheos.cx/news.php3 search for KHTML. I can't find the source at
the moment though. This is probably already widley out of date.
I agree with Dimi however that stubbs are gonna be the way to go however,
maintaining a port isn't going to
> You guys are nuts! :) Who is going to maintain all this. This is a
> *large* project. Look at Mozilla for crying out loud, a full blown
> HTML/JS/etc. engine will easily double the size/scope of Wine.
(broken my promise already :)
I only said fork cos I don't think the KHTML team would accept
> Any current efforts to port WebCore to Win32? Or it's maybe easier
> to create a WinCode? BTW, any idea how big this effort is?
In a minute I'll get on with some work and stop spamming everyone. One
last thing, the WebCore framework isn't what we're interested in, we
want KWQ (pronounced quack a
> The project seems to have died around jan/feb of this year,
Correction, it seems despite first appearances the project was never
born. Its CVS tree is empty. Suckage.
Rereading Enders email I can't quite decide if he stubbed Qt out in
order to get it running on Win32 or not if we were to tr
> Any current efforts to port WebCore to Win32? Or it's maybe easier
> to create a WinCode? BTW, any idea how big this effort is?
Use Google power dimi! First hit for "khtml win32":
http://khtml-win32.sourceforge.net/
The project seems to have died around jan/feb of this year, but I think
he got
On 28 May 2003, Mike Hearn wrote:
> > Isn't the eventual goal of WebCore to de-QTfy them? QT is a show
> > stopper due to licensing
>
> WebCore is a set of Qt stubs as far as I know, which map Qt onto the
> MacOS APIs. It's like Wine, but for Qt.
Any current efforts to port WebCore to Win32? Or
> Isn't the eventual goal of WebCore to de-QTfy them? QT is a show
> stopper due to licensing
WebCore is a set of Qt stubs as far as I know, which map Qt onto the
MacOS APIs. It's like Wine, but for Qt.
> I haven't followed this lately, but I
> thought WebCode will eventually get rid of QT, an
On May 28, 2003 06:56 am, Ender wrote:
> However KHTML and KJS -are- tied to the QT library. It's quite possible to
> decouple them (the embedded konq suite already does this to some extent,
> as does WebCore from Apple's Safari project)... however it is somewhat
> time consuming. Using WebCore can
On Wed, 2003-05-28 at 11:56, Ender wrote:
> I've already written the major chuck of a CHM viewer - to the point I have
> a native Windows viewer using nothing but the WebBrowser ActiveX control.
This would be a good thing to submit anyway. It's been possible (though
not easy) to install IE into Wi
http://www.quakesrc.org/ | our distribution should be ignored with
http://www.enderboi.com/ | extreme prejudice" - [EMAIL PROTECTED]
On Wed, 28 May 2003, Pabs3 wrote:
> Date: Wed, 28 May 2003 03:07:52 -0400
> From: Pabs3 <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
>
Hi wine peeps,
Just wondering if Wine folks are implementing a chm viewer and if you would be
interested in a specification on the internal files of CHMs and even
relicencing some of the code for my chm decompiler.
all at http://bonedaddy.net/pabs3/hhm/
BTW; please cc me in replies since, whil
25 matches
Mail list logo
