February 2014 - Wine-Devel - list.winehq.org

Re: winemac.drv: Improve positioning of IME client window based on caret

by Ken Thomases

On Feb 19, 2014, at 4:19 PM, Aric Stewart wrote: > humm, so how should i determine line height? I don't think you can. It's not a well-formed concept. Windows don't have any inherent line height property (directly or indirectly). Have you tried the GetGUIThreadInfo() approach and rcCaret? You're trying to fix the case when using GetCaretPos() but maybe we shouldn't be using that. If you're thinking forward to IMC_SETCANDIDATEPOS, then a horrible kludge might be to return a rect whose bottom left is at the specified point and which extends up and to the right to the screen boundaries. The idea is to try to make the input method position its candidate window so its top-left is at the specified point. It will likely align its left side with the left side of the character rect we return (for left-to-right languages, at least) and, by taking up the area of the screen above and to the right of that point, you force the candidate window to be below the rect. -Ken

Feb. 19, 2014

FFE (force feedback) file format reverse engineered

by Elias Vanderstuyft

Hi, Two weeks ago, I started working on reverse engineering the FFE file format, because the functionality to load and write is currently not available in Wine: http://wiki.winehq.org/ForceFeedbackSummerOfCode2005Summary " Missing functionality: - Reading and writing FF effects to files (IDirectInputDevice8::WriteEffectToFile and IDirectInputDevice8::EnumEffectsInFile) have not been implemented. They are stored in a RIFF file, the details of which are undocumented. Given the nature of RIFF, it should be relatively simple (albeit time-consuming) to determine the exact format of the effect files. " So I wrote a Python program that can read and validate FFE files, based on my assumption of the file format structure. In the Python file: - I tried to maximally expose the relation of the FFE file contents and the RIFF structure. - Every single bit in the FFE file will be tested/validated, and the program will throw a 'Warning' when something odd/against my assumptions, occurred with the file of interest. I did not yet implement write functionality in the Python file, but it should not be difficult (~inverse operation of read). For the CustomForce effect, my assumptions are hypothetical: there was no way to test it, because: - I did not find any file containing such effect - I couldn't create such file, because FEdit.exe does not support CustomForce effects to be created. This should be a starting point to implement these read and write stubs in Wine. I don't have time to do that now, so, maybe someone else is interested to do so? Any feedback is welcome, Best regards, Elias

Feb. 19, 2014

Re: winemac.drv: Improve positioning of IME client window based on caret

by Aric Stewart

On 2014/02/20 6:57, Ken Thomases wrote: > On Feb 19, 2014, at 3:42 PM, Aric Stewart wrote: > >> On 2014/02/20 0:32, Ken Thomases wrote: >>> I don't think this does what you want. GetDC() typically returns a DC whose parameters were reset. It doesn't know what font has previously been used in the window. So, you're basically getting the metrics for the System font. I suppose that may be better than nothing. >> >> I never knew that about GetDC, I did not see anything about reset parameters in MSDN. > > It's the first paragraph of the Remarks. <http://msdn.microsoft.com/en-us/library/windows/desktop/dd144871%28v=vs.85%…> Don't be confused by the last sentence with its mention of GetTextFace(). That's not a solution to the problem described in the rest of the paragraph; it's a non sequitur. > >> It was working for me pretty accurately in my testing even with different fonts. Is there a way to get the font metrics from a window handle? > > No. This isn't a property of the window in the common case. It's only a property of the DC, which may exist only temporarily while drawing. And one may select various fonts into the DC at different times to draw different parts of the window. > humm, so how should i determine line height? -aric

Feb. 19, 2014

Re: ff-core effect id handling in case of a failed effect upload

by Elias Vanderstuyft

On Wed, Feb 19, 2014 at 10:05 PM, Dmitry Torokhov <dmitry.torokhov(a)gmail.com> wrote: > On Wed, Feb 19, 2014 at 06:49:36PM +0200, Anssi Hannula wrote: >> (added Dmitry to CC) >> >> 19.02.2014 13:42, Elias Vanderstuyft kirjoitti: >> > Hi, >> > >> >> Hi, >> >> > In the process of reviewing the Wine DInput translation layer, I >> > noticed an inconvenience (in the ff-core implementation?) that can >> > possibly lead to confusing problems to application developers (not >> > only for Wine), in short: >> > If a new (id==-1) effect was uploaded (look at >> > ff-core.c::input_ff_upload(...)) that failed (e.g. returning EINVAL), >> > ff-core will have assigned a positive number to the effect id. This >> > can be confusing because the dev->ff->effects[] array will not contain >> > an element at the index of that new effect id. >> >> I agree that this is a bit confusing, and the kernel code should >> probably be modified to not clobber the ioctl-provided effect on failure >> (effect->id is set to an "undefined" value, i.e. next free effect slot). >> >> Dmitry, WDYT? > > Yeah, it looks like we need to change evdev.c to read: > > error = input_ff_upload(dev, &effect, file); > if (error) > return error; > > if (put_user(effect.id, &(((struct ff_effect __user *)p)->id))) > return -EFAULT; > > return 0; Alright, who will create the patch? Do I may / have to do it? > > Unfortunately applications should still expect changed effect ID for > quite some time. > > Thanks. > > -- > Dmitry Best regards, Elias

Feb. 19, 2014

Re: winemac.drv: Improve positioning of IME client window based on caret

by Ken Thomases

On Feb 19, 2014, at 3:42 PM, Aric Stewart wrote: > On 2014/02/20 0:32, Ken Thomases wrote: >> I don't think this does what you want. GetDC() typically returns a DC whose parameters were reset. It doesn't know what font has previously been used in the window. So, you're basically getting the metrics for the System font. I suppose that may be better than nothing. > > I never knew that about GetDC, I did not see anything about reset parameters in MSDN. It's the first paragraph of the Remarks. <http://msdn.microsoft.com/en-us/library/windows/desktop/dd144871%28v=vs.85%…> Don't be confused by the last sentence with its mention of GetTextFace(). That's not a solution to the problem described in the rest of the paragraph; it's a non sequitur. > It was working for me pretty accurately in my testing even with different fonts. Is there a way to get the font metrics from a window handle? No. This isn't a property of the window in the common case. It's only a property of the DC, which may exist only temporarily while drawing. And one may select various fonts into the DC at different times to draw different parts of the window. -Ken

Feb. 19, 2014

Re: winemac.drv: Improve positioning of IME client window based on caret

by Aric Stewart

On 2014/02/20 0:32, Ken Thomases wrote: > On Feb 19, 2014, at 3:08 AM, Aric Stewart wrote: > >> diff --git a/dlls/winemac.drv/ime.c b/dlls/winemac.drv/ime.c >> index 2c74f6e..066c77a 100644 >> --- a/dlls/winemac.drv/ime.c >> +++ b/dlls/winemac.drv/ime.c >> @@ -1585,14 +1585,20 @@ BOOL query_ime_char_rect(macdrv_query* query) >> if (focus && (focus == hwnd || IsChild(hwnd, focus)) && >> GetClientRect(focus, &charpos.rcDocument)) >> { >> + HDC hdc = GetDC(focus); >> + TEXTMETRICA tm; >> + >> if (!GetCaretPos((POINT*)&charpos.rcDocument)) >> charpos.rcDocument.left = charpos.rcDocument.top = 0; >> >> + GetTextMetricsA(hdc, &tm); >> charpos.rcDocument.right = charpos.rcDocument.left + 1; >> + charpos.rcDocument.bottom = charpos.rcDocument.top + tm.tmHeight; >> MapWindowPoints(focus, 0, (POINT*)&charpos.rcDocument, 2); >> >> *rect = cgrect_from_rect(charpos.rcDocument); >> ret = TRUE; >> + ReleaseDC(focus, hdc); >> } >> } > > I don't think this does what you want. GetDC() typically returns a DC whose parameters were reset. It doesn't know what font has previously been used in the window. So, you're basically getting the metrics for the System font. I suppose that may be better than nothing. I never knew that about GetDC, I did not see anything about reset parameters in MSDN. It was working for me pretty accurately in my testing even with different fonts. Is there a way to get the font metrics from a window handle? I am going to need that for when I am implementing the Candidate Window stuff also. > > Also, you don't check if GetTextMetricsA() succeeded. > True. > > Perhaps using GetGUIThreadInfo() and the rcCaret field of the GUITHREADINFO structure would be better than using GetCaretPos(). In that case, you'd map the coordinates from hwndCaret (which may be different from "focus") to the screen. Be sure to read the remarks in the MSDN docs for the GetGUIThreadInfo() function about how to use rcCaret, although it's not clear to me if Wine implements this faithfully. > I will look into this, I have a number of programs where GetCaretPos is not returning correct information anyway so an alternative would be useful. -aric

Feb. 19, 2014

Re: ff-core effect id handling in case of a failed effect upload

by Dmitry Torokhov

On Wed, Feb 19, 2014 at 06:49:36PM +0200, Anssi Hannula wrote: > (added Dmitry to CC) > > 19.02.2014 13:42, Elias Vanderstuyft kirjoitti: > > Hi, > > > > Hi, > > > In the process of reviewing the Wine DInput translation layer, I > > noticed an inconvenience (in the ff-core implementation?) that can > > possibly lead to confusing problems to application developers (not > > only for Wine), in short: > > If a new (id==-1) effect was uploaded (look at > > ff-core.c::input_ff_upload(...)) that failed (e.g. returning EINVAL), > > ff-core will have assigned a positive number to the effect id. This > > can be confusing because the dev->ff->effects[] array will not contain > > an element at the index of that new effect id. > > I agree that this is a bit confusing, and the kernel code should > probably be modified to not clobber the ioctl-provided effect on failure > (effect->id is set to an "undefined" value, i.e. next free effect slot). > > Dmitry, WDYT? Yeah, it looks like we need to change evdev.c to read: error = input_ff_upload(dev, &effect, file); if (error) return error; if (put_user(effect.id, &(((struct ff_effect __user *)p)->id))) return -EFAULT; return 0; Unfortunately applications should still expect changed effect ID for quite some time. Thanks. -- Dmitry

Feb. 19, 2014

Re: [PATCH] user32: Fix RealGetWindowClass() to return what it's supposed to for same process windows (try3)

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -1098,22 +1098,81 @@ INT WINAPI GetClassNameW( HWND hwnd, LPWSTR buffer, INT count ) > return ret; > } > > +static const struct builtin_class_descr *builtin_classes[] = > +{ > + &BUTTON_builtin_class, > + &COMBO_builtin_class, > + &DIALOG_builtin_class, > + &EDIT_builtin_class, > + &LISTBOX_builtin_class, > + &MDICLIENT_builtin_class, > + &SCROLL_builtin_class, > + &STATIC_builtin_class > +}; There's no need to add this either, you can simply store the pointer. -- Alexandre Julliard julliard(a)winehq.org

Feb. 19, 2014

Re: ff-core effect id handling in case of a failed effect upload

by Elias Vanderstuyft

On Wed, Feb 19, 2014 at 8:32 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > On Wed, Feb 19, 2014 at 06:32:54PM +0100, Elias Vanderstuyft wrote: >> I'll include the code (with effectId_old variable) and this discussion >> when I submit my whole patchset for Wine's DInput libs to Wine-devel >> mailing list. Right now, I don't know who I should personally mail to. >> > > Patches ready to be included in Wine should go to > wine-patches(a)winehq.org. I've done a bit of work in dinput myself, so > you can feel free to send them to me and/or wine-devel first if you'd > like a review. <offtopic> Alright, thanks Andrew! I've also done some work on reverse engineering the FFE file format, which is needed to complete some missing functionality (http://wiki.winehq.org/ForceFeedbackSummerOfCode2005Summary) of the following functions: IDirectInputDevice8::WriteEffectToFile and IDirectInputDevice8::EnumEffectsInFile. Can I send it to you (in a new mail subject, of course) and cc wine-devel? </offtopic> > > Andrew Elias

Feb. 19, 2014

Re: ff-core effect id handling in case of a failed effect upload

by Andrew Eikum

On Wed, Feb 19, 2014 at 06:32:54PM +0100, Elias Vanderstuyft wrote: > I'll include the code (with effectId_old variable) and this discussion > when I submit my whole patchset for Wine's DInput libs to Wine-devel > mailing list. Right now, I don't know who I should personally mail to. > Patches ready to be included in Wine should go to wine-patches(a)winehq.org. I've done a bit of work in dinput myself, so you can feel free to send them to me and/or wine-devel first if you'd like a review. Andrew

Feb. 19, 2014