Thanks for merging these in! I pushed out a new release (1.2.1) that includes the changes. I made some minor changes. A few notes on that:
- I removed the option to have FWDB_CONFIG environment variable point to a file. Basically I am trying to enforce consistent ways to define the LaunchPad that work across all “lpad” commands, namely:
i) putting the launchpad file in the same dir
ii) using the -l or -c options when calling lpad
iii) setting the FW_CONFIG_FILE environment variable.
The closest thing to what you were doing before would be to use the FW_CONFIG_FILE environment variable (option iii). That env variable points not to a my_launchpad.yaml file but to a file called (say) FW_config.yaml. The contents of the config file has a LAUNCHPAD_LOC that points to the launchpad. The full instructions are here:
It is one more step involving an extra file from what you had before. Hopefully it is OK. If not, let me know and we can talk about how to make a more scalable solution.
I removed to state_to_class var as it was unused
I added some color keys in the wf details page that should help in interpreting the states
Thanks again for your contribution! If you are able to contribute the progress bars as well, it would also be very helpful. Updating bootstrap is certainly OK for us.
On Fri, Nov 6, 2015 at 3:31 PM, Chris [email protected] wrote:
Yea I’d love to, I’ll try to make time Sunday to pull down a new clone and merge some.
Sorry for the delay!
On Nov 6, 2015 6:29 PM, “Anubhav Jain” [email protected] wrote:
I just wanted to follow up to see if there is still interest from your side to contribute to the FWS web gui. The team would be very happy to have even a subset of your modifications.
On Monday, October 19, 2015 at 10:26:43 AM UTC-7, Anubhav Jain wrote:
It would be great to have these integrated into the main branch. If you can submit a pull request for the relevant features I can merge them and make any modifications as needed.
Regarding the shared filesystem, you’re right that it probably would not be globally functional. At some point it would be nice to have a similar feature for the Trackers (https://pythonhosted.org/FireWorks/tracker_tutorial.html) but I am not sure how much work it would be to adapt the code.
I am not sure what features are easy or difficult to separate out, but would be happy to start with whatever is simple and go from there.
On Mon, Oct 19, 2015 at 7:17 AM, Chris H [email protected] wrote:
I figured I had asked enough questions and should offer to contribute something
Here is a load of screenshots detailing some of the GUI changes we currently have functional:
- cytoscape.js draws the directed graph in the wf_details screen. (zoomable, pannable, rearrangeable)
- on click handlebars templated step details
- we have a shared filesystem for all nodes, so on click can pull up the error/output tail as well, but I guess that might not be globally functional.
- home.html uses bootstrap progress bars to show condensed statuses, since the details screen consumes that functionality in our fork
I redid the backend of the flask GUI in order to support multiple fireworks database per instance of mongo, since we have a per-user setup of fireworks at the moment.
So these aren’t instantly contributable, but I’d be happy to break out the relevant code and ship it as a pull request or patch, if there’s any interest.
You received this message because you are subscribed to the Google Groups “fireworkflows” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/fireworkflows/320f7d4a-c134-45fc-aa9b-745b9a542398%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.