[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Mozilla NGLayout and KDE
From:       weis () stud ! uni-frankfurt ! de
Date:       1999-06-19 13:21:45
[Download RAW message or body]

Hi,

On Fri, 18 Jun 1999, Michael Reiher wrote:

> Hello guys,
> 
> Iīm back. And I think that I will have more time(well, in fact
> everything is
> more that none at all ;) for coding on KDE now again. First: You have
> done an
> amazing work in the last time!! Seems that I need to catch up with all
> the changes:)
> 
> As I had nothing better to do during the last weekend I took a closer
> look at
> the Mozilla layout engine(AKA NGLayout(NGL) or Gecko or Raptor) and
> played
> around with it. I tried to create a KDE wrapper around it, and mostly
> got it. But now I have the problem that it, even though it is supposed
> to be platform independent, relies on a GTK around it. And there I'm
> stuck currently. But hopefully this will change in the near future
> (Know what? GTK is sooooooooooooo ugly!! I love Qt/C++ :)) 
> 
> Anyway, I guess many people(including me ;) would be happy if Konqy
> would be able to use NGL for HTML viewing. 
> 
> But how to do it? I figured out basically four different ways:
> 
> 1. Include the NGL code into the KDE sources and make Konqy(or however
> needs it) link against it. AFAIK you changed the standard Konqy views to
> be somehow internal parts? If we do that with NGL it would probably be
> the fastest way. 
> 2. The other way would be to just create a standalone OP wrapper that
> also links directly against it and provide it together with NGL in a
> seperate package. Would be a bit more flexible(but also a bit slower) as
> we neednīt link a core KDE part against GTK (Eeerrkss!:) and ensure KDE
> to run on platforms where Mozilla doesnīt run or only
> insufficiently.(Linux is the only official Unix platform for it right
> now). Anyway whoever has GTK installed and is able to run Mozilla would
> still be able to use the advanced HTML widget.
> 
> But there are two big drawbacks with options 1 and 2. The first is that
> AFAIK you canīt link GPLed code against NPL. But Iīm a bit stupid when
> it comes to licences so I might be wrong. The other thing is that until
> thereīs no QT frontend for NGL weīd have to link KDE code against GTK(
> paying attention to the GTK event processing, threading(?) and such
> stuff).
> 
> Mozilla uses an own object model called XPCOM(itīs a COM derivate:).
> AFAIK itīs relatively lightweight and useable in GPLed code. At the
> moment itīs not easily possible to rip off XPCOM libs from Mozilla. But
> it shall be distributed along NGLayout when Mozilla is done or before.
> When using it also that GTK problem shouldnīt be an issue anymore as the
> code that contains the GTK stuff runs in another process(of course NGL
> itself would still need to link against it, but thatīs not our problem
> then). So two more options:
> 
> 3. Create an internal OP in Konqy thatīs a wrapper around the XPCOM
> stuff. Similar to 1.
> 4. Create a seperate OP thatīs a wrapper around the XPCOM stuff. Similar
> to 2. This is probably the slowest option, although I donīt know how
> slow it will be effectivly in the end. But itīs for sure the most
> flexible.
> 
> In both 3 and 4 it should be possible to use the NGL of an existing
> Mozilla. But we could also distribute a seperate package, e.g. to ensure
> that the user has a version that works nicely together with itīs current
> KDE. At least thatīs what I heard in the Mozilla news groups. 
> 
> My favourite would currently be 4. if itīs not tooooo slow. But if the
> licencing is a non issue and there is a QTFE someday, 2. would IMHO be
> better(because faster).
> 
> What do you think about that and which solution would you prefer?

No GTK at all is the only solution!

Bye
Torben

> Greets
> 
> Michael
> 
> -- 
> Michael Reiher  
>      Student at Dresden University of Technology
>           Department of Computer Science
>                email: michael.reiher@gmx.de
> 
> 

[prev in list] [next in list] [prev in thread] [next in thread]