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, while i'm subscribed i don't want to get heaps of other wine discussion & so i've turned off mail delivery. Bye, Pabs ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
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. The secondary problem is how to display the HTML + JavaScript needed for a CHM viewer. I've started work on this several times, and so far the *best* (in terms of existing compatability with IE's CSS/JS/HTML 'features') has been KJs and KHtml from the KDE project. Gecko doesn't cut it - it's quite slow, bulky and worst of all too strict on standards compliance. Nothing you want in a Windows system component. Well, not the last one anyway :) 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 probably greatly speed this up of course. I ran into two other problems. First, I have gotten a Windows-native KHTML/KJS viewer running - however splitting it into an API mapping to the existing dll structure is complicated... and I know next to nothing about writing ActiveX objects. The second is that I never could get an answer from Alexandre as to adding C++ code to WINE itself. It would be possible to write it as a seperate non-core implementation, but many of these DLLs also have non-browser related APIs that need to be in WINE itself. Again, diverting api calls between the versions in WINE and our browser versions is complicated and in this case plain ugly. Anyway, that's all rather off-topic... we can already build a CHM viewer, it's displaying the HTML/JS that's the problem :) - Ender http://www.scummvm.org/ | "Amen! Attempts to eradicate humour from http://www.quakesrc.org/ | our distribution should be ignored with http://www.enderboi.com/ | extreme prejudice" - cjwatson(a)debian.org On Wed, 28 May 2003, Pabs3 wrote:
Date: Wed, 28 May 2003 03:07:52 -0400 From: Pabs3 <pabs3(a)bonedaddy.net> To: wine-devel(a)winehq.com Subject: Wine folks interested in a CHM spec?
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, while i'm subscribed i don't want to get heaps of other wine discussion & so i've turned off mail delivery.
Bye, Pabs
------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
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 Wine for some time now. If this is all it takes to get CHM support up and running then this is cool - we don't want to block CHM help on needing a webbrowser control.
The secondary problem is how to display the HTML + JavaScript needed for a CHM viewer. I've started work on this several times, and so far the *best* (in terms of existing compatability with IE's CSS/JS/HTML 'features') has been KJs and KHtml from the KDE project.
Gecko doesn't cut it - it's quite slow, bulky and worst of all too strict on standards compliance. Nothing you want in a Windows system component. Well, not the last one anyway :)
I've been reconsidering this lately. Originally I argued for KHTML, for the above reasons. They are still valid, but we overlooked the issue of editing support. My recent work with IE in Java (where IE is used as an embedded html-enabled word processor) has made me realise that this feature is used a lot in corporate scenarios. You'd be surprised at the number of IE-specific web apps that utilise the contentEditable feature of the rendering engine. KHTML simply does not support this as far as I know, and I have no idea how easy it'd be to make it support it. Gecko does. This is a significant + in favour of Gecko. On the other hand, I'm not doing the work, and forking KHTML is probably easier than Gecko. Adding editing support to KHTML would be quite a bit of work, but still maybe less over all.
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 probably greatly speed this up of course.
I ran into two other problems. First, I have gotten a Windows-native KHTML/KJS viewer running - however splitting it into an API mapping to the existing dll structure is complicated... and I know next to nothing about writing ActiveX objects.
Simply getting KHTML/KJS working under Win32 is a great start. Are the patches for this available anywhere online?
The second is that I never could get an answer from Alexandre as to adding C++ code to WINE itself. It would be possible to write it as a seperate non-core implementation, but many of these DLLs also have non-browser related APIs that need to be in WINE itself. Again, diverting api calls between the versions in WINE and our browser versions is complicated and in this case plain ugly.
I think if it was a choice between accepting C++ into the tree, and not having a large set of crucial APIs in Wine, AJ would accept C++. But I don't speak for him. For some of the DLLs/objects that IE provides I guess C could be used, that isn't really a problem, IE provides a load of stuff that pure KHTML/KJS doesn't and that would probably be provided by core Wine in C. If it comes down to it, a WineTrident installer that is tested against and known to work with Wine would be possible. It'd be highly annoying for users to install it separately, but that's something good packaging can take care of.
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/installed would be a good first step. Writing COM objects in C is a PITA but not all that hard, although if I remember correctly ActiveX controls have to implement about a gazillion interfaces which could get painful. Anyway, I think Wine supports COM objects written in C++, it's in the documentation somewhere. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
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/installed would be a good first step.
Yes, even if its just plain-text for the time being, any CHM viewer is better than no CHM viewer. -- Paul McNett
I'll try and remember to dig up the source and post it somewhere. But regardless, most helpfiles that people actually -need- to read do use htmlhelp elements that require CSS/JS to actually navigate. *wanders off to reply to other e-mails, and curses himself for starting a thread just before bed last night :) - Ender http://www.scummvm.org/ | "Amen! Attempts to eradicate humour from http://www.quakesrc.org/ | our distribution should be ignored with http://www.enderboi.com/ | extreme prejudice" - cjwatson(a)debian.org On Wed, 28 May 2003, Paul McNett wrote:
Date: Wed, 28 May 2003 14:46:36 -0700 From: Paul McNett <p(a)ulmcnett.com> To: wine-devel(a)winehq.com 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 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/installed would be a good first step.
Yes, even if its just plain-text for the time being, any CHM viewer is better than no CHM viewer.
-- Paul McNett
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 probably greatly speed this up of course.
Isn't the eventual goal of WebCore to de-QTfy them? QT is a show stopper due to licensing. I haven't followed this lately, but I thought WebCode will eventually get rid of QT, and that work will find it's way into the mainline, no? -- Dimi.
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, and that work will find it's way into the mainline, no?
I seriously doubt that. You know the KDE guys as well as I do - they love Qt, and insist on using it for everything. Having Qt removed from the mainline KHTML/KJS will probably never happen, so building stubs is a rather lame, but unfortunately required prerequisite to using it. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
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 it's maybe easier to create a WinCode? BTW, any idea how big this effort is? -- Dimi.
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 most of the classes ported. I emailed the guy a few months ago about it, can't quite remember the details of the exchange, but I think he basically ran out of time/motivation. Running through 3 translation layers is going to suck though. KHTML -> KWQ -> Wine -> Linux Bearing in mind KWQ would have to provide a pthreads wrapper around win32, then have win32 mapped back onto pthreads - ouch! -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
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 track KHTML CVS, stubs would be the only solution, but as it might need to be forked anyway actually de-Qt'ing is another possibility. Ender, could you give more details about how you got it running on win32? -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
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 ^^^^^^ 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.
Stubbing is the only solution IMO. BTW, I knew about that project, I email with the guy a bit, he didn't seem to understand some things, even though I tried hard to explain. Like for example he wanted to implement everything (controls, etc.) on top of GDI because the standard controls are bloated and slow... Heh! I gave up. Obviously, with that approach I didn't expect him to get too far. -- Dimi.
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 <sigh> :) I only said fork cos I don't think the KHTML team would accept bug-for-bug compatability patches with IE. I guess they might, they seem more liberal about it than the Gecko team (wrongly imho, but useful here). 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 would probably require a D3D style dedicated team to work on it though, which so far doesn't exist. And I don't think a web engine would be double the size/scope of Wine, that's exagguration. Wine by definition has a massive scope.... there's no denying that IE is a part of the APIs now, too many apps rely on it being there. Maybe when Red Hat try and sell to the corporate desktop and run into this problem they will help.... wishful thinking perhaps.
Stubbing is the only solution IMO.
Sure, it's either that or rewrite KHTML. And I think geckos code is too big to use :(
BTW, I knew about that project, I email with the guy a bit, he didn't seem to understand some things, even though I tried hard to explain. Like for example he wanted to implement everything (controls, etc.) on top of GDI because the standard controls are bloated and slow... Heh! I gave up. Obviously, with that approach I didn't expect him to get too far.
Hmm. Double suck. I guess we're back to square one then. Unless Ender has done a lot more work than we are imagining. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
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 would probably require a D3D style dedicated team to work on it though, which so far doesn't exist.
Oh no - you open software developers are off your head! Next thing you will be developing a .NET replacement! Wait, you are. Hmm, nobody will be crazy enough to work on an entire GUI shell, though. Two you said? Not including the small ones? Not a modern OS, though. HOW many? Surely none is enterprise ready! What precentage of web servers? PEOPLE! GET A LIFE!!!! Good thing I'm not part of it. What do you mean by "grep wine/AUTHORS"? AAAAAARRRRRGGGGGHHHHH!!!!!!!! P.S. Yes, I spent the day working on a perl util to convert an MSSQL DB to postgres for a client (yes, I'm getting paid to do this, at least, I hope does anybody happen to know something that does that already?). I think expecting any USEFUL mails from me would be a total waste of time. Sorry for the OT posts. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
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, and then only because there's a buttload of proprietary code out there that relies on bizarre quicks and "features" of mshtml in order to operate. b) it'd be based on either khtml or mozilla. not starting a new rendering engine. c) we have little choice. Well, that's slightly melodramatic, obviously nobody has to work on it. But sooner or later somebody will find they need it. Probably lots of people.
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 as either a elf or PE binary. Plus it will save us on the ReactOS side some work when we go to do a explorer/browser clone. =) Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
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 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 work when we go to do a explorer/browser clone. =)
The problem with that approach is that many CHM files rely on some IE-only extensions and/or quirks. Gecko seems to be too much standards-compliant to be very useful in this form, at least without some heavy modifications to the rendering engine. Vincent
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 to be too much standards-compliant to be very useful in this form, at least without some heavy modifications to the rendering engine.
Vincent
===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
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 work when we go to do a explorer/browser clone. =)
Well, anything is a start... but IMHO whilst Mozilla is a fair browser, and Gecko is a fair rendering engine... neither of them are up to coping with the stress of providing IE-compatible integration. Also upstream tracking of Gecko would be very much impossible, and there is ZERO chance that IE'isms would ever make it into upstream anyway... KHTML has a far better chance in that respect :) Also Geckos JavaScript engine is very so-so with a lot of the MS-formatted JS I've tried feeding it :( - Ender
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 as it might need to be forked anyway actually de-Qt'ing is another possibility.
Ender, could you give more details about how you got it running on win32?
Well, if you look back through wine-devel's archives when this last came up, I had a KHTML running natively without stubbing (much, there were a few for simple heavily used classes like QString). We had this very same discussion then too, that we really need to stub in order to keep track of upstream. I started writing a wrapper, but then Safari was released and people were talking about porting WebCore to Win32. I paused my work about then, firstly because of the C++ in CVS issue (writing stubs and wrappers is fairly easy but tedious, and if none of the work could go into CVS anyway..)... But also because I was being lazy and hoping that the WebCore port would get to point I could at least use it as a base. Obviously that never happened :( - Ender http://www.scummvm.org/ | Where am I going... http://www.quakesrc.org/ | ...and why am I in a handbasket? http://www.enderboi.com/ |
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 to be essentially: KHTML -> Wine -> Linux And I don't think QT/X11 is all that much faster than Wine.
Bearing in mind KWQ would have to provide a pthreads wrapper around win32, then have win32 mapped back onto pthreads - ouch!
But we do integrate with pthreads right now, it should just work, no? -- Dimi.
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 apparently) which is what maps Qt -> MacOS. 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() documentView]; [tableView setDelegate:nil]; [tableView setDataSource:nil]; [_items release]; } As if C++ wasn't hard enough to read already! KWQ consists of 296 files, might as well call it 300. These cover a part of the Qt classes and also the KDE ones. Quite a few are simply stubs: int QXmlParseException::lineNumber() const { ERROR("not yet implemented"); return 0; } Luckily, most of the files are small, in fact some are about 2-3k, of which most is the boilerplate header (seems to be a pretty liberal license). Some parts, like KWKQURL (i kid you not, that is the name of the class) look pretty reusable. Other parts are heavily reliant upon the NeXTStep APIs. Basically porting it to Win32 would be a major piece of work. KWQ itself is a large effort. I'm not sure why Apple didn't simply license Qt for its developers, then bind it into Objective-C in the traditional way. That would surely have been simpler than duplicating all this code from Qt. Perhaps the idea that the cost of Qt is insignificant next to developer time, as espoused lately by some KDE devs, is flawed? Or maybe it was needed to get good bindings into their Cocoa framework (sounds unlikely but possible). Anyway. I'm guessing that porting this would be the first step, if KHTML was used. thanks -mike (goes back to work) -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
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() documentView]; [tableView setDelegate:nil]; [tableView setDataSource:nil]; [_items release]; }
Gee! I've heard about it before, people saying is so much easier than C++. Yeah, right!
Luckily, most of the files are small, in fact some are about 2-3k, of which most is the boilerplate header (seems to be a pretty liberal license).
Important point is if it's compatible with the LGPL. Can we use stuff from it in Wine? -- Dimi.
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 be much fun. Having said that KHTML/KJs is a lot neater/smaller code than mozilla/gecko. Mark (goes to have his hair cut)
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 not have LKML's faschist charter, I'll go really OT and mention that Objective-C was developed parallel to C++, so any attempts to claim that it was redundant are a little hind-site oriented. Major IIRC disclaimer here, of course. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
participants (13)
-
Dimitrie O. Paun -
Dimitrie O. Paun -
Ender -
Mark Westcott -
Mike Hearn -
Mike Hearn -
Pabs3 -
Paul McNett -
Shachar Shemesh -
Steven Edwards -
Sylvain Petreolle -
Vincent Béron -
winedev＠admdev.com