Hi,
wine cmd /c echo yes now downloads gecko.
Me to -- I'm not pleased with Wine-1.1.33 starting an installation request upon startup. - How am I going to automate regression testing when it hangs waiting for a mouse click? - I tried to think positively about it and expected the winetest-1.1.33.exe to install Gecko and perform the mshtml tests when online. Curiously they were skipped. I have yet to find out why.
Any suggestions are welcome.
Winecfg would be a better place to propose the installation of an optional component.
Perhaps I'm a very atypical Wine user: - no MMORPG, no ie6 - My Wine is not used for anything online. Quite to the contrary, I have some iptables firewall rules to disable Wine IP traffic should anything ever manage to get in. - I never used winetricks. I sometimes peeked at it. When I needed Gecko long ago, I saw that the Wine source contains code to install it, downloaded Gecko.cab myself, modified the one registry entry to point to the .cab and let it install. Worked.
IMHO, no general-purpose application should attempt to talk to the internet when it starts. Please leave that behaviour to viruses and trojans only (and alikes, e.g. Adobe's pdf). Maybe I'm too old-fashioned in this decade of "always online even in the subway" technical achievements. Or I've been in the privacy-protection (Datenschutz) and security business for too long.
Regarding winecfg, it could display "no Gecko/HTML support, click here to install it (need be online)" in flashing red to attract the user's attention once you start it. I wouldn't mind.
Regards, Jörg Höhle.
Joerg-Cyril.Hoehle@t-systems.com wrote:
Hi,
wine cmd /c echo yes now downloads gecko.
Me to -- I'm not pleased with Wine-1.1.33 starting an installation request upon startup.
- How am I going to automate regression testing when it hangs waiting for a mouse click?
- I tried to think positively about it and expected the winetest-1.1.33.exe to install Gecko and perform the mshtml tests when online. Curiously they were skipped. I have yet to find out why.
Did you read the page from the link that is on the dialog informing about missing Gecko?
Jacek
Hi Jacek,
On Mon, Nov 16, 2009 at 10:16 AM, Jacek Caban jacek@codeweavers.com wrote:
Did you read the page from the link that is on the dialog informing about missing Gecko?
I've been kind of following this thread and see where Jörg is coming from. I don't think the argument about broken wine due to missing gecko makes much sense given the way we have other soft dependencies that can be missing if you build Wine yourself. A good example is the xml or opengl libraries. It's possible to have a working wine for specific needs without this package. If we are going to require this package for every wine install then I would argue we should not have any other soft dependencies either.
If a packager has not packaged Gecko or a hacker has built from source it seems like winecfg should be invoked when a new prefix is created rather than prompting for the download. Maybe for the general usage case we should do it anyway. Alternatively, if we are going to have this hook in here to satisfy this dependency during prefix creation due to packagers not following a required guideline, maybe a little public ridicule will force them to fix the package. Something along the lines of 'your version of wine does not contain the gecko package, please contact the package maintainer and inform them about this issue' or something and let it proceed to download at least.
On Mon, Nov 16, 2009 at 11:38 PM, Steven Edwards winehacker@gmail.comwrote:
Hi Jacek,
On Mon, Nov 16, 2009 at 10:16 AM, Jacek Caban jacek@codeweavers.com wrote:
Did you read the page from the link that is on the dialog informing about missing Gecko?
I've been kind of following this thread and see where Jörg is coming from. I don't think the argument about broken wine due to missing gecko makes much sense given the way we have other soft dependencies that can be missing if you build Wine yourself. A good example is the xml or opengl libraries. It's possible to have a working wine for specific needs without this package. If we are going to require this package for every wine install then I would argue we should not have any other soft dependencies either.
If a packager has not packaged Gecko or a hacker has built from source it seems like winecfg should be invoked when a new prefix is created rather than prompting for the download. Maybe for the general usage case we should do it anyway. Alternatively, if we are going to have this hook in here to satisfy this dependency during prefix creation due to packagers not following a required guideline, maybe a little public ridicule will force them to fix the package. Something along the lines of 'your version of wine does not contain the gecko package, please contact the package maintainer and inform them about this issue' or something and let it proceed to download at least.
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Jacek,
How does this work off line? If Wine cant download and install gecko at wineprefix creation then Wine wont work? And if so every time you create a wineprefix your going to have to be connected and the server is going to have to be up 100% of the time or Wine wont properly create a prefix.. You could time out and move to a backup server but it still begs the question of what if the servers are down, then what?
Can you please comment on this..
Tom
Tom Wickline wrote:
Jacek,
How does this work off line? If Wine cant download and install gecko at wineprefix creation then Wine wont work? And if so every time you create a wineprefix your going to have to be connected and the server is going to have to be up 100% of the time or Wine wont properly create a prefix.. You could time out and move to a backup server but it still begs the question of what if the servers are down, then what?
Can you please comment on this..
The answer is not to use the downloader. You've just given another reasons to install Gecko properly.
Jacek
Steven Edwards wrote:
Hi Jacek,
On Mon, Nov 16, 2009 at 10:16 AM, Jacek Caban jacek@codeweavers.com wrote:
Did you read the page from the link that is on the dialog informing about missing Gecko?
I've been kind of following this thread and see where Jörg is coming from. I don't think the argument about broken wine due to missing gecko makes much sense given the way we have other soft dependencies that can be missing if you build Wine yourself. A good example is the xml or opengl libraries. It's possible to have a working wine for specific needs without this package. If we are going to require this package for every wine install then I would argue we should not have any other soft dependencies either.
These dependences are different because they are Linux dependences. There is no way we could tread Gecko the same way.
If a packager has not packaged Gecko or a hacker has built from source it seems like winecfg should be invoked when a new prefix is created rather than prompting for the download. Maybe for the general usage case we should do it anyway. Alternatively, if we are going to have this hook in here to satisfy this dependency during prefix creation due to packagers not following a required guideline, maybe a little public ridicule will force them to fix the package. Something along the lines of 'your version of wine does not contain the gecko package, please contact the package maintainer and inform them about this issue' or something and let it proceed to download at least.
Well, I hope that a side effect of installation during wineprefix creation is that it will force packagers to package gecko <g> The brutal true is that we had a very bad situation for a long time. I can see three types of Wine users:
- regular users They use Wine packages that should guarantee presence of Gecko (as Wine dependency or in Wine package, depends on packagers preferences). The current situation will probably force packagers to do the right thing <g>
- Wine developers I'm surprised how many developers are affected by this change. It means that developers were not aware of the right way to install Gecko (probably because winetricks is too good :-) ). I'm sure it will change now.
- Users who compile Wine themselves Well... the information about proper Gecko installation is easy to find and it's pointed on every wineprefix creation. They should survive as long as they read what's .
Given that, I think this change will force changes that will allow us to forget about the problem soon.
Jacek
On Mon, Nov 16, 2009 at 05:08:21PM +0100, Jacek Caban wrote:
Well, I hope that a side effect of installation during wineprefix creation is that it will force packagers to package gecko <g> The brutal true is that we had a very bad situation for a long time. I can see three types of Wine users:
- regular users
They use Wine packages that should guarantee presence of Gecko (as Wine dependency or in Wine package, depends on packagers preferences). The current situation will probably force packagers to do the right thing <g>
The Wine packages for openSUSE now do the right thing, since last Friday ;) It will hopefully get this way into openSUSE 11.3 too.
Ciao, Marcus
Marcus Meissner wrote:
On Mon, Nov 16, 2009 at 05:08:21PM +0100, Jacek Caban wrote:
Well, I hope that a side effect of installation during wineprefix creation is that it will force packagers to package gecko <g> The brutal true is that we had a very bad situation for a long time. I can see three types of Wine users:
- regular users
They use Wine packages that should guarantee presence of Gecko (as Wine dependency or in Wine package, depends on packagers preferences). The current situation will probably force packagers to do the right thing <g>
The Wine packages for openSUSE now do the right thing, since last Friday ;) It will hopefully get this way into openSUSE 11.3 too.
Thanks!
I've added openSUSE to the list on: http://wiki.winehq.org/Gecko It would be great if others could update the list for their distros. AFAIK Ubuntu packages also support Gecko, but I've never touched it, so I can't be sure. I don't know about other distros.
Jacek
Jacek Caban skrev:
Well, I hope that a side effect of installation during wineprefix creation is that it will force packagers to package gecko <g>
You can't *force* the creation of packages which would likely fail to meet the requirements for inclusion into Debian's main archive. Even if I didn't think the package's build system is a problem, the ftpmasters likely would.
Ove Kaaven wrote:
Jacek Caban skrev:
Well, I hope that a side effect of installation during wineprefix creation is that it will force packagers to package gecko <g>
You can't *force* the creation of packages which would likely fail to meet the requirements for inclusion into Debian's main archive. Even if I didn't think the package's build system is a problem, the ftpmasters likely would.
Then I can't see better solution for Debian users than downloading Gecko on wineprefix creation. It's not perfect, but we don't have much choice.
Jacek
Jacek Caban skrev:
Ove Kaaven wrote:
Jacek Caban skrev:
Well, I hope that a side effect of installation during wineprefix creation is that it will force packagers to package gecko <g>
You can't *force* the creation of packages which would likely fail to meet the requirements for inclusion into Debian's main archive. Even if I didn't think the package's build system is a problem, the ftpmasters likely would.
Then I can't see better solution for Debian users than downloading Gecko on wineprefix creation. It's not perfect, but we don't have much choice.
It really should be optional. Making it mandatory for a program to go out on the Internet, download 'untrusted' binaries, and then running them, without the user actually having (and knowing) a reason for the program to do this, might be too much for some security-conscious (and spyware-hating) people to handle. Debian packagers have been forced to turn off that kind of automatic behaviour before. Hence, it's possible that downloading Gecko on wineprefix creation is not a solution for Debian users at all, and that any attempt at this will result in a release-critical bug (with a "security problem" tag to boot, claiming "a dns spoof could mean someone could control your computer" etc) requiring this to be turned off in the Debian package.
(It is actually for similar reasons that binaries must be buildable on a clean system (say, a build daemon), without any special (non-free) tools or sourceless libraries. Magic libshell32.a in the source package fails this requirement, and so does usage of non-free cabinet.dll to make cab file.)
Maybe I could ask on debian-devel if there's a good way to handle this, maybe someone can come up with a good answer beyond the typical "upstream developers suck", or at least agree that a kludgy package might be acceptable in this case. (I'd need some time to prepare something to ask, though.)
But in any case, I really don't think Gecko should be any less optional than, say, OpenGL, lcms, or ALSA/OSS/etc, without which Wine will reduce functionality (even at runtime, not only compile time), but still allow programs that don't need that functionality to work. You don't need CUPS to run games and you don't need OpenGL to run Office, why should you need Gecko for anything that won't ever do any HTML rendering? There's often much to be said for only installing what you need... and some people like that. (Wasn't there a reason Gentoo was popular?)
On Mon, Nov 16, 2009 at 5:52 PM, Ove Kaaven ovek@arcticnet.no wrote:
(It is actually for similar reasons that binaries must be buildable on a clean system (say, a build daemon), without any special (non-free) tools or sourceless libraries. Magic libshell32.a in the source package fails this requirement, and so does usage of non-free cabinet.dll to make cab file.)
I don't suppose the build could be fixed?
"The wine-gecko build is unclean" is a separate issue from "Wine-gecko should/shouldn't be a run-time requirement". Both of them are important issues, and the unclean gecko build would still be important (if not as visible) without this change.
I wouldn't expect anything less of Debian than to refuse to include wine-gecko in the free parts or as a download at startup for exactly the reasons you describe. I hope they do. These are valid concerns, and someone has to stubbornly insist that they be addressed, pointing to clear, inhuman policies.
As for the run-time requirement, I think it's good for calling attention to the fact that gecko is a requirement for a fully functional Wine (even though configure doesn't warn about it) and that "when needed" is too late, but it's absolutely useless in terms of *forcing* packagers to do anything and much more annoying than it needs to be for calling attention to the requirement.
(It also doesn't seem to actually find the .cab file, even though I'm sure I've put it in the right place, but that's a third issue that I'll have to test more carefully and possibly file a bug for.)
Providing, say, an environment variable that one could use to specify a path of the .cab would make things much less annoying for me (I'd have a work-around for the aforementioned bug-or-user-error, and I wouldn't have to copy a .cab whenever I make a new wine install in a new directory, which is fairly often.) and would make 'winetricks gecko' fixable. You'd still see the message box when invoking wine for the first time absolutely any other way, or if you do it wrong, so I don't see the problem there.
It also seems to me that a --disable-gecko-downloader configure switch that would disable the dialog COMPLETELY (even "when needed") would put gecko on equal footing with optional library requirements. It would mean: * You can warn about the perils of not having gecko at configure time. * If gecko is installed properly, it's used properly, installed at prefix creation time. * If gecko is not installed properly, programs that need it will simply fail, and you'll see an ERR in the console, as well as a nice "HTML rendering is disabled" message you wouldn't get from other components.
Vincent Povirk skrev:
On Mon, Nov 16, 2009 at 5:52 PM, Ove Kaaven ovek@arcticnet.no wrote:
(It is actually for similar reasons that binaries must be buildable on a clean system (say, a build daemon), without any special (non-free) tools or sourceless libraries. Magic libshell32.a in the source package fails this requirement, and so does usage of non-free cabinet.dll to make cab file.)
I don't suppose the build could be fixed?
Possibly. For the .a files, either the rules that generated them has to be documented somehow so the procedure can be replicated in the source package's build system, or mingw's w32api has to be patched to fix the problems that required them in the first place. (The latter probably won't happen overnight, I suppose.)
For the cab file, I suppose it would work to use one of those simple Linux tools for making cab files that don't actually compress the data like the native cabinet.dll do. The package will be larger, but it would be acceptable as DFSG-free.
Ove Kaaven wrote:
Vincent Povirk skrev:
On Mon, Nov 16, 2009 at 5:52 PM, Ove Kaaven ovek@arcticnet.no wrote:
(It is actually for similar reasons that binaries must be buildable on a clean system (say, a build daemon), without any special (non-free) tools or sourceless libraries. Magic libshell32.a in the source package fails this requirement, and so does usage of non-free cabinet.dll to make cab file.)
I don't suppose the build could be fixed?
Possibly. For the .a files, either the rules that generated them has to be documented somehow so the procedure can be replicated in the source package's build system, or mingw's w32api has to be patched to fix the problems that required them in the first place. (The latter probably won't happen overnight, I suppose.)
$ cd dlls/shell32 $ make libshell32.a
In the official build I also include there a little virus that checks for Oven Kaaven user name and if it finds one, it silently replaces Debian installation with Ubuntu at 18 November each year.
But seriously, patches are welcome. The build process is far from perfect, but it slowly improves. There are problems with gcc, mingw and mozilla itself. Patches are welcome. It's easy to complain, but a lot harder to fix.
Jacek
Jacek Caban skrev:
Ove Kaaven wrote:
Vincent Povirk skrev:
On Mon, Nov 16, 2009 at 5:52 PM, Ove Kaaven ovek@arcticnet.no wrote:
(It is actually for similar reasons that binaries must be buildable on a clean system (say, a build daemon), without any special (non-free) tools or sourceless libraries. Magic libshell32.a in the source package fails this requirement, and so does usage of non-free cabinet.dll to make cab file.)
I don't suppose the build could be fixed?
Possibly. For the .a files, either the rules that generated them has to be documented somehow so the procedure can be replicated in the source package's build system, or mingw's w32api has to be patched to fix the problems that required them in the first place. (The latter probably won't happen overnight, I suppose.)
$ cd dlls/shell32 $ make libshell32.a
So this is confirmation that all the .a files included in the source are generated from a Wine build tree, there's no other patches or anything?
So to achieve a binary-less source package, perhaps I can do something with a Wine build-dependency or something, I suppose. I'll take a look at whether that suffices.
In the official build I also include there a little virus that checks for Oven Kaaven user name and if it finds one, it silently replaces Debian installation with Ubuntu at 18 November each year.
Like I would run it as root... (even if you had spelled my name right)
But seriously, patches are welcome. The build process is far from perfect, but it slowly improves. There are problems with gcc, mingw and mozilla itself. Patches are welcome. It's easy to complain, but a lot harder to fix.
I thought mingw needed patching the most.
I would just like to second Vincent's suggestion.
Vincent Povirk wrote:
It also seems to me that a --disable-gecko-downloader configure switch that would disable the dialog COMPLETELY (even "when needed") would put gecko on equal footing with optional library requirements. It would mean:
- You can warn about the perils of not having gecko at configure time.
- If gecko is installed properly, it's used properly, installed at
prefix creation time.
- If gecko is not installed properly, programs that need it will
simply fail, and you'll see an ERR in the console, as well as a nice "HTML rendering is disabled" message you wouldn't get from other components.
On Tuesday 17 November 2009 04:15:29 pm Nate Gallaher wrote:
I would just like to second Vincent's suggestion.
Vincent Povirk wrote:
It also seems to me that a --disable-gecko-downloader configure switch that would disable the dialog COMPLETELY (even "when needed") would put gecko on equal footing with optional library requirements. It would mean:
- You can warn about the perils of not having gecko at configure time.
- If gecko is installed properly, it's used properly, installed at
prefix creation time.
- If gecko is not installed properly, programs that need it will
simply fail, and you'll see an ERR in the console, as well as a nice "HTML rendering is disabled" message you wouldn't get from other components.
Plus a button or link to (download and) install it for the next time I'd say.
On Mon, Nov 16, 2009 at 11:29:51PM +0100, Ove Kaaven wrote:
Jacek Caban skrev:
Well, I hope that a side effect of installation during wineprefix creation is that it will force packagers to package gecko <g>
You can't *force* the creation of packages which would likely fail to meet the requirements for inclusion into Debian's main archive. Even if I didn't think the package's build system is a problem, the ftpmasters likely would.
I btw thought of actually building wine-gecko using mingw instead of just distributing the .cab.
Just did not have the time to try it in the .spec file.
This is also the 1 problem I see with distro inclusion here, so far I just have it in my openSUSE buildservice repos.
Ciao, Marcus
Marcus Meissner wrote:
On Mon, Nov 16, 2009 at 11:29:51PM +0100, Ove Kaaven wrote:
Jacek Caban skrev:
Well, I hope that a side effect of installation during wineprefix creation is that it will force packagers to package gecko <g>
You can't *force* the creation of packages which would likely fail to meet the requirements for inclusion into Debian's main archive. Even if I didn't think the package's build system is a problem, the ftpmasters likely would.
I btw thought of actually building wine-gecko using mingw instead of just distributing the .cab.
Just did not have the time to try it in the .spec file.
This is also the 1 problem I see with distro inclusion here, so far I just have it in my openSUSE buildservice repos.
I'm afraid it won't work well ATM. We're quite not yet there with Wine Gecko source and build system. I hope it will be possible at some point, but we're far from there.
Jacek
2009/11/17 Jacek Caban jacek@codeweavers.com:
I can see three types of Wine users:
- regular users
They use Wine packages that should guarantee presence of Gecko (as Wine dependency or in Wine package, depends on packagers preferences). The current situation will probably force packagers to do the right thing <g>
- Wine developers
I'm surprised how many developers are affected by this change. It means that developers were not aware of the right way to install Gecko (probably because winetricks is too good :-) ). I'm sure it will change now.
- Users who compile Wine themselves
Well... the information about proper Gecko installation is easy to find and it's pointed on every wineprefix creation. They should survive as long as they read what's .
Given that, I think this change will force changes that will allow us to forget about the problem soon.
You're missing a type of user that has been quite vocal on this thread: - Users who have no need for Gecko These are "regular users" who don't use applications or games that require MSHTML/Gecko/IE6/whatever. They don't view .chm files either, and most of them don't run the test suite. This group has been completely forgotten in the decision to force Gecko.
OK, so you can hit "Cancel" to stop the download. This is *not* satisfactory. As it is at the moment, Gecko sits half-way between an opt-in and an opt-out system. It should be made one or the other - either force it to be installed (by all package maintainers) on first install and then have it optionally removed *without* causing a stupid pop-up box saying it's missing, or have a button in winecfg or similar that downloads it if it is missing.
As the maintainer of WineHQ's Debian packages, I have produced a new wine-gecko-1.0 package for use with 1.1.33, something that I was considering for a long time. However, I refuse to force the Wine package to depend on it because this wine-gecko-1.0 package doubles the required download (7.8MB wine-gecko-1.0, 7.8MB wine 1.1.33 package). I realise that this will not be required to download on every upgrade, but I also can't predict when wine-gecko releases are made.
Currently, the wine-gecko-1.0 package I have produced depends on Wine. I may need to rethink this to cater for user groups 2 and 3 above.
Furthermore, I have not yet packaged earlier versions of wine-gecko for use with earlier versions of Wine, but I believe I have had the foresight to think of this potential situation. This is in direct contrast to the obviously low about of thought that went into the change to how Wine downloads Gecko.
2009/11/17 Jacek Caban jacek@codeweavers.com:
You can't *force* the creation of packages which would likely fail to meet the requirements for inclusion into Debian's main archive. Even if I didn't think the package's build system is a problem, the ftpmasters likely would.
Then I can't see better solution for Debian users than downloading Gecko on wineprefix creation. It's not perfect, but we don't have much choice.
It shouldn't even be an option. What's wrong with adding an opt-in button to "winecfg"?
The rigidity of proponents of the "new way" is disheartening. The feeling coming across is "this way is better for everyone because we say it is". If this was something like, e.g., my decision to not separate OpenGL from the core Wine package, it wouldn't be a real problem (OpenGL support is used by the majority of Wine users, and takes up very little space in the binary distrobution), but it's not. Gecko is purely optional (although not recommended, "winetricks ie6" does get some apps working where Gecko doesn't), and quite large.
However, I refuse to force the Wine package to depend on it because this wine-gecko-1.0 package doubles the required download (7.8MB wine-gecko-1.0, 7.8MB wine 1.1.33 package). I realise that this will not be required to download on every upgrade, but I also can't predict when wine-gecko releases are made.
What's the download size got to do with anything? Do you want to force people to use an old, unsupported version of Wine because its download size is smaller? Please, don't conflate unrelated issues.
say it is". If this was something like, e.g., my decision to not separate OpenGL from the core Wine package, it wouldn't be a real problem (OpenGL support is used by the majority of Wine users, and takes up very little space in the binary distrobution), but it's not.
Says who? Don't make unsupported claims, please. I've never used OpenGL support in Wine, but I have used gecko.
Jacek's justification has been the number of bugs that are closed invalid due to an invalid configuration. Strongly encouraging people to install gecko would reduce the time we all spend looking at bogus bug reports. Personally, I think that's worth considering, especially because developer man hours are perhaps the most scarce resource for the Wine project. --Juan
2009/11/17 Juan Lang juan.lang@gmail.com:
However, I refuse to force the Wine package to depend on it because this wine-gecko-1.0 package doubles the required download (7.8MB wine-gecko-1.0, 7.8MB wine 1.1.33 package). I realise that this will not be required to download on every upgrade, but I also can't predict when wine-gecko releases are made.
What's the download size got to do with anything? Do you want to force people to use an old, unsupported version of Wine because its download size is smaller? Please, don't conflate unrelated issues.
If a previously-optional component is now deemed to be mandatory, and that component *on its own* happens to double the download size required to install Wine, I consider that a problem. Not everyone has a cable or ADSL2+ connection.
say it is". If this was something like, e.g., my decision to not separate OpenGL from the core Wine package, it wouldn't be a real problem (OpenGL support is used by the majority of Wine users, and takes up very little space in the binary distrobution), but it's not.
Says who? Don't make unsupported claims, please. I've never used OpenGL support in Wine, but I have used gecko.
Most users, espcecially new users, seem to want to use Wine for games. Perhaps they are merely the most vocal.
Jacek's justification has been the number of bugs that are closed invalid due to an invalid configuration. Strongly encouraging people to install gecko would reduce the time we all spend looking at bogus bug reports. Personally, I think that's worth considering, especially because developer man hours are perhaps the most scarce resource for the Wine project.
I understand this, but it's a quick-fix to a problem that has long-term ramifications which were not even considered when the decision was made. It is simply not satisfactory that ALL use-cases of Wine now present the users with the "you need Gecko" dialog.
wine cmd /c echo yes now downloads gecko.
How can you possibly justify this?
Jacek,
- I tried to think positively about it and expected the winetest-1.1.33.exe to install Gecko and perform the mshtml tests when online. Curiously they were skipped. I have yet to find out why.
Did you read the page from the link that is on the dialog informing about missing Gecko?
What part from wiki/Gecko did you have in mind? Regarding the above, I see the following explanation: http://wiki.winehq.org/Gecko
Wine 1.1.33 and later will download Gecko when a prefix is created.
Aha -- I did not run winetest creating a prefix at the same time. I created the prefix earlier, running winecfg. So that's why winetest did not download Gecko and why I saw no dialog box at winetest time.
I can see three types of Wine users:
I don't find myself in the description you gave.
I've a feeling that I'm misunderstood. I have nothing against Gecko. I simply tend to test apps in a minimal configuration environment. Optional packages like Gecko are not part of that environment, and I always saw a risk that a nMB third-party Gecko package introduces its own bugs when I want to find out about the ones in Wine (or the app).
None but three of the many apps that I've tested depended on HTML/Gecko. That is my experience. Sometimes, when I thought Gecko should be needed (to view advanced .hlp or .chm files), I tested with Gecko -- or so I thought -- but it didn't help rendering the .hlp pages (witness bug #17682).
allow us to forget about the problem soon
What actually is *the* problem?
It seems to me like "Gecko is not compulsory" is the problem in your eyes, isn't it? This is not my experience. To me, Gecko appears strictly optional, and rarely needed (for the kind of apps that I'm running). I've no problem with the Wine team now declaring Gecko as compulsory, and would then start to use it. But the wiki/Gecko page right now does not say that it is so.
My problem, namely rm -rf ~/.wine; wine /c cmd or wine xyz hanging in a dialog box or believing that it is allowed to access the network, then of course would go away (at the cost of a larger .wine tree).
Regards, Jörg Höhle.
Joerg-Cyril.Hoehle@t-systems.com wrote:
Jacek,
- I tried to think positively about it and expected the winetest-1.1.33.exe to install Gecko and perform the mshtml tests when online. Curiously they were skipped. I have yet to find out why.
Did you read the page from the link that is on the dialog informing about missing Gecko?
What part from wiki/Gecko did you have in mind? Regarding the above, I see the following explanation: http://wiki.winehq.org/Gecko
Wine 1.1.33 and later will download Gecko when a prefix is created.
'If your distribution of Wine doesn't put the .cab file in the right place for you, you can avoid problems by putting it there yourself as follows: (...)'
Aha -- I did not run winetest creating a prefix at the same time. I created the prefix earlier, running winecfg. So that's why winetest did not download Gecko and why I saw no dialog box at winetest time.
I can see three types of Wine users:
I don't find myself in the description you gave.
You're a user compiling Wine himself.
I've a feeling that I'm misunderstood. I have nothing against Gecko. I simply tend to test apps in a minimal configuration environment. Optional packages like Gecko are not part of that environment, and I always saw a risk that a nMB third-party Gecko package introduces its own bugs when I want to find out about the ones in Wine (or the app).
If you run winetest, you *should* have Gecko installed. Otherwise your test results are confusing. Also bugs in Gecko are as bad for Wine as Wine own bugs. Consider Gecko as a part of mshtml.dll.
None but three of the many apps that I've tested depended on HTML/Gecko. That is my experience. Sometimes, when I thought Gecko should be needed (to view advanced .hlp or .chm files), I tested with Gecko -- or so I thought -- but it didn't help rendering the .hlp pages (witness bug #17682).
.chm files require Gecko and if they don't work, it's due to bugs that you claim to want to find.
allow us to forget about the problem soon
What actually is *the* problem?
The problem is that you have to click install during wineprefix creation. The fix is to install Gecko correctly.
It seems to me like "Gecko is not compulsory" is the problem in your eyes, isn't it?
It's surely strongly recommended. The configuration without Gecko is still possible, you just have to click cancel. No better solution was proposed so far.
This is not my experience. To me, Gecko appears strictly optional, and rarely needed (for the kind of apps that I'm running). I've no problem with the Wine team now declaring Gecko as compulsory, and would then start to use it. But the wiki/Gecko page right now does not say that it is so.
Feel free to change wiki.
My problem, namely rm -rf ~/.wine; wine /c cmd or wine xyz hanging in a dialog box or believing that it is allowed to access the network, then of course would go away (at the cost of a larger .wine tree).
Again, install Gecko properly if you don't want the dialog box.
You should understand, that we don't want users to have problems due to *lack* of Gecko. Any solution like moving installation to winecfg means that most user (at least these, who don't get Gecko from their distro packages) will have this problem. You also didn't give me any single good reason to not install Gecko properly. Instead you just said that you pollute winetest results with your bad configuration.
Jacek
On Mon, Nov 16, 2009 at 12:58 PM, Jacek Caban jacek@codeweavers.com wrote:
You should understand, that we don't want users to have problems due to *lack* of Gecko. Any solution like moving installation to winecfg means that most user (at least these, who don't get Gecko from their distro packages) will have this problem. You also didn't give me any single good reason to not install Gecko properly. Instead you just said that you pollute winetest results with your bad configuration.
Isn't winetest web configured to reject certain classes of test results already? I seem to recall Alexandre adding some magic to winetest and the site to reject reports or flag them if they were with a sha1hash that did not match a git revision. Could we not do something like this with gecko? If it's not installed then just ignore those results?
Jacek Caban wrote:
You should understand, that we don't want users to have problems due to *lack* of Gecko.
Fair enough.
Instead you just said that you pollute winetest results with your bad configuration.
Are you being rude or what? I've not been polluting anything. I've -- quite simply -- used for years a (seemingly) perfectly reasonable and supported[*] configuration, namely a Wine without Gecko. Austin English too has provided "ae-nogecko" test data for ages.
[*] "you can avoid problems" in WineGecko is not at all the same as "It is highly recommended that you install Gecko in order to avoid mysterious failures even with applications that do not seem to have anything to do at all with HTML. That's not how Windows works."
Well, as I said earlier, my next Mac testdata will use Gecko.
I'd appreciate if the WineGecko page could be augmented with a recommendation about how to add Gecko to an existing .wine. I'm used to rm .wine/.update-timestamp wine winecfg Is that fine?
Regards, Jörg Höhle.
-
Ben Klein -
Jacek Caban -
Joerg-Cyril.Hoehle＠t-systems.com -
Juan Lang -
Marcus Meissner -
Marcus Meissner -
Nate Gallaher -
Ove Kaaven -
ovek＠arcticnet.no
-
Paul Chitescu -
Steven Edwards -
Tom Wickline -
Vincent Povirk