Hi all,
It's time to update our Gecko package. I've prepared a new one. I'd like to avoid any regression, esp. ones that would require changing the package again. That's why I'd like to do a good test. I'm interested in regressions, so just a simple test if app that worked before still works will be fine. To do so download:
http://gerwazy.lo3.wroc.pl/~jcaban/wine/wine_gecko.tar.bz2
1) if you already have installed Gecko, simply extract the package and replace c:\windows\wine_gecko with it. 2) otherwise extract the package and set GeckoPath variable of HKCU\Software\Winde\MSHTML registry key to its location.
Then run an app and check if it still works.
Note that you have to use current Git, older Wine is not compatible with the new Gecko.
Expected visible difference should be: - Working scrollbars (still not perfect, they will be visible even if app sets it to not be, but it's better than before - I will work on it later) - Pages that require plugins will render like there was no plugin instead of offering downloading one (that doesn't work anyway)
From technical point of view this version differs much from previous
one. Previous version was just a SeaMonkey with manually removed and changed some files. This one is my built from source (I will create a page on wiki about how to do so). It's based on XUL Runner 1.8.1.3, which has the same source as Firefox 2.0.0.3.
After testing it, I will change Gecko installer a bit to be able to deal with different Gecko versions for different Wine version and upload it to SourceForge.
Thanks, Jacek
Jacek Caban wrote:
Hi all,
It's time to update our Gecko package. I've prepared a new one. I'd like to avoid any regression, esp. ones that would require changing the package again. That's why I'd like to do a good test. I'm interested in regressions, so just a simple test if app that worked before still works will be fine. To do so download:
wine iexplore http://winehq.org/ crashes for me.
Expected visible difference should be:
- Working scrollbars (still not perfect, they will be visible even if
app sets it to not be, but it's better than before - I will work on it later)
Sweet, they finally do work in steam!
BTW why JavaScript doesn't work or any pop-up windows don't open? I know this works fine with Firefox.
Vitaliy.
Hi Vitaliy,
Vitaliy Margolen wrote:
Jacek Caban wrote:
Hi all,
It's time to update our Gecko package. I've prepared a new one. I'd like to avoid any regression, esp. ones that would require changing the package again. That's why I'd like to do a good test. I'm interested in regressions, so just a simple test if app that worked before still works will be fine. To do so download:
wine iexplore http://winehq.org/ crashes for me.
Could you please send me seh,tid,mshtml,shdocvw logs?
Expected visible difference should be:
- Working scrollbars (still not perfect, they will be visible even if
app sets it to not be, but it's better than before - I will work on it later)
Sweet, they finally do work in steam!
Seriously it still doesn't work as expected (Steam draws its own scrollbar, while currently Gecko's ones are painted, but it's a step forward).
BTW why JavaScript doesn't work or any pop-up windows don't open? I know this works fine with Firefox.
It needs some support from Gecko embedder (MSHTML in our case) and I haven't worked on it yet (with exception of built in alert pop-up).
Thanks for testing!
Jacek
Jacek Caban wrote:
Hi Vitaliy,
Vitaliy Margolen wrote:
Jacek Caban wrote:
wine iexplore http://winehq.org/ crashes for me.
Could you please send me seh,tid,mshtml,shdocvw logs?
Never mind. It was some testing patch in my tree that broke things.
BTW why JavaScript doesn't work or any pop-up windows don't open? I know this works fine with Firefox.
It needs some support from Gecko embedder (MSHTML in our case) and I haven't worked on it yet (with exception of built in alert pop-up).
You mean that what Wine has now uses gecko for just HTML rendering and nothing else?! That you are pretty much rewriting the whole browser from the scratch?!! How is that better then what we had before?!!!
The impression you gave about a year ago that Mozilla active-X controls needed number of things modified, but other then that it worked fine. Here I see only most rudimentary things work, and everything else would probably never work. And Wine is open for stream of never ending security issues, that so far no one even risen.
I hate to sound negative about things here, but how hard will it be to put things back the way they were before? Or at least make it possible to use Mozilla ActiveX controls instead of wine_gecko?
Vitaliy Margolen.
Vitaliy Margolen wrote:
BTW why JavaScript doesn't work or any pop-up windows don't open? I know this works fine with Firefox.
It needs some support from Gecko embedder (MSHTML in our case) and I haven't worked on it yet (with exception of built in alert pop-up).
You mean that what Wine has now uses gecko for just HTML rendering and nothing else?! That you are pretty much rewriting the whole browser from the scratch?!! How is that better then what we had before?!!!
Well, it would be perfect if we used it only for rendering... but I don't think we'll ever reach that state. Just take a look at how deep an API may meddle with a HTML document. In case of pop-ups Gecko asks the embedder to create the window. It's not like IE API, which is a complete browser. Pop-up window is, in fact, a new IE window. Gecko isn't anything like a complete web browser, it's just an engine. The embedder creates a window and integrates it with its other windows. In case of Wine it's not trivial, as this new window should be, in fact, an IE window with its associated MSHTML object etc.
The impression you gave about a year ago that Mozilla active-X controls needed number of things modified, but other then that it worked fine.
And my impression was that people would like to use apps like Picasa and Steam out of box with perspectives of getting much more instead of having a lots of "won't fix" bugs.
Here I see only most rudimentary things work, and everything else would probably never work. And Wine is open for stream of never ending security issues, that so far no one even risen.
Well, if you call apps like Outlook a rudimentary thing... Sure, there still is a lot to do, but with correct architecture we can support more complex apps. Mozilla ActiveX control will never allow us to run programs like Outlook. And it's not the only example. Pop-ups, in particular, arn't too interesting as apps that embed HTML documents don't usually use them.
I hate to sound negative about things here, but how hard will it be to put things back the way they were before? Or at least make it possible to use Mozilla ActiveX controls instead of wine_gecko?
It'd be quite simple, but don't count on my support in it. I very much disagree with such ideas and I prefer concentrating on improving MSHTML rather than looking for ugly workarounds. Mozilla ActiveX control may work only for WebBrowser control but it *can't* work with MSHTML.
Jacek
Jacek Caban wrote:
Vitaliy Margolen wrote:
BTW why JavaScript doesn't work or any pop-up windows don't open? I know this works fine with Firefox.
It needs some support from Gecko embedder (MSHTML in our case) and I haven't worked on it yet (with exception of built in alert pop-up).
You mean that what Wine has now uses gecko for just HTML rendering and nothing else?! That you are pretty much rewriting the whole browser from the scratch?!! How is that better then what we had before?!!!
Well, it would be perfect if we used it only for rendering... but I don't think we'll ever reach that state. Just take a look at how deep an API may meddle with a HTML document. In case of pop-ups Gecko asks the embedder to create the window. It's not like IE API, which is a complete browser. Pop-up window is, in fact, a new IE window. Gecko isn't anything like a complete web browser, it's just an engine. The embedder creates a window and integrates it with its other windows. In case of Wine it's not trivial, as this new window should be, in fact, an IE window with its associated MSHTML object etc.
So you want to say that we will never have pages with embedded JavaScript working in Wine?
The impression you gave about a year ago that Mozilla active-X controls needed number of things modified, but other then that it worked fine.
And my impression was that people would like to use apps like Picasa and Steam out of box with perspectives of getting much more instead of having a lots of "won't fix" bugs.
Indeed they would. Only I would say picasa to steam ratio would be 1-to-100. And btw only most rudimentary things work in both! Steam worked _perfectly_ before. And I'm sure would still worked. But now, you can't buy stuff, you can't open screen-shots (because they are popups) you don't see MOTO when joining servers, lots of things do not work. So I would use Steam as an example on the contrary.
Here I see only most rudimentary things work, and everything else would probably never work. And Wine is open for stream of never ending security issues, that so far no one even risen.
Well, if you call apps like Outlook a rudimentary thing... Sure, there
Yes they are! Most e-mails don't have anything even close to most simple website has.
still is a lot to do, but with correct architecture we can support more complex apps. Mozilla ActiveX control will never allow us to run programs like Outlook. And it's not the only example. Pop-ups, in particular, arn't too interesting as apps that embed HTML documents don't usually use them.
Ok if we can support more apps, then why aren't we? Do you have a todo list? Or at least a list of what needs to be done before we can open a stinking popup? Or what all needs to be done to get JavaScrip working?
I hate to sound negative about things here, but how hard will it be to put things back the way they were before? Or at least make it possible to use Mozilla ActiveX controls instead of wine_gecko?
It'd be quite simple, but don't count on my support in it. I very much disagree with such ideas and I prefer concentrating on improving MSHTML rather than looking for ugly workarounds. Mozilla ActiveX control may work only for WebBrowser control but it *can't* work with MSHTML.
The thing is, I personally, as well as most users want things *to work*. Users don't care how proper the architecture is. With Mozilla ActiveX things used to and still does work! But now Wine can't use it, because you removed such possibility. What's wrong with having two alternative implementation? Let users decide what they want - Picasa, Outlook or Steam.
Vitaliy
Indeed they would. Only I would say picasa to steam ratio would be 1-to-100. And btw only most rudimentary things work in both! Steam worked _perfectly_ before. And I'm sure would still worked. But now, you can't buy stuff, you can't open screen-shots (because they are popups) you don't see MOTO when joining servers, lots of things do not work. So I would use Steam as an example on the contrary.
I completely agree about the 1 to 100 ratio. Steam is a pretty critical application for wine given its large number of users.
Chris
Vitaliy Margolen wrote:
Jacek Caban wrote:
Vitaliy Margolen wrote:
BTW why JavaScript doesn't work or any pop-up windows don't open? I know this works fine with Firefox.
It needs some support from Gecko embedder (MSHTML in our case) and I haven't worked on it yet (with exception of built in alert pop-up).
You mean that what Wine has now uses gecko for just HTML rendering and nothing else?! That you are pretty much rewriting the whole browser from the scratch?!! How is that better then what we had before?!!!
Well, it would be perfect if we used it only for rendering... but I don't think we'll ever reach that state. Just take a look at how deep an API may meddle with a HTML document. In case of pop-ups Gecko asks the embedder to create the window. It's not like IE API, which is a complete browser. Pop-up window is, in fact, a new IE window. Gecko isn't anything like a complete web browser, it's just an engine. The embedder creates a window and integrates it with its other windows. In case of Wine it's not trivial, as this new window should be, in fact, an IE window with its associated MSHTML object etc.
So you want to say that we will never have pages with embedded JavaScript working in Wine?
It already works! I only said that pop-ups don't work.
The impression you gave about a year ago that Mozilla active-X controls needed number of things modified, but other then that it worked fine.
And my impression was that people would like to use apps like Picasa and Steam out of box with perspectives of getting much more instead of having a lots of "won't fix" bugs.
Indeed they would. Only I would say picasa to steam ratio would be 1-to-100.
Hm, where do you have those statistics from? How do you know how many apps are *fixed* by switch to the new implementation?
And btw only most rudimentary things work in both! Steam worked _perfectly_ before. And I'm sure would still worked. But now, you can't buy stuff, you can't open screen-shots (because they are popups) you don't see MOTO when joining servers, lots of things do not work. So I would use Steam as an example on the contrary.
Steam didn't work at all unless you used Mozilla ActiveX control used by TG that had some unacceptable forthe main Gecko tree hacks. I didn't know about pop-ups in Steam. I've attached a hack from Picasa tree that causes links opening in new window to be opened in winebrowser. It's a nicer behavior than opening them in our IE replacement, but it's not guaranteed to work (app doesn't have control over it, different cookie manager...). As I wrote, correct implementation is much more complicated, but we're getting nearer to it. Eg. implementing InternetExplorer object (more or less that's what iexplore.exe is) was a big step forward. Anyway if the attached patch helps, it may go to Git IMO.
Here I see only most rudimentary things work, and everything else would probably never work. And Wine is open for stream of never ending security issues, that so far no one even risen.
Well, if you call apps like Outlook a rudimentary thing... Sure, there
Yes they are! Most e-mails don't have anything even close to most simple website has.
Not from API point of view. First of all app has to be able to embed HTML, then we can think about how nicely is HTML handled.
still is a lot to do, but with correct architecture we can support more complex apps. Mozilla ActiveX control will never allow us to run programs like Outlook. And it's not the only example. Pop-ups, in particular, arn't too interesting as apps that embed HTML documents don't usually use them.
Ok if we can support more apps, then why aren't we?
Aren't we? Still more and more works. Take a look at number of MSHTML patches. Do you think they are only to make Wine compilation time longer?
Do you have a todo list?
Yes, fix a few MSHTML bugs I'm working ATM, then come back to activation context to get it accepted to Wine. I usually target on a specific app and fix it, so I have no clear todo list. There are a few hacks I'd like to fix (we're slowly getting there) and find time to make bug hunting on bugzilla.
Or at least a list of what needs to be done before we can open a stinking popup?
Test how exactly does WebBrowser/MSHTM/InternetExplorer interface in this case and implement it or stay with the attached patch for now.
Or what all needs to be done to get JavaScrip working?
As I wrote, it works. JavaScript is not only for pop-ups.
I hate to sound negative about things here, but how hard will it be to put things back the way they were before? Or at least make it possible to use Mozilla ActiveX controls instead of wine_gecko?
It'd be quite simple, but don't count on my support in it. I very much disagree with such ideas and I prefer concentrating on improving MSHTML rather than looking for ugly workarounds. Mozilla ActiveX control may work only for WebBrowser control but it *can't* work with MSHTML.
The thing is, I personally, as well as most users want things *to work*. Users don't care how proper the architecture is. With Mozilla ActiveX things used to and still does work! But now Wine can't use it, because you removed such possibility. What's wrong with having two alternative implementation? Let users decide what they want - Picasa, Outlook or Steam.
It will add configure option that we will want to remove anyway.
Jacek
Jacek Caban wrote:
I've attached a hack from Picasa tree that causes links opening in new window to be opened in winebrowser.
I forgot to attach the patch. Here it is.
Jacek
-
Chris Morgan -
Jacek Caban -
Jacek Caban -
Vitaliy Margolen