GUI Notes
This page is for anything having to do with the GUI. Feel free to add a section and make note of anything that we should be collaborating on.
clean up context menus
- take out 'placeholder' actions everywhere to reduce clutter. if 'placeholder' type actions are needed to propose a certain action, actually fill them in with the proposed action and append something like '(TESTING)' to it to indicate that it should not work at this point. doing this may be a good visual way to propose and discuss new actions on types
- label actions in a more descriptive way (e.g. on script_batch nodes, 'remove node' should be replaced with 'remove script batch')
better tab handling
- associate open tabs with the currently open project so they are closed when the project is closed and possibly opened again when the project is reopened
- label new tabs better
- view result as> [advanced configuration] pops up a tab labeled'Generate Results' and so does the 'generate results with...' action
- the 'run estimation' action pops up a tab labeled with the project name (e.g. seattle_parcel.xml)
- the 'run this model' action pops up a tab labeled with the project name (e.g. seattle_parcel.xml)
opening, closing, and saving project issues
- after adding a new db connection either through the add new or clone options, the project is not marked as dirty. close project and open project will automatically discard newly created db connections
- if anything is changed in Database Server Connections after that (making the project dirty), then open or close project is called (without saving manually first), I get this error: 'there was an error removing the old config' then i have to restart the application to do anything useful
- there is a similar problem in the Results Manager where if new results are calculated (a new node is added under Results), the project is not marked as dirty, consequently open or close project will automatically discard the newly created Results
- in general, if a new node is added but not changed in any of the trees, or removed from the tree, the project is not marked as dirty. this happens in the script_library when using the 'add script' action, when using the 'clone batch' action on script_batch nodes, when using 'remove node' on a script_batch
- if you open a project, double click on any node with the intention of changing it, but then do not change it, the project is marked as dirty. if no change has been made, it is not really dirty. if this "non-change" was made in the database server connections area, from this point forward, if you attempt to close this project all trees are removed except the database server connections tree. if you then attempt to open another project, you get the 'there was an error removing the old config' message and you then need to restart the application to do anything useful.
results manager misc
- when using the 'generate results with...' action on a 'source_data' node, the new tab should already have the 'Simulation data' drop down pre-selected to reflect the exact 'source_data' node that the user started the action on
- likewise, when using the 'generate results with...' action on an 'indicator' node, the new tab should already have the 'Indicator' drop down pre-selected to reflect the exact 'indicator' node the user started the action on
- calculated results nodes need a 'delete' action, and should at least remove the node. should it also delete results stored on disk?
- a computed result has the 'view result as> [advanced configuration]' action, this needs a better label and possibly better organization. how about a context menu with 'view result as...' and 'export result as...' options?
- we should be able to delete an indicator from my_indicators
- the dataset drop down menu should contain more options than gridcell and zone, but we need to work out how to populate this
data manager misc
- the 'opus array to sql' and 'opus array to esri' actions in the opus data section dont make much sense to me by themselves. i can see wanting to do things with an array (e.g. histogram) but exporting them seems strange
- the 'opus database/dataset to sql/esri' actions should pop up a menu asking the user where they want to export to. this menu should be populated with selections created in the database server connections area
- db_connection types need a 'delete db connection' action
- db_connection types need the 'test db connection' action to work
- script_file types need the 'create new config' action to work
- script_file types need the 'exec script' action to work by popping up a window with required parameters. this would allow a script_file to be run as a one off action rather than requiring a user to create a script_config type from it in order to run it
- the script_batch type needs the 'execute batch' action to work
- we need a way to document scripts and display that in the gui so the user can get answers to questions like: what parameters are required? what form should they take? what does this script do?
- script_config types need move up, move down, delete, and clone actions
- script_batch types need add new script_config action and do not need the create new config action
- there needs to be more organization in the opus scripts area in general. we should be able to create organizational folders to place script_batch types into to reduce clutter.
- we need to decide how the user will ultimately add new scripts to the script library and edit them, will it be a manual process or will we create facilities in the gui to add and edit python scripts? will we provide the same sharing capabilities here that we plan to have elsewhere (e.g. my_indicators and eugene.frank.indicators)?
other misc
- better feedback provided to the user when an action completes successfully. something other than messages to the command line. possibly messages in the status bar? pop up messages with an 'ok' box? this will vary depending on the situation of course...
- readability of nodes: can we display 'Simulation_runs' as 'Simulation Runs' in the gui even if the underlying xml tag is still 'Simulation_runs'?
- make the 'type' column hideable
- the default editor, python console, and log view tabs dont do much useful work right now:
- the editor tab is not really an editor in the sense that we cannot edit then save anything. this functionality should be thought through. what are we going to edit here (simple .txt? color coded text like .xml or .sql? python scripts?). where should the commands go that control it (save, open, etc.), toolbar within the tab? menu commands?
- the log view tab currently does nothing. is this going to replace the messages normally seen in the command window? on this subject, we have various log areas scattered throughout the gui (estimation, scenario running, indicator calculation) which is pretty confusing
- the python console tab really doesn't do anything at this point. perhaps this should be removed until we decide what will be done with it (interactive multi-line python shell? iPython?)
- allowing two database server connections with the same name could be problematic, but this could also be a problem in other parts of the GUI (e.g. multiple calculated results with the same name?). we may need a general way to check to see if there is a duplicate node with some way to alert the user
