Re: user32/tests: SetWindowPos() propagates update region from WS_CLIPCHILDREN child to its children (try 3).
On 2013-03-04 10:39, Sergey Guralnik wrote: This patch demonstrates the most interest case from previous versions. When SetWindowPos() moves child window, that has some invalid area, it also invalidates children of this window according to its update region, even if moved window has WS_CLIPCHILDREN style. Wine doesn't perform this invalidation. One pretty large application depends on this feature, and now, runned under Wine, it has broken output. Hope this variant is more clear than all previous. It stays queued since Monday without any reply. Is something wrong with it? -- Sergey
Re: d3dx9 [patch 1/2, try 3]: Implement D3DXSHEvalConeLight
hello Still problems with this patch? Nozomi.
Re: [PATCH 1/7] winemac: Implement OpenGL support.
On Mar 6, 2013, at 1:58 PM, C.W. Betts wrote: > It seems like there's conflicting types for GLhandleARB, one defined by Wine, > the other by OS X, on Mountain Lion. I assume that the #define __gl_h_ is a > try to work around the issue, but OS X's gltypes.h still gets included. Ugh. Thanks for letting me know. I'll have to investigate. I'm not well set up to build against later SDKs at the moment, but I'll see what I can do. Of course, if you can figure out a solution, that would be great. -Ken
Re: [PATCH 1/7] winemac: Implement OpenGL support.
It seems like there's conflicting types for GLhandleARB, one defined by Wine, the other by OS X, on Mountain Lion. I assume that the #define __gl_h_ is a try to work around the issue, but OS X's gltypes.h still gets included. On Mar 6, 2013, at 3:59 AM, Ken Thomases wrote: > --- > dlls/winemac.drv/Makefile.in|4 +- > dlls/winemac.drv/cocoa_opengl.h | 32 + > dlls/winemac.drv/cocoa_opengl.m | 154 > dlls/winemac.drv/cocoa_window.m | 187 > dlls/winemac.drv/gdi.c |2 +- > dlls/winemac.drv/macdrv.h | 10 + > dlls/winemac.drv/macdrv_cocoa.h | 15 + > dlls/winemac.drv/opengl.c | 1912 +++ > dlls/winemac.drv/window.c | 11 +- > 9 files changed, 2322 insertions(+), 5 deletions(-) > create mode 100644 dlls/winemac.drv/cocoa_opengl.h > create mode 100644 dlls/winemac.drv/cocoa_opengl.m > create mode 100644 dlls/winemac.drv/opengl.c > > <0001-winemac-Implement-OpenGL-support.patch>
Re: ntdll: make NtDelayExecution a bit more efficient
On 03/06/2013 07:10 PM, Graham wrote: > Alexandre wrote: >> That's what the existing code already does. > > Indeed. I don't know what I was thinking... > >>> 2. If you're about to block on select(), then I don't see any point in >>> preceding that with a call to sched_yield(). >> >> This was added for a reason; most likely you'll have to write tests. > > i.e. commit 8099c2b9. JW says "... to more closely resemble Windows > behavior. The key is to yield in a Sleep..." JW is Jeremy White so us old timers chuckle now ;) > I haven't yet figured out how he came up with this analysis, but I > think it's safe to assume that he is correct, and my patch is garbage. > Lesson learned: consult history. "Date: Tue Nov 2 19:32:03 2004 +" and the comment mentions Win2K. If the ancient wisdom isn't backed by tests there's a fair chance that it might not be applicable today. Or that it was a wrong theory back then too. bye michael
Re: ntdll: make NtDelayExecution a bit more efficient
Alexandre wrote: > That's what the existing code already does. Indeed. I don't know what I was thinking... >> 2. If you're about to block on select(), then I don't see any point in >> preceding that with a call to sched_yield(). > > This was added for a reason; most likely you'll have to write tests. i.e. commit 8099c2b9. JW says "... to more closely resemble Windows behavior. The key is to yield in a Sleep..." I haven't yet figured out how he came up with this analysis, but I think it's safe to assume that he is correct, and my patch is garbage. Lesson learned: consult history. -- graham
Re: Use accented letters in their names.
> On 3/4/13, Frédéric Delanoy wrote:
>> On Fri, Mar 1, 2013 at 5:01 PM, Tae Wong wrote:
>>> The authors file is outdated and you want this updated with the
>>> missing authors. Andrej Znidarsic should have Slovenian accented
>>> letters for his last name.
>>>
>>> On 2/4/13, Tae Wong wrote:
You will want to use accented letters in their authors names.
Caolan McNamara
Ferenc Wagner
Marko Nikolic
Every once and a while the GNOME Live website is down with an error on
Netscape called “The operation timed out when attempting to contact .”
- This paragraph should have a website name. You want to be unbanned
in Amaterasu Translations and the DOS ain’t dead forums.
>>
>> Feel free to send a patch to wine-patches fixing those issues.
>>
On Wed, Mar 6, 2013 at 3:02 PM, Tae Wong wrote:
> You’ve sent a patch to wine-patches but never got them fixed!
I didn't send a patch, but you did (well, sort of, this wasn't really
a patch, but a mere email)
See http://wiki.winehq.org/SubmittingPatches for instructions
(http://source.winehq.org/patches/ helps you see what is the status of
your patch, in this case 94687)
Note however that this authors list is likely autogenerated from
git.("John Doo ") email addresses, so it's up to the
patch submitter to correctly spell his/her own name to begin with.
Rewriting the history to fix this seems overkill to me.
Hence, if you fix the AUTHORS file, your changes might be overwritten
the next time the file is generated.
Frédéric
Re: [1/3] Make mac driver the default on OS X
On Mar 6, 2013, at 8:24 AM, wrote: > Bug report: > Toying around with built-in notepad, clock, winhlp32, I noticed that > notepad and winhlp32 are not resizable, whereas the system > preferences "control" is. By comparison, with the x11 driver, > notepad's window is resizable even though it has no triangle > widget at the bottom left. Works here™. I can resize notepad and winhlp32 just fine. > Also, the virtual desktop seems gone or not yet implemented. This is a key > requirement for enough apps that do not handle today's huge resolutions. There is no mechanism for one Mac process to draw into the windows of another. That's key to how the virtual desktop is implemented. So, it's not really possible as things stand. Alexandre and I have considered some sort of shared-memory mechanism, but it's barely into the conceptualization stage, let alone design or implementation. Alternatively, we'd have to recreate X11 – a protocol for shuttling drawing operation requests from one process to another – to fix this. I'm not sure it's worth it. In my experience, the virtual desktop has more often been used to work around X window manager limitations. The hope is that we have greater control with the Mac driver. If all else fails, the X11 driver is still available. > Another annoyance was that there's no HIDE function or short cut and some > dialogues do not provide the orange button (middle one) to iconify the window. > As a result, those pesky windows clutter your screen. > That alone is enough reason to me a reason not to use that driver. It is not > acceptable that one cannot get rid of a set of windows! > Example: wine control, then navigate to the root CA certificates. More items can be added to the menus easily enough. However, I'm loathe to assign the usual keyboard shortcuts. The problem is that the Command key is used to generate Alt keystrokes and it's relatively likely that a Windows program will want to receive Alt-H for its menus. Or, perhaps, a game uses Alt for a player action (e.g. crouch) and H for another action and the user would end up pressing them simultaneously without even considering them a key combination. My principle has been that only keyboard shortcuts that combine Command and Option should be used, since that's unlikely to be pressed by accident. In the case of the Hide menu item, though, Command-Option-H would ordinarily mean Hide Others, just the opposite of Hide. In any case, for the meantime, you can hide a Wine app from its Dock menu. > The menu bar sometimes was refreshed badly, causing some texts therein > to be displayed twice, shifted by a few pixels, or with varying fonts. I'm not familiar with that, but it's not likely to be the fault of the Mac driver. The Mac driver is not really a "graphics" driver. It doesn't draw anything. It uses Wine's relatively new client-side graphics implementation. User32 arranges for the DIB engine to do all of the drawing and then just deliver bitmaps to the Mac driver for it to blit to the window. Are you sure you aren't see the same thing with the X11 driver? -Ken
ntdll: make NtDelayExecution a bit more efficient
You may try and find that MSDN or blog page where people explain the subtle differences of Sleep(0) and Sleep(1) on multi-core machines. Regards, Jörg Höhle
[1/3] Make mac driver the default on OS X
Hi, Ken Thomases wrote: >I think that the Mac driver should not be made the default >until OpenGL and clipboard support are in. Exactly :-( Following Josh DuBois explanation about HKCU/Software/Wine/Drivers "Graphics"="mac,x11" I decided to give it a try over the week-end and was very disappointed to see that seemingly *not any* app would run. It took me some time to understand that they all want graphics. Please don't waste the user's time when such "basics" don't work. What you can do is post to wine-devel and the user forum, asking for people to test your work. That would be polite. Josh DuBois wrote: >I propose an environment variable, WINEDRIVERLOADORDER Too generic. Include "DISPLAY" into the name, if at all, e.g. WINEDISPLAYDRIVER, or "GRAPHICS" as in the registry. The winepulse driver might face similar issues. I have not looked how Maarten thinks that it may coexist nicely with winealsa. Bug report: Toying around with built-in notepad, clock, winhlp32, I noticed that notepad and winhlp32 are not resizable, whereas the system preferences "control" is. By comparison, with the x11 driver, notepad's window is resizable even though it has no triangle widget at the bottom left. Also, the virtual desktop seems gone or not yet implemented. This is a key requirement for enough apps that do not handle today's huge resolutions. Another annoyance was that there's no HIDE function or short cut and some dialogues do not provide the orange button (middle one) to iconify the window. As a result, those pesky windows clutter your screen. That alone is enough reason to me a reason not to use that driver. It is not acceptable that one cannot get rid of a set of windows! Example: wine control, then navigate to the root CA certificates. The menu bar sometimes was refreshed badly, causing some texts therein to be displayed twice, shifted by a few pixels, or with varying fonts. Regards, Jörg Höhle
Re: [1/3] Make mac driver the default on OS X
On 3/6/13 12:24 AM, Ken Thomases wrote: As I believe you're aware, I think that the Mac driver should not be made the default until OpenGL and clipboard support are in. So, maybe this was just submitted in preparation for that time, but there should probably have been a note to that effect. Sure. Also, this patch seems exceedingly complex for a relatively simple problem. Just because it has historically been user32 that reported failure to load the driver doesn't mean it must remain so, at least to my way of thinking. Why not just print out the diagnostics directly in gdi32 as each attempt to load a driver fails? I figured it was that way for a reason, so I was trying to reduce noise in the case that fall-through drivers fail. Even with making mac the first thing we try to load, it seemed that a valid use was setting by hand to, e.g., x11,mac, with working X11 libraries and DISPLAY unset. But yes, it's more complicated: I don't care where they're printed. (The same is true for the ERR->TRACE bits in the third chunk - I certainly don't mind them both staying ERRs, or WARNs. I had interpreted the failure of those things differently until the point at which a window creation was attempted, but maybe that's wrong.) +case ERROR_DLL_INIT_FAILED: +load_err->err_msg = "Make sure you have permission to create \na window or check for errors with Console.app. \n(The Mac driver cannot do remote display: try X11 if you need that.)"; +break; Probably it's just best to say that the Mac driver is running in a non-GUI session such as a remote login. Well, if something in Apple's code fails, it's still likely they'll print to the console, yes? At any rate, I'm not attached to the error message. As for whether to print errors in gdi32 or user32, I don't feel strongly about that personally, either, but I'm curious what others think.
Re: winegcc: Add support for -Ttext-segment linker flag to set image base of a dll. (try 2)
Alexandre Julliard writes: > Tijl Coosemans writes: > >> On 03-03-2013 17:44, André Hentschel wrote: >>> You would rather call it PLATFORM_FREEBSD >> >> Well, the flag isn't FreeBSD specific. It works on all ELF targets >> (including Linux which then wouldn't need prelink). > > Then it should be used by default, and you don't need to add a new > platform for it. Actually, I looked into this and it isn't widely supported at all, so it can't be the default. Ideally it would need a run-time check to see if the option works. -- Alexandre Julliard julli...@winehq.org
Re: winegcc: Add support for -Ttext-segment linker flag to set image base of a dll. (try 2)
Tijl Coosemans writes: > On 03-03-2013 17:44, André Hentschel wrote: >> You would rather call it PLATFORM_FREEBSD > > Well, the flag isn't FreeBSD specific. It works on all ELF targets > (including Linux which then wouldn't need prelink). Then it should be used by default, and you don't need to add a new platform for it. -- Alexandre Julliard julli...@winehq.org
Re: ntdll: make NtDelayExecution a bit more efficient
Graham writes: > This patch is vaguely related to bug 24558. It eliminates a few > syscalls in NtDelayExecution: > > 1. If the caller requests a zero-wait yield, then do just that, and > nothing more. That's what the existing code already does. > 2. If you're about to block on select(), then I don't see any point in > preceding that with a call to sched_yield(). This was added for a reason; most likely you'll have to write tests. -- Alexandre Julliard julli...@winehq.org
Re: qcap: Fix compilation on systems that have v4l1 but not VIDIOCMCAPTURE & co.
Francois Gouget writes: > In particular this fixes compilation on FreeBSD 8.1. > > configure | 74 > +++ > configure.ac| 18 + > dlls/qcap/v4l.c |4 +-- > include/config.h.in |3 +++ > 4 files changed, 97 insertions(+), 2 deletions(-) It's not very useful to add a configure check for a #define, you can check for it directly. -- Alexandre Julliard julli...@winehq.org
