[qmtest] The state of GUI

[Vladimir Prus]

On Tuesday 05 April 2005 14:42, Stefan Seefeld wrote:

> > Fair enough. I'm too not entirely sure if it's best to improve the
> > existing GUI, use custom databases, or just my own GUI with PyQt.
>
> I find the GUI quite convenient to introspect a test database
> interactively, and so I'm very interested into improving the existing one
> (in particular, since it is much more portable than any GUI toolkit - based
> will ever be).

I realize this point. OTOH, HTML approach incurs some sloweness and autoload 
tricks. Maybe some smart JavaScript can sure this, but I don't now much of 
JavaScript to comment.

> > Essentially, there are several test results which are merged in a big
> > table. Each failure can have "notes" -- that's my proposed failure
> > annotations. As I've mentioned somewhere in the tracker, the key point is
> > that there's one expectation file for all toolsets.
>
> Oh, I missed that. Since in QMTest expectations are simply results of prior
> test executions, my initial design proposal is to provide the means to
> annotate result files. (Nothing is stopping you from using the same result
> file as expectation in multiple toolsets.)
>
> Does this make sense ?

You mean "this test results are for configuration 1"? That would make sense. 
However
- last time I checked, expectations loading was hardcoded logic to test either 
for xml file or for pickled data. Maybe this changed, but if not, this is not 
particularly flexible. What if I have my own way to describe expectations.
- If xml/pickle format is OK for now, there should be some way to edit it with 
a GUI. Loading results for each configuration, editing them and saving would 
be very inconvenient. Say I want to mark a test as failing for gcc-2.95, 2.96 
and 2.95-stlport.

This suggests we probably need a format for expectation file that can contain 
several sets of results. So, QMTest will load the file and ask for results 
for a specific tested configuration. 

- Volodya