Widget Assembler Notes

  • The Gui_DynamicGrid_Layout class is used when “Entity Images” are being displayed and its implementation does not make use of the Gui_Layout_Interface. You’d think Gui_ImageWidgetEx would implement Gui_Layout_Interface but it does not. What’s a little more uncomfortable is the relationship between the widget interface, layout classes and the Gui_WidgetAssemblerEx. Where the dynamic layout does not use the layout interface at all the grid does by casting the widget interface objects to the layout interface.
    • Discussed with Dwayne…1) remove the exposing of the widget list from Gui_Widget_AssemblerEx by making Gui_Layout_Base a friend.   2) Rename Gui_Layout_Interface to Gui_Grid_Interface since Gui_Grid_Layout is the the only layout derivation to use this interface.

 

  • Currently Gui_WidgetAssemblerEx has image widget loading code. This should be moved into the PS updater class.

 

  • Change the name of Gui_EntityImage_View to Gui_NavigationView or something that represents the 2D/3D-ness that the view will represent. This splitter/view class will be allow the top pane to split between a Gui_WIdgetAssemblerEx and Dave’s soon to be derived class that uses the hierarchy to allow for 3D display which can then be saved to a 2D layout.

 

  • A new Gui_Widget_AssemblerEx derivation will need to be made to support Plant Setups need for allowing a “View” to be created using image widgets and menu widgets representing Inspection Points. In the PS implementation, the addition of an IP onto the canvas should create a menu widget by default with a connector that can be attached to a point on the image. The connector should be allowed to be maneuvered around the edge of the source IP. The destination end of the connector should only be allowed to be attached to a destination connector type, in this case an image widget. As the destination connector type is moved or resized, the connector end point should adjust accordingly.
    • Some of these issues are general and will be included so as to allow the Reporting Client to use these  features for custom report creation.
    • Additional general issues include being flexible enough to handle resolution adjustments and adjusting to print within the selected page size.
    • The existing menu widget will need to be ported to the new widget hierarchy.

 

  • A new Gui_Widget_AssemblerEx derivation will need to be created to support the Reporting Clients need for creation a custom report. The specific need in 4.7 is for the Die Hemmer report which is the same functionality needed in the PS description above with the exception of the IP in this implementation will be represented by a trend chart with a maximum of 5 jobs being displayed.
    • It would seem that the only difference at this point in this class and the PS class is the type of widget created when an IP is added to the canvas.
    • It may be that there is a derivation of the existing Gui_Widget_AssemblerEx that includes the common implementation and then the PS and RC specific types just implement a hook method to supply the type of widget to be created when an IP is added to the canvas. Alternatively the common code could be pushed into the existing Gui_Widget_AssemblerEx.
    • The existing trend chart widget will need to be ported to the new widget hierarchy. Porting this widget will allow us to investigate how we’ll handle pushing data into the trend chart.

 

  • In converting the current PTV’s in PS to the new line of assembler code the list control within the Gui_EntityImage_View will be able to be used. The problem will be in determining which container to display. The current PTV displays either the Aps_InspectionPoint or Aps_ExternalInspectionPoint. The only difference between these types is that the latter filters to only external IP types (offline cell IP’s). In order to display only IP’s that are assigned to the PTV being displayed we’ll need to create a database view that returns the appropriate IP’s. The problem is completely a display problem in that I don’t want to have to derive a new class from both Aps_InspectionPoint and Aps_ExternalInspectionPoint.
    • One solution that might work would be to implement the tableName method of both classes to return the new database view when the current level is the PTV level.

UI Discussion Meeting (Navigator)

Dwayne, Mike Blood

Navigator is basically set in terms of existing functionality but has been delayed because it doesn’t have the visual appeal that is desired.  The goal is to release in 4.6 with a face life.  Mike Blood has a vision for the look and feel.  A tracker exists (PER00038) with a power point of the look.

The goals are:

  • face lift including
    • “perceptron” title,
    • stacked dynamically sized images (currently icons)
    • rounded/beveled images
  • essential links to be supplied by blood/boomer
  • docking on the right
    • future would allow docking anywhere where top or bottom docking would only display buttons and not links.
  • icons for links that match the toolbar and menu icons in PS
  • gradient background starting with blue (top) ending with gray.
    • more difficult with multiple controls.  initially top control would be blue to ??? and list would be gray.

Initial UI Discussions Meeting w/Dwayne

Native Reporting – 4.5.1

·         Jeffery will be completing the SEAT report

·         I will be implementing printing support – still needs to be defined.

 

MM Refactoring

This is a fairly large task that includes several items.  The main idea is that Dwayne wants to re-use the same type functionality that is currently in MM in PS (Part Type Views and Part Type View Images at the Part Type level) and Native Reporting (user defined reports). 

 

It should be noted that the term “widget” functionality refers to the types of things that are currently implemented in MM but weren’t implemented in the most re-usable way.  I’ll be using “widget” functionality to refer to the re-usable component that will grow out of the current code used in PS.

 

User-Defined Reports

Users will be allowed to define reports using the widget functionality (placing charts, header information, customer logos, etc. on a canvas).  These reports could then be used in the native Reporting Client for historical reporting or be used in MM for “live” reporting.

 

Native Reporting

In the current implementation the requirement is to include a “shrunk-down” image of a Part Type View configuration on certain reports (*).  The reduced image would contain only the liter lines with dots at the end of the lines representing the points.  In the case of an Inspection Point report this reduced image would only contain the single line and point that represented the Inspection Point.  The point displayed in this case would not be interactive (cannot right-click to initiate further actions).

 

Plant Setup

The widget functionality would be incorporated into the current image display at the Part Type level and would replace the current Part Type View functionality.

 

At the Part Type level the same reduced image mentioned in the Native Reporting discussion above would be displayed as the image for the Part Type View.  This image would contain all the lines and points and the points would be interactive as compact charts.

 

Required for 4.6

·         See the Native Reporting section above (*).


 

Vector UI Usability Issues

The goal was to address specific issues that have been mentioned as problem areas with regard to Vector UI’s and their usage.  There have been many comments regarding the tree control used in Plant Setup, the difficulty in finding specific functionality, whether within Plant Setup or first determining which application to execute.  In addition other issues such as Cell branding or “walk-up” confusion have been mentioned.

 

Initial “Walk-Up” 

Problems:   

o   Users don’t know where to start

o   No Branding

 

Solutions:   

o   Desktop Management

o   Folders with Icons linked to current UI functionality

 

This could be accomplished now by creating a Perceptron folder at install containing Setup, Maintenance & Reporting folders.  The Setup folder would contain icons with links to functionality such as Limits, Offets, etc. allowing the user to launch Plant Setup for a specific purpose.

 

o   Implement a Namespace Shell Extension

 

This approach is more involved.  It would allow for a customized desktop with the Perceptron and customer logo’s along with access to the folder functionality mentioned above and possibly a note or graffiti area.

 

Plant Setup

Problems:   

o   To overwhelming

 

Solutions:   

o   Integrate the Navigator Toolbar into Plant Setup

o   Allow for linking/jumping to functionality:

o   Externally

§  For example, allow a user to launch reports from any display of an Inspection Point.

§  How many types of operations like this are not known but would need to be investigated.

 

o   Internally

§  For example, allow the Tool Position or Feature information from an Inspection Point.

§  Whether this information would appear as pages on the Inspection Point property sheet or as menu items is unknown.

§  Additionally, the locking rules would have to be re-investigated.  As it stands at the moment, the Platform must be locked in order to modify a Feature.  Requiring the user to lock the Platform prior to launching the feature information from the Inspection Point would be cumbersome.

§  Also discussed was a new mode (Run/Program) to allow for more entities to be configured while in production.

o   2D graphic enhancements

o   3D graphic enhancements

o   Part Type View enhancements

o   Attach icons to all menu items

o   Review tool bars for completeness at all levels

o   Modify context menus to communicate functionality rather than having a “Properties” item only.

 

o   Navigation View

In order to allow users to access functionality with or without the tree being visible the following modifications will be made to give the user a better feel for the level they are at:

 

o   Additional list controls in the Navigation view where applicable.  As an example when the user navigates to a specific Part Space (with or without the tree) the Navigation view will contain a Navigation window, Part Type list control, Phase list control and an additional list control with a combo or buttons that allows for switching between the remaining entities at that level (Inspection Points, Anchor Points, Relationships, Tool Positions & Visual Fixtures).

 

o   Gradient title bars for each list control in the Navigation View to give the user a better feel for what they are viewing.

 

o   Tree Control – New display options

Show/Hide:                               

o   Allows the tree to be hidden and restored.

 

Full mode

o   Displays the current complete configuration.

 

Minimum mode

o   Displays fewer folders.  This might be considered more of a novice mode but the idea is to allow for the tree to be displayed for navigation but remove a number of the folder levels that clutter up the user ability to locate functionality.  Accompanied by the navigation pane changes the user would still have access to all entities.