State Introspection

Introduction

One of the things that would be great when either debugging a bug from a remote user or when making sweeping changes to the views of Unity would be to be able to get at the data that Unity is "seeing". This would be "model" of what the views inside unity are currently seeing and rendering.

Ideally this could be used:

This is not a replacement for ATK-based testing. Both can co-exist and provide testing for different parts and levels of the code

Unity will NOT implement an interface that allows external programs to cause mouse or keyboard actions on it, this is the job of the ATK and input-method support

Implementation

I'd like to separate the idea of "this view can provide information about it's state" from the presentation of the state (JSON/XML/etc) as well as how to retrieve it (D-Bus/internal method/etc).

Therefore I'd propose the following (pseudo code):

unity::PropertyWriter { //abstract class

  PushNode (const char *name) = 0;
  AddProperty (const char *name, Value? value) = 0; // this can just be a bunch of AddProperty methods with different signatures
  PopNode () = 0; // pops the topmost node
}


// UI elements implement this to have their state dumped.
// The idea is that each UI element keeps track of its direct children. 
// The top level shell would have (for all intensive purposes) a list of 3 items: the panel, the launcher, and the dash. 
// When ToString was called on Unity-shell it would write out whatever state was specific to itself, 
// and then to ToString on each of the items in GetChildren. This would repeat for all UI elements
// until all state had been written
unity::Introspectable { //abstract class

  GetName () = 0;  
  ToString (PropertyWriter *writer) = 0;
  static std::list&<Introspectable> GetChildren () = 0;
}

With these objects, you can imagine that the panel can do this:

A service inside Unity that allows external sources to dump this info could work like this:

In the same way, for internal testing, we could create a fake panel model and a memory-based PropertyWriter, and then validate that the Panel is seeing what we expect it to see by going through it's code-paths rather than the models.

PropertyWriter - JSON example

"panel": {
    "backend": "remote-service",
    "remote-service-address" : "/com/canonical/Unity/Panel/Service/324234243",
    "launch-type" : "dbus",
    "width" : 1024,
    "height" : 24,
    "theme" : "gtk",
    "indicators" : {
        "appmenu" : {
            "model-name" : "com.canonical.Unity.Panel.Service.Indicators.appmenu.324234243",
            "entries" : {
                "0" : {
                    "label" : "_File",
                    "image" : "",
                    "visible" : "true",
                    "sensitive" : "true",
                    "active" : "false",
                    "width" : "34",
                    "height" : "24"
                },
                "1" : {
                    "label" : "_Edit",
                    "image" : "",
                    "visible" : "true",
                    "sensitive" : "true",
                    "active" : "false",
                    "width" : "34",
                    "height" : "24"
                }
            }
        },
        "appindicator" : {
            "model-name" : "com.canonical.Unity.Panel.Service.Indicators.appindicator.324234243",
            "entries" : {
                "id" : "0",
                "label" : "",
                "image" : "transmission",
                "visible" : "true",
                "sensitive" : "true",
                "active" : "false",
                "width" : "24",
                "height" : "24"
            }
        },
     
    }
}

Unity/QA/StateIntrospection (last edited 2010-11-09 10:42:15 by 188)