Hi Edward
Edward d'Auvergne schrieb: > Hi Michael, > > I've been thinking of how to better design how different analysis > types are handled in the GUI, and have a few ideas. What do you think > of the following? > > 1) Each new analysis appears not as tabs but as a new window. This > would be similar to oowriter or MS Word, where there is a 'Window' > menu where one can switch between the analyses. This is also similar > to what sparky does. Either there is an entire new window for each > analysis, or it could be done as now where each is in a tab (just that > you don't show the tab bit). Each analysis can be created at any > time, and closed at any time. The window with buttons with pictures > of each analysis type can appear at the start and also when clicking > on 'File -> New analysis'. > I somehow like the idea that the whole relaxation analysis is in one window, separated by tabs. This helps to keep all the informations together. I would suggest to split the kind of dynamics calculation, i.e. model-free, dispersion.... > > 2) The code paths are too complex! This can be done after the paper, > but please don't discount this. If I would like to make modifications > to or debug the model-free code (GUI and calculation), I have to jump > all over the place and have to separate it in my mind from all the > other code. I would suggest a big rearrangement of the code, to make > it more like lego where you have reusable blocks. Firstly, what does > the directory 'res/' stand for? I cannot for the life of me work out > why you have this directory! I would propose the following, logical > directory structure: > > gui_bieri/ -> All the GUI element modules (filedialog.py, > settings.py, etc) go in the base directory. In the future when the > interface is more complex, the GUI elements could be grouped and > shifted into packages (directories). > gui_bieri/analyses/ -> All the analysis specific code goes here. > I.e. 'gui_bieri/analyses/model_free.py', 'gui_bieri/analyses/r1.py', > etc. > gui_bieri/oxygen_icons/ -> Have dedicated directories for material > that is differently, but legally licenced! The may shift down a > directory to the base relax directory when other types of GUI are > added. > gui_bieri/images/ -> All the bitmap pictures go here. I would > suggest that for the future of the project, that SVG versions whenever > possible are placed here. This will allow for better image resizing, > tiny icons to be made, etc. > gui_bieri/execution/ -> All the calc_* modules can be shifted here. > Or alternatively it goes into gui_bieri/analyses/ as well. > sure! I just placed everything into the res (from resources) folder. but it's getting messy and overfilled now! > > 3) Code recycling. Many analysis types re-use the same user > functions. For example model-free, J(w) mapping, consistency testing, > and in the future SRLS and other analysis types will all use relation > data input. Therefore this GUI element could be separated and each > analysis type then places where it likes. I would suggest that it > looks as follows (100% redesign). There is a canvas (forgotten the > GUI element name here) which displays the loaded relaxation data, > displaying a label (ri_label and frq_label will soon be combined so > Sebastian can better work with relaxation dispersion data) and the > frequency in MHz. Each can be selected by clicking on them. Then > there are a series of buttons on the right hand side. A big + icon > adds new data, and opens a dialog box to select the file, specify the > label, the frequency, all the column numbers, the column separator, > and allowing a spin_id selector to only load a specific subset of the > data. A big - icon can remove data. Another icon can display the > data for all spin systems. Therefore I would suggest a module called > 'gui_bieri/relax_data.py' for this that can be imported by > 'gui_bieri/analyses/model_free.py'. The relaxation data input GUI > element can then be modified/expanded at any time independent of the > rest of the GUI. > I would suggest to have an initial window that shows which calculations (modelfree, J(w)...) can be performed by relax. Under these buttons, we could have a list or tree that shows projects that are already calculated or in the middle of analysis. So users can either start a new analysis or continue. > > 4) PyMOL (http://www.pymol.org/). This is open source and can be > imported as a python module. Therefore I propose as a future idea > that we bundle this with relax, import it in > 'gui_bieri/molecular_viewer', and provide its OpenGL canvas to display > the results of the analyses to each analysis type. Not the PyMOL GUI > - this sucks - but the OpenGL canvas GUI element. This could possibly > appear in a new window, as a new tab, or even as part of the main > window using buttons to switch rather than tabs. We can then provide > relevant functions as menu entries - 'Display diffusion tensor', > 'Display data' where S2, te, Rex, CSA, J(0), J(wN), etc can be mapped > onto the structure, 'Write PNG', 'Ray trace', etc. This would make > the relax GUI much more awesome! > this would be very cool!! what do you think about the future of relax? do want to drive it in a more GUI like application, so future elements are designed together with a GUI? I am currently also working on a software that analyzes dispersion data (at the moment cp-CPMG). There, I completely build everything in a GUI, which facilitates a lot of issues about preparing input files. Peak files are just loaded in an excel-like grid. Users choose which are residue number columns and data columns. Like this, a lot of formatting problems are avoided. If you would like, we could fuse these programs as well! There is another idea: Wouldn't it be great if the user only needs one HSCQ assignment (or TROSY for better dispersion data) and relax(GUI) reads in all the recorded spectra, finds peaks, groups them and start the analysis? This would be a really fat automatic software! The main issue would be to have a good peak picking algorithm included. I know that Mehdi Mobli (IMB) is writing a promising one. We will have a collaboration about dynamics in 2 weeks and I could ask him to join. What do you think about this? There is a lot we can do to get relax THE software for protein dynamics! Cheers Michael > > These are just a few ideas of many that I consider important. What do > you think? > > Regards, > > Edward > > _______________________________________________ > relax (http://nmr-relax.com) > > This is the relax-devel mailing list > [email protected] > > To unsubscribe from this list, get a password > reminder, or change your subscription options, > visit the list information page at > https://mail.gna.org/listinfo/relax-devel > > _______________________________________________ relax (http://nmr-relax.com) This is the relax-devel mailing list [email protected] To unsubscribe from this list, get a password reminder, or change your subscription options, visit the list information page at https://mail.gna.org/listinfo/relax-devel
