On November 12, 2002 02:37 am, Ender wrote:
> Clause 3 of the LGPL would thus cause kdelibs to revert to the GPL, not
> the LGPL.
Yes, but if you remove the the code that forces the conversion to GPL,
you can use the remaining code as LGPL.
In other words, say you have:
-- Source A which is lic
Who am I to argue with you over KDE licensing? :)
But while I know TrollTech wouldn't do anything, technically I'm pretty
sure I'm correct.
The problem isn't linking a GPL'd program against an LGPL library (which
is fine for two reasons, in this case glibc is a 'system library', and
secondly the
> I was initially confused, because from TrollTech's website, KDE is
> illegal. It links QT, a GPL'ed library as far as TrollTech claim, against
> LGPL'ed libraries. Which is in violation of the GPL.
> [See: http://www.trolltech.com/developer/licensing/gpl.html]
>
> Basically, KDE and TrollTech are
> "socket", that allows other things to be plugged into it. The browser
> server then creates a window containing a KHTML control and reparents
> it. That way you'd avoid having to rewrite KHTML to use GDI, instead it
> can just use X11 directly. Or would that cause issues with Wine?
It'd cause is
> I've done it before, it's actually not that hard to write wrapper classes
> for most of the QT stuff. It's not the first time I've de-QT'ed an
> application. I'll probably base most of the work off the stuff done in
> Atheos, if we can resolve the licensing issue.
Good point, I'd forgotten atheo
> Unfortunately in KDE code Qt is used extensively, and I mean like
> everywhere. For instance Qt defines its own string classes. I don't know
> how much they are used, finding out would be easy enough, but you'd find
> it almost impossible to remove the Qt dependancies without having to go
> throu
> That's what the 1.0 branch of Mozilla is for. Stability in API.
True
> Plus it's available under the LGPL (although not all of it; should be
> checked almost an a file by file basis).
I've just got an email saying that the KDE libs might actually be under
the lgpl. It's something to check
On
Mike Hearn a écrit:
Esp startup time is to be considered, gecko requires initialization of
XPCOM and other stuff, also the biggest problem with gecko is that the
embedding interfaces tend to change with every major release of Mozilla.
As Moz is often kept quite up to date, that means Wine would co
> - BIG Con: The KDE libraries are GPLed. We can ask the team to perhaps
> allow us to use it under the LGPL. As far as I am aware, the
> only reason the libraries are under the GPL is because QT is
> under the GPL. Since one of the major factors in using
> KHTML/KJS in WINE will be removing the Q
I'll just add my specific reasoning (plus pro's and con's) for supporting
Konq, and some words on how IWebBrowser may be implemented:
- BIG Con: The KDE libraries are GPLed. We can ask the team to perhaps
allow us to use it under the LGPL. As far as I am aware, the
only reason the libraries are u
Well, I for one (though as i'm not writing the code this is just my
comments) would not be willing to choose a rendering engine based on
whether it works or not on platform X.
Both Mozilla and KHTML work quite well on a large number of platforms.
I'd need to know a lot more about why Mozilla does
Hi,
Please make sure you try whatever rendering engine you choose with a
wide sample of CHM pages. From what I remember of my Windows days, CHM
help often contains lots of IEisms, from VBScript to IE specific DHTML,
ie they're not standard HTML despite the name.
Whatever renderer is chosen then s
--- Thomas Wickline <[EMAIL PROTECTED]> wrote:
> Ender wrote:
>
> > >Well, a minimal Mozilla/Win32 installation is 6MB. How can you develop
> > >on Wine when you can't afford 6MB? I've just checked, and you need
> > >400MB to compile Wine...
> >
> >
> > Which is why I can't afford the space :)
> >
Ender, did you look at Microsoft patch to make a windows CHM compatible
?
This could be a good point to know if the functions we look for aren't
already implemented in wine.
--- Ender <[EMAIL PROTECTED]> a écrit : > Just so people don't double
up, I'll let everyone know I'm working on
> a CHM vie
On November 10, 2002 05:14 am, Ender wrote:
> Ugh, I don't want to start a browser war or anything, but my personal
> opinion is exactly the other way around. I detest Mozilla as a browser,
> and although it's rendering engine (eg, as used in Galeon) is okay, I find
> it annoying slow and unhelpful
> Well, a minimal Mozilla/Win32 installation is 6MB. How can you develop
> on Wine when you can't afford 6MB? I've just checked, and you need
> 400MB to compile Wine...
Which is why I can't afford the space :)
/dev/hdb1 10GB 9.1GB 415MB 96% /development
- Ender
Just so people don't double up, I'll let everyone know I'm working on a CHM viewer.
Although I still havn't worked out how I will do the actual HTML viewing,
my first priority is to actually build code to parse the file :)
I might even ponder implementing a simple IWebBrowser implementation based
Much as I'd love to say yes, I don't want to because it'll kind of
obligate me to do it.. and if I suddenly run out of time by something
stupid happening - say, like me getting a job - then I'd feel guilty.
.. that and Australian banks won't accept international personal cheques.
:)
- Ender
> >
Ender wrote:
>Well, a minimal Mozilla/Win32 installation is 6MB. How can you develop
>on Wine when you can't afford 6MB? I've just checked, and you need
>400MB to compile Wine...
Which is why I can't afford the space :)
/dev/hdb1 10GB 9.1GB 415MB 96% /development
- Ender
I
> On November 10, 2002 05:01 am, J.Brown (Ender/Amigo) wrote:
> > Which is why I can't afford the space :)
> >
> > /dev/hdb1 10GB 9.1GB 415MB 96% /development
>
> Oh, come on! :) You can't spare 6MB out of 415?!? It's <2%! :)
Yes, but remember, I need 400 of that 415 to compile WIN
On November 10, 2002 05:01 am, J.Brown (Ender/Amigo) wrote:
> Which is why I can't afford the space :)
>
> /dev/hdb1 10GB 9.1GB 415MB 96% /development
Oh, come on! :) You can't spare 6MB out of 415?!? It's <2%! :)
BTW, if you feel like reimplementing IWebBrowser, why not do
it so
> Well, a minimal Mozilla/Win32 installation is 6MB. How can you develop
> on Wine when you can't afford 6MB? I've just checked, and you need
> 400MB to compile Wine...
Which is why I can't afford the space :)
/dev/hdb1 10GB 9.1GB 415MB 96% /development
- Ender
On November 10, 2002 04:40 am, J.Brown (Ender/Amigo) wrote:
> Just so people don't double up, I'll let everyone know I'm working on a CHM viewer.
Way cool! Noted in the TODO.
> I might even ponder implementing a simple IWebBrowser implementation based
> off of Konq-Embedded/khtml, which would be
Just so people don't double up, I'll let everyone know I'm working on a CHM viewer.
Although I still havn't worked out how I will do the actual HTML viewing,
my first priority is to actually build code to parse the file :)
I might even ponder implementing a simple IWebBrowser implementation based
> This is certainly possible, and it should work, to some extent.
> The problem with it is that it's a complete deadend, that can
> not be massaged into the final solution.
agreed, but I don't call installing mozilla-Win32 on linux to have CHM
support a final solution either
> We know (correct me
On November 10, 2002 04:18 am, Eric Pouech wrote:
> agreed, but I don't call installing mozilla-Win32 on linux to have CHM
> support a final solution either
No, it's not. But it can be massaged in the right solution. That is,
we can start using IWebBrower all over the plave were we needed, we
enab
Alexandre Julliard a écrit :
>
> Eric Pouech <[EMAIL PROTECTED]> writes:
>
> > so do you prefer:
> > 1/ hacky 16 bit block, still Win9x compatible
> > 2/ DDE implementation, but incompatible with any native winhlp32/winhelp
>
> We definitely don't want 16-bit hacks in the messaging code, we shou
Eric Pouech <[EMAIL PROTECTED]> writes:
> so do you prefer:
> 1/ hacky 16 bit block, still Win9x compatible
> 2/ DDE implementation, but incompatible with any native winhlp32/winhelp
We definitely don't want 16-bit hacks in the messaging code, we should
try to do things as NT-like as possible. Ru
CHM is a special extension of IE.
The patch to make any windows compatible with CHM (except Win 3.1) is
downloadable at
http://www.microsoft.com/downloads/release.asp?ReleaseID=30328
To handle and generate CHM I found a french page (tools are in
english).
http://www.jurixt.com/informatique/hlp_co
On November 9, 2002 01:06 pm, Eric Pouech wrote:
> another way (absolutely not tested), would be to:
> 1/ extract html files (+images...) into a temp dir
> 2/ direct any browser to browse
This is certainly possible, and it should work, to some extent.
The problem with it is that it's a complete de
> I have this on my todo list. it would be possible to implement a wine
> specific message passing between WinHelp API and wine's builtin winhlp32
> however, it would be rather difficult to support all the ways windows
> handles this (it does it differently in Win9x, NT...), so support of
> native
> True, but it's a good start. Right now we have Nothing (TM). :)
another way (absolutely not tested), would be to:
1/ extract html files (+images...) into a temp dir
2/ direct any browser to browse (I have no idea whatsoever how links are
handled in chm, but it wouldn't be to hard to change... if
On November 8, 2002 03:01 pm, Eric Pouech wrote:
> yup, but I fear we'll discover more issues as far we go on (way too
> early to know, until we dig a bit more into it)
True, but it's a good start. Right now we have Nothing (TM). :)
> it also creates a dependency on Wine & Mozilla-win32. I don't
--- Eric Pouech <[EMAIL PROTECTED]> a écrit : > > The html viewer
is a problem, but according
> > to a recent thread, Mozilla-win32 runs just fine under Wine, and it
> > implements IWebBrowser & friends interfaces, which is exactly what
> we
> > need here, don't we?
> yup, but I fear we'll discove
On November 8, 2002 01:00 pm, Eric Pouech wrote:
> I have this on my todo list. it would be possible to implement a wine
> specific message passing between WinHelp API and wine's builtin winhlp32
> however, it would be rather difficult to support all the ways windows
> handles this (it does it diff
> The html viewer is a problem, but according
> to a recent thread, Mozilla-win32 runs just fine under Wine, and it
> implements IWebBrowser & friends interfaces, which is exactly what we
> need here, don't we?
yup, but I fear we'll discover more issues as far we go on (way too
early to know, until
Ender a écrit :
>
> WINE already comes with a very very basic WinHelp program, but it needs
> several large pieces of work done before it'd be useful:
>
> - Implementation of HLP95EN, or at least Dynalink support in
> HLPFILE_AddParagraph to call and process results from a native HLP95EN.dll
>
+
> From: Mike Hearn <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Wine Devel <[EMAIL PROTECTED]>
> Subject: Re: Help support
>
> I think the problem with that (last time I checked) was that nobody had
> completely reverse engineered the message protocol bet
> "Dimitrie" == Dimitrie O Paun <[EMAIL PROTECTED]> writes:
Dimitrie> Another on for the 0.9 TODO: -- launching Help from apps
Dimitrie> This does not work now, IIRC. It's rather 'simple', and
Dimitrie> visible from the user POV, so needs fixing IMO.
Supporting native winhlp32 in
I think the problem with that (last time I checked) was that nobody had
completely reverse engineered the message protocol between the WinHelp
api calls and the winhelp app. I think there is an exchange of
undocumented messages, but this is just going from what I've read on
bugzilla and the lists.
Another on for the 0.9 TODO:
-- launching Help from apps
This does not work now, IIRC. It's rather 'simple', and visible
from the user POV, so needs fixing IMO.
--
Dimi.
41 matches
Mail list logo
