[qmtest] The state of GUI

[Stefan Seefeld]

Vladimir Prus wrote:
> On Thursday 07 April 2005 13:57, Stefan Seefeld wrote:

>>I don't think it's QMTest's job to keep track of a toolchain taxonomy.
> 
> 
> No, but ideally there should be a an extension mechanism I can use to define 
> expectation in any way I like.

The simplest approach would provide the python API to manipulate results
(result files), and users would write their own python scripts using
qmtest's python modules, instead of using the 'qmtest' CLI.
In any way, that's the first step to any solution.

>>>Yea, but if people decide that editing 15 files for 15 versions of "yfc"
>>>is not too nice (even with GUI), they should be able to do something.
>>>Like using custom file format.
>>
>>I don't think a custom file format is a good idea, as I don't believe
>>QMTest itself should care about these things. However, once we have an API
>>to manipulate expectation files it should be easy for you to define some
>>aliasing mechanism that lets you make modifications that get propagated to
>>all instances that are in your alias list. But again, that would be on top
>>of such a 'QMTest API'.
> 
> 
> If fact, if there's "qmtest report" that takes N test results and N expected 
> result and produces a report, then I can write a script that takes N toolset 
> names and a expectation file in Boost format and produces N separate expected 
> result files, which can be used by "qmtest report".
> 
> Seems workable.

I think qmtest should store the expectation within the result file as annotation,
so 'qmtest report' would only have to load N result files.
However, that doesn't appear to be what qmtest does, i.e. while the summary
section indicates the unexpected passes/failures, individual results don't
contain information about whether they were expected or not.
Mark, is that accidental ?

Regards,
		Stefan