Idea: stop bond perceiving using timer

There is a known problem with Avogadro and big molecules: bond perceiving is enabled by default, and it can take unreasonable time. I thought about automatic disabling of bond perceiving based on atoms’ number, but one’s mileage may vary.

Now I propose to stop import (which is working in thread) after fixed amount of time and automatically re-run it with disabled bond perceiving. Do you like this idea? What time span is the best?


Regards,
Konstantin

On Oct 19, 2010, at 11:36 AM, Konstantin Tokarev wrote:

There is a known problem with Avogadro and big molecules: bond perceiving is enabled by default, and it can take unreasonable time. I thought about automatic disabling of bond perceiving based on atoms’ number, but one’s mileage may vary.

This should change with Open Babel 2.3, there is a built-in timeout in several of the OB functions to prevent, e.g. slow performance on nanotubes. But your idea isn’t bad – as long as you put up some sort of warning for the user that bond perception was disabled – similar to how we tell users about 2D molecules.

Now I propose to stop import (which is working in thread) after fixed amount of time and automatically re-run it with disabled bond perceiving. Do you like this idea? What time span is the best?

I would propose ~10 seconds. That might be on the long end, but I think it’s better to give it a chance.

What do you think?

-Geoff

20.10.2010, 05:26, “Geoffrey Hutchison” geoff.hutchison@gmail.com:

On Oct 19, 2010, at 11:36 AM, Konstantin Tokarev wrote:

There is a known problem with Avogadro and big molecules: bond perceiving is enabled by default, and it can take unreasonable time. I thought about automatic disabling of bond perceiving based on atoms’ number, but one’s mileage may vary.

This should change with Open Babel 2.3, there is a built-in timeout in several of the OB functions to prevent, e.g. slow performance on nanotubes. But your idea isn’t bad – as long as you put up some sort of warning for the user that bond perception was disabled – similar to how we tell users about 2D molecules.

Now I propose to stop import (which is working in thread) after fixed amount of time and automatically re-run it with disabled bond perceiving. Do you like this idea? What time span is the best?

I would propose ~10 seconds. That might be on the long end, but I think it’s better to give it a chance.

Oh, I thought about 30 seconds :slight_smile:
What about 20?


Regards,
Konstantin

How about putting up a box with some non-scrolling progressbar after 5
seconds, and say after 20 or 30 seconds (depending on what you choose)
do the alternate action (be it turn of bond perceiving or other
stuff). But if you then put a button on said box, it would enable to
user to actually cancel (ahead of time) the bond perceiving algorithm.

To things will happen because of this:

  1. the user is notified that an action is taking a long time, thus not
    just sitting around and waiting while nothing happens.
  2. the user is in control of what action should be performed (wait for
    it to finish or cancel it)

Cheers,

Casper

2010/10/20 Konstantin Tokarev annulen@yandex.ru:

20.10.2010, 05:26, “Geoffrey Hutchison” geoff.hutchison@gmail.com:

On Oct 19, 2010, at 11:36 AM, Konstantin Tokarev wrote:

There is a known problem with Avogadro and big molecules: bond perceiving is enabled by default, and it can take unreasonable time. I thought about automatic disabling of bond perceiving based on atoms’ number, but one’s mileage may vary.

This should change with Open Babel 2.3, there is a built-in timeout in several of the OB functions to prevent, e.g. slow performance on nanotubes. But your idea isn’t bad – as long as you put up some sort of warning for the user that bond perception was disabled – similar to how we tell users about 2D molecules.

Now I propose to stop import (which is working in thread) after fixed amount of time and automatically re-run it with disabled bond perceiving. Do you like this idea? What time span is the best?

I would propose ~10 seconds. That might be on the long end, but I think it’s better to give it a chance.

Oh, I thought about 30 seconds :slight_smile:
What about 20?


Regards,
Konstantin


Download new Adobe® Flash® Builder™ 4
The new Adobe® Flex® 4 and Flash® Builder™ 4 (formerly
Flex® Builder™) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

20.10.2010, 11:08, “Casper Steinmann” casper.steinmann@gmail.com:

How about putting up a box with some non-scrolling progressbar after 5
seconds, and say after 20 or 30 seconds (depending on what you choose)
do the alternate action (be it turn of bond perceiving or other
stuff). But if you then put a button on said box, it would enable to
user to actually cancel (ahead of time) the bond perceiving algorithm.

To things will happen because of this:

  1. the user is notified that an action is taking a long time, thus not
    just sitting around and waiting while nothing happens.
  2. the user is in control of what action should be performed (wait for
    it to finish or cancel it)

Good idea!
I propose to simplify it a bit: after 20-30 seconds add button “Cancel bond
perceiving” under progress bar.

Geoff: AFAIK, there is no way to cancel bond perceiving without restarting
import, is it?


Regards,
Konstantin

Well,

To be honest, I would much rather be able to cancel it faster if I
don’t need the bonds. Also, isn’t it more confusing if the button
suddenly appear instead of having it displayed at all times?

Anyways, I was just throwing it up in the air because I, as a user,
likes to know what is going on when the application is performing
something in the background.

I am a bit hesitant to suggest that there should be much information
in the dialog window, because it should automatically go away when the
bond perceiving is completed (and it will lead to the user being
confused when information was displayed but not fully read)… But
somehow, if a user chooses to cancel, he/she should be notified of
it’s implications.

Casper

On Wed, Oct 20, 2010 at 4:22 PM, Konstantin Tokarev annulen@yandex.ru wrote:

20.10.2010, 11:08, “Casper Steinmann” casper.steinmann@gmail.com:

How about putting up a box with some non-scrolling progressbar after 5
seconds, and say after 20 or 30 seconds (depending on what you choose)
do the alternate action (be it turn of bond perceiving or other
stuff). But if you then put a button on said box, it would enable to
user to actually cancel (ahead of time) the bond perceiving algorithm.

To things will happen because of this:

  1. the user is notified that an action is taking a long time, thus not
    just sitting around and waiting while nothing happens.
  2. the user is in control of what action should be performed (wait for
    it to finish or cancel it)

Good idea!
I propose to simplify it a bit: after 20-30 seconds add button “Cancel bond
perceiving” under progress bar.

Geoff: AFAIK, there is no way to cancel bond perceiving without restarting
import, is it?


Regards,
Konstantin

On Wed, Oct 20, 2010 at 04:08:04PM +0900, Casper Steinmann wrote:

How about putting up a box with some non-scrolling progressbar after 5
seconds, and say after 20 or 30 seconds (depending on what you choose)
do the alternate action (be it turn of bond perceiving or other
stuff). But if you then put a button on said box, it would enable to
user to actually cancel (ahead of time) the bond perceiving algorithm.

To things will happen because of this:

  1. the user is notified that an action is taking a long time, thus not
    just sitting around and waiting while nothing happens.
  2. the user is in control of what action should be performed (wait for
    it to finish or cancel it)

Additionally, one could just display the atoms without bonds (or mabye
single bonds everywhere is also quick?) initially above a threshold of
molecule size, and display the bonds properly after some time, if the
molecule has not been changed by the user until then (in which case,
recalculate). Not sure the OpenBabel interface in Avogadro allows for
this, though.

Michael

20.10.2010, 11:52, “Michael Banck” mbanck@gmx.net:

On Wed, Oct 20, 2010 at 04:08:04PM +0900, Casper Steinmann wrote:

How about putting up a box with some non-scrolling progressbar after 5
seconds, and say after 20 or 30 seconds (depending on what you choose)
do the alternate action (be it turn of bond perceiving or other
stuff). But if you then put a button on said box, it would enable to
user to actually cancel (ahead of time) the bond perceiving algorithm.

To things will happen because of this:

  1. the user is notified that an action is taking a long time, thus not
    just sitting around and waiting while nothing happens.
  2. the user is in control of what action should be performed (wait for
    it to finish or cancel it)

Additionally, one could just display the atoms without bonds (or mabye
single bonds everywhere is also quick?) initially above a threshold of
molecule size, and display the bonds properly after some time, if the
molecule has not been changed by the user until then (in which case,
recalculate). Not sure the OpenBabel interface in Avogadro allows for
this, though.

Bond perceiving is often useless for large systems. Sometimes people load
large fragments of crystal structures in Avogadro and wonder why they doesn’t
open or open too slow. Than imagine what it be if bond perceiving is done in
background and is restarted after every change…


Regards,
Konstantin

On Wed, Oct 20, 2010 at 12:18:45PM +0400, Konstantin Tokarev wrote:

20.10.2010, 11:52, “Michael Banck” mbanck@gmx.net:

On Wed, Oct 20, 2010 at 04:08:04PM +0900, Casper Steinmann wrote:

How about putting up a box with some non-scrolling progressbar after 5
seconds, and say after 20 or 30 seconds (depending on what you choose)
do the alternate action (be it turn of bond perceiving or other
stuff). But if you then put a button on said box, it would enable to
user to actually cancel (ahead of time) the bond perceiving algorithm.

To things will happen because of this:

  1. the user is notified that an action is taking a long time, thus not
    just sitting around and waiting while nothing happens.
  2. the user is in control of what action should be performed (wait for
    it to finish or cancel it)

Additionally, one could just display the atoms without bonds (or mabye
single bonds everywhere is also quick?) initially above a threshold of
molecule size, and display the bonds properly after some time, if the
molecule has not been changed by the user until then (in which case,
recalculate). Not sure the OpenBabel interface in Avogadro allows for
this, though.

Bond perceiving is often useless for large systems. Sometimes people load
large fragments of crystal structures in Avogadro and wonder why they doesn’t
open or open too slow. Than imagine what it be if bond perceiving is done in
background and is restarted after every change…

I am not sure I get your point. AIUI, bond perceiving is currently done
unconditionally on molecule load. I did not propose to redo it after
every change, just until we have it finished once (or maybe just time
out at some point).

Michael

I am not sure I get your point. AIUI, bond perceiving is currently done
unconditionally on molecule load. I did not propose to redo it after
every change, just until we have it finished once (or maybe just time
out at some point).

Sorry for misunderstanding. I just wanted to mention that highly resource
consuming process in a background may not be desired


Regards,
Konstantin

On Oct 20, 2010, at 3:08 AM, Casper Steinmann wrote:

  1. the user is notified that an action is taking a long time, thus not
    just sitting around and waiting while nothing happens.
  2. the user is in control of what action should be performed (wait for
    it to finish or cancel it)

I think I prefer this route. The catch is that we have two possible sources of slow import:

  1. The user has picked a huge multi-molecule SD file (or QM output from an optimization with lots of steps, etc.)
  2. The user has picked a huge molecule and bond perception is slow.

We currently display a progress bar with a “cancel import” button. So we’d be adding another method, which would trigger a re-import.

I’m not sure the MainWindow class gets enough information to separate the two sources of slowdown…

-Geoff

20.10.2010, 15:37, “Geoffrey Hutchison” geoff.hutchison@gmail.com:

On Oct 20, 2010, at 3:08 AM, Casper Steinmann wrote:

  1. the user is notified that an action is taking a long time, thus not
    just sitting around and waiting while nothing happens.
  2. the user is in control of what action should be performed (wait for
    it to finish or cancel it)

I think I prefer this route. The catch is that we have two possible sources of slow import:

  1. The user has picked a huge multi-molecule SD file (or QM output from an optimization with lots of steps, etc.)
  2. The user has picked a huge molecule and bond perception is slow.

We currently display a progress bar with a “cancel import” button. So we’d be adding another method, which would trigger a re-import.

I’m not sure the MainWindow class gets enough information to separate the two sources of slowdown…

Maybe it’s better to move import routines into library?


Regards,
Konstantin

On Wednesday 20 October 2010 08:03:52 Konstantin Tokarev wrote:

20.10.2010, 15:37, “Geoffrey Hutchison” geoff.hutchison@gmail.com:

On Oct 20, 2010, at 3:08 AM, Casper Steinmann wrote:

  1. the user is notified that an action is taking a long time, thus not
    just sitting around and waiting while nothing happens.
  2. the user is in control of what action should be performed (wait for
    it to finish or cancel it)

I think I prefer this route. The catch is that we have two possible
sources of slow import: 1) The user has picked a huge multi-molecule SD
file (or QM output from an optimization with lots of steps, etc.) 2) The
user has picked a huge molecule and bond perception is slow.

We currently display a progress bar with a “cancel import” button. So
we’d be adding another method, which would trigger a re-import.

I’m not sure the MainWindow class gets enough information to separate the
two sources of slowdown…

Maybe it’s better to move import routines into library?

There is already an import extension, if you use import -> molecule file it
allows you to turn off bond perception from the beginning. I added this for the
very reason you mention - maybe we just need better documentation? Having
intelligent popups could also help out, so long as they don’t make things more
complex than they need to be.

Marcus

Maybe it’s better to move import routines into library?

There is already an import extension, if you use import -> molecule file it
allows you to turn off bond perception from the beginning. I added this for the
very reason you mention - maybe we just need better documentation? Having
intelligent popups could also help out, so long as they don’t make things more
complex than they need to be.

I’ve remember about import -> molecule file (and it is a real workaround)
I was talking about merging of open and import in order to make open more intelligent
(e.g. separate cases of multi-molecule file and file with large molecule as Geoffrey
proposed)


Regards,
Konstantin

There is already an import extension, if you use import -> molecule file it
allows you to turn off bond perception from the beginning.

Maybe it’s worth to integrate settings from Import dialog into regular Open dialog?

http://developer.qt.nokia.com/faq/answer/how_can_i_add_widgets_to_my_qfiledialog_instance


Regards,
Konstantin

On Oct 26, 2010, at 5:18 AM, Konstantin Tokarev wrote:

Maybe it’s worth to integrate settings from Import dialog into regular Open dialog?

http://developer.qt.nokia.com/faq/answer/how_can_i_add_widgets_to_my_qfiledialog_instance

I’m willing to give it a try. My only worry is that on Mac and Windows, this will force Qt to use it’s dialog, rather than the native open file dialog.

The only way to know is to try. If you submit a patch to Gerrit, I’ll try it.

Cheers,
-Geoff

On Tue, Oct 26, 2010 at 11:55 AM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:

On Oct 26, 2010, at 5:18 AM, Konstantin Tokarev wrote:

Maybe it’s worth to integrate settings from Import dialog into regular Open dialog?

http://developer.qt.nokia.com/faq/answer/how_can_i_add_widgets_to_my_qfiledialog_instance

I’m willing to give it a try. My only worry is that on Mac and Windows, this will force Qt to use it’s dialog, rather than the native open file dialog.

The only way to know is to try. If you submit a patch to Gerrit, I’ll try it.

Why not just put import file right under open, and document that for
big files etc you likely need the control and should use the more
advanced dialog?

Marcus

Actually, while you’re on this, can anyone tell me if this manipulation
technique is working?
Because I’ve been trying to do this with PyQt for a week now for my project
(ccwatcher.sourceforge.net) in like a hundred variations (subclassing etc.)
and the QFileDialog never shows my new widget.
I even posted on a forum but got no answers so far
(http://www.qtcentre.org/threads/35405-PyQt-How-to-manipulate-
QFileDialog?p=163543) so I was wondering if there maybe was a qt or python
problem around this…

Regards,
Xaver

Am Dienstag 26 Oktober 2010, 17:55:47 schrieb Geoffrey Hutchison:

On Oct 26, 2010, at 5:18 AM, Konstantin Tokarev wrote:

Maybe it’s worth to integrate settings from Import dialog into regular
Open dialog?

http://developer.qt.nokia.com/faq/answer/how_can_i_add_widgets_to_my_qfil
edialog_instance

I’m willing to give it a try. My only worry is that on Mac and Windows,
this will force Qt to use it’s dialog, rather than the native open file
dialog.

The only way to know is to try. If you submit a patch to Gerrit, I’ll try
it.

Cheers,
-Geoff

— Nokia and AT&T present the 2010 Calling All Innovators-North America
contest Create new apps & games for the Nokia N8 for consumers in U.S.
and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M
in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish
to Ovi Store http://p.sf.net/sfu/nokia-dev2dev


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

28.10.2010, 01:00, “Xaver Wurzenberger” xaver.xn@web.de:

Actually, while you’re on this, can anyone tell me if this manipulation
technique is working?
Because I’ve been trying to do this with PyQt for a week now for my project
(ccwatcher.sourceforge.net) in like a hundred variations (subclassing etc.)
and the QFileDialog never shows my new widget.
I even posted on a forum but got no answers so far
(http://www.qtcentre.org/threads/35405-PyQt-How-to-manipulate-
QFileDialog?p=163543) so I was wondering if there maybe was a qt or python
problem around this…

Hi Xaver,
Please look more carefully into
http://developer.qt.nokia.com/faq/answer/how_can_i_add_widgets_to_my_qfiledialog_instance

you will see that C++ code in first link does not inherit QFileDialog (like yours), but only interacts
with public methods of it (QFileDialog::layout() in this case). I suppose it will work in Python

P.S. you should not expect inheritance of Python classes from C++ ones to be fully functional
If you need customization you may need to inherit in C++, than use in Python


Regards,
Konstantin

Hi Xaver,
Please look more carefully into
http://developer.qt.nokia.com/faq/answer/how_can_i_add_widgets_to_my_qfiled
ialog_instance
you will see that C++ code in first link does not inherit QFileDialog (like
yours), but only interacts with public methods of it
(QFileDialog::layout() in this case). I suppose it will work in Python

Hi Konstantin,
as I indicated there are many ways I tested, public methods were of course my
first try. I believe this to be a complete “translation” of your page - which
is not working:

1 import sys
2 from PyQt4 import QtCore,QtGui
3
4 app = QtGui.QApplication(sys.argv)
5 box = QtGui.QFileDialog()
6 button = QtGui.QPushButton(box)
7 button.setText(“New button”)
8 layout = box.layout()
9 layout.addWidget(button, 0, 0)
10 box.show()
11 sys.exit(app.exec_())

I’m not completely sure about line 9, though.
I know there’s probably no PyQt experts here, but if someone (Geoff if he’ll
implement it) could test this way in c++ and assure me it works, that would be
a start.

P.S. you should not expect inheritance of Python classes from C++ ones to
be fully functional If you need customization you may need to inherit in
C++, than use in Python

What makes you say that? PyQt is a fully operational Qt API. Why should there
be classes that can be inherited (I subclass QMainWindow and QWidget all the
time) and classes which can’t?

Regards, Xaver