(Resend, the first email never arrived. I didn't realise one of my
patches was 33k >_<)
I've thrown together a rather-rough-but-working-in-a-limited-sense
implementation of XInput2-based DirectInput.
It's got a fair few problems, I'm mainly interested in feedback on
the approach, although obviously any code or style criticisms are
welcome.
Current limitations:
* Doesn't check for XInput2.h, so it won't build without it. (Laziness)
It will _run_ without XInput2, falling back to the …
[View More]current dinput
WndProc hooks even if compiled with XInput2 support.
* Doesn't send button-ups; XI2 can't distinguish button up from down
* Doesn't send events after button-down until after button-up on a window.
I'm pretty sure this is an XI2 bug, but it might be a design feature.
* Doesn't support exclusive mode. XI2 bug (grabs not yet implemented)
Hopefully this can be implemented entirely within the dinput code in
winex11drv (ie disabling and hiding the mouse on acquire. dinput
already takes care of unacquiring when we are no longer the foreground
app)
* Mouse buttons aren't remapped nicely downwards.
Need to look harder at this, my mouse reports buttons 1, 2, 3, 4, 5,
8, 9, 10, 11 and 12 under X. 4 and 5 are scroll, 6 and 7 might be
horizontal scroll in which case if this is always the case we can
just remap downwards. Might need to implement device querying to
confirm mouse button mapping...
* Only supports the Mouse. Adding keyboard support should be really
trivial compared to actually getting the framework right.
* Doesn't detect capabilities... A mouse with a horizontal scroll
wheel'd have four axes. I haven't looked to see if DirectInput
can support that, or if our dinput code can easily accomodate more
axes or buttons than the current 3/8 setup. This the point we'd need
another callthrough from gdimouse to the graphics driver.
* Assumes a process will only try and acquire the mouse once. I'm
not sure that this is a bad assumption, and it might be that dinput
makes this a valid assumption for us.
* Assumes no one else wants GenericEvents. Some day we'll need a
GenericEvent handler system inside WineX11, particularly if wintab
gets converted to XInput 2 support. Easy enough to do now if wanted.
* gdimouse uses Wine Mouse GUID value. I'm not sure where these come
from, if anywhere. Trivial to fix before submission.
If this format is fine, then the first patch is basically ready to go,
the latter two patches may need to be re-split or merged more sensibly.
In the libs folder I've also attached a couple of fixes for the XI2
stuff if anyone wants to try it. One only affects 64-bit builds, and one
fixes XCB locking assertions which you could probably otherwise ignore.
So they're both kinda optional in the Wine context.
Also one more patch, against the xinput utility from whot's git tree, to
fix a compile failure in the XI2 test functionality.
--
Paul "TBBle" Hampson, Paul.Hampson(a)Pobox.com
Shorter .sig for a more eco-friendly paperless office.
[View Less]
--- On Thu, 28/5/09, Luke Bratch <l_bratch(a)yahoo.co.uk> wrote:
> In a couple of weeks I'm going to be travelling around
> India for about a month, from 14th June - 17th July, so I'll
> need somebody to cover list moderation during that period.
>
> It's a simple task; you just need to bring up a web page
> for each list a couple of times per day, and single out any
> genuine messages that are awaiting approval, discarding the
> rest.
>
> You'll need to do …
[View More]it almost every day for the whole month,
> otherwise people will start to wonder where their mail is
> getting to.... :)
>
> If you are interested, please email me directly.
No responses so far - anybody?
Luke
[View Less]
Stephan Rose wrote:
> Adds support for aligning a string inside the given bounding rectangle
> for GdipDrawString. Both vertical and horizontal alignments implemented.
>
>
> ------------------------------------------------------------------------
>
>
Hi Stephan,
No remarks about the real contents of the patch (not my area of expertise).
You are mixing tabs and spaces in this patch. This file uses 4 space
indentation, please stick to that.
The use of curly brackets …
[View More]is also not consistent. Looks like the rest of
the file puts the opening curly bracket right after the closing round
bracket (not even a space in between), like you do here:
+ if(format){
but a bit further you do:
+ if(format->vertalign != StringAlignmentNear)
+ {
Usually when patches are created, one should try to adhere to the style
of the file touched.
--
Cheers,
Paul.
[View Less]
>I don't know why gdiplus does its own linebreaks. I haven't really
>done any work in that area.
>
>If I had to guess, I'd say it's because StringFormatFlagsNoWrap has no
>equivalent flag for DrawText. That probably means you can't pass it
>off to DrawText.
>
>Since they'll probably have to be done differently, it's best to
>implement one direction at a time. When you're happy with horizontal
>alignment, you can send a patch for that regardless of the status of
…
[View More]>vertical alignment.
>
>You should be able to use GdipMeasureString to get the size of the
>text. In fact, the alignments will need to be implemented there too,
>and it may be better to start there.
Hmm the only way I can see alignments having any influence on MeasureString would be if the boundingBox of the text is to be aligned to the layoutRect based on the alignment flags. Should just be able to then take the calculated bounding rect and align that to the layout based on the flags.
And you're right, if I use MeasureString I solve my issue where I don't know the height of the text ahead of time. Perfect.
Thanks,
Stephan
[View Less]
To the list as well.
-------- Original Message --------
Subject: Re: DIB engine
Date: Mon, 01 Jun 2009 19:09:15 -0700
From: James McKenzie <jjmckenzie51(a)earthlink.net>
To: Andrew Eikum <andrew(a)brightnightgames.com>
References:
<a71bd89a0905301414j5bd70f74y3441d367b49bc5f0(a)mail.gmail.com>
<1243755935.4535.1.camel@stephan-desktop>
<4A22AD55.5020306(a)brightnightgames.com>
<b6bb06270905311154w2b9ccb12jee6d64ea587f9524(a)mail.gmail.com>
<4A22D65A.…
[View More]3030205(a)brightnightgames.com>
Andrew Eikum wrote:
> Austin English wrote:
>> On Sun, May 31, 2009 at 11:16 AM, Andrew
>> <andrew(a)brightnightgames.com> wrote:
>>
>>> My name's Andrew Eikum, I'm an undergraduate Computer Science
>>> student at the
>>> University of Minnesota. I contacted a Wine dev a few weeks ago
>>> asking for
>>> a small project to use to get familiar with Wine. I was pointed
>>> towards the
>>> gdiplus section and told to begin stubbing out the missing
>>> functions, to
>>> facilitate debugging. After familiarizing myself with how Wine's
>>> DLLs are
>>> built, and with Git, I'm now making quick progress. I expect to have a
>>> (huge) patchset ready in the next week or two with most of the gdiplus
>>> functions stubbed.
>>>
>>> After that, I plan to begin work on implementing some of the
>>> functions. My
>>> degree's emphasis is computer graphics, so working on gdiplus will
>>> give me a
>>> chance to learn more about the field as well as apply what I already
>>> know.
>>> I'm looking forward to working with other Wine devs on gdiplus, and
>>> other
>>> parts of Wine in the future.
>>>
>>
>> Welcome to Wine!
>>
>> Be sure when sending patches to break them into small sets, with one
>> change per patch. It makes it much easier to review that way, and if
>> your patch causes a regression, much easier to identify which part if
>> it's in multiple patches.
>>
> Thanks for the welcome!
>
> I am definitely doing small commits and following the WineGit wiki
> page. One concern I have is that the number of patches will probably
> be over 50 or even 75 -- I'm not sure if it'd be better to submit them
> all in one go as they're pretty much all alike (just stubbing), or
> just do batches of 5-10 every couple days as I finish them (so it's
> not a deluge of patches). Any suggestions?
>
>
>
I'll second what Austin said. Please send in like the following:
[1/2] Test for some gdiplus Windows function with todo_wine wrapper
that demonstrates default Windows function from a source other than
reverse-engineering (this is an absolute no-no.)
[2/2] Code that implements the default function along with code to
remove todo_wine wrapper.
This way if your second code breaks something, the test will be in place
and the todo_wine wrapper will remain.
James McKenzie
[View Less]