Re: [Avogadro-devel] Avogadro2 Edit/View Molecule - Code and Interface
So the weekend resulted in no code being written, mostly ended up having to fix some stuff in the house I was behind on due to all the travel :-/ I did manage to get Windows reinstalled on the machine I was using to create binaries (it suffered a hard drive failure a month or two back - new, bigger hard drive too). I will have some time to actually work on this in the coming days though, apologies on the delay - I hadn't factored in spending so much time on real life stuff... Marcus On Thu, Sep 4, 2014 at 9:31 PM, Marcus D. Hanwell marcus.hanw...@kitware.com wrote: Hi Geoff, Sorry, crazy travel schedule, so didn't get this finished as soon as I had hoped. I am working on some changes to make the conversion much simpler, and to alleviate the UI issue. As I said at the time - totally agree, and not pushing to keep the current UI. I think it was a necessary step as I fleshed it out, but hope to make this much smoother. I think any of the edit functionality can convert to an editable molecule, they use implicitly shared arrays and so the copy cost is minimal with only the coordinates triggering a real copy when the forcefield kicks in. I would love to see what you are thinking for the auto-optimize, I just spent a few days at Daresbury Lab last week talking about some of these features (along with QMMM, how we might define regions, residues, etc). Let me see what I can get done on the weekend to make it clearer, and sketch out what I thought would work. Happy to iterate on this, and yes it is better to put more of these discussions on the mailing list. Measurement is a tool that I think we make work with edit and view molecules to be honest - so no need to switch at all. Marcus On Wed, Sep 3, 2014 at 10:44 PM, Geoffrey Hutchison geoff.hutchi...@gmail.com wrote: Hi Marcus, I wanted to follow-up about an off-list discussion with Avogadro v2. Between v0.7, and the current git master (0.8?) there's now a clear UI division between edit and view molecules. Can you outline some of the real reasons for this behind the scenes, particularly on the UI side? I think this is currently a usability nightmare and I'd like to make sure we can work past this or write up conversion code that allows tools, extensions, etc. to convert back and forth. My big use-case concern is the Auto Optimize tool, which I'm trying to design for Avogadro v2's very different architecture. For example, let's say a user wants to set a measurement between two atoms (view). Then they switch to the Auto Optimize tool (edit) and start pushing atoms around. In Avogadro v1, this wasn't a problem. The measurements would update while the optimization occurred in a different thread. How can this work in Avogadro v2? Thanks, -Geoff -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Avogadro-devel mailing list Avogadro-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avogadro-devel
[Avogadro-devel] Avogadro2 Edit/View Molecule - Code and Interface
Good morning, Let me add a bit to this discussion as well. I've been working on the crystallography extension in Avogadro2 and I find it exceeding difficult to use the CrystalTools while editing or creating molecules. 1. It takes several clicks in and out of view mode along with renaming the molecule before the Crystal QT plugin recognizes that there is even a molecule present. From what I can tell in edit mode the following check returns false for a new molecule. crystal.cpp: if (m_molecule) 2. Once a unit cell has been added it is not visible in edit mode. The following appears to return false. 3. Crystal operations, like filling a unit cell, show nothing in edit mode. They appear to work and the output is present once the user changes to view mode. All of these operations just worked in the 0.7 release and it didn't care if the user had selected an edit tool or a view tool. One of the great features of Avogadro is that the molecule was always editable and the programmer didn't have to make many, or even any, special considerations when writing tools. Albert -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Avogadro-devel mailing list Avogadro-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avogadro-devel
Re: [Avogadro-devel] Avogadro2 Edit/View Molecule - Code and Interface
On Mon, Sep 8, 2014 at 10:14 AM, Defusco III, Albert A defu...@pitt.edu wrote: Good morning, Let me add a bit to this discussion as well. I've been working on the crystallography extension in Avogadro2 and I find it exceeding difficult to use the CrystalTools while editing or creating molecules. 1. It takes several clicks in and out of view mode along with renaming the molecule before the Crystal QT plugin recognizes that there is even a molecule present. From what I can tell in edit mode the following check returns false for a new molecule. crystal.cpp: if (m_molecule) 2. Once a unit cell has been added it is not visible in edit mode. The following appears to return false. 3. Crystal operations, like filling a unit cell, show nothing in edit mode. They appear to work and the output is present once the user changes to view mode. All of these operations just worked in the 0.7 release and it didn't care if the user had selected an edit tool or a view tool. One of the great features of Avogadro is that the molecule was always editable and the programmer didn't have to make many, or even any, special considerations when writing tools. Like I said, please give me a little time to finish it up, perhaps I committed the feature too soon. Many of these issues are rendering artifacts, along with some issues around certain editing features not being ported to use the right structure. I am not pushing to keep it this way, but like I said when I was over in Pittsburgh this can be made intuitive with a little more work - I will see if I can get that finished up soon so that things are easier, and we can make a release. Thanks for your patience, I am thankfully done with travel for a while, and should be able to focus on finishing this up. Major advantages are a scalable undo/redo (with some rough edges admittedly), and I honestly think it will be worth it to reduce confusion about properties that are simply no longer valid after editing. In the UI the difference between editing and viewing should be fluid, but I hope to create a much clearer model in the API so that we focus on doing one or the other well in most cases. If by some chance it doesn't work out I can back out some of the changes. Marcus -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Avogadro-devel mailing list Avogadro-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avogadro-devel
