Winetest progress bar

[Ferenc Wagner]

Hi,

I put together a feedback window for winetest.  The code is
somewhat inside-out to make it less intrusive, and the
dialog is ugly.  Where can one find a dialog editor?
Anyway:

1. If compiled with Winelib, the dialog stays on screen
   after the main thread finishes with the tests; under
   Windows, it disappears at once.

2. I am not sure what to do with the console which pops up
   under Windows.  Under Wine it comes and goes.

3. When the cross-compiled version run under Wine the GUI
   thread throws an exception at the very end.  It seems to
   come from the statusbar's WM_PAINT.  I am clueless.

4. How can I convert the icons into ASCII to put them into
   the resource script?

5. Do we actually need textual output at all?

Comments are welcome.  Find the programs/winetest directory
enclosed.  A cross-compiled binary is also available at
<http://afavant.elte.hu/~wferi/wine>.

Feri.

[Dimitrie O. Paun]

On January 2, 2004 06:47 pm, Ferenc Wagner wrote:
> Hi,
>
> I put together a feedback window for winetest.  The code is
> somewhat inside-out to make it less intrusive, and the
> dialog is ugly.  Where can one find a dialog editor?

Nice! A few suggestions about the dialog:
  -- The progress bars can use some clearer labeling
     (about what they actually track). Maybe the text
     above the bars should start with something like:
         "Extracting: ..."
         "Running: ..."
         "Transfering: ..."
     where "..." is:
	- empty when the step has not yet started
	- the name of the test for the first two,
	  and just "In Progress" for the third,
	  when in progress :)
	- "Done" when the step has completed
  -- The edit boxes displaying the dirs are way too small
     We should just make the dialog a lot wider, no?
  -- Maybe we should move the stop button below, because:
	- it will allow more space for the dir boxes
	- we haven't reached any vertical space constraints
	- we might need more buttons, like an "About" button
	  that displays some info about what the heck this
	  program is doing, etc.
> Anyway:
>
> 1. If compiled with Winelib, the dialog stays on screen
>    after the main thread finishes with the tests; under
>    Windows, it disappears at once.

This is a bug in Wine, don't worry about it for now. Having
a Winelib version is important so that others that don't have
Windows can contribute, and while this is a little annoying,
it's no showstopper. Of course, we should eventually fix this...
> 2. I am not sure what to do with the console which pops up
>    under Windows.  Under Wine it comes and goes.

It did go away when I've ran it (under Win2k). Would be nice
if it went away, but I think this is up to each individual
user to configure IIRC. IOW, don't worry about it :)
> 3. When the cross-compiled version run under Wine the GUI
>    thread throws an exception at the very end.  It seems to
>    come from the statusbar's WM_PAINT.  I am clueless.

Wine bug, obviously. Same comment as in (1) applies.
> 4. How can I convert the icons into ASCII to put them into
>    the resource script?

tools/bin2res. Just run "tools/bin2res -h" for help on how
to use it. Search for the BINRES marker in other .rc files
for some actual running examples.
> 5. Do we actually need textual output at all?

On the user side? Not really, but it would be nice to have it
in case the user wants to make sure no unwanted information
is sent from their computer. This can be the very purpose of
yet another button at the bottom of the dialog :)
> Comments are welcome.  Find the programs/winetest directory
> enclosed.

A diff would be so much better :)
> A cross-compiled binary is also available at
> <http://afavant.elte.hu/~wferi/wine>.

Cool, pretty smooth! The example HTML summary seems to be older, no?
Also, it has no colour in either Konqy nor IE, it seems that the CSS
is busted (wrong URL?).

-- 
Dimi.

[Mike Hearn]

On Sat, 2004-01-03 at 09:29, Dimitrie O. Paun wrote:
> > 1. If compiled with Winelib, the dialog stays on screen
> >    after the main thread finishes with the tests; under
> >    Windows, it disappears at once.
>
> This is a bug in Wine, don't worry about it for now. Having
> a Winelib version is important so that others that don't have
> Windows can contribute, and while this is a little annoying,
> it's no showstopper. Of course, we should eventually fix this...

I think we're tracking this in bugzilla - I was poking at it the other
day:

http://bugs.winehq.com/show_bug.cgi?id=1918

Basically it's not at all obvious from MSDN how WM_QUIT is generated
from a window being destroyed. I rather suspect that Microsofts
defwndproc notices when the window being destroyed is the last one owned
by the thread and then does a PostQuitMessage (which we do not). That
behaviour should be verified by test case first though.

I have a feeling Alexandre should know about this - it seems like a
rather core bug to still be around in Wine after all this time. I guess
most apps do PostQuitMessage themselves....

[Shachar Shemesh]

Mike Hearn wrote:
> On Sat, 2004-01-03 at 09:29, Dimitrie O. Paun wrote:
> > > 1. If compiled with Winelib, the dialog stays on screen
> > >   after the main thread finishes with the tests; under
> > >   Windows, it disappears at once.
> >
> > This is a bug in Wine, don't worry about it for now. Having
> > a Winelib version is important so that others that don't have
> > Windows can contribute, and while this is a little annoying,
> > it's no showstopper. Of course, we should eventually fix this...
>
> I think we're tracking this in bugzilla - I was poking at it the other
> day:
>
> http://bugs.winehq.com/show_bug.cgi?id=1918
>
> Basically it's not at all obvious from MSDN how WM_QUIT is generated
> from a window being destroyed. I rather suspect that Microsofts
> defwndproc notices when the window being destroyed is the last one owned
> by the thread and then does a PostQuitMessage (which we do not). That
> behaviour should be verified by test case first though.

When you click the close button, a message (I'm not sure which - 
possibly WM_CLOSE) is sent to the window. DefWndProc takes that message 
and asks to close the window. This, in turn, sends WM_DESTROY to the 
window. That's all that happens in Windows. If you want your application 
to quit at that stage, you have to manually trap WM_DESTROY and call 
PostQuitMessage. I found that out the hard way.

As a bare minimum, each and every application must handle the following 
event:
It's main window being closed with WM_DESTROY (usually by calling 
PostQuitMessage).
The window session it's in quiting WM_ENDSESSION (the application will 
NOT receive WM_DESTROY in that case).
Paint requests WM_PAIN (no, defwndproc doesn't do beginpaint and 
endpaint, and if noone else does that, they queue up).

Each and every application must handle all of the above cases, or things 
go wrong. Not handling WM_DESTROY, for example, causes your app to 
continue running after all of its windows have closed.

             Shachar

-- 
Shachar Shemesh
Lingnu Open Systems Consulting
http://www.lingnu.com/

[Jakob Eriksson]

Ferenc Wagner wrote:
> Comments are welcome.  Find the programs/winetest directory
> enclosed.  A cross-compiled binary is also available at
> <http://afavant.elte.hu/~wferi/wine>.

I UPX-packed the binary and put it up here:

http://vmlinux.org/jakov/winetest.exe

It went down from 2 megs to 600 k.



regards,
Jakob