PostMortemOverview

Welcome to the end of the beginning. Here we will record our current thoughts about what's going on, and where we need to go for the future. Please add issues, and join in on discussions/topics that get you worked into a lather.

We'll start discussing these topics in our next telecon.

 When editing, please follow the standard convention of talk page
 (http://en.wikipedia.org/wiki/Wikipedia:Talk_page).  In particular, indent responses from 
 what they are responding to with colons (:) and make sure you sign your entries with four 
 tildes (~~~~)

Undo/Redo

Summary: Need flexible support for undo/redo.

Links: Undo Design

This capability is important to integrate from the start. It'll be an added 'tax', but well worth it to users!

--Hollywood 17:30, 22 Jan 2006 (EST)

Selection

Summary: Need flexible support for selection operations.

Links: Selection

This is one of the things that we have support well. People react visibly to linked view selections in our demos.

--Hollywood 17:30, 22 Jan 2006 (EST)

Plotting

Summary: Flexible support for parallel graph operations, as well as highly interactive client-side graphing.

Links: Plotting Parallel Data (PGraph)

Ken's PGraph work will address parallel concerns, but there is a huge component of client-side graphing in ParaQ. How do we manage mulitple client-side graphs? How does the user understand what's being graphed? How is that controlled? In our recent demos, one use case that came up was that of having client-side graphs appear on a tiled display. Not a high priority, but something to think about in the overall architecture. We seem to be spending a lot less time on the tile display requirements these days.

--Hollywood 17:30, 25 Jan 2006 (EST)

I think putting the plots in the multi-view with the other views will make it easier to expand the capability of the graphs. It will also simplify the graph/model coordination. If we put the plots in the multi-view, we can add them into the pipeline browser(s). This can greatly expand our options. We could use tool buttons and context menus to connect the plots to the appropriate model.

Mark Richardson 12:40, 26 Jan 2006 (EST)

Testing

Summary Test or die.

LinksTesting Requirements, Testing Design, Notes on ParaQ Testing, Testing Prototype, Early Testing Prototype, Hello World Testing

We're on our way with the dashboard, the testing framework, and the mentality of the group. Now, we have to commit to writing test plans, test cases, etc. Again, a balancing act with development.

--Hollywood 17:30, 22 Jan 2006 (EST)

We need to improve our existing tests. Image based tests have to submit results so that we can see image diffs etc. on the dashboard. We also have to start testing client/parallel server.

Berk 11:29, 30 Jan 2006 (EST)

Build and Repository Restructuring

Summary: Cleanup of the CVS repository and the build process

Links:

We will reorganize the CVS tree so that only the KW GUI directories are excluded. Instead of including the whole ParaView directory, we should included selected subdirectories in the ParaQ tree. This will require changing the build files a bit.

There are some problems with VTK libraries conflicting with Qt libraries, mainly freetype. We have to find a solution to this. The solution will probably be mangling the freetype used in VTK.

Berk 11:35, 30 Jan 2006 (EST)

Connection

Summary: Flexible support for connection to servers; wide range of users and use cases.

Links:

Tim, Lisa, John and I were talking about this at lunch today, and if we can make this aspect of using ParaQ simple (OK, as simple as possible ...), we're going to win big. This will be a lot of work, for something that the user blows by every time he/she uses ParaQ. I can also be a big user sticking point, if we ignore it.

--Hollywood 17:30, 22 Jan 2006 (EST)

Save/Restore

Summary: We can save a lot of information, but what operations (Save, Restore, etc.) make sense to the user?

Links:

Installation Management

Summary: Several platforms need installation scripts/packages soon, so that we can manage user testing, demos, etc.

Links:

Development Process

Summary: What is our development model for the coming releases?

Links:

We touched on this briefly in a recent meeting, but we'll need to formalize it in the next few weeks. I'm a big, big fan of frequent 'working releases', especially given that we want to exercise a lot of capability in the coming months. Testing (including user testing) will have to be an integral part of our development process, as UI design and useability issues are a major motivator of the entire ParaQ project.

In addition, we should reflect on how we're starting to work together as a team. If there are problems in communication, or if we need to re-structure our responsibilities, let's talk about that as we move forward.

--Hollywood 17:30, 22 Jan 2006 (EST)

Alternate views of the pipeline

Summary: What are our standard UI views of the pipeline?

Links:

Our current pipeline browser is fine for demos, but we'll quickly outgrow this. Will we always support several views of the pipeline? What designs - whether alone, or in concert - best allow the user to understand and operate on the pipeline?

--Hollywood 17:30, 22 Jan 2006 (EST)

I have a plan for the pipeline list view that will make it useful beyond the demo. I don't think we will outgrow it. I've been putting the pieces into place as I've prepared it for the demo. I can make some examples after the demo, but I think we can show any pipeline in the list view. I think we should still implement a graph view of the pipeline to give users another option.

Mark Richardson 12:34, 26 Jan 2006 (EST)

I can understand how we'd show 'fan-out' pipelines - one thing indented below anther - but how about 'fan-in' - things that have more than one input? At present, this case is rare, but it may become more common in the future. Of more pressing concern is a pipeline like that in Prism - where a pipeline branches like this, to several windows:

 A->B->C->D->E->(shown in window_a)
          |
           ->F->G->(shown in window_b)
          |
           ->H->I->(shown in window_c)

This seems like it'd be hard to represent in the current pipeline browser, but maybe if we just remove the windows from it, we're OK. Dunno.

Hollywood 17:30, 22 Jan 2006 (EST)

Architecture for Coordinated Views

Summary: How are Client-side views integrated into the overall ParaView/ParaQ architecture?

Links:

Lots of interesting uses of ParaQ are going to include multiple linked views. What is a good multiview architecture? A good linking architecture? How much of this functionality is available to the users - are there compound-filter-like things that we can use to set up multiview interfaces? This is an important part of UI customization.

--Hollywood 17:30, 22 Jan 2006 (EST)

Taming the Filter Zoo

Summary: How can we make it easy to use the different types of filters?

Links:

The Filter graph architecture, though powerful for programming, can be difficult for users to grasp. In fact, it's one thing that stands in the way of simplifying ParaQ. We've spoken briefly about having the user perform 'operations' (clip, threshold, etc.) rather than 'apply filters to anther filter', but is it possible to hide the filters from the user, or should we force the user to understand the paradigm? Maybe it's enough to have the 'expert' mode, in which the entire pipeline is exposed, and a 'novice' or 'compound filter mode' where everything is hidden. We may only determine this through user testing and prototyping.

Filters fall into several rough categories. A few that make sense to me are 'filters that operate on pure data' and 'filters that need a couple of inputs'. An example of the former is a Threshold filter, an example of the latter is the Glyph filter. The Glyph filter needs in input data set and in input glyph. Will it be up to the user to understand the input needs of a filter? Can the PV Server provide a client with enough information to auto-generate a useful UI (object inspector)? How does the user want to interact with various filters?

--Hollywood 16:15, 26 Jan 2006 (EST)

I think limiting the (non-advanced) users to only 'operations' would significantly restrict the capabilities of ParaQ. Unless, that is, we create a lot of these operations. It is common to load a dataset, appy a filter and then apply another filter to the result and to keep going like this. This is not an advanced operation at all. Tools that do not allow this (for example Tecplot) are severly limited compared to tools that do (ParaView, EnSight). VisIt is somewhere in between and I think is unnecessarily complicated to anybody but MeshTV users.

Berk 11:26, 30 Jan 2006 (EST)

Coding Style and Documentation

Summary: ParaQ should follow VTK coding standards and should be documented well

Links:

ParaQ still does not follow VTK coding standards 100%. One example is the use of:

if (foo)
  bar;

instead of

if (foo)
  {
  bar;
  }

We should either follow the VTK coding standards or come up with new ones for ParaQ. Also, we have to go back and document well all the ParaQ classes we will keep. The current documentation is very sparse. We should also start running doxygen.

Berk 11:41, 30 Jan 2006 (EST)

Configurable GUI?

Summary: How are we going to customize ParaQ and build application on top of it?

Links:

What will customizing ParaQ involve? Will we have to develop portions of the custom GUI in designer and write the glue clode manually? How are we going to develop custom property pages for proxies?

Berk 11:56, 30 Jan 2006 (EST)

For the demo, I put in a simple custom property page for an exodus reader. I made a ui file in the designer, and gave certain widgets special names. These names are the same as one would find in the paraview resources xml files. The designer ui file is compiled into a resource file, and the resource is included in ParaQ. When an exodus reader is created/viewed, the resource will be found by name, and used. The glue code connects the ui widgets to actions in ParaQ. For now, the glue code only supports a few widget types. If we wanted to support it, we can allow loading of shared libraries with these ui files in them, as well as support reading them in as text files on disk. Those making custom forms would not have to write any code at all.

Clinton 21:26, 30 Jan 2006 (EST)

Multiple Clients

Summary: To what extent are the clients sync'ed?

Links:

How much do we care about collaboration and to what extent are the clients sync'ed? Having two GUI clients connected to the same server is different than having one GUI and one python client connected to the same server. In the case of two GUI clients, we have to worry about syncing renders, interactions etc. Same with progress. Are we to consider these issues in the design?

Berk 12:02, 30 Jan 2006 (EST)

Multiple Servers

Summary: Update ParaQ to support multiple connections.

Links:

The server manager now has support for multiple servers through connections. ParaQ should be updated to support this. In this design, there is one process module and one connection per server. There is no longer need to create a new process module in File -> New. The process module should be created at startup.

Berk 12:02, 30 Jan 2006 (EST)

Source proxies are not special

Summary: Generalized interface to edit proxies should not be limited to source proxies.

Links:

The demo assumes that most of the proxies it is working with are source proxies (via SafeDownCast) and makes assumptions about connections using properties of type InputProperty. This will limit what kind of objects are editeable/displayable. The only time there is a need to cast a proxy to a source proxy is when one wants to display information about the dataset (part) associated with that proxy. If we treat the source proxies as any other proxy everywhere else. We will be able to use the same code to access all types of objects. Some examples: lookup tables, compound proxies, implicit functions. Having these objects show up in the pipeline inspector under a group has a lot of uses. For example, it can allow the user to reuse lookup tables and implicit functions and edit them from a centralized place. And as far as the user is concerned, an implicit plane is an "input" to a clip filter. The same is true for streamline seeds or lookup tables (input to a display).

Berk 12:10, 30 Jan 2006 (EST)

Plugin architecture

Summary: API and other support for building plugins.

Links:

We need early support for plugins to ParaQ - we hope to build Prism as a plugin, and having this supported right away will allow us to iterate on features and API sooner rather than later.

Hollywood 19:17 30 Jan 2006 (EST)

Replacing ParaVies

Summary: What is our feature set for replacing ParaView? What is our timeframe?

Links:

ParaQ development would be helped enormously by focusing all efforts on it, rather than splitting time between ParaView and ParaQ. How can we accomplish this? How soon?

Hollywood 19:17 30 Jan 2006 (EST)