-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Perspective View #79
Comments
That looks absolutely fantastic, Marcus! 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? |
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. |
Good idea, let's try that. |
Implementation step 1 - The skeletonThe 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. 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. |
IdeallyThe 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. NowA 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
} |
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? |
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. |
TimelineHere'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? |
Implemented and ongoing since 0.2.9 |
Goal
To provide a complete summary of a publish.
Implementation
The summary would be accessible to artists via the Overview right after publishing.
The text was updated successfully, but these errors were encountered: