|
|
Bioinformatics.org
|
![[?]](https://www.bioinformatics.org/images/icons/info.png)
|
|
Research
|
Online databases
Online analysis tools
Online education tools
|
|
Development
|
|
|
Forums
|
News & Commentary
Jobs Forum
(Career Center)
|
|
|
Ghemical: Molecular modelling - Message forums
|
         
|
 |
|
Expanded view | Monitor forum | Save place
|
Message
|
|
Maybe this is an obvious remark, but I hope we could save the settings in a file
$HOME/.ghemical
TH
|
|
Post a followup to this message:
You have to be to post a reply.
Thread view
|
|
Hello.
I just added a "preview" version of my reduced protein modelling system to the CVS. There is nothing functional yet; you can just open some example files from the "examples" directory. The system is almost ready, and I will release it ASAP, but I have to wait for blessing from the referees before I can do it (takes a few months I suppose).
The reason why I added the model now, is that we are planning new features to the user interface right now, and I wish that you see an example of a model which differs quite much from traditional "all atoms" MM and QM models.
The new model has for example the following (peculiar) features:
- in the model, there is no "atoms" or "bonds", at least in the same sense as in "all atoms" models (I would call them virtual atoms and virtual bonds).
- unlike in an "all atoms" model, it makes no sense to "draw" or "erase" those bonds; instead, we will "mutate" the amino acid residues directly here.
- there is no quick and simple way to convert this model, say to an all atoms MM model. But the conversion in reverse direction is quite easy.
So, I have had quite cautious views what comes to the user interface, and I hope you now understand better why is that so. There truly are many kinds of models, and I hope the user interface would fit for all of them.
TH
|
|
|
|
|
|
Hummm... Or maybe this is not a problem after all; maybe we just have to make the user interface flexible and, especially, configurable enough so that it fits for all purposes.
Let's take toolbar buttons like "select element", "select bondtype", "add hydrogens" and "remove hydrogens" as an example. These would be very convenient when working with all atoms models, but useless when working with these "strange" models.
So, maybe we just set this set of buttons configurable (among many other things), and set the default settings according to estimated "typical" use (in this case, "enabled").
TH
|
|
|
|
|
|
Yes!
This is why I suggested having one set of menus... For example, bond types are meaningless to QM models (or your "reduced" model), but are still useful to see in rendering!
It's also why I placed "Add hydrogens" and "Remove hydrogens" as separate menu items directly under "build" because they're more convenient that way.
And I imagine there's some way of "greying out" buttons that are currently disabled.
-Geoff
|
|
|
|
|
|
Originally I thought about toolbar buttons here, but maybe we can apply it to the menu as well.
I thought that someone might want a complete toolbar, with a truckload of buttons (takes much screen real estate), or a lighter one with most important buttons (maybe just those element/bondtype/hydrogens buttons), or a minimal one with just the current mouse tool buttons. With toolbar this is easy; we just read the user's "settings" file when the program starts, and create the toolbar buttons according to those instructions (we just create those buttons (or button sets) that user has selected). I guess nothing else is needed.
But the code for buttons must be generic. The buttons are visible all the time, and the user might have any of the models (or no model at all) active when the button is pressed.
If we have a single menu, we must use similar generic code also there. Currently each model has it's own menu, and no checking is necessary. In a single menu we would like to grey out (or even make invisible if possible) some items depending on the situation.
Both menu types are OK to me, I will just support that alternative that turns out to be more easier and convenient to handle (that is, for developers, since I am a lazy man by nature). We could make some of those new toolbar buttons and see what kind of code we need there.
BTW, we have already now quite many graphics settings in the menu. Would it be easier to convert them into a single dialog box?
TH
|
|
|
|
|
|
All of the popup menus that we have can also be effectively used as toolbars just by 'undocking' that menu from the popup. If we could only figure out how to save the settings of these windows/toolbar from session to session then these could be effective toolbars...
is this a window-manager specific function (turnung popup menu items into windows/toolbars) or a gnome feature?
- James
|
|
|
|
|
|
Still forgot to mention one idea about popup menus.
Soon I'm trying to improve the "treelist view", and I believe we could add some small popup-menus to the "treelist view" items. For example, in the section where the lights or objects are listed, we could add a small popup menu with items like "select" and "delete" to each "treelist view" item.
This way, I'm afraid we will still have many different popup menus in the program, even if we choose to make a single popup-menu for each model.
TH
|
|
|
|
|
|
|
I'm going to start, maybe this week by adding settings for the periodic table. I'm going to add a GNOME color selector and a few text entry boxes to the bottom of the PT dialogue to set these using gnome-config.
If this goes well, we can perhaps begin adding defaults/preferences for other graphics options.
|
|
|
|
|
|
Maybe this is an obvious remark, but I hope we could save the settings in a file
$HOME/.ghemical
TH
|
|
|
|
|
|
|
I don't think there's any problem with having many different popup menus. (Here on the Mac, they're called "contextual menus" and thus refer to the "context" of the user.)
But as you say, we're all a bit lazy. So I worry when there's several copies of nearly-identical code for the modes. I expect I'll probably forget to update one or the other. (e.g. I don't think there's import/export for the QM mode.)
-Geoff
|
|
|
|
|
|
I think that we could do import/export in QM mode using logic
"import in QM" ==
"import in MM + convert MM to QM"
I will have a few busy weeks here, but then I will start working with these mode changes and things like that...
TH
|
|
|
|
|
|
During the first make, of installation process, ghemical calls for:
/home/name/mpqc-target/lib/
and looks for specific files, with extension .a
Nothing is mentioned about this in the install file. I believe that it would be appropiate to indicate the user that s/he has to make a copy of:
/home/name/mpqc-x.y.z/lib
and paste it in:
home/name/mpqc-target
|
|
|
|
|
|
Or perhaps just use 'sc-config --libs' !?!
|
|
|
|
|
|
Yep, it would be better to use headers/libs produced by MPQC directly. I'll try to study & fix this later.
|
|
|
|
|
![[University of Birmingham]](https://www.bioinformatics.org/images/ack_banners/Birmingham-728x90.gif)
![[Patsnap]](https://www.bioinformatics.org/images/ack_banners/Patsnap-728x90.png)