Hi. Please consider this mail as: Re: Built-in iexplore Re: acad 2004 licence file bug Re: Broken FC5 packages - stay clear. Last week Wine Gecko was mentioned a few times on this mailing list and I can see that there is no understanding of it. It's not really surprising as it's a big mess ATM. We can still use Mozilla ActiveX control (but that needs to be removed) or (xor) directly Gecko. Sometimes (if the app uses HTMLDocument directly, not via WebBrowser, like iexplore does) only the second option works. That has led me to do what I am planning to do later. I've just sent Wine Gecko installer. After it will be committed, a system similar to Mozilla ActiveX control download will have to be set up (that is upload the package to SourceForge and add a script that directs download of it). That will allow us to get rid of Mozilla ActiveX control. Thanks, Jacek
On 6/14/06, Jacek Caban <jacek(a)codeweavers.com> wrote:
Last week Wine Gecko was mentioned a few times on this mailing list and I can see that there is no understanding of it. It's not really surprising as it's a big mess ATM. We can still use Mozilla ActiveX control (but that needs to be removed) or (xor) directly Gecko.
Directly how? I am still confused, sorry. By "Gecko" do you mean: - A win32 copy of Gecko/GRE/XRE installed in ~/.wine/drive_c? - A native Linux copy of Gecko installed as part of, say, the distributions Firefox? - Something else? thanks -mike
Mike Hearn wrote:
On 6/14/06, Jacek Caban <jacek(a)codeweavers.com> wrote:
Last week Wine Gecko was mentioned a few times on this mailing list and I can see that there is no understanding of it. It's not really surprising as it's a big mess ATM. We can still use Mozilla ActiveX control (but that needs to be removed) or (xor) directly Gecko.
Directly how? I am still confused, sorry. By "Gecko" do you mean:
- A win32 copy of Gecko/GRE/XRE installed in ~/.wine/drive_c? - A native Linux copy of Gecko installed as part of, say, the distributions Firefox? - Something else? See http://www.winehq.org/?issue=285#MSHTML%20Update. I'd really like to use Linux Gecko, but it's impossible because we'd need XEmbed embedder support that's impossible to implement in Wine (perhaps if we added what we need to XEmbed spec?). That's why MSHTML uses Windows Gecko.
Jacek
On 6/14/06, Jacek Caban <jacek(a)codeweavers.com> wrote:
See http://www.winehq.org/?issue=285#MSHTML%20Update. I'd really like to use Linux Gecko, but it's impossible because we'd need XEmbed embedder support that's impossible to implement in Wine (perhaps if we added what we need to XEmbed spec?). That's why MSHTML uses Windows Gecko.
OK. What exactly *do* we need from XEmbed? Is this because we can no longer use child X windows? thanks -mike
Mike Hearn wrote:
On 6/14/06, Jacek Caban <jacek(a)codeweavers.com> wrote:
See http://www.winehq.org/?issue=285#MSHTML%20Update. I'd really like to use Linux Gecko, but it's impossible because we'd need XEmbed embedder support that's impossible to implement in Wine (perhaps if we added what we need to XEmbed spec?). That's why MSHTML uses Windows Gecko.
OK. What exactly *do* we need from XEmbed? Is this because we can no longer use child X windows?
I think Alexandre can give you the best answer. Yes, the problem is mostly because of lack of child X windows. The main thing we'd have to add to XEmbed spec is clipping but probably there will be more problems. And I have no idea if freedesktop guys will accept what we need as clipping in XEmbed spec is useless for most apps (probably everyone except Wine). Jacek
Yes this problem with the lack of child windows is most troublesome. I wonder if there is another way to solve this though. By using COMPOSITE to redirect the window heirarcy of the embedded window to a pixmap we can proxy events and copy the pixmap to simulate window embedding, without actually doing so. However it is probably best to ignore this for now, there is nothing wrong with using a Windows gecko. Especially if it is included in packages. On 6/15/06, Jacek Caban <jacek(a)codeweavers.com> wrote:
I think Alexandre can give you the best answer. Yes, the problem is mostly because of lack of child X windows. The main thing we'd have to add to XEmbed spec is clipping but probably there will be more problems. And I have no idea if freedesktop guys will accept what we need as clipping in XEmbed spec is useless for most apps (probably everyone except Wine).
* On Thu, 15 Jun 2006, Jacek Caban wrote:
* Mike Hearn wrote:
* On 6/14/06, Jacek Caban <jacek(a)codeweavers.com> wrote:
I'd really like to use Linux Gecko, but it's impossible because we'd need XEmbed embedder support that's impossible to implement in Wine (perhaps if we added what we need to XEmbed spec?).
OK. What exactly *do* we need from XEmbed? Is this because we can no longer use child X windows?
I think Alexandre can give you the best answer. Yes, the problem is mostly because of lack of child X windows. The main thing we'd have to add to XEmbed spec is clipping but probably there will be more problems. And I have no idea if freedesktop guys will accept what we need as clipping in XEmbed spec is useless for most apps (probably everyone except Wine).
Then maybe we can say to freedesktop folks Wine isn't one application. It's tens of applications. Or maybe they would accept spec for independent protocol, called XWine (e.g.) for the mentioned reason? :]
Jacek Caban wrote:
Hi.
Please consider this mail as:
Re: Built-in iexplore Re: acad 2004 licence file bug Re: Broken FC5 packages - stay clear.
Last week Wine Gecko was mentioned a few times on this mailing list and I can see that there is no understanding of it. It's not really surprising as it's a big mess ATM. We can still use Mozilla ActiveX control (but that needs to be removed) or (xor) directly Gecko. Sometimes (if the app uses HTMLDocument directly, not via WebBrowser, like iexplore does) only the second option works. That has led me to do what I am planning to do later. I've just sent Wine Gecko installer. After it will be committed, a system similar to Mozilla ActiveX control download will have to be set up (that is upload the package to SourceForge and add a script that directs download of it). That will allow us to get rid of Mozilla ActiveX control.
Thanks, Jacek Hi Jacek.
This would maybe also Address my problem. Please see my posting this week [Wine's Mozilla Control - Very old] Please I have a few Questions: - Are you intending to produce a PE Gecko installer maintained by you or are you using a ready made package? - Will this package be updated from time to time when Gecko is updated? and kept as current as possible? - In theory, do you think your implementation when finished could be replacing the "Mozilla ActiveX control" on windows (and ReactOS). I don't think you will have any problems with DLL names since Windows can be made to load local DLL's first. Any way a Makefile hack could be made to change the names. You will, however, need an alternative GUID for windows if needed to run alongside IE. - Will/are you in contact with Mozilla.org people to support us in this task. (Updates, chromes, settings, plugins ...) - Will you have a browser-like application along side this installation to let users maintain their gecko engine. (Updates, chromes, settings, plugins ...) I have attempted a bit of this task based on SeaMonkey but I have come to the conclusion that I'm not up to the task. Too many if(s) that I don't have the answer to. There is this site <http://www.iol.ie/~locka/mozilla/control.htm> which is the Official site for the Mozilla activeX Control. It looks like it as stopped maintaining the Control. The only availability of the 1.8 version of Gecko and the Control is in SeaMonkey. I have written Adam Lock a short e-mail asking on the project status, yesterday. I will keep you posted on his response. (??) Mike wrote ...
A native Linux copy of Gecko installed as part of, say, the distributions Firefox?
Please note that Firefox distribution according to Mozilla documentation (See FAQ on link above) is not good because the Gecko is statically linked and cannot be accessed from outside. The only Project that can be used with current Gecko is SeaMonkey. (I may be wrong about Linux-Gecko but I suspect they have the same problems as on Windows. dynamic-linking load speed) It looks like all kind of people are looking for a Gecko SDK-kind package. I did not find any. If any one knows of one please tell me. Free Life Boaz
Hi Boaz, Boaz Harrosh wrote:
Hi Jacek.
This would maybe also Address my problem. Please see my posting this week [Wine's Mozilla Control - Very old] I doubt if it's what you need. This implementation replaces windows' DLLs. What you need is something that replaces only the control. Choosing our implementation you loose advantages of Gecko but you get more compatibility with IE. Please I have a few Questions: - Are you intending to produce a PE Gecko installer maintained by you or are you using a ready made package? I have a cab file that contains all the needed libraries. This is SeaMonkey with some files removed or changed to reduce its size. It would be better to build the package ourselves in the future, but it's not so important ATM. The code that installs Gecko will be in our MSHTML so that no more installers will be needed. - Will this package be updated from time to time when Gecko is updated? and kept as current as possible? Yes, that's the plan. - In theory, do you think your implementation when finished could be replacing the "Mozilla ActiveX control" on windows (and ReactOS). The plan is to replace IE libraries, not Mozilla ActiveX control. This means replacing the use of Mozilla ActiveX control in Wine (and ReactOS) but it's not an option for apps that want to embed Gecko. BTW if someone wants to embed Gecko, raw Gecko API is a better choice (and perhaps GTK wrapper for Linux) IMO. I don't think you will have any problems with DLL names since Windows can be made to load local DLL's first. That's not the goal of this work but if someone really wants it, one can do it. Any way a Makefile hack could be made to change the names. Our goal to replace these DLLs... You will, however, need an alternative GUID for windows if needed to run alongside IE. Again, that's our goal to replace these objects, not to give an app an alternative implementation. - Will/are you in contact with Mozilla.org people to support us in this task. (Updates, chromes, settings, plugins ...) We'll provide our own package so we'll have to do updates ourselves. There are some changes I'd like to do in Gecko to allow better MSHTML implementation and to remove some hacks, but it has nothing to do with packaging and it's not the thing for near future. - Will you have a browser-like application along side this installation to let users maintain their gecko engine. (Updates, chromes, settings, plugins ...) We want to hide Gecko before user. All settings have to be set the way IE does it and automatically passed to Gecko. Updates can be useful, but it's not really important ATM. And it can be done automatically so there is no need for a new tool for this.
I have attempted a bit of this task based on SeaMonkey but I have come to the conclusion that I'm not up to the task. Too many if(s) that I don't have the answer to.
There is this site <http://www.iol.ie/~locka/mozilla/control.htm> which is the Official site for the Mozilla activeX Control. It looks like it as stopped maintaining the Control. The only availability of the 1.8 version of Gecko and the Control is in SeaMonkey. I have written Adam Lock a short e-mail asking on the project status, yesterday. I will keep you posted on his response. (??)
Mike wrote ...
A native Linux copy of Gecko installed as part of, say, the distributions Firefox?
Please note that Firefox distribution according to Mozilla documentation (See FAQ on link above) is not good because the Gecko is statically linked and cannot be accessed from outside. The only Project that can be used with current Gecko is SeaMonkey. (I may be wrong about Linux-Gecko but I suspect they have the same problems as on Windows. dynamic-linking load speed) How about XUL Runner?
It looks like all kind of people are looking for a Gecko SDK-kind package. I did not find any. If any one knows of one please tell me.
There is one. It's called gecko-sdk. You may find it on Mozilla ftp: http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.8b1/ I don't know how about other distros, but Gentoo provides a gecko-sdk package. Jacek
Hi, Now that Wine Gecko installer is in the tree, we have to enable it. All we have to do on Wine side is set one registry value, but first we need to have wine_gecko.cab file available to download. It means: - Uploading wine_gecko.cab to SourceForge. I don't have an access to do so. Could someone that can do it contact me privately? Or perhaps I could get access so that in the future, when it needs to be updated I could do it without involving others? - We need php script redirecting to SourceForge similar to one that forwards to Mozilla ActiveX control. Thanks, Jacek
On Sat, 2006-06-24 at 20:06 +0200, Jacek Caban wrote:
- Uploading wine_gecko.cab to SourceForge. I don't have an access to do so. Could someone that can do it contact me privately? Or perhaps I could get access so that in the future, when it needs to be updated I could do it without involving others?
Yes, I can give you rights to upload. Give me a few minutes... -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.
This is now live at: http://source.winehq.org/winegecko.php On Sun, 2006-06-25 at 11:40 +0200, Jonathan Ernst wrote:
Le samedi 24 juin 2006 à 20:06 +0200, Jacek Caban a écrit :
Hi,
[...]
- We need php script redirecting to SourceForge similar to one that forwards to Mozilla ActiveX control.
Here you are.
Jeremy Newman wrote:
This is now live at: http://source.winehq.org/winegecko.php
This is grate! It is Based on SeaMonkey version 1.8.0.1. We might want to do some kind of version system, this thing gets updated pretty fast, security updates and stuff... By the way, How do you make a CAB file is there a free tool to make it? or is it Just a renamed ZIP file? Free Life Boaz
Jeremy Newman wrote:
This is now live at: http://source.winehq.org/winegecko.php
On Sun, 2006-06-25 at 11:40 +0200, Jonathan Ernst wrote:
Le samedi 24 juin 2006 à 20:06 +0200, Jacek Caban a écrit :
Hi,
[...]
- We need php script redirecting to SourceForge similar to one that forwards to Mozilla ActiveX control.
Here you are.
Thanks Jeremy and Jonathan. I'll send patches that will add the last missing part. Jacek
participants (7)
-
Boaz Harrosh -
Dimi Paun -
Jacek Caban -
Jeremy Newman -
Jonathan Ernst -
Mike Hearn -
Saulius Krasuckas