Re: Can I request that a Gramps bug report be re-assessed?

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

Re: Can I request that a Gramps bug report be re-assessed?

GRAMPS - User mailing list
I posted a bug report and it was re-categorised as a "feature" rather than a bug. Can I ask for a re-assessment?

The bug is that identical interface for the same functionality in 2 spots of the program (a button action for the search filter in the grouped/nested Places view) gives different results.

The differing behaviors indicates that : 1) there is redundant code; and 2) it is out of sync.

The reason that this is important is that inconsistency of interface without a visual cue undermines confidence

Was my offering an opinion on which behavior was preferable inappropriate? It seems that the opinion is why it might be deemed a "feature" rather than a bug. Or should I have been more explicit that the bug was out-of-sync redundant code rather than the functionality?

Reference:
0010421: Place 'Find' behavior
Summary: the action of "Clear" button in the find Nested/Grouped Places list gives differing results (when adding a Place to an Event versus when in the main Places panel.)

-Brian

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

Re: Can I request that a Gramps bug report be re-assessed?

Dave Scheipers
Hi Brian

Reading your 'bug' submittal it is actually a Feature Request.

Bugs are reports that the code is not doing what is advertised or
expected. You are seeking the code to do something different, a new
Feature Request.

An earlier 'bug' fix on the place list resulted in all lists being
automatically expanded. A disaster especially for large databases. I
like your idea that after a search and selecting a place, hitting
'clear' should be able to keep the focus on the selected place so a
further search of the nested places below the parent place can be
done.

Dave



On Tue, Feb 20, 2018 at 6:32 AM, Emyoulation--- via Gramps-users
<[hidden email]> wrote:

> I posted a bug report and it was re-categorised as a "feature" rather than a bug. Can I ask for a re-assessment?
>
> The bug is that identical interface for the same functionality in 2 spots of the program (a button action for the search filter in the grouped/nested Places view) gives different results.
>
> The differing behaviors indicates that : 1) there is redundant code; and 2) it is out of sync.
>
> The reason that this is important is that inconsistency of interface without a visual cue undermines confidence
>
> Was my offering an opinion on which behavior was preferable inappropriate? It seems that the opinion is why it might be deemed a "feature" rather than a bug. Or should I have been more explicit that the bug was out-of-sync redundant code rather than the functionality?
>
> Reference:
> 0010421: Place 'Find' behavior
> Summary: the action of "Clear" button in the find Nested/Grouped Places list gives differing results (when adding a Place to an Event versus when in the main Places panel.)
>
> -Brian
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Gramps-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-users
> https://gramps-project.org

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

Re: Can I request that a Gramps bug report be re-assessed?

GRAMPS - User mailing list
In reply to this post by GRAMPS - User mailing list
Thanks Dave,

I can't take credit for the focus idea. That behavior is what already happens when the "Search bar" is visible in the "Places category of the Navigator". No new functionality.

The differing behavior is in the "Place Reference Editor" dialog after clicking the "Select Place selector". (Whew! I had to dig a while in the manual to find the official GUI Object names!)

Identical interface object (the Search bar) is acting differently on the same data set (Places). So the bug is that there IS a difference, not the nature of the difference.  

It is irrelevant if fixing inconsistency enhances functionality. Fixing the difference could delete the existing functionality or apply it in both areas... preferably by consolidating the function/subroutine rather than having redundant code.

That said, it is a pity that this deeper functionality is in the less frequently used part of Gramps. But easier drill-down IS more vital when Merging duplicate sub-entries in a vast Places list... like an unknown set of duplicate townships (perhaps created by an import) in a county name used in several states.



--------------------------------------------
On Tue, 2/20/18, Dave Scheipers <[hidden email]> wrote:

 Subject: Re: [Gramps-users] Can I request that a Gramps bug report be re-assessed?
 To: "[hidden email]" <[hidden email]>
 Cc: "Gramps users" <[hidden email]>, "John Kitz" <[hidden email]>
 Date: Tuesday, February 20, 2018, 7:38 AM
 
 Hi Brian
 
 Reading your 'bug' submittal it is
 actually a Feature Request.
 
 Bugs are reports that the code is not doing
 what is advertised or
 expected. You are
 seeking the code to do something different, a new
 Feature Request.
 
 An earlier 'bug' fix on the place list
 resulted in all lists being
 automatically
 expanded. A disaster especially for large databases. I
 like your idea that after a search and
 selecting a place, hitting
 'clear'
 should be able to keep the focus on the selected place so
 a
 further search of the nested places below
 the parent place can be
 done.
 
 Dave
 
 
 
 On Tue, Feb 20, 2018 at
 6:32 AM, Emyoulation--- via Gramps-users
 <[hidden email]>
 wrote:
 > I posted a bug report and it was
 re-categorised as a "feature" rather than a bug.
 Can I ask for a re-assessment?
 >
 > The bug is that identical interface for
 the same functionality in 2 spots of the program (a button
 action for the search filter in the grouped/nested Places
 view) gives different results.
 >
 > The differing behaviors indicates that :
 1) there is redundant code; and 2) it is out of sync.
 >
 > The reason that this
 is important is that inconsistency of interface without a
 visual cue undermines confidence
 >
 > Was my offering an opinion on which
 behavior was preferable inappropriate? It seems that the
 opinion is why it might be deemed a "feature"
 rather than a bug. Or should I have been more explicit that
 the bug was out-of-sync redundant code rather than the
 functionality?
 >
 >
 Reference:
 > 0010421: Place
 'Find' behavior
 > Summary: the
 action of "Clear" button in the find
 Nested/Grouped Places list gives differing results (when
 adding a Place to an Event versus when in the main Places
 panel.)
 >
 > -Brian
 >
 >
 ------------------------------------------------------------------------------
 > Check out the vibrant tech community on
 one of the world's most
 > engaging
 tech sites, Slashdot.org! http://sdm.link/slashdot
 >
 _______________________________________________
 > Gramps-users mailing list
 > [hidden email]
 > https://lists.sourceforge.net/lists/listinfo/gramps-users
 > https://gramps-project.org

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

Re: Can I request that a Gramps bug report be re-assessed?

prculley
In reply to this post by GRAMPS - User mailing list
Sam marked this as a feature request, as nothing is actively broken (for once).  I agree that this is inconsistent, and perhaps someone will try to correct the situation in the future, but it will definitely be a lower priority than actual bugs.

You can add this email info as a comment on the bug tracker for this bug, which will push it back up to the front of the line.

Paul C.

On Tue, Feb 20, 2018 at 5:32 AM, Emyoulation--- via Gramps-users <[hidden email]> wrote:
I posted a bug report and it was re-categorised as a "feature" rather than a bug. Can I ask for a re-assessment?

The bug is that identical interface for the same functionality in 2 spots of the program (a button action for the search filter in the grouped/nested Places view) gives different results.

The differing behaviors indicates that : 1) there is redundant code; and 2) it is out of sync.

The reason that this is important is that inconsistency of interface without a visual cue undermines confidence

Was my offering an opinion on which behavior was preferable inappropriate? It seems that the opinion is why it might be deemed a "feature" rather than a bug. Or should I have been more explicit that the bug was out-of-sync redundant code rather than the functionality?

Reference:
0010421: Place 'Find' behavior
Summary: the action of "Clear" button in the find Nested/Grouped Places list gives differing results (when adding a Place to an Event versus when in the main Places panel.)

-Brian

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


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

Re: Can I request that a Gramps bug report be re-assessed?

GRAMPS - User mailing list
In reply to this post by GRAMPS - User mailing list
Thanks Paul.

When I was managing a bug list for commercial software (in the Dark Ages of preprocessing, compiling, assembling, linking), anything that was unsponsored & put onto the 'feature' list was condemned to oblivion.

The only way it could be redeemed was if Marketing team decided the item was sellable. Is it the same with Gramps? (Of course, Gramps has no Marketing path to redemption.)

I was thinking this falls in the Tweak (or Trivial) severity with Low priority.

Brian

--------------------------------------------
On Tue, 2/20/18, Paul Culley <[hidden email]> wrote:

 Subject: Re: [Gramps-users] Can I request that a Gramps bug report be re-assessed?
 To: "[hidden email]" <[hidden email]>
 Cc: "gramps-users" <[hidden email]>, "John W. Kitz" <[hidden email]>
 Date: Tuesday, February 20, 2018, 9:18 AM
 
 Sam marked this as a feature request, as
 nothing is actively broken (for once).  I agree that this
 is inconsistent, and perhaps someone will try to correct the
 situation in the future, but it will definitely be a lower
 priority than actual bugs.
 
 You can add this email info as a comment
 on the bug tracker for this bug, which will push it back up
 to the front of the line.
 
 Paul C.
 
 On Tue, Feb 20, 2018 at
 5:32 AM, Emyoulation--- via Gramps-users <[hidden email]>
 wrote:
 I posted
 a bug report and it was re-categorised as a
 "feature" rather than a bug. Can I ask for a
 re-assessment?
 
 
 
 The bug is that identical interface for the same
 functionality in 2 spots of the program (a button action for
 the search filter in the grouped/nested Places view) gives
 different results.
 
 
 
 The differing behaviors indicates that : 1) there is
 redundant code; and 2) it is out of sync.
 
 
 
 The reason that this is important is that inconsistency of
 interface without a visual cue undermines confidence
 
 
 
 Was my offering an opinion on which behavior was preferable
 inappropriate? It seems that the opinion is why it might be
 deemed a "feature" rather than a bug. Or should I
 have been more explicit that the bug was out-of-sync
 redundant code rather than the functionality?
 
 
 
 Reference:
 
 0010421: Place 'Find' behavior
 
 Summary: the action of "Clear" button in the find
 Nested/Grouped Places list gives differing results (when
 adding a Place to an Event versus when in the main Places
 panel.)
 
 
 
 -Brian
 
 
 
 ------------------------------
 ------------------------------ ------------------
 
 Check out the vibrant tech community on one of the
 world's most
 
 engaging tech sites, Slashdot.org! http://sdm.link/slashdot
 
 ______________________________ _________________
 
 Gramps-users mailing list
 
 Gramps-users@lists.
 sourceforge.net
 
 https://lists.sourceforge.net/
 lists/listinfo/gramps-users
 
 https://gramps-project.org
 
 
 

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

Re: Can I request that a Gramps bug report be re-assessed?

Nick Hall
In reply to this post by GRAMPS - User mailing list
On 20/02/18 11:32, Emyoulation--- via Gramps-users wrote:
> Was my offering an opinion on which behavior was preferable inappropriate? It seems that the opinion is why it might be deemed a "feature" rather than a bug. Or should I have been more explicit that the bug was out-of-sync redundant code rather than the functionality?
>
> Reference:
> 0010421: Place 'Find' behavior
> Summary: the action of "Clear" button in the find Nested/Grouped Places list gives differing results (when adding a Place to an Event versus when in the main Places panel.)

This lies in a grey area somewhere between a bug and a feature request.

Views and selectors share the same data model, but their interfaces
differ slightly.  Clicking on a row in a view will change the active
object.  The view will then select the row that corresponds to the
active object.  Views and gramplets will respond to a change of active
object, selectors will not.

Try opening the example database and filtering on the place name
"fair".  You will get 4 results.  Now select two of these rows and click
"Clear".  Only the active object will remain selected and the tree
expanded so that it is visible.

Your feature request is perfectly valid.  I can see why this
functionality would be useful, for example when selecting a building in
a town when you forget the exact street number.

However, as Dave pointed out, I made a mistake in the past by
implementing a feature request in a maintenance branch.  Although some
people liked the change, others didn't and it also had a performance
impact.  I ended up reverting the commit.

Regards,


Nick.


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