August 2007 - Wine-Devel - list.winehq.org

RE: exporting file associations for linux desktops

by Koshelev, Misha Vladislavo

>From: madewokherd(a)gmail.com on behalf of Vincent Povirk >On 8/9/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: ><snip> >> still be able to start both). Using this approach would also solve any >> problems with wine's start not necessarily having the appropriate >> command line parameter support. I am starting to like/favor the >> install-time association approach. > >How would it solve that? > >If you mean we should attempt to start the program directly using the >command-line from Linux instead of ShellExecute, I think this is a >very bad idea. We would suddenly have to worry about setting the >working directory correctly, replacing %1 and anything similar, not to >mention handling those actions that use some other method. We'd pretty >much have to rewrite ShellExecute on the Linux side. That is a good point, especially when you consider things like DDE. If I remember my Windows registry correctly though this would mean only one Win32 application/MIME-type (at least per wine prefix I guess). I guess that means we would have to go through start or some kind of start-like approach. So any info about the non-open verbs being supported on the Linux side of things? Misha

Aug. 9, 2007

Re: exporting file associations for linux desktops

by Vincent Povirk

On 8/9/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: <snip> > still be able to start both). Using this approach would also solve any > problems with wine's start not necessarily having the appropriate > command line parameter support. I am starting to like/favor the > install-time association approach. How would it solve that? If you mean we should attempt to start the program directly using the command-line from Linux instead of ShellExecute, I think this is a very bad idea. We would suddenly have to worry about setting the working directory correctly, replacing %1 and anything similar, not to mention handling those actions that use some other method. We'd pretty much have to rewrite ShellExecute on the Linux side. -- Vincent Povirk

Aug. 9, 2007

Re: exporting file associations for linux desktops

by Misha Koshelev

On Thu, 2007-08-09 at 13:24 +0200, Stefan Dösinger wrote: > Another drawback of using a general "wine start" to call the windows apps is > that we sacrifice a bit of desktop integration. It would be cool if the Linux > mime type generated from the wine registry contained the application's name > and icon, instead of some "Open with Wine" name. That is a good point. That favors the winemenubuilder/install-time approach that Steven Edwards suggested. > > I don't know if the registry can assign multiple programs to one mime type, > but KDE can also offer a list of programs if multiple apps can handle one > mime type. If a user has e.g. Internet Explorer and Win32 Opera installed, > then he should see both IE and Opera next to the Linux apps he has installed, > and should be able to select a default for KDE/Gnome, without having to > select a Wine default too. Good point as well. I suppose the winemenubuiler/program install time approach would solve this problem too (if you installed IE and then Win32 Opera we would keep the mime types around in Linux so you would still be able to start both). Using this approach would also solve any problems with wine's start not necessarily having the appropriate command line parameter support. I am starting to like/favor the install-time association approach. Misha

Aug. 9, 2007

Re: [Winetest] Possible removal of LoadLibrary and friends in the conformance tests

by Detlef Riekenberg

On Di, 2007-08-07 at 09:43 +0200, Paul Vriens wrote: > My plan, and this is open for discussion of course, is to: > > 1. Add the main dll back as part of the IMPORTS in the Makefile.in files Some API are defined once, but implemented many times: The monitor in localspl and localui as examples. You must make sure, that the tests can still be compiled with msvc. (localspl.lib / localui.lib does not exist) -- By by ... Detlef

Aug. 9, 2007

Re: exporting file associations for linux desktops

by Stefan Dösinger

> You will have to forgive my ignorance but I guess my other concern would > be is there even a way for GNOME to handle such verbs at the moment? I > was looking at > http://www.freedesktop.org/wiki/Specifications/mime-actions-spec > and it seems like there is plans for this but, at least according to > that page the spec for this is still in development. Also, just playing > around with a few files on my desktop I could not find any useful way to > invoke verbs other than open, but maybe I am missing something... Another drawback of using a general "wine start" to call the windows apps is that we sacrifice a bit of desktop integration. It would be cool if the Linux mime type generated from the wine registry contained the application's name and icon, instead of some "Open with Wine" name. I don't know if the registry can assign multiple programs to one mime type, but KDE can also offer a list of programs if multiple apps can handle one mime type. If a user has e.g. Internet Explorer and Win32 Opera installed, then he should see both IE and Opera next to the Linux apps he has installed, and should be able to select a default for KDE/Gnome, without having to select a Wine default too.

Aug. 9, 2007

Re: WineD3D: better pixelformat selection code

by H. Verbeet

On 09/08/07, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Hi, > > This code lets WineD3D use the pixelformat of the D3D device. The code helps > on Windows where OpenGL offers multiple pixelformats. > The stencil column is probably useful for determining if we need an stencil attachment for FBOs as well. >+int count_bits(int mask) >+{ >+ int i, count=0; >+ for(i=0; i<32; i++) >+ { >+ if(mask & (1<<i)) >+ count++; >+ } >+ return count; >+} The "classical" way to do that would be something like this: unsigned int count_bits(unsigned int mask) { unsigned int count; for (count = 0; mask; ++count) { mask &= mask - 1; } return count; } Ie, simply mask out the set bits one by one until none are set, rather than looping over all of them.

Aug. 9, 2007

Re: exporting file associations for linux desktops

by Misha Koshelev

On Wed, 2007-08-08 at 21:59 -0400, Vincent Povirk wrote: > Wine start is not quite what I had in mind. Each file type can have > multiple "verbs" (such as open, edit, print..), and I'd like GNOME to > give me the option to use any of the verbs that are available. Wine > start is apparently hard-coded to use the "open" verb. You will have to forgive my ignorance but I guess my other concern would be is there even a way for GNOME to handle such verbs at the moment? I was looking at http://www.freedesktop.org/wiki/Specifications/mime-actions-spec and it seems like there is plans for this but, at least according to that page the spec for this is still in development. Also, just playing around with a few files on my desktop I could not find any useful way to invoke verbs other than open, but maybe I am missing something... > > That may mean it's simple to modify it for my purposes, but there's a > windows equivalent. Changing the way it works to deviate from Windows > may not be a good idea. Yes, very good point. I believe this was one of the reasons I decided not to submit any patches to modify start to work with UNIX paths. Provided we only use the open verb could still use the shell script approach... > > As for converting unix/windows paths, that's what winepath is for. Good point, didn't notice that particular program. Misha

Aug. 9, 2007

Re: user32: CallWindowProc[AW] for mismatched built-in winprocs should take into account if the window is Unicode (with testcase, fixes bug #9198)

by Mikołaj Zalewski

>> >> static const char classA[] = "deftest"; >> static const WCHAR classW[] = {'d','e','f','t','e','s','t',0}; >> + WCHAR unistring[] = {0x142, 0x40e, 0x3b4, 0}; /* a string that >> would be destoryed by a W->A->W conversion */ > > Any other string should work just fine. In the current form the test > will fail > for some locales. It will work as this string is never converted to ANSI. On the other hand if there is a conversion to ANSI I expect it to fail on any locale as the characters are chosen each from a different script. And that's why this string was chosen - to show that we shouldn't try to convert the result of the ANSI function but call the wide function directly. As for the other suggestions I'll send soon an improved patch. Mikolaj Zalewski

Aug. 9, 2007

Re: exporting file associations for linux desktops

by Vincent Povirk

Wine start is not quite what I had in mind. Each file type can have multiple "verbs" (such as open, edit, print..), and I'd like GNOME to give me the option to use any of the verbs that are available. Wine start is apparently hard-coded to use the "open" verb. That may mean it's simple to modify it for my purposes, but there's a windows equivalent. Changing the way it works to deviate from Windows may not be a good idea. As for converting unix/windows paths, that's what winepath is for. -- Vincent Povirk

Aug. 9, 2007

Re: exporting file associations for linux desktops

by Misha Koshelev

> To register those verbs for Linux desktops, some sort of command-line > wrapper around ShellExecute would be needed. I think this is a good > idea anyway. Does Windows have anything like that? Is it worth it for > me to try writing something like that based on winelib? Well this is exactly the start program which is already implemented. In fact I thought about this problem myself a bit, the problems with start right now for this purpose (starting wine associated files from linux) are: 1. start currently doesn't understand a simple UNIX path, easily fixed by prepending a Z: (assuming this is the drive the user has mapped to the UNIX root dir) 2. there is no standalone winestart program, and at least from my experimentation with Right Click->Open File With... on GNOME (or whatever the menu item is called), it won't let you put in "wine start" or wine start or the sort. What I actually do right now is use this shell script (I almost started working on this problem but then since the shell script was so easy I decided to focus on other things, but am still very interested in seeing it solved): #!/bin/sh wine start Z:$* And just associating it with my file type (well the problem with doing what I am doing is I am just associating it with a file .gb which I guess GNOME puts into some kind of text/plain type, so anything that is a text file ends up being opened with notepad on wine instead of gedit... I am too lazy to make it any more complex on my computer for now). Anyway, just though this info might help if you were not already aware, as the start program is definitely this wrapper around ShellExecute that already exists. One possibility would be to extend it to handle UNIX paths and then have it compiled and installed as a standalone winestart - like the other wine standalone programs we install, another is just to have the shell script somewhat like above installed (dangerous as Z: may not be mapped to the root so this would have to figured out) - I believe wineshelllink which is installed is a shell script, or maybe even go the route of letting the wine binary itself ShellExecute things (haven't really looked at it/thought this out in detail). Anyway, just my two cents. Thanks for thinking about/hopefully working on this. Misha > > > -- > Vincent Povirk

Aug. 9, 2007