On 02/08/13 21:02, Alexandre Julliard wrote:
Folks,
I'll be on vacation for the next 10 days, so you'll have to live without
commits for a while...
They let you have time off? Unbelievable!
Have a good un!
Folks,
I'll be on vacation for the next 10 days, so you'll have to live without
commits for a while...
--
Alexandre Julliard
julli...@winehq.org
Am 02.08.2013 08:13, schrieb Austin English:
> On Thu, Aug 1, 2013 at 11:03 PM, Kyle Auble wrote:
>> So I've finished with pretty much all of the edits I had in mind for
>> the wiki, but before I ride off into the sunset for a while, I wanted
>> to toss out a few ideas.
> ..
>> 2. There's still a
Frédéric Delanoy writes:
> That's just replacing the Tabs by spaces in the affected lines. The
> affected lines were using a mix of tabs and spaces
>
> It's indented two spaces from the parent listitem tag as it was before
> (at least when tabs are displayed as 4 chars)
>
> Should I keep those t
On Fri, Aug 2, 2013 at 2:25 PM, Alexandre Julliard wrote:
> Frédéric Delanoy writes:
>
>> @@ -710,17 +714,18 @@ Path="c:\windows;c:\windows\system;e:\;e:\test;f:\"
>> choose between several edition modes:
>>
>>
>> -
Ken Thomases writes:
> On Aug 2, 2013, at 9:57 AM, Ken Thomases wrote:
>
>> OK. So, is it acceptable to load AppKit regardless of which graphics driver
>> is configured?
>
> And, if so, would you prefer that I just link gdi32 against AppKit
> rather than loading it dynamically? That would mean
2013/8/2 Alexandre Julliard :
> Caibin Chen writes:
>
>> diff --git a/dlls/riched20/tomimpl.h b/dlls/riched20/tomimpl.h
>> new file mode 100644
>> index 000..886c3a8
>> --- /dev/null
>> +++ b/dlls/riched20/tomimpl.h
>> @@ -0,0 +1,59 @@
>> +/*
>> + * RichEdit - TOM interfaces implementations
>>
On Aug 2, 2013, at 9:57 AM, Ken Thomases wrote:
> OK. So, is it acceptable to load AppKit regardless of which graphics driver
> is configured?
And, if so, would you prefer that I just link gdi32 against AppKit rather than
loading it dynamically? That would mean that it would be loaded even fo
On Aug 2, 2013, at 9:19 AM, Alexandre Julliard wrote:
> Ken Thomases writes:
>
>> On Aug 2, 2013, at 4:22 AM, Alexandre Julliard wrote:
>>> That's ugly. freetype.c has no business knowing about the details of the
>>> graphics driver.
>>
>> Is it acceptable to load the graphics driver at that po
Nikolay Sivov writes:
> +static void reader_normalize_space(xmlreader *reader, WCHAR *ptr)
> +{
> +encoded_buffer *buffer = &reader->input->buffer->utf16;
> +
> +if (!is_wchar_space(*ptr)) return;
> +
> +if (*ptr == '\r' && *ptr == '\n')
That's not going to happen very often...
--
On Fri, Aug 02, 2013 at 04:29:07PM +0200, Alexandre Julliard wrote:
> Marcus Meissner writes:
>
> > Triggered by the Novell Groupwise installer currently,
> > from the ISBE64W.exe Installshield Helper program.
> >
> > The typelib is contained directly in ISBE64W.exe itself :/
> >
> > Basically if
Marcus Meissner writes:
> Triggered by the Novell Groupwise installer currently,
> from the ISBE64W.exe Installshield Helper program.
>
> The typelib is contained directly in ISBE64W.exe itself :/
>
> Basically if we encounter this case the program will crash
> anyway (but with random backtrace),
Ken Thomases writes:
> On Aug 2, 2013, at 4:22 AM, Alexandre Julliard wrote:
>> That's ugly. freetype.c has no business knowing about the details of the
>> graphics driver.
>
> Is it acceptable to load the graphics driver at that point, by calling
> DRIVER_load_driver("display", …)?
That code i
On Aug 2, 2013, at 4:22 AM, Alexandre Julliard wrote:
> Ken Thomases writes:
>
>> +/* If the Mac driver might be used, then load AppKit now before using
>> the Core Text API.
>> + Otherwise, AppKit crashes on Mac OS X 10.7+ because CTFontDescriptor
>> isn't toll-free
>> + bridg
De : Matteo Bruni
À : Nozomi Kodama
Cc : Wine Devel
Envoyé le : Jeudi 1 août 2013 9h46
Objet : Re: d3dx9 [patch 1/2]: Implement D3DXCreatePolygon
2013/8/1 Nozomi Kodama :
>
+ vertices = HeapAlloc(GetProcessHeap(), 0, 2 * (sides + 1) *
sizeof(D3DXVEC
On 02/08/13 12:05, Alexandre Julliard wrote:
Ken Sharp writes:
On 02/08/13 10:57, Alexandre Julliard wrote:
Ken Sharp writes:
Hi Alexandre,
http://source.winehq.org/patches/data/97460 should be correct but
would I be right in assuming you would rather have the changes made
along with th
Frédéric Delanoy writes:
> @@ -710,17 +714,18 @@ Path="c:\windows;c:\windows\system;e:\;e:\test;f:\"
> choose between several edition modes:
>
>
> -
> - Emacs: the same keybind
2013/8/1 Matteo Bruni :
> Instead of generating an entry for the struct with the correct
> members, the compiler generates TWO entries for sbnf, one with all its
> fields in D3DXRS_FLOAT4 and the other with D3DXRS_BOOL. Which, if I'm
> reading this correctly, makes 0 sense.
> Calling GetConstantByN
On Fri, 02 Aug 2013 01:03:34 -0500
Kyle Auble wrote:
>
> 3. There are actually a few more fixes to the theme code at the head
> of my bitbucket repo (and also branches for 2 different Moinmoin
> upgrade paths).
By any chance do any of those fixes/branches take care of
http://bugs.winehq.org/s
Ken Sharp writes:
> On 02/08/13 10:57, Alexandre Julliard wrote:
>> Ken Sharp writes:
>>
>>> Hi Alexandre,
>>>
>>> http://source.winehq.org/patches/data/97460 should be correct but
>>> would I be right in assuming you would rather have the changes made
>>> along with the next string for each lan
On 02/08/13 10:57, Alexandre Julliard wrote:
Ken Sharp writes:
Hi Alexandre,
http://source.winehq.org/patches/data/97460 should be correct but
would I be right in assuming you would rather have the changes made
along with the next string for each language?
You say you want to catch the tr
Ken Sharp writes:
> Hi Alexandre,
>
> http://source.winehq.org/patches/data/97460 should be correct but
> would I be right in assuming you would rather have the changes made
> along with the next string for each language?
You say you want to catch the translators attention, but you are doing
jus
Caibin Chen writes:
> diff --git a/dlls/riched20/tomimpl.h b/dlls/riched20/tomimpl.h
> new file mode 100644
> index 000..886c3a8
> --- /dev/null
> +++ b/dlls/riched20/tomimpl.h
> @@ -0,0 +1,59 @@
> +/*
> + * RichEdit - TOM interfaces implementations
> + *
> + * Copyright 2013 by Caibin Chen
>
Andrew Cook writes:
> diff --git a/dlls/ntdll/tests/Makefile.in b/dlls/ntdll/tests/Makefile.in
> index 10d6674..a44b880 100644
> --- a/dlls/ntdll/tests/Makefile.in
> +++ b/dlls/ntdll/tests/Makefile.in
> @@ -7,6 +7,7 @@ C_SRCS = \
> directory.c \
> env.c \
> error.c \
> + eve
Probably better to post this here rather than the forums:
http://forum.winehq.org/viewtopic.php?f=2&t=19501
"Not sure if this is a Wine bug (as usual) so I'd rather put this here
than to open a new bug.
On Cygwin 1.7.22 the compilation stops at jscript, apparently a conflict
in the declaratio
Nikolay Sivov writes:
> On 8/2/2013 13:33, Alexandre Julliard wrote:
>> Nikolay Sivov writes:
>>
>>> @@ -1031,6 +1105,17 @@ static BOOL parse_window_class_elem(xmlbuf_t*
>>> xmlbuf, struct dll_redirect* dll)
>>> if (!(entity->u.class.name = xmlstrdupW(&content))) return
>>> FALSE;
>>>
Hi Alexandre,
http://source.winehq.org/patches/data/97460 should be correct but would
I be right in assuming you would rather have the changes made along with
the next string for each language?
On 8/2/2013 13:33, Alexandre Julliard wrote:
Nikolay Sivov writes:
@@ -1031,6 +1105,17 @@ static BOOL parse_window_class_elem(xmlbuf_t* xmlbuf,
struct dll_redirect* dll)
if (!(entity->u.class.name = xmlstrdupW(&content))) return FALSE;
+/* each class entry needs index, data an
With all the corrections in-place for Canadian English, the British
English it defaults to is identical (as far as Wine is concerned).
This patch has a couple of errors now so it can be disregarded.
If a separate entry to en_CA is necessary then let me know and I'll
resubmit with the changes,
I've just started looking at the Wiki myself. There's a lot of outdated
stuff on there and it needs a lot of attention.
There's little hope of me helping with anything related to the actual
programming but I'm willing to help with other stuff.
On 02/08/13 07:03, Kyle Auble wrote:
So I've fin
Nikolay Sivov writes:
> @@ -1031,6 +1105,17 @@ static BOOL parse_window_class_elem(xmlbuf_t* xmlbuf,
> struct dll_redirect* dll)
>
> if (!(entity->u.class.name = xmlstrdupW(&content))) return FALSE;
>
> +/* each class entry needs index, data and string data */
> +acl->actctx->wn
Ken Thomases writes:
> +/* If the Mac driver might be used, then load AppKit now before using
> the Core Text API.
> + Otherwise, AppKit crashes on Mac OS X 10.7+ because CTFontDescriptor
> isn't toll-free
> + bridged to NSCTFontDescriptor. That bridging is only set up if
> Ap
On Friday, 2 August 2013 6:58 PM, Nikolay Sivov wrote:
>>> There's no need for separate variable here nor for incrementing pointer.
>> The incrementing pointer is needed because the 'value' is a Byte array. But
>> the separate variable is not needed.
>Yes, so value[i] will do the same.
Yes, you'
On 8/2/2013 12:52, Hugh McMaster wrote:
+case REG_BINARY:
+case REG_NONE:
+pValue = value;
+for (i=0; i
There's no need for separate variable here nor for incrementing pointer.
The incrementing pointer is needed because the 'value' is a Byte array. But the
On Thursday, 1 August 2013 11:55 PM, Nikolay Sivov wrote:
>> +p = strchrW(key_name,'\\');
>> +if (!p)
>> +{
>> +p = 0;
>> +}
>> +else p++;
>I'm not sure what this is supposed to do.
It is equivalent to the following code;
p = strchrW(key_name, '\\');
if (p != N
Charles Davis writes:
> These lines generate what Clang thinks is the header guard for the
> "config.h" header, but we know that it isn't--that header AFAICT has
> never had an include guard, and __WINE_CONFIG_H is just there to
> indicate that it's been included. Should we change the __WINE_CONF
On 02.08.2013 00:03, Christian Costa wrote:
+technique = (D3DXHANDLE)0xdeadbeef;
+hr = effect->lpVtbl->FindNextValidTechnique(effect, technique1,
&technique);
+ok(hr == D3D_OK, "FindNextValidTechnique failed, got %#x, expected %#x\n",
hr, D3D_OK);
+ok(technique == technique2, "T
On 01.08.2013 17:25, Matteo Bruni wrote:
Instead of generating an entry for the struct with the correct
members, the compiler generates TWO entries for sbnf, one with all its
fields in D3DXRS_FLOAT4 and the other with D3DXRS_BOOL. Which, if I'm
reading this correctly, makes 0 sense.
Calling GetC
38 matches
Mail list logo
