Re: [Chimera-users] Three suggestions
Dear Eric, Thank you for your replies and your quick implementation of an automated refresh for named selections! Concerning suggestion #1: changing Chain ID of a portion of a chain was meant to assist matchmaker in targeting the right domain and not let it take adventice (meaningless) pieces into account. I realize now that this could be quiet a challenge for Chimera to interpret in all the procedures already available... and will stick to the cut-into-domains-of-interest approach. About suggestion #2: the ~namesel command that you proposed would allow to edit the listing, which is sometimes useful, i.e. when you happen to get more and more named selections, sometimes similar in different models, and realize the names given were not specific enough. That would be nice! Suggestion #3: if this is a problem then leave it where it stands! (In case it is not: would it sound more reasonable to offer the window-size memorization as a tickable option? Could the window-location memorization and the tiling be combined when the "same" window is to be opened more than once?) All in all, suggestion #2 might make it: that's a big thank you already! Cheers, Antoine Antoine Maillard wrote:
Dear Chimera developpers,
Thank you so much for your work and your dedication! Having used Chimera quiet intensively recently, I have listed a few suggestions for your consideration.
Suggestion #1: Tools > Structure Editing > Change Chain IDs: lacks a "restrict to current selection" button (would allow to name various domains of a single protein) Are these domains disconnected from one another? Because I don't think there are many programs (including Chimera) that will like connected polypeptide chains that change chain IDs in the middle. If we're talking about disconnected domains then I can see the usefulness. Otherwise I would think that a named selection or and alias would be more appropriate -- and more descriptive.
Suggestion #2: Named selections: - I did not find out how to edit them (even "suppress" would add flexibility and reliability). - The list is not refreshed as session is closed (Windows). Thus opening and closing sessions one after the other results in merging the "Named selections" of all sessions successively opened... In the current daily build if a named selection becomes empty (which will happen during session close for example) it will delete itself. Does this meet the need you're describing? Otherwise I could implement ~namesel for deleting them even when they're not empty...
Suggestion #3: The 'window-size memory' feature that was devised by Eric for the File>Open window would be of interest to most windows: model panel / matchmaker / match / etc... Could you make it a general feature of the various windows in the GUI? Well, due to the way the windowing library we use (Tk) works, it is quite a headache to impose an overall size on a window a priori. The File->Open thing works by imposing a size on the browser widget inside the window and the window adjusts to compensate. I wouldn't want to try to do this on a generic window basis. Nonetheless, for certain dialogs where it would be high value (i.e. that get a lot of use and that are resized initially a lot) I could see implementing it. The Model Panel comes to mind as you suggested. I'd listen to other suggestions...
(It would also be a plus if the preferred location of any of these windows could be memorized as well.) This has been suggested and I have thought about it. The are several problems. One is that it doesn't work well with tiling. Say you bring up some dialogs that get tiled. Then you bring up a dialog whose placement is remembered, and it is right on top of the tiled dialogs. Or say you make the main Chimera window larger today that you did yesterday -- there's an excellent chance that the memorized positions will be on top of the larger window. Or you put the Chimera window on the right side of your display instead of the left side. Or you put it on a second monitor. I think you get the idea.
--Eric
Eric Pettersen UCSF Computer Graphics Lab http://www.cgl.ucsf.edu
I trust your expert appreciation whether these suggestions are to be implemented sooner or later... or never :-( Thank you for your consideration and for your help!
Antoine
_______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-users
On Apr 10, 2013, at 9:54 AM, Antoine Maillard wrote:
Concerning suggestion #1: changing Chain ID of a portion of a chain was meant to assist matchmaker in targeting the right domain and not let it take adventice (meaningless) pieces into account. I realize now that this could be quiet a challenge for Chimera to interpret in all the procedures already available... and will stick to the cut-into-domains-of-interest approach.
Hi Antoine, Actually you can tell MatchMaker to use only part of a chain by selecting that part and using the "Further restrict matching to current selection" option in the graphical interface, or if using the matchmaker command, specifying only the residue ranges you want to use. <http://www.cgl.ucsf.edu/chimera/docs/ContributedSoftware/matchmaker/matchmaker.html> <http://www.cgl.ucsf.edu/chimera/docs/UsersGuide/midas/mmaker.html> Maybe that will let you get the superposition you want without having to cut the domains apart or change their chain IDs. Best, Elaine ----- Elaine C. Meng, Ph.D. UCSF Computer Graphics Lab (Chimera team) and Babbitt Lab Department of Pharmaceutical Chemistry University of California, San Francisco
Hi Antoine, On Apr 10, 2013, at 9:54 AM, Antoine Maillard wrote:
Dear Eric,
Thank you for your replies and your quick implementation of an automated refresh for named selections!
Concerning suggestion #1: changing Chain ID of a portion of a chain was meant to assist matchmaker in targeting the right domain and not let it take adventice (meaningless) pieces into account. I realize now that this could be quiet a challenge for Chimera to interpret in all the procedures already available... and will stick to the cut-into-domains-of-interest approach.
Yeah, as Elaine mentioned, the "restrict to selection" feature was implemented for exactly this reason -- matching domains embedded in longer chains.
About suggestion #2: the ~namesel command that you proposed would allow to edit the listing, which is sometimes useful, i.e. when you happen to get more and more named selections, sometimes similar in different models, and realize the names given were not specific enough. That would be nice!
Okay, I've implement a ~namesel command. It will be in the next daily build.
Suggestion #3: if this is a problem then leave it where it stands! (In case it is not: would it sound more reasonable to offer the window-size memorization as a tickable option? Could the window-location memorization and the tiling be combined when the "same" window is to be opened more than once?)
Memorizing the window size is more feasible / has less pitfalls than memorizing the position. Even then only certain dialogs can actually be distinguished by Chimera. In Python, such dialogs have "name" attributes so that any tool can ask for that dialog to be shown (e.g. Model Panel, Volume Viewer) whereas other dialogs are essentially nameless (e.g. Sequence dialogs, CASTp dialogs). Sizes for named dialogs could conceivably be remembered. Even then there are a lot of limitations / pitfalls. Two that occur to me immediately are: you probably only want to restore a memorized size if it's larger than the dialog's "natural" size -- otherwise various interface elements will be clipped away, and if those elements are brand new because the tool was improved then the user might never become aware of them(!); the other is that you probably don't want to memorize size changes for some dialogs -- because they became larger to show more data (I'm thinking Volume Viewer here) and will be uselessly larger when shown in another context with less data. I don't know. If some more people ask for the same thing I might bite the bullet. Otherwise, I'll stick to my plan of implementing size remembrance on a dialog-by-dialog basis. Initially just the Model Panel. --Eric Eric Pettersen UCSF Computer Graphics Lab http://www.cgl.ucsf.edu
participants (3)
-
Antoine Maillard -
Elaine Meng -
Eric Pettersen