Hi Ken,
2015-09-30 17:05 GMT+08:00 Ken Thomases <ken@codeweavers.com>:
>
> Since FlashWindowEx() is the more general function — that is, FlashWindow() could be fully implemented in terms of FlashWindowEx(), but not the other way around — shouldn't the driver entry point be FlashWindowEx()?  Otherwise, when FlashWindowEx() is eventually implemented more completely, the driver entry will have to be changed.
>
> For now, since user32 implements FlashWindow() but FlashWindowEx() is a stub (or semi-stub after your next patch), FlashWindow() would have to create a FLASHWINFO structure, fill it in, and pass that along.  I think that dwFlags would be either FLASHW_ALL or FLASHW_STOP, depending on bInvert.  uCount would be 1, I guess.
>

Thanks for your review!

Yes, function() will be implemented by functionEx() commonly in Wine.

But I didn't find a perfect way to implement FlashWindowEx() and then implement FlashWindow() with FlashWindowEx().

Because in X11, how many times will the window be flashed is depend on design of window manager/desktop environment.(For example, in XFCE, taskbar will always flashes when _NET_WM_STATE_DEMANDS_ATTENTION is sent until the user active the window again; In Ubuntu Unity, it'll only be flashed one time and then highlight taskbar until the user active the window again.) And I don't think it's necessary (and any possible?) to follow Window's design.

In this way, implementing uCount and other parameters may  be useless, because all we need to do is sending _NET_WM_STATE_DEMANDS_ATTENTION to WM/DE one time when FlashWindow()/FlashWindowEx() is called.

So I implemented FlashWindowEx() by calling FlashWindow() simply.

> Shouldn't pFlashWindow (or pFlashWindowEx) be added to the USER_DRIVER structure among the "windowing functions" (see the comments), in alphabetical order (after pDestroyWindow)?  Of course, that affects the changes to driver.c in terms of where things are added.  The order in winex11.drv.spec is less clear, but it seems to be mostly alphabetical after a certain point.  I'd put it after EnumClipboardFormats() in that list.

Agree.

>
> Why does FlashWindow() only call the driver entry point if the window is minimized?  Shouldn't the driver get the opportunity to act for a non-minimized window, too?
>

Same as above, different WM/DE may have different UI effect, that makes it hard to follow Windows's design.

In Windows, different UI effects will be showed when window is minimized and non-minimized.

And in my opinion, it is a little noisy if USER_Driver->pFlashWindow( hWnd, bInvert ) is called all the time.

So I'll prefer to only let the user notice new message when the window is minimized (it may hard to be noticed when

it's minimized).

> For the X11 implementation, shouldn't something potentially remove the _NET_WM_STATE_DEMANDS_ATTENTION state, presumably when bInvert is false (or when dwFlags doesn't include FLASHW_CAPTION or FLASHW_TRAY)?
You are right. It seems flashing will be stopped when bInvert is false. I'll improve it for this case.

Thanks again! :)
--