Gui Integration #33
Comments
|
Not sure if this is the correct way to reply to this? Just to check why is this done this way, is it just to simplify the script hierarchy? I know at some point there was a discusion as to getting the gui script to call the terminal script to ensure consistency, is this just implementation of this? A better method would be to incorporate some of the preexisting functions in MeshOperations and PremeshFunctions. This is how its always worked - all the work scripts are imported into either the gui script or the terminal script dependent on how it is being called. By having a mesh_surface as a middle module which does all the work and having a python script which when called through the terminal would call the mesh_surface with the appropriate options would mean that would would have both functionalities and a more scalabe code. This is not necessary, mesh_surface inputs terminal commands to the work scripts, it does no work itself (or at least it shouldn't, there may be some functions that need moving). Likewise mesh_surface.py inputs commands from the gui to the work scripts. Apologies if this has all already been discussed. On 2 Oct 2013, at 16:37, Jose Kalladanthyil <[email protected]mailto:[email protected]> I have integrated the mesh_surface to the gui, however the way I've done it was a quick fix due to the time constraints I had. I have just added a system call calling mesh_surface through the terminal with if statements to include the options such as adding IDfiles and netcdf files. This is done in mesh_surface.py inside the run method. A better method would be to incorporate some of the preexisting functions in MeshOperations and PremeshFunctions. Also making the mesh_surface a python loadable file so that we can work through by just importing it. By having a mesh_surface as a middle module which does all the work and having a python script which when called through the terminal would call the mesh_surface with the appropriate options would mean that would would have both functionalities and a more scalabe code. — |
|
The problem found was that the gui script never called the terminal script and since the terminal script was the one being updated and modified all the time, the gui was outdated. Therefore the plugin never worked through the QGIS. Also I cannot see how mesh_surface could be accessed unless through a os.system call from another python file which in my opinion is a bad way of accessing the script hence I believe it should have multiple way of accessing it either through the method I suggested or something similar. |
|
mesh_surface is a terminal script The gui script and the terminal script Either the two should be independent (as The problem found was that the gui script never called the terminal script and since the terminal script was the one being updated and modified all the time, the gui was outdated. Therefore the plugin never worked through the QGIS. Date: Wed, 2 Oct 2013 08:53:31 -0700 Not sure if this is the correct way to reply to this? Just to check why is this done this way, is it just to simplify the script hierarchy? I know at some point there was a discusion as to getting the gui script to call the terminal script to ensure consistency, is this just implementation of this? A better method would be to incorporate some of the preexisting functions in MeshOperations and PremeshFunctions. This is how its always worked - all the work scripts are imported into either the gui script or the terminal script dependent on how it is being called. By having a mesh_surface as a middle module which does all the work and having a python script which when called through the terminal would call the mesh_surface with the appropriate options would mean that would would have both functionalities and a more scalabe code. This is not necessary, mesh_surface inputs terminal commands to the work scripts, it does no work itself (or at least it shouldn't, there may be some functions that need moving). Likewise mesh_surface.py inputs commands from the gui to the work scripts. Apologies if this has all already been discussed. On 2 Oct 2013, at 16:37, Jose Kalladanthyil <[email protected]mailto:[email protected]mailto:[email protected]> wrote: I have integrated the mesh_surface to the gui, however the way I've done it was a quick fix due to the time constraints I had. I have just added a system call calling mesh_surface through the terminal with if statements to include the options such as adding IDfiles and netcdf files. This is done in mesh_surface.py inside the run method. A better method would be to incorporate some of the preexisting functions in MeshOperations and PremeshFunctions. Also making the mesh_surface a python loadable file so that we can work through by just importing it. By having a mesh_surface as a middle module which does all the work and having a python script which when called through the terminal would call the mesh_surface with the appropriate options would mean that would would have both functionalities and a more scalabe code. — Reply to this email directly or view it on GitHubhttps://github.com//issues/33. — — |
I have integrated the mesh_surface to the gui, however the way I've done it was a quick fix due to the time constraints I had.
I have just added a system call calling mesh_surface through the terminal with if statements to include the options such as adding IDfiles and netcdf files. This is done in mesh_surface.py inside the run method.
A better method would be to incorporate some of the preexisting functions in MeshOperations and PremeshFunctions. Also making the mesh_surface a python loadable file so that we can work through by just importing it. By having a mesh_surface as a middle module which does all the work and having a python script which when called through the terminal would call the mesh_surface with the appropriate options would mean that would would have both functionalities and a more scalabe code.
The text was updated successfully, but these errors were encountered: