I’ve implemented a check for new/modified plugins on startup
What is desired behavior in case user rejected plugin?
a) Don’t load factory at all (letting user to enable it again will require more effort)
b) Load plugin in disabled state
–
Regards,
Konstantin
On Tue, Nov 9, 2010 at 1:14 PM, Konstantin Tokarev annulen@yandex.ru wrote:
I’ve implemented a check for new/modified plugins on startup
What is desired behavior in case user rejected plugin?
a) Don’t load factory at all (letting user to enable it again will require more effort)
b) Load plugin in disabled state
Perhaps you can let the user decide? I’m not sure what you GUI looks
like, but I’m picturing a table with the name of the plugin and three
exclusive checkboxes: “Load”, “Load disabled”, “Do not load” or
similar.
Dave
09.11.2010, 22:31, “David Lonie” loniedavid@gmail.com:
On Tue, Nov 9, 2010 at 1:14 PM, Konstantin Tokarev annulen@yandex.ru; wrote:
I’ve implemented a check for new/modified plugins on startup
What is desired behavior in case user rejected plugin?
a) Don’t load factory at all (letting user to enable it again will require more effort)
b) Load plugin in disabled state
Perhaps you can let the user decide? I’m not sure what you GUI looks
like, but I’m picturing a table with the name of the plugin and three
exclusive checkboxes: “Load”, “Load disabled”, “Do not load” or
similar.
Right now it’s QMessageBox with question and “Yes” and “No” options
–
Regards,
Konstantin
2010/11/9 Konstantin Tokarev annulen@yandex.ru:
09.11.2010, 22:31, “David Lonie” loniedavid@gmail.com:
On Tue, Nov 9, 2010 at 1:14 PM, Konstantin Tokarev annulen@yandex.ru; wrote:
I’ve implemented a check for new/modified plugins on startup
What is desired behavior in case user rejected plugin?
a) Don’t load factory at all (letting user to enable it again will require more effort)
b) Load plugin in disabled state
Perhaps you can let the user decide? I’m not sure what you GUI looks
like, but I’m picturing a table with the name of the plugin and three
exclusive checkboxes: “Load”, “Load disabled”, “Do not load” or
similar.
Right now it’s QMessageBox with question and “Yes” and “No” options
Does a separate message box pop up for every new/changed extension?
This would be bad, most users will just click through them all without
really reading them.
Dave
Does a separate message box pop up for every new/changed extension?
This would be bad, most users will just click through them all without
really reading them.
OK, I will change it to table. It would be nice to display plugin descriptions
alongside with file names, but it is not secure to load untrusted factory
–
Regards,
Konstantin
Does a separate message box pop up for every new/changed extension?
Anyway, it will be disabled on Avogadro update when all plugins are modified
–
Regards,
Konstantin
10.11.2010, 00:20, “David Lonie” loniedavid@gmail.com:
2010/11/9 Konstantin Tokarev annulen@yandex.ru;:
09.11.2010, 22:31, “David Lonie” loniedavid@gmail.com;:
On Tue, Nov 9, 2010 at 1:14 PM, Konstantin Tokarev annulen@yandex.ru;; wrote:
I’ve implemented a check for new/modified plugins on startup
What is desired behavior in case user rejected plugin?
a) Don’t load factory at all (letting user to enable it again will require more effort)
b) Load plugin in disabled state
Perhaps you can let the user decide? I’m not sure what you GUI looks
like, but I’m picturing a table with the name of the plugin and three
exclusive checkboxes: “Load”, “Load disabled”, “Do not load” or
similar.
Right now it’s QMessageBox with question and “Yes” and “No” options
Does a separate message box pop up for every new/changed extension?
This would be bad, most users will just click through them all without
really reading them.
Should dialog be created inside library or application?
Arguments for library:
- implementation is more straightforward;
- other client of libavogadro (e.g. Kalzium) can get this feature with minimal effort
Arguments for application:
- client application may want to use their own GUI (or non-GUI) handling of this situation
- currently there are no actual GUI components (except the GLWidget) in libavogadro
Any opinions?
–
Regards,
Konstantin
On Nov 16, 2010, at 2:05 PM, Konstantin Tokarev wrote:
- other client of libavogadro (e.g. Kalzium) can get this feature with minimal effort
Other clients may strictly list plugins anyway and not allow dynamic loading.
Arguments for application:
- client application may want to use their own GUI (or non-GUI) handling of this situation
- currently there are no actual GUI components (except the GLWidget) in libavogadro
Application would be my preferred mechanism. I agree with your division about the GUI components not existing in libavogadro, and that client applications may have their own technique. Consider, for example, embedding libavogadro in a Python script from the command-line.
That’s my $0.02,
-Geoff
17.11.2010, 07:24, “Geoffrey Hutchison” geoff.hutchison@gmail.com:
On Nov 16, 2010, at 2:05 PM, Konstantin Tokarev wrote:
- other client of libavogadro (e.g. Kalzium) can get this feature with minimal effort
Other clients may strictly list plugins anyway and not allow dynamic loading.
This code protects not only from new plugins, but also from their modification, so it
may be useful even when the list of plugins is fixed
–
Regards,
Konstantin
16.11.2010, 22:05, “Konstantin Tokarev” annulen@yandex.ru:
10.11.2010, 00:20, “David Lonie” loniedavid@gmail.com;:
2010/11/9 Konstantin Tokarev annulen@yandex.ru;;:
09.11.2010, 22:31, “David Lonie” loniedavid@gmail.com;;:
On Tue, Nov 9, 2010 at 1:14 PM, Konstantin Tokarev annulen@yandex.ru;;; wrote:
I’ve implemented a check for new/modified plugins on startup
What is desired behavior in case user rejected plugin?
a) Don’t load factory at all (letting user to enable it again will require more effort)
b) Load plugin in disabled state
Perhaps you can let the user decide? I’m not sure what you GUI looks
like, but I’m picturing a table with the name of the plugin and three
exclusive checkboxes: “Load”, “Load disabled”, “Do not load” or
similar.
Right now it’s QMessageBox with question and “Yes” and “No” options
Does a separate message box pop up for every new/changed extension?
This would be bad, most users will just click through them all without
really reading them.
One more question on this topic: should it be submitted to 1.0 or master?
Right now I’m writing it on 1.0 branch
Arguments for 1.0:
- it fixes security vulnerability
- it does not modify ABI (I’ve put the most of new code in class PluginLoader
which replaces QPluginLoader in PluginManager)
Arguments for master:
- it’s non-trivial change
- it adds new GUI (if it were not added it would not be user-friendly as David pointed previously)
- it adds new API functions (because of (2) it’s impossible to incapsulate everything inside
PluginLoader)
–
Regards,
Konstantin
On Wednesday 17 November 2010 07:56:36 Konstantin Tokarev wrote:
16.11.2010, 22:05, “Konstantin Tokarev” annulen@yandex.ru:
10.11.2010, 00:20, “David Lonie” loniedavid@gmail.com;:
2010/11/9 Konstantin Tokarev annulen@yandex.ru;;:
09.11.2010, 22:31, “David Lonie” loniedavid@gmail.com;;:
On Tue, Nov 9, 2010 at 1:14 PM, Konstantin Tokarev
annulen@yandex.ru;;; wrote:
I’ve implemented a check for new/modified plugins on startup
What is desired behavior in case user rejected plugin?
a) Don’t load factory at all (letting user to enable it again will
require more effort) b) Load plugin in disabled state
Perhaps you can let the user decide? I’m not sure what you GUI looks
like, but I’m picturing a table with the name of the plugin and
three exclusive checkboxes: “Load”, “Load disabled”, “Do not load” or
similar.
Right now it’s QMessageBox with question and “Yes” and “No” options
Does a separate message box pop up for every new/changed extension?
This would be bad, most users will just click through them all without
really reading them.
One more question on this topic: should it be submitted to 1.0 or master?
Right now I’m writing it on 1.0 branch
Arguments for 1.0:
- it fixes security vulnerability
- it does not modify ABI (I’ve put the most of new code in class
PluginLoader which replaces QPluginLoader in PluginManager)
Arguments for master:
- it’s non-trivial change
- it adds new GUI (if it were not added it would not be user-friendly as
David pointed previously) 3) it adds new API functions (because of (2)
it’s impossible to incapsulate everything inside PluginLoader)
I think it should go into master - we will release new versions of 1.1, and
1.0 should ideally be bug fixes - new features can, and often do, introduce
unintentional bugs.
Marcus