Context Navigation

← Previous Ticket
Next Ticket →

Warning: Can't synchronize with repository "(default)" (/local/svn/repos/sde does not appear to be a Subversion repository.). Look in the Trac log for more information.

Ticket #18 (closed defect: fixed)

Opened 10 years ago

Last modified 9 years ago

Suggesting some changes for the UI

Reported by:	sensoria	Owned by:	sensoria
Priority:	minor	Milestone:	IntegrationVersionM30
Component:	SDE core	Version:	3.0
Keywords:		Cc:

Description

When an object is posted to the blackboard, the Sensoria Blackboard View's tree-viewer is added a new item labelled with date, time, toString() and class name. I ran some tests and I think this information is very useful. However I think that in some occasions displaying raw toString content and canonical class names might be a bit confusing. For instance, a service we provide returns an array of doubles, the toString() representation being "[D@" and some memory location, which is not very easy to interpret. In general this lack of readability happens when we return objects we don't have control over (i.e. we can't override the toString method). Also, in such cases it is likely that toString has already the class name, the label thus showing repeated information.

Another point is about showing the implementing classes of objects declared as interface in the signature of the function. For example, the Eclipse UML2 has the interface Interaction which is displayed as its implementing class InteractionImpl?? in the Sensoria Blackboard. In addition, strange behaviour also occurs when the implementing class is anonymous, the label showing "(class null)".

I would humbly suggest a few changes in the implementation of the user interface which might cope well with these issues. The main suggestion is to provide a lightweight tree label provider wrapped around a posted object with at least one field 'label'. The tool invocation wizard would have a section to initialise it properly (an initial guess for this label might be [class name of the returned object as declared in the function] + [some counter]). The idea is to have a more user-friendly label to the object. The object's tree item would then show date, time, and getLabel. Since I think that advanced information on the object is still necessary, I would change the implementation of the tree content provider in order for the posted object to have children, which would be the canonical class name and the toString representation. This should fix the problem pointed out by Philip in the source code about the rendering of the tree being slowed down when the length of toString is big - the toString() would be called lazily when the user expands the object's node.

Change History

comment:1 Changed 10 years ago by sensoria

Owner changed from mayer to sensoria
Status changed from new to assigned
Milestone set to IntegrationVersionM30

This will be implemented in the next version.

comment:2 Changed 9 years ago by rolexco

comment:3 Changed 9 years ago by paydays

comment:4 Changed 9 years ago by guccico

comment:5 Changed 9 years ago by pursesohh

comment:6 Changed 9 years ago by paydayone

comment:7 Changed 9 years ago by paymoneyday

comment:8 Changed 9 years ago by cheaptickets

comment:9 Changed 9 years ago by mayer

Status changed from assigned to closed
Resolution set to fixed

Implemented by means of a new interface to be implemented by a tool. The interface (ISensoriaModelHandler) contains methods for retrieving label and contents of a model object. This way, we do not need to change the actual model objects and are still able to leverage additional information about them.

Note: See TracTickets for help on using tickets.

Download in other formats: