Mike 12.29.2010

Made a few architecture and functionality choices for the SWFManager:

  • Desktops: A Desktop is exactly as it sounds.  It contains everything one would normally associate with the desktop: a set of applications in windows, a taskbar of some type and anything else added later at this level.  An instance of SWFManager can have multiple Desktops but only one visible at a time and, for now, applications can not be shared between desktops though it would not be impossible to implement.  Communication between desktops will be possible.  In fact, some events may be fired that can span desktops while others are limited to only live within a single desktop.
  • Apps: An app is very similar to most applications on a windows machine.  They contain everything needed to run independently but, in this case, will be able to communicate between each other.  Every App is placed on a Desktop within an AppTitleWindow which is an extension of DynamicPanel.  An AppTitleWindow has buttons for minimize, maximize, and close and can be moved and resized around the desktop.  The interface for IApp as it stands now:
    • Get and Set configuration, this is a DataObject that contains all the information the application needs to restore its state
    • Get Icon, this returns an icon that will be used in the task bar and possible in menus elsewhere
    • Validate configuration, this returns a boolean indicating whether or not the provided configuration object is valid
    • Default configuration, takes a config object and defaults all its properties
  • Widgets: A Widget is a basic user interface component such as a Chart, Datagrid, RichTextArea, or map with navigation controls.  Widgets live within SOME Apps.  A developer may make a very elaborate App with charts, datagrids, text, maps, and all sorts of things without needing to worry about defining them as Widgets or using our IWidget interface.  However, for some of our internal Apps, it makes sense to make reusable Widgets with certain capabilites.  All Widgets will be added to an App inside of an EditableWidgetContainer which contains controls for accessing Widget options.  The current inteface:
    • Get and Set configuration, this is a DataObject that contains all the information the widget needs to restore its state
    • Validate configuration, this returns a boolean indicating whether or not the provided configuration object is valid
    • Default configuration, takes a config object and defaults all its properties
    • Get Configuration Menu, returns a UIComponent containing whatever inputs are necessary to configure the widget, this is how users will configure their widgets at run-time
  • A few notes on Apps and Widgets:
    • Their interfaces are very similar and it would be possible for a component to implement BOTH IApp and IWidget so an App can be contained within an App.  The interfaces are purposely being kept separate so the developer can make that choice.  For example, it makes sense that an RSSReader may exists as both a Widget within a report or as a standalone App.  However, it wouldn’t make sense for Visiblity to be contained within another App.
    • Their positioning and sizing information will not be held within their own configurations.  It will instead be held either in the parent container’s config or the parent container’s layout config.
  • IApp, AppTitleWindow, and several applications are already written at this point so I’m now working on EditableWidgetContainer and a few sample widgets: AdvancedDataGrid, RichTextArea, and maybe a chart or 2