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)

Putting plots on the tile display is pretty straighforward. It's a pretty easy extension to what's in Plotting Parallel Data (PGraph) except that you now need an OpenGL version for every plot type (see Talk:Plotting Parallel Data (PGraph)#Plots on Parallel Displays).

We don't need an OpenGL version of the plots to put them in the multi-view in ParaQ. We can put the current Qt widgets in there. All we have to do is allow it to happen in the gui. The code has already been semi-prepared for it. Most of the mapping code I put in the pipeline data class takes a QWidget, not a QVTKWidget. Mark Richardson 11:53, 31 Jan 2006 (EST)

In short, I don't think this will be a difficult thing to add in the future. My inclination is to punt for now and add the feature later. However, I think Mark's suggestion of putting plots with the rest of the multi-views will make this easier to implement in the future (in addition to the other advantages he lists).

--Kmorel 08:54, 31 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)

Once we manage to get the dashboard green (no compile errors/warnings and no failing tests), then it will be easier to see when something newly committed is causing problems.

Amy 09:13, 31 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)

Or more correctly, VTK libraries conflicting with the system freetype library. Qt doesn't use freetype at all if the system doesn't have it. Perhaps VTK should be reviewed for its freetype usage? Some functions it uses from freetype (see FTC_Manager_LookupFace & FTC_Manager_LookupSize in vtk_freetype.h) can prevent binary distributions of ParaQ from working on some platforms.

Clinton 21:34, 30 Jan 2006 (EST)

I agree with Clinton. We should review VTK's usage of the freetype library and see if it can work with existing freetype libraries. Maybe the freetype library included in VTK can be updated to match what is currently distributed with linux. We would still use the system freetype library if it is available. I am guessing this problem is occuring because VTK is using a freetype feature that is no longer available. Am I correct?

Berk 10:01, 31 Jan 2006 (EST)

Yeah, it might be easier to make VTK work with the system freetype better, than to mangle freetype. We can query the Qt installation for freetype usage, and set VTK_USE_SYSTEM_FREETYPE accordingly. VTK does use a relatively recent freetype. However, building VTK on an older linux using system freetype won't work. Building on a newer one, and distributing to an older one won't work. ETI has a couple linux machines with older freetypes, and I imagine other people would. This is because is seems the freetype developers broke the rules and VTK uses 2 functions that exist only in the newer freetype library. The other freetypes have rough equivalents of those 2 functions, but the function names are different. So to fix that, maybe change VTK to not call those 2 functions?

Clinton 12:41, 31 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:

The first step is to determine what the "document" is for the application. In the case of ParaQ, the document seems to contain two parts: the multi-view layout and the pipeline setup. Prism has a nice setup. ParaQ should probably follow what prism does. Mark Richardson 11:58, 31 Jan 2006 (EST)

Installation Management

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

Links: NullSoft is a good, open-source installer for Win32 operating systems.

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)

To handle multiple inputs, the pipeline list would use a chain for each input. It would branch off the window with an icon place holder similar to the place holder used to branch the pipeline. At the end of the "merge" chain, there whould be a "link back" item. This item would link the input chain to the filter with multiple inputs. Double clicking the "link back" item would jump to the connected item to help the user follow the chain.

To handle multiple windows, there would be "link out" and "link in" items. They would behave similarly to the "link back" item and allow the user to navigate back and forth between the windows. Mark Richardson 12:09, 31 Jan 2006 (EST)

Here's an example of a pipeline with multiple inputs and output to multiple windows.

This was an early concept design. It doesn't show the multiple input "merge" chain as described above. It does show the link items though. The greenish arrow pointing back down the pipeline is the "link back" item. The light blue circles with the triangle pointing out and in are the "link out" and "link in" items respectively. Mark Richardson 12:50, 31 Jan 2006 (EST)

I think it's clear that no single pipeline view is best for all situations. Offhand I can think of three potentially useful pipeline views: a hierarchical view (like in the demo), a simple list of filters (like what is in ParaView now + renaming and reordering capabilities), and a full pipeline graph (like in VisTrails).

In short, I expect that eventually we will have multiple, tabbed pipeline views. At the very least it should be trivial to add and remove pipeline views from the GUI.

--Kmorel 09:23, 31 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)

Coordination among charts and multiple views has already come up as an issue in the demo - as an example, switching back-and-forth between proxies in the pipeline view updates the current variable and the variable displayed by the histogram and line charts. On the other hand, the set of elements displayed by the line chart / element inspector does not change. In long term we will likely want to support individual charts that "follow" the current view, multiple charts each connected to a "specific" view, charts that "follow" the current variable, charts that always display a specific variable, etc.

Tshead 11:23, 31 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)

I think the current reorganization of the Filter menu in ParaQ to group filters according to their functionality will make applying filters easier for users. Seeing a 2-column list of filters is somewhat overwhelming. Maybe this categorization of the filters will be enough to make filters manageable to users.

Is it the language that users are getting hung up on: "applying a filter to a filter"? Would it be enough if we instead called filters "operations", but still allowed the user to apply several operations to a dataset? Is there a way we can hide the complexity from the user while not taking functionality away from them?

Amy 09:30, 31 Jan 2006 (EST)

"Modifiers" may be a more neutral term, it avoids the one-input, one-output, "taking something away" semantics of the world "filter".

Tshead 11:13, 31 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 applications 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)

Wow this approach sounds cool.

Berk 10:00, 31 Jan 2006 (EST)

Although I like the idea of being able to create a new resource by simply making a ui file in designer and an xml description, I don't think ParaQ should read in files directly. Trying to support a third-party GUI descriptor file does not sound like a good use of our resources, especially as the ui format will inevitably change. A user sophisticated enough to use Qt Designer is also probably sophisticated to compile some code.

There also needs to be the possibility of adding glue code if necessary. This is important for property pages that have widgets that interact with each other (think calculator widget). Ultimately, the ParaQ build should include a macro that will build a library containing GUI components (or anything else that can plug into the ParaQ GUI or server):

PARAQ_ADD_LIBRARY(
  name 
  ServerManagerXmlFile
  GUIXmlFile
  [EXPORTED_WIDGETS widget1 header1 widget2 header2 ...]
  [SOURCES file1.cxx file2.cxx ...]
  [CLIENT_SERVER_WRAPPING file1 file2 ...]
  )

Whatever mechanism we use, it should be easy and we should use the same one for the widgets in that come with ParaQ and ones that a user might add.

--Kmorel 10:58, 31 Jan 2006 (EST)

I would argue that the current ParaQ client is the model for just such an application - if you look at Qt/Client, you will see that it is basically just main() plus the pqMainWindow class, which is using components from Qt/Widgets and tying them together - there is very little logic in pqMainWindow. Creating a custom application should be a simple matter of creating a new binary that links to the same libraries, and combines the same components in different ways.

Tshead 11:36, 31 Jan 2006 (EST)

I agree with Tim's statement. There are a few things still in the main window class that I'd like to move to Qt/Widgets in order to make future customization easier. Mark Richardson 12:16, 31 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: ProcessModule And Connections

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)

I've added a Wiki page describing the usage of the process module with multiple client-server connections. (the link is in Links)

Utkarsh 1:41, 31 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)

I think Clint would agree that our use of compound proxies is a bit of a hack. The compound proxies need more support for connections. We already have the concept of exposed properties. I think we need the same thing for connections. What inputs should be used? When connected to a subsequent proxy in the pipeline, what sub-proxy of the compound proxy should be used? It would be great to be able to name the inputs and outputs for the user. It would make it easier for them to connect the compound proxy correctly. (Have we come up with a user friendly name? I like Bundle.) Mark Richardson 12:32, 31 Jan 2006 (EST)

Yes, I think we need to fix ParaQ in this respect and make it more generic with proxies. I have put if()'s in several places to handle compound proxies. Better to fix it sooner than later. I'd appreciate suggestions for how to be generic, yet do the right thing with some actions that only make sense with certain types of proxies. A couple issues I haven't figured out are: how to determine which part of a compound proxy to connect to a display proxy, traversal of the pipeline when a compound proxy is involved, and traversal leads you to the insides of a compound proxy (when one doesn't care about the insides of it), how to interact with objects that only work with certain types of proxies (e.g. histogram with source proxies).

Clinton 12:57, 31 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)

I mentioned some thoughts on plugins in #Configurable GUI?.

--Kmorel 11:02, 31 Jan 2006 (EST)

Replacing ParaView

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)