Difference between revisions of "Version 2"

From VistrailsWiki
Jump to navigation Jump to search
 
(12 intermediate revisions by 4 users not shown)
Line 14: Line 14:
** [DK] It is, arguably, the same amount of business as the PIP, however.
** [DK] It is, arguably, the same amount of business as the PIP, however.
** [CT] I often used the picture-in-picture to select a different version without having to change to the history view and then change back.  I miss it.  If it is detachable, the user can just put it where they want it, which makes this a question of where to put it by default and whether or not to allow it to be where it used to be (since detachable objects can not generally be placed there).   
** [CT] I often used the picture-in-picture to select a different version without having to change to the history view and then change back.  I miss it.  If it is detachable, the user can just put it where they want it, which makes this a question of where to put it by default and whether or not to allow it to be where it used to be (since detachable objects can not generally be placed there).   
** [DK] maybe the correct approach here is to allow views to be detatched?
** [CT] no.  they should always have the center.  perhaps a detachable PIP?  Meaning, it might be nice to have the history view by the pipeline view, but when you click the history button on top, you still want the history view to show up in the center panel.  I have some ideas, I'll share a few.  I'll still refer to the additional view as the PIP even if it is no longer a picture-in-picture.
*** leave the PIP where it was and make it easy to turn on/off (ie a shortcut key, button in the toolbar, or menu item).  optionally allow users to resize it.
*** Have a "combined" view button in the toolbar that switches to a view that has the PIP.  Then have a simple shortcut key to swap views (switch the larger with the smaller).
*** let the PIP come up in a new window, users can move or resize it.  it should be easy to toggle on/off (ie pressing the spacebar, etc.).  the issue here is having too many windows.  So, we could think of it as an extension to the existing window, meaning it should always stay on top of the main window (but it doesn't need to overlap it, it could be to the side).  For example, selecting the spreadsheet window would put it (the spreadsheet) on top.  Then, selecting the main window would give the main window the focus, but the PIP would still be on top of it.  Also, when I tab through all windows in VisTrails, the PIP would not get it's own tab, it would be considered part of the main window.  Then when people get tired of it, they can turn it off.
*** We could do a pseudo detach with the view, meaning the views stay where they are, but when you go to detach it, it comes up in its separate window.  Users are then free to put it where they want it.  I think we would want this detached view to show the history view when the pipeline view is selected, or the pipeline view when the history view is selected.
* We need some indication of which workflow is being displayed. Somewhere, we should display the label that identifies the workflow
* We need some indication of which workflow is being displayed. Somewhere, we should display the label that identifies the workflow
** [DK] In the v2.0 branch, the tab shows this.  I have it display "Pipeline: alias" or "Pipeline: ROOT + 3". [JF] Ok.
** [DK] In the v2.0 branch, the tab shows this.  I have it display "Pipeline: alias" or "Pipeline: ROOT + 3". [JF] Ok.
Line 21: Line 28:
* When I click on the workflow tab (in the main window,lower left corner) it always shows an "untitled.vt". This looks like a bug... And if I click on  untitled.vt, nothing happens.
* When I click on the workflow tab (in the main window,lower left corner) it always shows an "untitled.vt". This looks like a bug... And if I click on  untitled.vt, nothing happens.
** [DK] Yes, Emanuele mentioned this at the meeting.  I'm also not happy with the current interface.
** [DK] Yes, Emanuele mentioned this at the meeting.  I'm also not happy with the current interface.
** [TE] This has been fixed. "untitled.vt" will disappear when a vistrail is opened. It will also reappear when all vistrails are closed.


=== Dave's List ===
=== Dave's List ===
Line 29: Line 37:


* Diff currently being shown as a pipeline.  Should we create a mode for this
* Diff currently being shown as a pipeline.  Should we create a mode for this
** [TE] What is the advantage with not having diff as a popup? It seems it worked well as a modal popup.


* Buttons in Messages window look bad on the Mac, don't need all of them now as well, I think
* Buttons in Messages window look bad on the Mac, don't need all of them now as well, I think


* Missing callbacks for Merge and Control Flow Assistant menu items
* Missing callbacks for Merge and Control Flow Assistant menu items
** [TE] Merge can now be done by dragging a vistrail to another vistrail in the workspace window.


* Move execute button so it doesn't look like a mode
* Move execute button so it doesn't look like a mode
Line 43: Line 53:


* Do we need to worry about parameters with default values that won't be saved?  For example, a Boolean that we want set to False will not show as a set parameter currently because that is the default.  Same for an empty string...
* Do we need to worry about parameters with default values that won't be saved?  For example, a Boolean that we want set to False will not show as a set parameter currently because that is the default.  Same for an empty string...
** [DK] mimic 1.6 and create the function immediately?


=== Claurissa's Notes V2.0===
=== Claurissa's Notes V2.0===
* It is unclear to me how to get group and subworkflow options enabled.  If I start VisTrails, open a file, and then try to group some of its modules, the options remain disabled.  However, if I create a pipeline on the untitled workspace, group and subworkflow are enabled, and then I can open the other file and the options remain enabled.
* In the Module Configuration window, I can click on the check boxes, but it makes me save after each one and doesn't update the builder window.  Configuring ports to be visible works on the Module Information tab. 


* Parameter Exploration doesn't work.  When I hit the execute button, nothing seems to happen.
* Parameter Exploration doesn't work.  When I hit the execute button, nothing seems to happen.
Line 77: Line 92:
** [ES] In the mashup preview tab, pressing "Update" will run the pipeline with the values filled in the gui. It doesn't change anything in the mashup. I am still not sure what to do with the "save" button. I just wanted a button where the user could tell that he wants that mashup to be in the list, but for that he can just tag the mashup on inspector. What do you think?
** [ES] In the mashup preview tab, pressing "Update" will run the pipeline with the values filled in the gui. It doesn't change anything in the mashup. I am still not sure what to do with the "save" button. I just wanted a button where the user could tell that he wants that mashup to be in the list, but for that he can just tag the mashup on inspector. What do you think?
** [JF] From the interface, it is not clear that by just changing the tag, the mashup will be saved. Maybe, when the user hits save, if a tag has not been entered (i.e., the default tag is being used), we could prompt the user to enter a tag name? Also, while editing the mashup using the inspector, it might be better to have the name of the workflow on the top, don't you think? (and the mashup tag right below).
** [JF] From the interface, it is not clear that by just changing the tag, the mashup will be saved. Maybe, when the user hits save, if a tag has not been entered (i.e., the default tag is being used), we could prompt the user to enter a tag name? Also, while editing the mashup using the inspector, it might be better to have the name of the workflow on the top, don't you think? (and the mashup tag right below).
 
** [ES] I've reorganized the panels. It seems more crowded, but I think it looks more usable. I temporarily removed the "save" button while I finish the dialogs. It will be called "Keep this" and it will be enabled when the version is not tagged.
* [JF] Should we have a special widget for entering file names?
* [JF] Should we have a special widget for entering file names?
** [ES] You mean when the alias point to a filename? Or to any string, a user might define it as a file widget using the display widget combo box?
* [JF] How do I view the actual mashup interface? And how to I execute the mashup on my laptop?
* [JF] How do I view the actual mashup interface? And how to I execute the mashup on my laptop?
 
** [ES] When you select a version that has at least a mashup saved, you will see a Mashups (#) button below the thumbnail preview widget. Clicking on that button, will show the mashups and selecting one of them will execute it.
* I made some changes to the "Alias Details" and then clicked on "Save" and then "Preview", nothing happened. After I clicked on these two buttons a few times, the workflow executed, but the actual mashup preview was not displayed.
* I made some changes to the "Alias Details" and then clicked on "Save" and then "Preview", nothing happened. After I clicked on these two buttons a few times, the workflow executed, but the actual mashup preview was not displayed.
** [ES] I am working on fixing this now.
** [ES] <del>I am working on fixing this now.</del> It should be fixed in the current mashups branch and in the binary uploaded on --[[User:Emanuele|Emanuele]] 20:16, 26 May 2011 (MDT)


* <del>It would be nice if it were possible to center and resize the workflow to fit in the window (cmd-shift-R)</del>
* <del>It would be nice if it were possible to center and resize the workflow to fit in the window (cmd-shift-R)</del>
** [ES] This is supported in the current mashups branch (I haven't built a new binary yet)
** [ES] This is supported in the current mashups branch. (I haven't built a new binary yet)
 
===More Mashups Comments===
 
===Tommy's comments on tabs===
 
* To support viewing multiple workflows from possibly different vistrails we need to improve the way we handle tabs.
* What is a tab?
** Each tab represents a view for a specific vistrail
** All tabs use the same global toolbar
** We may need to have mode buttons for each tab to avoid confusion.
** A tab should only contain one of the possible modes. PiP should be okay but the visual diff should open in a new window.
** How to see which tab is currently selected?
* Switching vistrail only does so for the main window. Detached tabs remain connected to their original vistrail.
** The main window is responsible for switching vistrails.
Is it useful to have stacked tabs when we can only see one of them at a time and they are all a view of the current vistrail? Maybe we should always open them in a new window.
 
[ES] I agree that we need to improve the way we handle tabs.
 
'''Currently''', when you create/open a vistrail, a vistrail view containing all the views (pipeline, history, parameter exploration, etc.) created in a stacked widget and you have a single tab that displays the current view. You switch views by pressing the buttons in the top toolbar. You can also create other pipeline tabs.  All vistrail views (including their tabs) share the same toolbar and global palettes. 
 
'''My suggestion''' is that a vistrail view can use multiple tabbed windows. It starts with one single window, similar to what we have now, but when you drag the tab outside, it duplicates the top toolbar on the new window. You can add a tab to one of these windows. So the current state would be composed by current_vistrail_view, current_tab_window, current_tab. The palettes would still be global. In terms of implementation, we will just have to add another element in the hierarchy that will take over some of the behavior of the current vistrail view and vistrails window. Almost all the logic to keep track of action states that is in place wouldn't change. So notice that we don't have the concept of a main window anymore. The global palettes will function as the access point to the other views. For example, you change vistrails using the workspace panel.

Latest revision as of 15:59, 7 June 2011

This page is setup to address and track issues with the new VisTrails 2.0 construction. Please add comments or new issues to this page.

Juliana's notes about new interface

  • It seems there are too many windows when we start VisTrails. What about only showing the main window? And fire the spreadsheet and inspector only when 'needed'? for the inspector, when a vt is open and a wf is selected, and for the spreadsheet when a workflow is run.
    • [DK] What do you mean by windows? The tabbed windows or the fact that there is a builder window, "utility" window, and a spreadsheet window?
    • [JF] The latter: 3 windows popup when I start VisTrais: the builder, the inspector and the spreadsheet.
    • [DK] Many of the windows in the "utility" window are not dependent on a workflow (for example, the console and messages tabs). We could however, not display them until a user asks to see the given view.
    • [JF] This is what I meant.
  • I noticed that the picture-in-picture disappeared. I think that is helpful to give context. At least when we are displaying a workflow, it is useful to see the version tree.
    • [DK] I think it was too small to be useful. I can see the argument for being able to see both, but I think we need more real estate than the PIP had; perhaps we allow the History View to be shown as a tab on the left or as a detached view?
    • [JF] the only issue here is whether this will be too busy
    • [DK] It is, arguably, the same amount of business as the PIP, however.
    • [CT] I often used the picture-in-picture to select a different version without having to change to the history view and then change back. I miss it. If it is detachable, the user can just put it where they want it, which makes this a question of where to put it by default and whether or not to allow it to be where it used to be (since detachable objects can not generally be placed there).
    • [DK] maybe the correct approach here is to allow views to be detatched?
    • [CT] no. they should always have the center. perhaps a detachable PIP? Meaning, it might be nice to have the history view by the pipeline view, but when you click the history button on top, you still want the history view to show up in the center panel. I have some ideas, I'll share a few. I'll still refer to the additional view as the PIP even if it is no longer a picture-in-picture.
      • leave the PIP where it was and make it easy to turn on/off (ie a shortcut key, button in the toolbar, or menu item). optionally allow users to resize it.
      • Have a "combined" view button in the toolbar that switches to a view that has the PIP. Then have a simple shortcut key to swap views (switch the larger with the smaller).
      • let the PIP come up in a new window, users can move or resize it. it should be easy to toggle on/off (ie pressing the spacebar, etc.). the issue here is having too many windows. So, we could think of it as an extension to the existing window, meaning it should always stay on top of the main window (but it doesn't need to overlap it, it could be to the side). For example, selecting the spreadsheet window would put it (the spreadsheet) on top. Then, selecting the main window would give the main window the focus, but the PIP would still be on top of it. Also, when I tab through all windows in VisTrails, the PIP would not get it's own tab, it would be considered part of the main window. Then when people get tired of it, they can turn it off.
      • We could do a pseudo detach with the view, meaning the views stay where they are, but when you go to detach it, it comes up in its separate window. Users are then free to put it where they want it. I think we would want this detached view to show the history view when the pipeline view is selected, or the pipeline view when the history view is selected.
  • We need some indication of which workflow is being displayed. Somewhere, we should display the label that identifies the workflow
    • [DK] In the v2.0 branch, the tab shows this. I have it display "Pipeline: alias" or "Pipeline: ROOT + 3". [JF] Ok.
    • [ES] Dave, it doesn't show anymore. I remember seeing the tab before, but I've just checked out v2.0 and I can't see it either.
    • [DK] Right, when there is only a single tab, I hide the tab bar. You can see the titles when if you create a new view (Ctrl/Cmd+T)
  • When I click on the workflow tab (in the main window,lower left corner) it always shows an "untitled.vt". This looks like a bug... And if I click on untitled.vt, nothing happens.
    • [DK] Yes, Emanuele mentioned this at the meeting. I'm also not happy with the current interface.
    • [TE] This has been fixed. "untitled.vt" will disappear when a vistrail is opened. It will also reappear when all vistrails are closed.

Dave's List

  • Reduce size of palette names so they don't take so much space
  • Set default palettes for diff, other views
  • Diff currently being shown as a pipeline. Should we create a mode for this
    • [TE] What is the advantage with not having diff as a popup? It seems it worked well as a modal popup.
  • Buttons in Messages window look bad on the Mac, don't need all of them now as well, I think
  • Missing callbacks for Merge and Control Flow Assistant menu items
    • [TE] Merge can now be done by dragging a vistrail to another vistrail in the workspace window.
  • Move execute button so it doesn't look like a mode
  • Aliases support for parameters.
    • [DK] I really want to see old-style aliases finally go away with the globals for workflow and vistrails taking their place, but we can add them for now.
    • [ES] I just added them in v2.0 branch.
  • How do we support functions that have no parameters in the new port configuration?
  • Do we need to worry about parameters with default values that won't be saved? For example, a Boolean that we want set to False will not show as a set parameter currently because that is the default. Same for an empty string...
    • [DK] mimic 1.6 and create the function immediately?

Claurissa's Notes V2.0

  • It is unclear to me how to get group and subworkflow options enabled. If I start VisTrails, open a file, and then try to group some of its modules, the options remain disabled. However, if I create a pipeline on the untitled workspace, group and subworkflow are enabled, and then I can open the other file and the options remain enabled.
  • In the Module Configuration window, I can click on the check boxes, but it makes me save after each one and doesn't update the builder window. Configuring ports to be visible works on the Module Information tab.
  • Parameter Exploration doesn't work. When I hit the execute button, nothing seems to happen.
  • Search doesn't work either. If I double click execute, I need to force quit Vistrails. If I press it only once, nothing seems to happen. If I type something into the box rather than creating a visual query, it does display a tree, but nothing is highlighted.
  • When you detach and close a tab from the Configure/Console/Documentation/Latex/Messages/etc. window, there is no way to get it back without restarting VisTrails.
  • Is there a way to collapse all lists in the modules tab? That would be nice to have.
  • The save file option is disabled even after I make a change. I can only select save as, or save on exit (on either the v2.0 or mashup branches). An asterisk does appear next to the filename in the window title on the mashups branch, but not the v2.0 branch.
  • Changing between files using the workspace tab doesn't work on the 2.0 branch (but does on mashups).
  • The Provenance browser doesn't contain newly executed workflows unless I exit VisTrails and restart (it doesn't update). Perhaps that is because I can't save the file???
  • Are the objects that appear in the bottom half of the workspace tab associated with execution provenance? It is not clear to me what they are for. It seems a new one appears after I save a new file and stays there permanently. Clicking on them doesn't seem to do much. Are they just for information?

Juliana's notes about the mashup functionality

  • Since it is not possible to create aliases with the current 2.0, I used 1.6 to create aliases for brain.vt. But when I loaded brain.vt into the 2.0 version and selected the mashup inspector, no aliases were shown [JF] My bad: it works!
  • When I save a mashup, where is it saved? Should it be displayed under the "List" tab in the mashup inspector?
    • [ES] The mashups are saved when you save the vistrail. When you tag a mashup it is added to the list.
  • I changed a tag for a mashup, and clicked "save". But the new tag was not displayed in the "List".
    • [ES] There was a problem with the signals that were not being caught. You don't have to save. Just changing a tag should put it in the list.
  • In the "List", will I be able to select a previously created mashup and change it?
    • [ES] Yes, this is working in the current mashups branch
  • What is the difference between the "Save" and the "Update"?
    • [ES] In the mashup preview tab, pressing "Update" will run the pipeline with the values filled in the gui. It doesn't change anything in the mashup. I am still not sure what to do with the "save" button. I just wanted a button where the user could tell that he wants that mashup to be in the list, but for that he can just tag the mashup on inspector. What do you think?
    • [JF] From the interface, it is not clear that by just changing the tag, the mashup will be saved. Maybe, when the user hits save, if a tag has not been entered (i.e., the default tag is being used), we could prompt the user to enter a tag name? Also, while editing the mashup using the inspector, it might be better to have the name of the workflow on the top, don't you think? (and the mashup tag right below).
    • [ES] I've reorganized the panels. It seems more crowded, but I think it looks more usable. I temporarily removed the "save" button while I finish the dialogs. It will be called "Keep this" and it will be enabled when the version is not tagged.
  • [JF] Should we have a special widget for entering file names?
    • [ES] You mean when the alias point to a filename? Or to any string, a user might define it as a file widget using the display widget combo box?
  • [JF] How do I view the actual mashup interface? And how to I execute the mashup on my laptop?
    • [ES] When you select a version that has at least a mashup saved, you will see a Mashups (#) button below the thumbnail preview widget. Clicking on that button, will show the mashups and selecting one of them will execute it.
  • I made some changes to the "Alias Details" and then clicked on "Save" and then "Preview", nothing happened. After I clicked on these two buttons a few times, the workflow executed, but the actual mashup preview was not displayed.
    • [ES] I am working on fixing this now. It should be fixed in the current mashups branch and in the binary uploaded on --Emanuele 20:16, 26 May 2011 (MDT)
  • It would be nice if it were possible to center and resize the workflow to fit in the window (cmd-shift-R)
    • [ES] This is supported in the current mashups branch. (I haven't built a new binary yet)

More Mashups Comments

Tommy's comments on tabs

  • To support viewing multiple workflows from possibly different vistrails we need to improve the way we handle tabs.
  • What is a tab?
    • Each tab represents a view for a specific vistrail
    • All tabs use the same global toolbar
    • We may need to have mode buttons for each tab to avoid confusion.
    • A tab should only contain one of the possible modes. PiP should be okay but the visual diff should open in a new window.
    • How to see which tab is currently selected?
  • Switching vistrail only does so for the main window. Detached tabs remain connected to their original vistrail.
    • The main window is responsible for switching vistrails.

Is it useful to have stacked tabs when we can only see one of them at a time and they are all a view of the current vistrail? Maybe we should always open them in a new window.

[ES] I agree that we need to improve the way we handle tabs.

Currently, when you create/open a vistrail, a vistrail view containing all the views (pipeline, history, parameter exploration, etc.) created in a stacked widget and you have a single tab that displays the current view. You switch views by pressing the buttons in the top toolbar. You can also create other pipeline tabs. All vistrail views (including their tabs) share the same toolbar and global palettes.

My suggestion is that a vistrail view can use multiple tabbed windows. It starts with one single window, similar to what we have now, but when you drag the tab outside, it duplicates the top toolbar on the new window. You can add a tab to one of these windows. So the current state would be composed by current_vistrail_view, current_tab_window, current_tab. The palettes would still be global. In terms of implementation, we will just have to add another element in the hierarchy that will take over some of the behavior of the current vistrail view and vistrails window. Almost all the logic to keep track of action states that is in place wouldn't change. So notice that we don't have the concept of a main window anymore. The global palettes will function as the access point to the other views. For example, you change vistrails using the workspace panel.