In trying to install the United Devices application the installer prompts me to go to a website to get the msi installer. Wine doesn't have a HKEY_LOCAL_MACHINE\software\classes\http\shell\open\command key in the registery. I was thinking about making a shell script something along the lines of: if browserX exists browserX $1 else if browserY exists browserY $1 ... I would imagine most people have mozilla installed on their machines and we can check for konqueror, opera and other browsers. I've created a simple 'winebrowser' script, placed it in /usr/local/bin manually thus far, set the value for the above key to 'winebrowser %1' and symlinked /wine/system/ winebrowser.exe to /usr/local/bin/winebrowser. Sound reasonable? Comments? ;-) Chris
Bleh. I meant that I symlinked /c/windows/system/winebrowser.exe to /usr/ local/bin/winebrowser. Chris On Saturday 27 December 2003 09:50 pm, Chris Morgan wrote:
In trying to install the United Devices application the installer prompts me to go to a website to get the msi installer. Wine doesn't have a HKEY_LOCAL_MACHINE\software\classes\http\shell\open\command key in the registery. I was thinking about making a shell script something along the lines of:
if browserX exists browserX $1 else if browserY exists browserY $1 ...
I would imagine most people have mozilla installed on their machines and we can check for konqueror, opera and other browsers. I've created a simple 'winebrowser' script, placed it in /usr/local/bin manually thus far, set the value for the above key to 'winebrowser %1' and symlinked /wine/system/ winebrowser.exe to /usr/local/bin/winebrowser.
Sound reasonable? Comments? ;-)
Chris
Hello, I like the idea. Under LindowsOS, I hacked up the shlexec.c so that if no browsers are installed under wine, it tries to run mozilla (for linux). This is because the xten sipphone software attempts to open web pages in a few circumstances, and we want that to work. Ideally, we want the xten client to run under wine without any special LindowsOS patches, because it will be much easier for us to keep the version of wine in the CNR warehouse up-to-date if we can just use the default debian package. My patch to shlexec.c is the only patch that is likely to be rejected (it's totally the wrong way to do things, but I only had an hour to make something work). As for your specific implementation, it sounds resonable to me. The behaviour I would expect is that mozilla for linux would be launched if no browsers are installed under wine. But if you install a browser under wine, then it would automatically be the default. On the other hand, I might want to install ie under wine but still use linux for mozilla by default. So maybe there could be a config file option or something so that you can say 'prefer linux browser'. I realize I could edit the registry and change the setting back to mozilla, but: (a) it's way to geeky for most people (b) I would have to change the registry everytime ie reclaims control. Jeremy Shaw. At Sat, 27 Dec 2003 21:56:33 -0500, Chris Morgan wrote:
Bleh. I meant that I symlinked /c/windows/system/winebrowser.exe to /usr/ local/bin/winebrowser.
Chris
On Saturday 27 December 2003 09:50 pm, Chris Morgan wrote:
In trying to install the United Devices application the installer prompts me to go to a website to get the msi installer. Wine doesn't have a HKEY_LOCAL_MACHINE\software\classes\http\shell\open\command key in the registery. I was thinking about making a shell script something along the lines of:
if browserX exists browserX $1 else if browserY exists browserY $1 ...
I would imagine most people have mozilla installed on their machines and we can check for konqueror, opera and other browsers. I've created a simple 'winebrowser' script, placed it in /usr/local/bin manually thus far, set the value for the above key to 'winebrowser %1' and symlinked /wine/system/ winebrowser.exe to /usr/local/bin/winebrowser.
Sound reasonable? Comments? ;-)
Chris
On Saturday 27 December 2003 11:33 pm, Jeremy Shaw wrote:
Hello,
I like the idea. Under LindowsOS, I hacked up the shlexec.c so that if no browsers are installed under wine, it tries to run mozilla (for linux). This is because the xten sipphone software attempts to open web pages in a few circumstances, and we want that to work.
Ideally, we want the xten client to run under wine without any special LindowsOS patches, because it will be much easier for us to keep the version of wine in the CNR warehouse up-to-date if we can just use the default debian package. My patch to shlexec.c is the only patch that is likely to be rejected (it's totally the wrong way to do things, but I only had an hour to make something work).
As for your specific implementation, it sounds resonable to me. The behaviour I would expect is that mozilla for linux would be launched if no browsers are installed under wine. But if you install a browser under wine, then it would automatically be the default.
My thought exactly on the default behavior. When the new browser is installed under wine it should ask you "Do you want X to be your default browser?" If you answer yes it will modify the registry key that I mentioned and become the new default. So this should work as expected.
On the other hand, I might want to install ie under wine but still use linux for mozilla by default. So maybe there could be a config file option or something so that you can say 'prefer linux browser'. I realize I could edit the registry and change the setting back to mozilla, but:
(a) it's way to geeky for most people
(b) I would have to change the registry everytime ie reclaims control.
I'm not sure how to solve (b) since it happens all of the time under windows when you run both IE and mozilla, each one can ask you on startup whether it should be the new default browser. For (a) I would imagine we should add an option to winecfg at some point to list the available browsers, maybe search for most of the likely ones, and let the user choose their own but this may be far down the road.
Alright, here is a patch and script file. One interesting thing, I can run konqueror fine but mozilla appears to have some issue starting up. I get these odd error messages on the console with mozilla: Failed to create E:\/gconfd-cmorgan: No such file or directory Failed to create E:\/gconfd-cmorgan: No such file or directory Is this due to wine setting the TEMP environment variable? I've tried overriding that in the winebrowser script but it doesn't seem to make any difference. Ideas on how to fix this? One other issue, what to do when the user doesn't have a web browser installed? I can't imagine this is a likely case but in any event since the script will exist there won't be any kind of error returned by ShellExecute() when it is called on a url. Not something to worry about? * tools/winebrowser, tools/wineinstall, tools/Makefile.in, winedefault.reg Chris Morgan <cmorgan(a)alum.wpi.edu> Add HKEY_LOCAL_MACHINE\software\classes\http\shell\open\command key and value. Winebrowser script. Makefile changes to install/remove script. Wineinstall should create a simlink from windows/winebrowser.exe to the location of winebrowser on the machine. Chris On Saturday 27 December 2003 09:50 pm, Chris Morgan wrote:
In trying to install the United Devices application the installer prompts me to go to a website to get the msi installer. Wine doesn't have a HKEY_LOCAL_MACHINE\software\classes\http\shell\open\command key in the registery. I was thinking about making a shell script something along the lines of:
if browserX exists browserX $1 else if browserY exists browserY $1 ...
I would imagine most people have mozilla installed on their machines and we can check for konqueror, opera and other browsers. I've created a simple 'winebrowser' script, placed it in /usr/local/bin manually thus far, set the value for the above key to 'winebrowser %1' and symlinked /wine/system/ winebrowser.exe to /usr/local/bin/winebrowser.
Sound reasonable? Comments? ;-)
Chris
On Sun, 28 Dec 2003 17:54:03 -0500, you wrote:
Is this due to wine setting the TEMP environment variable? I've tried overriding that in the winebrowser script but it doesn't seem to make any difference. Ideas on how to fix this?
unset TMP TEMP Rein. -- Rein Klazes rklazes(a)xs4all.nl
Very nice. This fixes it completely. I had tried to do things like TMP=/tmp and TEMP=/tmp but it didn't work for whatever reason. Chris On Monday 29 December 2003 06:42 am, Rein Klazes wrote:
On Sun, 28 Dec 2003 17:54:03 -0500, you wrote:
Is this due to wine setting the TEMP environment variable? I've tried overriding that in the winebrowser script but it doesn't seem to make any difference. Ideas on how to fix this?
unset TMP TEMP
Rein.
On Sat, 27 Dec 2003 21:50:57 -0500, you wrote:
Sound reasonable? Comments? ;-)
Under KDE it should be enough to do: kfmclient exec "${file}" choosing in case of a html file the default browser configured for KDE. It works also for eg .mp3 files, but then the file spec must have been converted from WINE to Unix paths, for instance with "winepath". Rein. -- Rein Klazes rklazes(a)xs4all.nl
Rein Klazes wrote:
Under KDE it should be enough to do:
kfmclient exec "${file}"
choosing in case of a html file the default browser configured for KDE. It works also for eg .mp3 files, but then the file spec must have been converted from WINE to Unix paths, for instance with "winepath".
Makes me nervous... the ability to cause code to execute is one of the most frequently abused powers of IE. Besides, wine isn't kde specific; we can't rely on kfmclient to exist. It would be better to make use of http://freedesktop.org/Standards/shared-mime-info-spec That way it would work with not just KDE, but also Gnome and any other freedesktop.org-compliant environment. - Dan
The potential to exploit the kfmclient does seem like something to at least consider. Is there some way we can protect the user against this or should the 'kfmclient exec' be dropped due to its potential for being exploited? We may need a translation table to effectively use the mime database. http\ \shell is the windows key, text/html is the mime type. Not sure how other types map, like mp3 or avi on windows, too lazy to check atm ;-) It seems like a very worthwhile thing to do though. Chris On Monday 29 December 2003 10:13 pm, Dan Kegel wrote:
Rein Klazes wrote:
Under KDE it should be enough to do:
kfmclient exec "${file}"
choosing in case of a html file the default browser configured for KDE. It works also for eg .mp3 files, but then the file spec must have been converted from WINE to Unix paths, for instance with "winepath".
Makes me nervous... the ability to cause code to execute is one of the most frequently abused powers of IE.
Besides, wine isn't kde specific; we can't rely on kfmclient to exist. It would be better to make use of http://freedesktop.org/Standards/shared-mime-info-spec That way it would work with not just KDE, but also Gnome and any other freedesktop.org-compliant environment. - Dan
On Mon, 29 Dec 2003 19:13:17 -0800, you wrote:
Rein Klazes wrote:
Under KDE it should be enough to do:
kfmclient exec "${file}"
choosing in case of a html file the default browser configured for KDE. It works also for eg .mp3 files, but then the file spec must have been converted from WINE to Unix paths, for instance with "winepath".
Makes me nervous... the ability to cause code to execute is one of the most frequently abused powers of IE.
Well, disable or do not use IE then. Double clicking on an mp3 file to play it is not something that should make you nervous. Plenty of users take it for granted and wonder what is wrong when it doesn't work. And we are discussing using the Unix mime type database and we are using Unix programs. IE knows nothing about that, how can it abuse it to execute malicious code?. (or do I miss your point somewhere?)
Besides, wine isn't kde specific; we can't rely on kfmclient to exist. It would be better to make use of http://freedesktop.org/Standards/shared-mime-info-spec That way it would work with not just KDE, but also Gnome and any other freedesktop.org-compliant environment.
Of course, I wanted to take the discussion to integrating with the desktop and away from coding ourselves lists of browsers that may be available. I am a Gnome user myself. Last time is researched this, Gnome did not have the equivalent of kfmclient. It required some gtk programming. This may have changed, or maybe kfmclient will become gnome compatible at some time. I don't know. Rein. -- Rein Klazes rklazes(a)xs4all.nl
Rein Klazes wrote:
Under KDE it should be enough to do:
kfmclient exec "${file}"
Makes me nervous... the ability to cause code to execute is one of the most frequently abused powers of IE.
Double clicking on an mp3 file to play it is not something that should make you nervous. ...
(or do I miss your point somewhere?)
I'm fine with being able to run the right helper app for various mime types. It's just that "exec file" phrase that makes me nervous. I'm afraid kfmclient will have a mapping for shell scripts!
Besides, wine isn't kde specific; we can't rely on kfmclient to exist. It would be better to make use of http://freedesktop.org/Standards/shared-mime-info-spec That way it would work with not just KDE, but also Gnome and any other freedesktop.org-compliant environment.
Of course, I wanted to take the discussion to integrating with the desktop and away from coding ourselves lists of browsers that may be available.
I am a Gnome user myself. Last time is researched this, Gnome did not have the equivalent of kfmclient. It required some gtk programming. This may have changed, or maybe kfmclient will become gnome compatible at some time. I don't know.
Both KDE and Gnome are moving, if slowly, towards using the same mime type helper database. IMHO we should avoid all use of legacy KDE or Gnome code, and use the freedesktop.org protocols which KDE and Gnome support (or will soon support) for accessing the mime helper database. - Dan
participants (4)
-
Chris Morgan -
Dan Kegel -
Jeremy Shaw -
Rein Klazes