Re: [Avogadro-devel] Editing, viewing, and making things more fluid again
On Tue, Jan 06, 2015 at 01:06:15PM -0500, Geoffrey Hutchison wrote: Are you talking about how the user should do this with respect to mouse button-drag and modifier keys? If so, it would be interesting to this ... information above. Right now in Avogadro v2 (git master) you have to pick an edit or view widget with a button, then open the file, etc. Compared to Avogadro v1, this is a big hiccup for the user. Oh I see. For the render widgets I was also hoping to move to the new OpenGL classes added in Qt 5.4 soon. Any good reason for doing this? For one, we can request OpenGL features (e.g., anti-aliasing, shaders, etc.) in the widget rather than in main.cpp. It also ensures there's always a frame buffer (e.g., for saving bitmap graphics) and that multiple views of the same molecule can share OpenGL contexts. http://blog.qt.digia.com/blog/2014/09/10/qt-weekly-19-qopenglwidget/ Hrm, ok. No, I don't think the transition is critical, but I also don't imagine Avogadro 2.0.0 will be released until late summer or early fall, so the timing should still work with distributions, right? Well, Debian 8 will ship sometime early next year with 5.3, and there won't be an Ubuntu LTS until 2016 (which will ship 5.4 I guess). I tried to see whether RHEL7/Scientific Linux 7 ship Qt5 at all and if so which version, but couldn't find anything off-hand. So the development versions of Debian/Ubuntu will include it by the time 2.0 ships I guess, but if you look for people to run it on a stable distro once it's out (either self-compiled or via 3rd-party packages or backports), that might be more difficult. Michael -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Avogadro-devel mailing list Avogadro-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avogadro-devel
Re: [Avogadro-devel] Editing, viewing, and making things more fluidagain
Arch Linux ships at 5.4. Regards, Mark -Original Message- From: Michael Banck mba...@gmx.net Sent: 1/6/2015 1:48 PM To: avogadro-devel@lists.sourceforge.net avogadro-devel@lists.sourceforge.net Subject: Re: [Avogadro-devel] Editing, viewing, and making things more fluidagain On Tue, Jan 06, 2015 at 01:06:15PM -0500, Geoffrey Hutchison wrote: Are you talking about how the user should do this with respect to mouse button-drag and modifier keys? If so, it would be interesting to this ... information above. Right now in Avogadro v2 (git master) you have to pick an edit or view widget with a button, then open the file, etc. Compared to Avogadro v1, this is a big hiccup for the user. Oh I see. For the render widgets I was also hoping to move to the new OpenGL classes added in Qt 5.4 soon. Any good reason for doing this? For one, we can request OpenGL features (e.g., anti-aliasing, shaders, etc.) in the widget rather than in main.cpp. It also ensures there's always a frame buffer (e.g., for saving bitmap graphics) and that multiple views of the same molecule can share OpenGL contexts. http://blog.qt.digia.com/blog/2014/09/10/qt-weekly-19-qopenglwidget/ Hrm, ok. No, I don't think the transition is critical, but I also don't imagine Avogadro 2.0.0 will be released until late summer or early fall, so the timing should still work with distributions, right? Well, Debian 8 will ship sometime early next year with 5.3, and there won't be an Ubuntu LTS until 2016 (which will ship 5.4 I guess). I tried to see whether RHEL7/Scientific Linux 7 ship Qt5 at all and if so which version, but couldn't find anything off-hand. So the development versions of Debian/Ubuntu will include it by the time 2.0 ships I guess, but if you look for people to run it on a stable distro once it's out (either self-compiled or via 3rd-party packages or backports), that might be more difficult. Michael -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Avogadro-devel mailing list Avogadro-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avogadro-devel -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Avogadro-devel mailing list Avogadro-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avogadro-devel
[Avogadro-devel] Editing, viewing, and making things more fluid again
Hi, So I slacked off a lot over the Christmas break, but have been working on a few patches and thinking about the overall data architecture in the Avogadro 2 application. We spent quite a while thinking about the design, and I looked at a lot of what went well and not so well in Avogadro 1. I thought now might be a good time to explain some of those decisions (after a little prompting from Geoff), and improvements I am working on to improve the (unfortunately) non-intuitive interaction in the current application. Overly general mega-classes were a source of many bugs/crashes/inefficiencies in Avogadro. Several design decisions work to improve that situation in Avogadro 2, including the use of copy-on-write arrays, storing most molecular data in these arrays, use of proxy classes for atom/bond/other lightweight objects, and specializing an editable molecule with scalable undo/redo support, signals, slots, etc. If we have a specialized editable molecule we can focus on only the things that can/should be editable. We can add the necessary infrastructure to support scalable undo/redo - i.e. record addition/removal of an atom rather than make many copies of the entire molecule before and after an edit. The signals fired for each change, along with the undo/redo objects created, do not scale when adding millions of atoms though, and so having a view-focused molecule offers a more scalable option for I/O. Using copy-on-write arrays also offers very efficient copying from each molecule type - these arrays do not copy any underlying data unless a non-const method is called. So reading into a view molecule, copying to an editable molecule, deleting the view molecule, and editing the editable actually only ever creates one copy of the bulk of the data - the array will only be duplicated if a non-const method is called and its internal reference count is greater than 1. What doesn't work at all well is the edit/view GL widget, and the tough/hard line between editing a molecule/viewing it. I am working on merging the two widgets together, and reflecting the fluidity of moving between the two types in the interface so that it will be far less/barely noticeable that you went from viewing to editing a structure. I had hoped to get this merged sooner, I think I am pretty close to having it resolved now. I have also been experimenting with templating more of the algorithms, like hydrogen addition/removal, bond perception, etc. This would make it easy to use a command-line version with no undo/redo support (or Qt dependency), and build the same algorithm using the editable molecule. An added benefit would be the potential reuse by any other library/application using its own molecule class if they implement an adaptor that offers the expected API. I would love to avoid forcing everyone into virtuals and using the same base class/API. For the render widgets I was also hoping to move to the new OpenGL classes added in Qt 5.4 soon. This email got very long, and I haven't necessarily covered everything but would be happy to talk more on IRC/Skype/Hangouts/on this thread. If this generates a lot of additional work we should talk, and one thing I was never all that sold on was not having a common base class for the view/edit molecule - I have been weighing up if that would make things simpler/easier. I was hoping to start posting more details/discussions as things have become very quiet. I really want to get a new release out, but have been delaying until the edit/view problems are resolved, and apologize for the delays in getting this sorted - last year was pretty tough and featured very little spare time. This year is looking much better, and I really want to get this right while maintaining the speed and efficiency improvements made. Sincerely, Marcus -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Avogadro-devel mailing list Avogadro-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avogadro-devel
Re: [Avogadro-devel] Editing, viewing, and making things more fluid again
On Tue, Jan 6, 2015 at 12:03 PM, Michael Banck mba...@gmx.net wrote: On Tue, Jan 06, 2015 at 11:05:15AM -0500, Marcus D. Hanwell wrote: What doesn't work at all well is the edit/view GL widget, and the tough/hard line between editing a molecule/viewing it. I am working on merging the two widgets together, and reflecting the fluidity of moving between the two types in the interface so that it will be far less/barely noticeable that you went from viewing to editing a structure. I had hoped to get this merged sooner, I think I am pretty close to having it resolved now. Are you talking about how the user should do this with respect to mouse button-drag and modifier keys? If so, it would be interesting to this disucss this, but I have no idea how it does (not) work currently, how it was supposed to work, and how you plan to fix it, based on your information above. Referring to the need to close the edit widget, open the view widget, or vice-versa. That will go away, and the switch between the two modes will be pretty seamless. It is currently quite painful, but should be fixed up soon. For the render widgets I was also hoping to move to the new OpenGL classes added in Qt 5.4 soon. Any good reason for doing this? Is any major distribution shipping Qt 5.4 already? Yes, that is where I was hesitating... I may see if the API is close enough that we can detect the version and use the latest when available. I know how irritating it can be to require the latest release of a major library. QGLWidget is deprecated, the OpenGL variants already have more features and will be supported going forward. Marcus -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Avogadro-devel mailing list Avogadro-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avogadro-devel
Re: [Avogadro-devel] Editing, viewing, and making things more fluid again
On Tue, Jan 06, 2015 at 11:05:15AM -0500, Marcus D. Hanwell wrote: What doesn't work at all well is the edit/view GL widget, and the tough/hard line between editing a molecule/viewing it. I am working on merging the two widgets together, and reflecting the fluidity of moving between the two types in the interface so that it will be far less/barely noticeable that you went from viewing to editing a structure. I had hoped to get this merged sooner, I think I am pretty close to having it resolved now. Are you talking about how the user should do this with respect to mouse button-drag and modifier keys? If so, it would be interesting to this disucss this, but I have no idea how it does (not) work currently, how it was supposed to work, and how you plan to fix it, based on your information above. For the render widgets I was also hoping to move to the new OpenGL classes added in Qt 5.4 soon. Any good reason for doing this? Is any major distribution shipping Qt 5.4 already? Michael -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Avogadro-devel mailing list Avogadro-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avogadro-devel
Re: [Avogadro-devel] Editing, viewing, and making things more fluid again
Are you talking about how the user should do this with respect to mouse button-drag and modifier keys? If so, it would be interesting to this ... information above. Right now in Avogadro v2 (git master) you have to pick an edit or view widget with a button, then open the file, etc. Compared to Avogadro v1, this is a big hiccup for the user. For the render widgets I was also hoping to move to the new OpenGL classes added in Qt 5.4 soon. Any good reason for doing this? For one, we can request OpenGL features (e.g., anti-aliasing, shaders, etc.) in the widget rather than in main.cpp. It also ensures there's always a frame buffer (e.g., for saving bitmap graphics) and that multiple views of the same molecule can share OpenGL contexts. http://blog.qt.digia.com/blog/2014/09/10/qt-weekly-19-qopenglwidget/ No, I don't think the transition is critical, but I also don't imagine Avogadro 2.0.0 will be released until late summer or early fall, so the timing should still work with distributions, right? Thanks, -Geoff -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Avogadro-devel mailing list Avogadro-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avogadro-devel
