OPINIONS DESIRED: Updated Addon manager PR

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

OPINIONS DESIRED: Updated Addon manager PR

Paul Franklin-5
I urge every developer to express their opinion on this
pull request.  In my opinion, too much work has been
put into it for it to just keep languishing in limbo.

There is a difference of opinion -- a firm, strong one --
between the chief author (PaulC) and the reviewer-in-chief
(Nick) about a subtle aspect of the user interface.

Please read all the comments on that pull request, and
look at the example images, then express your opinion.

Thank you.


---------- Forwarded message ----------
From: Paul Culley <[hidden email]>
Date: Sat, 8 Apr 2017 16:06:36 -0500
Subject: [Gramps-devel] Updated Addon manager PR
To: Gramps Developers <[hidden email]>

Developers;
For quite a while now intermittent work has been done on an 'improved'
Addon manager by several people.  I've done the most recent work and I've
gotten some good feedback from a couple of developers, but think a wider
audience might help.  So please take a look at
https://github.com/gramps-project/gramps/pull/63
The development and comments history is long, you might want to start about
2/3 the way down the page.

I tried to make it a bit more user friendly while still supporting
developers with useful information and features...

* A single 'Addon manager...' item on the 'Edit' menu starts it.
* Preferences related to the Addon manager are on the 'Update' pane.
* Unified view combines Registered and Loaded views with all the available
3rd party plugins in a single view.
* Status column indicates status of Addon, Available, Installed, Built-in,
Update Available, and hidden (via strike-through).  A Failed addon also
adds 'Failed' status in red.
* All of Available, Installed, and Built-in plugins can be hidden.
* A "Remove hidden items from view" checkbox allows the user to get
uninteresting (hidden) addons off the Addons pane.
* A "Remove built-in items from view" checkbox allows the user to get these
off the pane if desired.
* Available and Update Available addons can be installed from Addons pane,
the "Install" button becomes active when this is possible.
* Installed addons can be un-installed from Addons pane; the "Uninstall"
appears when this is possible.
* Info button provides information on all addon types; includes 'Loaded'
and failure type and stack traceback, when applicable.
* In 'debug' mode, the 'Reload', 'Load', and 'Edit' buttons appear; load
and edit are greyed out when addon is not installed.
* after updates of Views or Gramplets, or uninstalls, the user is reminded
to restart Gramps.
* The manager opens on the last used pane from the same session, it always
opens on the 'Update' pane the first time.

Note: 3rd party addons can only be shown after at least one 'Update' to
download the list, a dialog pops up if the list is not present to remind
the user.  This happens only once per session when the Addon manager is
opened.

Comments welcome...

Paul Culley

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: OPINIONS DESIRED: Updated Addon manager PR

Gary Griffin
From my read, it seems like the crux of the disagreement is whether to have separate tabs for Built-in vs 3rd party Addons. As a user, the practical distinction between these Addons is one of stability/reliability and support (are there more differences?). Label seems sufficient to indicate stability/reliability. Putting in separate tabs does not communicate that support is thru the bug tracking system vs contacting the author. So for me, separate tabs does not add to the interface usability.

I think having on the same tab is the better solution. One less place to go, labels differentiate stability. This adheres to the principal of least astonishment.

Gary
Reply | Threaded
Open this post in threaded view
|

Re: OPINIONS DESIRED: Updated Addon manager PR

Nick Hall
On 30/04/17 16:55, Gary Griffin wrote:

> >From my read, it seems like the crux of the disagreement is whether to have
> separate tabs for Built-in vs 3rd party Addons. As a user, the practical
> distinction between these Addons is one of stability/reliability and support
> (are there more differences?). Label seems sufficient to indicate
> stability/reliability. Putting in separate tabs does not communicate that
> support is thru the bug tracking system vs contacting the author. So for me,
> separate tabs does not add to the interface usability.
>
> I think having on the same tab is the better solution. One less place to go,
> labels differentiate stability. This adheres to the principal of least
> astonishment.
>
The decision to keep third-party addons and core plugins separate was
deliberate.

Third-party addons vary in reliability and quality.  They are often a
route to prototype new functionality.

Core plugins should hopefully be stable.  The term "built-in" doesn't
usually refer to plugins.

An "Addon Manager" should primarily focus on addons.  Core plugins are
not addons.

As I have said previously, design decisions are made by Brian, Benny and
myself - they are not a result of a public vote. However, if a majority
of developers don't like this, then I am happy for us to discuss
changing the decision making process. Perhaps an elected administrator
or some kind of committee would be a better approach?


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: OPINIONS DESIRED: Updated Addon manager PR

Josip
In reply to this post by Paul Franklin-5
29.4.2017. u 21:03, Paul Franklin je napisao/la:

> I urge every developer to express their opinion on this
> pull request.  In my opinion, too much work has been
> put into it for it to just keep languishing in limbo.
>
> There is a difference of opinion -- a firm, strong one --
> between the chief author (PaulC) and the reviewer-in-chief
> (Nick) about a subtle aspect of the user interface.
>
> Please read all the comments on that pull request, and
> look at the example images, then express your opinion.
>
> Thank you.
>

It is more a major software concept design issue then just a subtle
aspect of the user interface. In which case i think second one must
follow first one. Internal parts of Gramps however they are modular
should be clearly separated from any external module|plugin|addon.

To me such tabular form is ugly and just waist of space (do anyone think
how they will look translated).
Most software i use have it visually separated in three parts: search
options, list of results and detail of selected result.


--
Josip

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: OPINIONS DESIRED: Updated Addon manager PR

John Ralls-2
In reply to this post by Nick Hall

> On Apr 30, 2017, at 10:21 AM, Nick Hall <[hidden email]> wrote:
>
> On 30/04/17 16:55, Gary Griffin wrote:
>>> From my read, it seems like the crux of the disagreement is whether to have
>> separate tabs for Built-in vs 3rd party Addons. As a user, the practical
>> distinction between these Addons is one of stability/reliability and support
>> (are there more differences?). Label seems sufficient to indicate
>> stability/reliability. Putting in separate tabs does not communicate that
>> support is thru the bug tracking system vs contacting the author. So for me,
>> separate tabs does not add to the interface usability.
>>
>> I think having on the same tab is the better solution. One less place to go,
>> labels differentiate stability. This adheres to the principal of least
>> astonishment.
>>
>
> Third-party addons vary in reliability and quality.  They are often a
> route to prototype new functionality.
>
> Core plugins should hopefully be stable.  The term "built-in" doesn't
> usually refer to plugins.
>
> An "Addon Manager" should primarily focus on addons.  Core plugins are
> not addons.
>

I agree that it should keep its name "Plugin Manager" unless it's going to manage only third-party plugins, aka add-ons.

How about instead of tabs the dialog box has a radio group for populating the list with selections for "Add-ons", "Built-Ins", and "Both". Tool tips could explain the difference between add-ons and built-ins. IMO "Add-ons" should be the default view and perhaps the radio group should be hidden by default with an "expert" preference setting to reveal it.

I don't like either of the "status" alternatives and I prefer words to using icons anywhere but on toolbars. Using icons to have meanings different from their names is anyway a bad idea: While the icon might evoke the meaning you want in adwaita there's no guarantee that another theme will use an icon that makes sense in the new context. Meanwhile having multiple words in the "status" column seems a bit cluttered. FWIW there are also accessibility issues with color, icons, and text styling like strikethrough because of the way that high-contrast themes and screen readers (fail to) handle them.

I suggest a bit of reanalysis of "status":

First off, "add-on" (or "third-party") and "built-in" aren't really status, and there needs to be a distinction only when both are present in the list. A separate single-character column could place a glyph next to one or the other in that case; it would be hidden when not needed.

Next, "Hidden" does two things to installed plugins: It removes the item from the list, but it also suppresses loading the item. Uninstalled items obviously won't be loaded anyway, so I suggest changing the status value to "Disabled" for installed and built-in plugins.

There are two flavors of "fail": Failed to install because of network, disk space, or permission problems, and failure to load because of dependency, compilation, or execution problems. Failure in either case is an exception worthy of raising a dialog box with details of the problem and for load problems the option to disable the plugin.

For the rest, they're mostly exclusive conditions: An "available" add-on can neither be enabled nor disabled, but it can be hidden. Once it's installed it can be enabled or disabled but not hidden, so its status is either "Enabled", "Disabled", or perhaps "Failed" if it's been disabled because of a loading problem. Installed add-ons can also have updates available, but I think most users will care about that only for enabled ones so a single "Update" status could mean "enabled and there's a new version that you can install".

Users will want to be able to show hidden and/or disabled add-ons, built-ins, or both. That's five selectors plus the Info, Hide/Disable, and Install buttons. That might be a bit busy, so perhaps a context menu with a radio group and two check menu items would be more appealing.

Regards,
John Ralls
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: OPINIONS DESIRED: Updated Addon manager PR

Nick Hall
John,

Thanks for your comments.  They appear to address most of my concerns.

On 01/05/17 22:07, John Ralls wrote:
> I agree that it should keep its name "Plugin Manager" unless it's going to manage only third-party plugins, aka add-ons.
>
> How about instead of tabs the dialog box has a radio group for populating the list with selections for "Add-ons", "Built-Ins", and "Both". Tool tips could explain the difference between add-ons and built-ins. IMO "Add-ons" should be the default view and perhaps the radio group should be hidden by default with an "expert" preference setting to reveal it.

Yes.  I think that would work well.

> I don't like either of the "status" alternatives and I prefer words to using icons anywhere but on toolbars. Using icons to have meanings different from their names is anyway a bad idea: While the icon might evoke the meaning you want in adwaita there's no guarantee that another theme will use an icon that makes sense in the new context. Meanwhile having multiple words in the "status" column seems a bit cluttered. FWIW there are also accessibility issues with color, icons, and text styling like strikethrough because of the way that high-contrast themes and screen readers (fail to) handle them.

I have no objection to words instead of icons.  It was just an idea.  I
agree that is is best to always choose standard icons with tooltips when
they are used.

We should also remove colours and strikethrough for the reasons you mention.


>
> I suggest a bit of reanalysis of "status":
>
> First off, "add-on" (or "third-party") and "built-in" aren't really status, and there needs to be a distinction only when both are present in the list. A separate single-character column could place a glyph next to one or the other in that case; it would be hidden when not needed.
>
> Next, "Hidden" does two things to installed plugins: It removes the item from the list, but it also suppresses loading the item. Uninstalled items obviously won't be loaded anyway, so I suggest changing the status value to "Disabled" for installed and built-in plugins.
>
> There are two flavors of "fail": Failed to install because of network, disk space, or permission problems, and failure to load because of dependency, compilation, or execution problems. Failure in either case is an exception worthy of raising a dialog box with details of the problem and for load problems the option to disable the plugin.
>
> For the rest, they're mostly exclusive conditions: An "available" add-on can neither be enabled nor disabled, but it can be hidden. Once it's installed it can be enabled or disabled but not hidden, so its status is either "Enabled", "Disabled", or perhaps "Failed" if it's been disabled because of a loading problem. Installed add-ons can also have updates available, but I think most users will care about that only for enabled ones so a single "Update" status could mean "enabled and there's a new version that you can install".

Do we still need "Hidden" in addition to "Enabled" and "Disabled"?

> Users will want to be able to show hidden and/or disabled add-ons, built-ins, or both. That's five selectors plus the Info, Hide/Disable, and Install buttons. That might be a bit busy, so perhaps a context menu with a radio group and two check menu items would be more appealing.

Why would anyone want to hide an available third-party addon?  It would
not be visible until installed.


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: OPINIONS DESIRED: Updated Addon manager PR

Nick Hall
In reply to this post by Josip
On 01/05/17 10:08, Josip wrote:
> To me such tabular form is ugly and just waist of space (do anyone think
> how they will look translated).
I agree.  I was hoping for a clearer and simpler UI.
> Most software i use have it visually separated in three parts: search
> options, list of results and detail of selected result.

Yes.  We could look at other software such as web browsers for inspiration.

Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: OPINIONS DESIRED: Updated Addon manager PR

John Ralls-2
In reply to this post by Nick Hall

On May 1, 2017, at 7:06 PM, Nick Hall <[hidden email]> wrote:

Do we still need "Hidden" in addition to "Enabled" and "Disabled"?

Users will want to be able to show hidden and/or disabled add-ons, built-ins, or both. That's five selectors plus the Info, Hide/Disable, and Install buttons. That might be a bit busy, so perhaps a context menu with a radio group and two check menu items would be more appealing.

Why would anyone want to hide an available third-party addon?  It would not be visible until installed.

Those questions are for Paul C. Hiding selected available add-ons is a feature of his new implementation and I would be speaking out of turn to try to explain his motivation.
If one stipulates that the capability should be provided then using "Disabled" to indicate both installed plugins that won't be loaded and uninstalled add-ons that the user finds uninteresting could lead to surprises.

Regards,
John Ralls


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: OPINIONS DESIRED: Updated Addon manager PR

prculley
Back to (fun) work on Gramps again...

Thanks to John Ralls for the carefully considered analysis of the work to date.  I am hopeful that if I implement fixes in these directions that I can get approval.

A couple of notes.
I did add the concept of 'hiding' items from the view as a way of de-cluttering it. When I look over the list, I evaluate each item for potential use by me. I like to leave the more likely ones in the list and remove the ones I don't expect to ever need.  So it seemed reasonable to me to overload the 'hide' functionality (which hides addons from the rest of the UI) for this purpose.

I don't consider this feature mandatory, but think it is nice to have.

An "available" add-on can neither be enabled nor disabled, but it can be hidden. Once it's installed it can be enabled or disabled but not hidden, so its status is either "Enabled", "Disabled"
Gramps has always had the ability to hide any kind of addon from the UI, built-in or 3rd party.  So historically hiding could be used on 3rd party plugins (since the unsophisticated user would be unable to uninstall them).  So 'Disabled' and 'Hidden'

I also added the ability to 'un-install' a 3rd party addon based on a comment quite a while ago.  Seemed like a reasonable idea to keep the startup time for Gramps down a bit if the user decided an addon was not interesting.

If I'm allowed to keep those two new features, then I consider the hide/un-hide and installed/un-installed state to be pretty much independent, although I admit hiding an installed 3rd party addon is not very necessary.

My current thoughts are to implement

 a 'Change view' button which brings up a small menu of view options.
  • a dropdown selector or radio group with three states 'Show builtin, Show 3rd party addon, Show both'
  • a checkbox for show disabled

On Mon, May 1, 2017 at 10:20 PM, John Ralls <[hidden email]> wrote:

On May 1, 2017, at 7:06 PM, Nick Hall <[hidden email]> wrote:

Do we still need "Hidden" in addition to "Enabled" and "Disabled"?

Users will want to be able to show hidden and/or disabled add-ons, built-ins, or both. That's five selectors plus the Info, Hide/Disable, and Install buttons. That might be a bit busy, so perhaps a context menu with a radio group and two check menu items would be more appealing.

Why would anyone want to hide an available third-party addon?  It would not be visible until installed.

Those questions are for Paul C. Hiding selected available add-ons is a feature of his new implementation and I would be speaking out of turn to try to explain his motivation.
If one stipulates that the capability should be provided then using "Disabled" to indicate both installed plugins that won't be loaded and uninstalled add-ons that the user finds uninteresting could lead to surprises.

Regards,
John Ralls


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: OPINIONS DESIRED: Updated Addon manager PR

prculley
Please ignore my previous email, it was sent before completion in error.

Paul Culley

On Tue, May 2, 2017 at 3:59 PM, Paul Culley <[hidden email]> wrote:
Back to (fun) work on Gramps again...

Thanks to John Ralls for the carefully considered analysis of the work to date.  I am hopeful that if I implement fixes in these directions that I can get approval.

A couple of notes.
I did add the concept of 'hiding' items from the view as a way of de-cluttering it. When I look over the list, I evaluate each item for potential use by me. I like to leave the more likely ones in the list and remove the ones I don't expect to ever need.  So it seemed reasonable to me to overload the 'hide' functionality (which hides addons from the rest of the UI) for this purpose.

I don't consider this feature mandatory, but think it is nice to have.

An "available" add-on can neither be enabled nor disabled, but it can be hidden. Once it's installed it can be enabled or disabled but not hidden, so its status is either "Enabled", "Disabled"
Gramps has always had the ability to hide any kind of addon from the UI, built-in or 3rd party.  So historically hiding could be used on 3rd party plugins (since the unsophisticated user would be unable to uninstall them).  So 'Disabled' and 'Hidden'

I also added the ability to 'un-install' a 3rd party addon based on a comment quite a while ago.  Seemed like a reasonable idea to keep the startup time for Gramps down a bit if the user decided an addon was not interesting.

If I'm allowed to keep those two new features, then I consider the hide/un-hide and installed/un-installed state to be pretty much independent, although I admit hiding an installed 3rd party addon is not very necessary.

My current thoughts are to implement

 a 'Change view' button which brings up a small menu of view options.
  • a dropdown selector or radio group with three states 'Show builtin, Show 3rd party addon, Show both'
  • a checkbox for show disabled

On Mon, May 1, 2017 at 10:20 PM, John Ralls <[hidden email]> wrote:

On May 1, 2017, at 7:06 PM, Nick Hall <[hidden email]> wrote:

Do we still need "Hidden" in addition to "Enabled" and "Disabled"?

Users will want to be able to show hidden and/or disabled add-ons, built-ins, or both. That's five selectors plus the Info, Hide/Disable, and Install buttons. That might be a bit busy, so perhaps a context menu with a radio group and two check menu items would be more appealing.

Why would anyone want to hide an available third-party addon?  It would not be visible until installed.

Those questions are for Paul C. Hiding selected available add-ons is a feature of his new implementation and I would be speaking out of turn to try to explain his motivation.
If one stipulates that the capability should be provided then using "Disabled" to indicate both installed plugins that won't be loaded and uninstalled add-ons that the user finds uninteresting could lead to surprises.

Regards,
John Ralls


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: OPINIONS DESIRED: Updated Addon manager PR

prculley
Back to (fun) work on Gramps again...

Thanks to John Ralls for the carefully considered analysis of the work to date.  I am hopeful that if I implement fixes in these directions that I can get approval.

A couple of notes.
I did add the concept of 'hiding' items from the view as a way of de-cluttering it. When I look over the list, I evaluate each item for potential use by me. I like to leave the more likely ones in the list and remove the ones I don't expect to ever need.  So it seemed reasonable to me to overload the 'hide' functionality (which hides addons from the rest of the UI) for this purpose.

I don't consider this feature mandatory, but think it is nice to have.

    An "available" add-on can neither be enabled nor disabled, but it can be hidden. Once it's installed it can be enabled or disabled but not hidden, so its status is either "Enabled", "Disabled"

    Gramps has always had the ability to hide any kind of addon from the UI, built-in or 3rd party.  So historically hiding could be used on 3rd party plugins (since the unsophisticated user would be unable to uninstall them).  So 'Disabled' and 'Hidden' could be considered the same thing...  I will stop using the 'hidden' or hide terminology in favor of 'enable'/'disable' as that seems to make people feel better.

I also added the ability to 'un-install' a 3rd party addon based on a comment quite a while ago.  Seemed like a reasonable idea to keep the startup time for Gramps down a bit if the user decided an addon was not interesting.

If I'm allowed to keep those two new features, then I consider the hide/un-hide (disable/enable) and installed/un-installed state to be pretty much independent, although I admit hiding an installed 3rd party addon is not very necessary.

'Failed' status is another bit of legacy functionality which was in the original plugin manager 'Loaded Plugins' tab.  Hopefully it will appear very infrequently.  When it does, it seems to occur when an addon is first executed or during use, not at Gramps load time.  You do get the usual Gramps problem popup with its traceback.  The plugin manager has always saved the traceback info; I allow this to be accessed via the 'Info' button for a failed plugin as a help for developers.

My current thoughts are to implement

  • Status for built-ins: Enabled, Disabled(hidden), or Failed
  • Status for 3rd party addons: Available, Disabled, Enabled, Update, Failed (I'd like to allow Update and Failed status to appear at the same time, as it seems possible that an Update might help a failing addon)
  • A single char wide unlabled column indicating 3rd party addons, I'll use an '*' character to indicate 3rd party.  If someone has another suggestion on a better character choice, please let me know.  I think I can also set up a tooltip on each 3rd party row that will pop up on hover over the row saying something like '3rd party addon, please contact author for support'
  •  a 'Change view' button which brings up a small menu of view options.
    •     a dropdown selector or radio group with three states 'Show builtin, Show 3rd party addon, Show both'
    •     a checkbox for 'show disabled'
   
Nick, rather than play 'bring me a rock, I'll tell you when I like it', I would prefer to get a tentative approval of this before spending any more time coding it up.  So please let me know if this will pass...

Paul Culley

On Tue, May 2, 2017 at 4:01 PM, Paul Culley <[hidden email]> wrote:
Please ignore my previous email, it was sent before completion in error.

Paul Culley

On Tue, May 2, 2017 at 3:59 PM, Paul Culley <[hidden email]> wrote:
Back to (fun) work on Gramps again...

Thanks to John Ralls for the carefully considered analysis of the work to date.  I am hopeful that if I implement fixes in these directions that I can get approval.

A couple of notes.
I did add the concept of 'hiding' items from the view as a way of de-cluttering it. When I look over the list, I evaluate each item for potential use by me. I like to leave the more likely ones in the list and remove the ones I don't expect to ever need.  So it seemed reasonable to me to overload the 'hide' functionality (which hides addons from the rest of the UI) for this purpose.

I don't consider this feature mandatory, but think it is nice to have.

An "available" add-on can neither be enabled nor disabled, but it can be hidden. Once it's installed it can be enabled or disabled but not hidden, so its status is either "Enabled", "Disabled"
Gramps has always had the ability to hide any kind of addon from the UI, built-in or 3rd party.  So historically hiding could be used on 3rd party plugins (since the unsophisticated user would be unable to uninstall them).  So 'Disabled' and 'Hidden'

I also added the ability to 'un-install' a 3rd party addon based on a comment quite a while ago.  Seemed like a reasonable idea to keep the startup time for Gramps down a bit if the user decided an addon was not interesting.

If I'm allowed to keep those two new features, then I consider the hide/un-hide and installed/un-installed state to be pretty much independent, although I admit hiding an installed 3rd party addon is not very necessary.

My current thoughts are to implement

 a 'Change view' button which brings up a small menu of view options.
  • a dropdown selector or radio group with three states 'Show builtin, Show 3rd party addon, Show both'
  • a checkbox for show disabled

On Mon, May 1, 2017 at 10:20 PM, John Ralls <[hidden email]> wrote:

On May 1, 2017, at 7:06 PM, Nick Hall <[hidden email]> wrote:

Do we still need "Hidden" in addition to "Enabled" and "Disabled"?

Users will want to be able to show hidden and/or disabled add-ons, built-ins, or both. That's five selectors plus the Info, Hide/Disable, and Install buttons. That might be a bit busy, so perhaps a context menu with a radio group and two check menu items would be more appealing.

Why would anyone want to hide an available third-party addon?  It would not be visible until installed.

Those questions are for Paul C. Hiding selected available add-ons is a feature of his new implementation and I would be speaking out of turn to try to explain his motivation.
If one stipulates that the capability should be provided then using "Disabled" to indicate both installed plugins that won't be loaded and uninstalled add-ons that the user finds uninteresting could lead to surprises.

Regards,
John Ralls


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: OPINIONS DESIRED: Updated Addon manager PR

Tim Lyons
Administrator
Paul,

I much prefer a single list.

The distinction between addons, built-ins, plugins, 3rd party addons is really unclear, and the various documentation elements seem to use different words for the same thing and the same words for different things. I did once look at trying to make the wordings clearer in the documentation, but it really isn't simple. This is all not a criticism, because I agree that it's up to people like me to make it better, and it s just difficult because of the way software grows organically. Anyway, my point is that in my opinion providing separate places to list the different things doesn't help.

I'd prefer the checkboxes/radio buttons to show different views to be visible, rather than hidden behind a 'change view' button, because behind a button it is not clear what you are looking at. (Imagine someone sending you a screenshot - you wouldn't know whether something was missing because of a bug or because of the view choice).

I prefer words to icons.

Context menus are really obscure - I bet there's not one user in a thousand that knows about the very important context menu on Tools -> Family Tree Processing -> Edit Database Owner Information... I certainly didn't know about it till I found it in the code.

Regards,
Tim.


P.S. I like the expression "play 'bring me a rock, I'll tell you when I like it'" I will definitely store that for future use outside Gramps - did you just invent it or get it from somewhere else!