Hi,
I believe I already faced the issue in the past and not sure if a solution has been found. When launching Gomboc in batch mode via the terminal to execute dynamic simulation (or any simulation) defined via a –run-script-file option, it seems that when using multiple monitors/screens, Gomboc fails to launch its interface, sometime it does not launch any batch instances interfaces at all, sometime it manages to launch some. When looking at the process in the task manager processes, I do see the Gomboc instances appearing as well.
The —disable–graphics is not used in that case when launching Gomboc, so I would still expect to see the Gomboc interface appearing.
When using one monitor, the instances are launching fine with their interfaces and it solves the issue. However I was wondering if the multi-screen behavior could be addressed so this feature would be available when using multiple monitors.
When launching in batch mode via terminal instances, it seems to take a bit of time to appear, more time compared to when it is opened manually via a shortcut double click, not sure if there is any optimization that could be done on this front as well. Could this be related to the way Gomboc.exe might be added in the environment variable path?
Another feature which might be useful is when those instances are launched via the batch command, having the ability to deactivate any interaction but still see them appear to see how the simulation perform live, so they could be monitored on the screen while the user would still be able to use their mouse and keyboard safely to carry on other tasks in parallel on the same machine.
Thanks,
Nicolas
Hi Nicolas,
Thank you very much for your question and suggestion about the GUI.
- We have experienced very similar behaviour when launching multiple instances of Gomboc in a very short timeframe. It seems that QT is unable to adhere to main window geometry commands. Please find below two possible workarounds:
- Something that seems to work a lot better is to launch the windows minimized and then open the ones of interest from the taskbar. Please use the command line option ‘
--minimized‘ to have minimized windows when launching Gomboc instances from the terminal. - Another solution used in the past is to let the model control its layout, using a module. Here is how to do it:
- Put a Gomboc window in the desired layout (screen position, widgets open and widgets location in the docking zones). Save this layout to the clipboard with Menubar–> Layout –> LayoutToClipboard
- Paste the Base64 String that is now on the clipboard somewhere in a BIC or JS file
- Repeat (1) and (2) for other desired layouts
- Create a module in the top-level BOC file that enforces the desired layout using the
Host.restoreWindowLayoutFromBase64Tuplecommand. Please make sure you do not enforce this at each timestep because it will make the simulation extremely slow. For the tested use case, it was good enough to enforce the layout at start-up and again at t == 5.00 and t == 10.0 in case Qt missed the previous ones.
- Something that seems to work a lot better is to launch the windows minimized and then open the ones of interest from the taskbar. Please use the command line option ‘
- Please find in OverlayPlayground.boc an example of the module described in 1.2. This “tictoc-layout” module toggles the layout every two seconds: it goes from minimized to left on the screen to right on the screen to minimized again. The Base64 strings pasted from the clipboard are on line 51 and 52. Please note that the layout strings are screen hardware topology dependent, so you can try using the strings from the example file but it is better to create your own ones.
Finally, this BOC example relies on a custom DataTableOverlayEx.js which enables to control the colour of the data cells depending on the channel value. More information about this custom DataTableOverlayEx.js in this post. - Regarding the difference you observed in terms performance when launching in batch mode via terminal instances compared to when opening manually via a shortcut double click, our experience points out that this is caused by Cryptlex, that probably does not scale very well with multiple instances. A single instance by double clicking from Explorer or from a command line launch are identical in start-up time on our machines. So the difference in start-up time observed is most likely coming from the multiple instances that are fighting for a “go-ahead” from Cryptlex.
- Your suggestion of the option to disable the GUI when launching is very interesting and has been implemented as a command line option ‘
--disable-gui‘. This new feature will be available in the next Gomboc release.