Closed jf--- closed 4 years ago
first of all, sorry for replying so late! most of my reply is now obsolete, but i will answer anyway :)
I suspect that each time an macro is invoked, the python script has to load a cached .json file, or loads geometry stored in designated layers. That is the state of the program isnt kept in memory, but is being rebuild.
the way the "old" compas
ui system for Rhino works is by using a front controller. the methods of the front controller are bound to the buttons of the toolbar. the front controller also stores an instance of the current form and force diagrams which are constantly updated and modified by the various actions assigned to the buttons. once loaded, the data is thus live and doesn't need to be reloaded, nor is it stored in Rhino geometry or layers. in fact, the Rhino geometry is just a representation of the current state of the live data.
for example, if you delete the entire form diagram and subsequently compute horizontal equilibrium, the tool will not complain and simply draw the new form diagram when the results of the algorithm are available.
the perceived lag of some of the methods of compas_tna
is most likely related to the fact that much of the computation is handled by Numpy/Scipy based algorithms which have to be run through an external process. in the past this was handled with so-called XFunc
s. although this was quite convenient, an XFunc
has the downside of starting a separate Python interpreter for every call and thus creates a lot of overhead. This has now been replaced with the much faster system of Remote Procedure Calls.
So the hunch here is that creating a ETO based UI is low hanging fruit, also since the actions already defined are easily hooked to such an ETO based UI. The upside here is that while the UI loop is running, the TNA mesh is kept in memory, hence quite a boost in responsiveness is to be expected
as you will see in the current version of the package, we have been working towards more transparent cross-platform UI implementations by using Python-based command plugins. the individual commands use the sticky
dict of the scriptcontext
to keep data alive across calls and could be linked to command buttons much like the methods of the front controller that was used before.
i assume though that you are talking about a single ETO form that handles the entire event loop of a TNA design session and therefore automatically keeps all data alive without the need for the sticky dict.
anyway, this is all still very much under construction but should be reaching a certain level of maturity as we approach the first full release of COMPAS at the beginning of the summer.
let me know what you think!
once loaded, the data is thus live and doesn't need to be reloaded
Thanks for pointing that out...
This has now been replaced with the much faster system of Remote Procedure Calls
I've noticed indeed that compas_tna
does feel more responsive than RhinoVault
indeed...
we have been working towards more transparent cross-platform UI implementations by using Python-based command plugins
Wow, that's wonderful news, so the RunCommand approach looks neat. I suppose corresponding widgets to the commands will be developed in the future?
a single ETO form that handles the entire event loop of a TNA design session and therefore automatically keeps all data alive
Indeed. Sorry, indeed its all about the event loop, I should have been more clear...
ETO seems pretty neat...
Following your matplotlib style Artist
abstraction, who knows we can think of ETO as a mere backend, such that these interfaces can be shared across UI API's ( Qt, blender ). Compas does a wonderful job in this regard 💘
let me know what you think!
First of all, stoked to be able to read the code after used RhinoVault
for some time...
Writing the commands before implementing the widgets / UI also seems a good idea.
I think it would be a good idea that Commands are inherit from a class, such undo
is easily implemented, in analogy to Qt's
undo framework. That approach might also help to manage state through a FSM.
forgot about this...
i am working on a command class in compas_rhino.ui
. adding undo
functionality there would be a good idea indeed.
we will also add some kind of autosave
functionality to make the undo process a bit more robust.
by the way, have a look at compas_viewers
for progress on the PySide2/PyOpenGL
based implementations...
gonna close this as it is no longer relevant because of the upcoming RV2 release...
Moving from .rui -> ETO ui
there's a method
rui_make
that generates a .rui file, a toolbar that calls python scripts. In summary hitting a button invokes amacro
.Details
Is your feature request related to a problem? Please describe.
( I'm making some assumptions here, I hope these are correct. Havent utilized the toolbar since working from RhinoMac )
I suspect that each time an macro is invoked, the python script has to load a cached .json file, or loads geometry stored in designated layers. That is the state of the program isnt kept in memory, but is being rebuild.
So the hunch here is that creating a
ETO
based UI is low hanging fruit, also since the actions already defined are easily hooked to such anETO
based UI. The upside here is that while the UI loop is running, the TNA mesh is kept in memory, hence quite a boost in responsiveness is to be expectedThat stated, stoked to read the crisp and clean
compas_tna
code!