"Load configuration" does not default to current day's output directory - Githubissues

labscript-suite-temp-2 / runmanager

runmanager is a graphical user interface (GUI) used to aid the compilation of labscript experiment scripts into hardware instructions to be executed on the hardware. Experiment parameters can be adjusted in the GUI, and lists of parameters can be used to create sequences of experiments, and scan over complex parameter spaces.

BSD 2-Clause "Simplified" License

0 stars 0 forks source link

"Load configuration" does not default to current day's output directory #1

Closed philipstarkey closed 10 years ago

philipstarkey commented 10 years ago

Original report (archived issue) by Shaun Johnstone (Bitbucket: shjohnst, GitHub: shjohnst).

When you load a configuration in runmanager, the output directory is set to the one used on the day the configuration was saved. If runmanager was using the default directory (not manually changed) when it was saved, then it should load the appropriate default directory for the current day.

philipstarkey commented 10 years ago

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

I've tried to fix this, but it is extremely difficult. This is mainly because the GTK file chooser behaves very strangely. If you set the path on a file chooser programatically, and then immediately read out the path again, it gives you the previous path, not the one you just set. The path is not updated internally until control is returned to the GTK event loop.

Long story short, this isn't going to be fixed until runmanager is ported to PyQt.

philipstarkey commented 10 years ago

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

Qt is so much nicer than GTK. Although it doesn't have a FileChooser widget, it was easy to make something that looks like one, and setting the text is immediate, like almost everything else.

In fact, I only realised recently that so long as you're in the main thread, slots are called immediately when signals are emitted, rather than being queued up and executing when execution gets back to the event loop. It's fantastic, it means everything is exactly in the state you expect it to be, and you almost never have to queue things up for later once the changes you've made take effect - because they've already taken effect.

Anyway this seems trivial, I'll do it when I'm implementing the save and load functions in the Qt port sometime in the next week.

philipstarkey commented 10 years ago

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

changed assignee_account_id from "557058:2f99420c-1dbd-4837-952c-82c421b8fbdd" to "557058:cbf1bc43-1dc2-477b-9e25-1a8f40fd7ee3"
changed assignee from "philipstarkey (Bitbucket: philipstarkey, GitHub: philipstarkey)" to "cbillington (Bitbucket: cbillington, GitHub: chrisjbillington)"

philipstarkey commented 10 years ago

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

changed state from "new" to "resolved"

Resolved in the Qt port (runmanager 2.0)

The save data now stores a parameter called is_using_default_shot_output_folder. The loader checks it and if True, sets the current default folder at load time.