Perspective View

[mottosso]

Goal

To provide a complete summary of a publish.

Implementation

The summary would be accessible to artists via the Overview right after publishing.

[ghost]

That looks absolutely fantastic, Marcus!

When the plugin fails, I would always put the exceptions first and then the list of plugins.

[mottosso]

When the plugin fails, I would always put the exceptions first and then the list of plugins.

Will do. Where would you rather see the Documentation?

[ghost]

Where would you rather see the Documentation?

Good question. I would probably keep it before the exceptions but always collapsed. The reason being is that with time you will get familiar with the plugin and you only need to read it in case that you need a refresher. Exceptions on the other hand are likely to be something that you want to read every time so I would not collapse it.

[mottosso]

Good idea, let's try that.

[mottosso]

Implementation step 1 - The skeleton

The skeleton will consist of a ListView with a model of models.

perspectiveModel

[
  {"name": "records", "model": app.recordProxy},
  {"name": "exceptions", "model": app.errorProxy},
  {"name": "gadget", "model": app.gadgetProxy}
]

Each inner model is a ProxyModel featuring items relevant to the current perspective; e.g. Richard01 or ValidateNamespaces.

recordsModel

[
  {"message": "My Message", "lineno": 501},
  {"message": "My other message", "lineno": 530}
]

gadgetModel

Only a single item is typically present.

[
  {
    "title": "Richard05",
    "family": "napoleon.asset.model",
    "passed": 13,
    "total": 15,
    "duration": 510,
    "date": 12301
  }
]

However, when browsing history, more items may be present; one for each item.

[mottosso]

Ideally

The cleanest implementation needs a tree-model.

In a nutshell, the terminal is driven by a model derived from results; each result is parsed into individual items which means they no longer share any commonality. E.g. a record doesn't know which errors are associated with it, or which plug-in it came from.

A tree-model would be able to encapsulate a result and it's content into a single object where each child can reference its parent. Additionally, when filtering items, children could be filtered within a parent.

{
        "duration": 0.026999950408935547, 
        "error": {
            "line_number": 40, 
            "message": "Controls with non-defaults values detected"
        },
        "instance": "Peter01", 
        "plugin": "ValidateNamespaces", 
        "records": [
            {
                "message": "I am a message"
            }
        ],
        "success": true
}

At the moment, I could produce a single delegate for a result and draw all children. This would produce a similar hierarchy to a tree-model in which each item is related as in the original result. However, as the model only knows a single item - the Result - it would not be able to exclude individual children from the result, which we need for the Perspective View to draw logs and errors related to a particular plug-in/instance.

Now

A tree-model will ship with QML in 5.5 at the end of this month.

Until then, during the parsing step, information from the parent is embedded into each item.

{
        "duration": 0.026999950408935547, 
        "error": {
            "line_number": 40, 
            "message": "Controls with non-defaults values detected",
            "plugin": "ValidateNamespaces",
            "instance": "Peter01",
        },
        "instance": "Peter01", 
        "plugin": "ValidateNamespaces", 
        "records": [
            {
                "message": "I am a message",
                "plugin": "ValidateNamespaces",
                "instance": "Peter01",
            }
        ],
        "success": true
}

[mottosso]

The above experiment worked well, here's the skeleton of what is about to be decorated and painted nicely.

There is one thing I didn't consider in the original design, which is that a Plug-in can only ever have a single error. An error is an exception and it can only be thrown once.

Therefore, the Errors panel will always only have a single child, which may look empty..

Suggestions?

[tokejepsen]

I guess most use of a plugin exception is singular, though you could have different messages depending on what error it is. But maybe you'll have a different plugin for what ever the exception is.

Suggestion would be to have the error message with the instances that errored out.

[mottosso]

Timeline

Here's some more rationale for the timeline visualisation.

For the developer, when developing plug-ins it can be helpful to spot which plug-ins take the longest so as to be able to make educated guesses as to where to make optimisations. Most time should be spent optimising the plug-ins that take the longest.

For the artist, it can be helpful to know what to expect of any plug-in or instance. For example, when publishing a character, an artist could spot which instances take less than a second, versus those that take a number of minutes or hours.

With this knowledge, the artist can know whether he will have time to run it before a meeting, whether he can run it and go to lunch/grab a coffee, or whether it will finish in less than a few seconds.

What other benefits can you think of?

[mottosso]

Implemented and ongoing since 0.2.9