"Avankuvan väli:" has this colon on purpose. It's the best way to make
this translation meaningful in the context (Avainkuvan väli: [BOX]
kuvaa). I've already discussed this with you in private. My opinion is
that the original text should be in one piece or at least have a msgctxt
to allow bett
"Thai" is right, "Thain" is wrong. Please don't mess with Finnish if
you don't know it. As I've said, I'm working on it. If you feel I'm too
slow, feel free to hire me and I'll do it faster. ;)
I'm currently away from my computer, but I'll send my patch this
weekend. It will have almost everyt
hello
I am developing the project related to wine. so I have no idea how the
programs are loaded and run by wine, what are the files initially loaded to
the memory ,what are the files loaded to the memory on demand of the
program.Is there any particular pattern of loading programs to memory file
w
Below is a patch which fixes the visuals for me, it simply uses
glXWaitForSbcOML, falling back to glFinish if that's not supported.
Partway through coding this up, I was thinking that maybe listening
for damage events would be more natural. One reason: the current
code is probably imperfect for si
Dmitry Timoshkov wrote:
> ---
> dlls/gdi32/gdiobj.c |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
What's the reason for the 'rejected' status?
--
Dmitry.
On Tue, 14 Feb 2012, Gustavo Henrique Milaré wrote:
[...]
> There are also problems in strings number 119 (line 547) and number 494
> (line 2075). The resource file doesn't allow enough space for the
> appropriate translations ("Vermelho:" and "Adicionar Propósito...",
> respectively).
Did you mea
2012/2/15 Frédéric Delanoy :
> 2012/2/14 Gustavo Henrique Milaré :
>> Hello,
>>
>> I've encountered some issues while translating Wine to Brazilian Portuguese.
>>
>> The first one is in string number 24 (line 150 in wine.pot) which is related
>> to wine control. When you open "wine control" and sel
On 2/16/2012 01:28, Marcus Meissner wrote:
On Thu, Feb 16, 2012 at 01:55:44AM +0300, Nikolay Sivov wrote:
The problem is that vsnprintf() was called multiple times with same
va_list. Ti fix that it was necessary to get rid of some tracing
bits like macro-defined callback calls and a single funct
On Wed, Feb 15, 2012 at 11:28:37PM +0100, Marcus Meissner wrote:
> On Thu, Feb 16, 2012 at 01:55:44AM +0300, Nikolay Sivov wrote:
> > The problem is that vsnprintf() was called multiple times with same
> > va_list. Ti fix that it was necessary to get rid of some tracing
> > bits like macro-defined
On Thu, Feb 16, 2012 at 01:55:44AM +0300, Nikolay Sivov wrote:
> The problem is that vsnprintf() was called multiple times with same
> va_list. Ti fix that it was necessary to get rid of some tracing
> bits like macro-defined callback calls and a single function for all
> kinds of error types.
>
>
Alistair Leslie-Hughes writes:
> @@ -1455,9 +1455,11 @@ static void test_token_attr(void)
> Size = 0;
> ret = GetTokenInformation(Token, TokenGroups, Groups, Size2, &Size);
> ok(Size > 1, "got %d\n", Size);
> -ok(!ret && GetLastError() == ERROR_INSUFFICIENT_BUFFER,
> -"
On Wed, Feb 15, 2012 at 7:37 AM, Vincent Povirk wrote:
> Well, it'll probably just mean we render the brush incorrectly, and
> the program goes on with what it was doing.
>
> It's theoretically possible for a program to break in a case where
> winforms currently catches the exception in .NET (inst
Well, it'll probably just mean we render the brush incorrectly, and
the program goes on with what it was doing.
It's theoretically possible for a program to break in a case where
winforms currently catches the exception in .NET (instead drawing the
famous red X) but will instead move on and break
The right solution is to remove the gdibrush and logbrush fields from
GpBrush, and generate the HBRUSH as needed in brush_fill_path. Note
that brush_fill_path will only be called for solid and hatch brushes
(those for which brush_can_fill_path returns true), so we don't need
the code to create a gd
This won't work. We create gdi32 brushes for hatch brushes based on
temporary bitmaps that won't exist at the time brush_fill_path is
called.
On Wed, Feb 15, 2012 at 2:44 AM, Dmitry Timoshkov wrote:
> This patch fixes the problem reported in the bug 29894.
> ---
> dlls/gdiplus/brush.c
joerg-cyril.hoe...@t-systems.com writes:
> Hi,
>
>>this Fixes bug #28388
>
> I think it is not a good idea to defer this patch until after 1.4.0.
>
> Every app using midiStreamOpen eventually calls SuspendThread
> which is simply a time bomb on a dual core machine. There are many
> more multi-core
Hi,
>this Fixes bug #28388
I think it is not a good idea to defer this patch until after 1.4.0.
Every app using midiStreamOpen eventually calls SuspendThread
which is simply a time bomb on a dual core machine. There are many
more multi-core machines now, so the situation degrades.
Dan Kegel wro
2012/2/14 Gustavo Henrique Milaré :
> Hello,
>
> I've encountered some issues while translating Wine to Brazilian Portuguese.
>
> The first one is in string number 24 (line 150 in wine.pot) which is related
> to wine control. When you open "wine control" and select the icon
> "Add/remove programs",
18 matches
Mail list logo
