From: Benny M. <ben...@gm...> - 2010-05-17 08:32:16
|
2010/5/12 Gerald Britton <ger...@gm...> On Wed, May 12, 2010 at 11:32 AM, jerome <rom...@ya...> wrote: > >> > There has been confusion over this issue. In fact I > >> have just found a > >> > bug in that the living proxy only used the data > >> available in the > >> > living proxy. It should be the case that we use the > >> full knowledge of > >> > the database, and not limit that to just what is > >> available via the > >> > proxy. > >> > >> No that is not correct. Each proxy access the > >> database through the > >> method given to it (which may be another proxy). > >> Also, each proxy > >> acts as if it is the entire world. So it makes sense > >> that the living > >> proxy uses its internal logic to access the data. > > > > Maybe case like this one : > > > > Can proxy.living returns/hides a spouse/child/parent of handle.private if > database = gen.proxy.PrivateProxyDb(database) > > > > Code is no more looking at complete database for matching entries (same > problem with filters) > > That is the way the proxy system is designed. They operate as if they > own the world but their view of the world may be limited by upstream > proxies. I believe that this is a good design that we should not > change. We can introduce options to specify the order of the proxies, > but since there are currently four of them, there are 4! combinations. > Talk about confusing the user! > > The same thing is done for filters when you use the rule "people > matching filter x." If that is the first rule in a new filter "y", > then the other rules in "y" will only see records that pass filter > "x". The beauty here is that you can reverse the rules so the "people > matching filter" rule comes last. You have the flexibility to put it > together to get the results you want. > > I agree here. There is no bug in the proxie databases, they work as they should. The proxies are not commutative however according to Doug, first filter, then private is different from first private then filter proxie (see the descendant of and then private versus private then descendant). Thinking about this, this seems indeed strange, as Gerald indicates, they should return the same result... The change of Doug means private is applied last. There is no real reasoning on why one or the other should be first, ..., well, perhaps there is? If they really are not commutative, I think the order should be in the way that is most difficult (or impossible) to achieve via a normal filter setup. Benny |
From: Doug B. <dou...@gm...> - 2010-05-17 13:51:02
|
On Mon, May 17, 2010 at 4:32 AM, Benny Malengier <ben...@gm...> wrote: > 2010/5/12 Gerald Britton <ger...@gm...> [snip] >> The same thing is done for filters when you use the rule "people >> matching filter x." If that is the first rule in a new filter "y", >> then the other rules in "y" will only see records that pass filter >> "x". The beauty here is that you can reverse the rules so the "people >> matching filter" rule comes last. You have the flexibility to put it >> together to get the results you want. >> > > I agree here. There is no bug in the proxie databases, they work as they > should. Yes, I agree that there is no bug in the proxies, nor in the filters. I've been continuing to play with proxies and filters, and I'm not sure that just changing the order is the right thing to do. But we all have to at least agree on what the issues are. > The proxies are not commutative however according to Doug, first filter, > then private is different from first private then filter proxie (see the > descendant of and then private versus private then descendant). Thinking > about this, this seems indeed strange, as Gerald indicates, they should > return the same result... This is easy to see that Filters/Proxies are not commutative: Consider a database with three people: Person A who has a son, Person B. Person B also has a son, Person C. Now mark Person B as private. If you apply the Private proxy first, then you effectively remove Person B from the database, and you will not find any connection between Person A and Person C. Thus, any filter that looks for a relationship between A and C will not find one. Descendants of A will not include C. This is how Gramps has worked for the last few years, when you export with a Private Proxy. On the other hand, if you do not apply the Private proxy first, there is no easy way to hide that relationship from the filters. You can try to make selections based on one's Private status, but that isn't considered when, for example, looking for descendants or ancestors. So, the first thing to realize is that filter-then-proxy is not guaranteed to be the same as proxy-then-filter. They are not commutative. The next thing to realize is that sometimes one may want to use private people in a filter, before having them removed. Thus, always applying the private proxy first may have effects on the filter that you may not realize, until you run an export. The final thing to realize is that a private filter does not take the place of the private proxy. Using a private filter only looks at a single person. Combining a private filter with, say, a descendant filter does not have any effect on limiting who is a descendant. As far as I can see, filters are commutative, and thus cannot be used to replace a proxy. > The change of Doug means private is applied last. There is no real reasoning > on why one or the other should be first, ..., well, perhaps there is? If > they really are not commutative, I think the order should be in the way that > is most difficult (or impossible) to achieve via a normal filter setup. If Benny's criteria is used, then the way that Gramps is now is the correct way: there is no easy way (that I see) to remove Person B (private) and Person C (public descendant) using just filters. On the other hand, selecting the proxy first can remove people that were important in constructing a filter, and a user might not notice until the export has been made, and then verified by examining what was exported. So what to do? I see four possibilities: 1) Leave as it is, Proxies first. To avoid having a Private proxy have adverse affects, a user can opt to not use the proxy, and use a private filter. I believe that a private filter is equivalent to a private proxy last. But this method causes confusion, even among long-time users (and developers) for why an exported group is what it is. 2) Change to proxies last. This is too limiting---users don't have the power that they need with just filters. 3) Allow each proxy to be applied before or after. Users would need to know the implications. However, this is still confusing and hard to verify. 4) Allow proxies to be used as a filter. I have no idea how this might work, but it would allow users to verify the selection and final output. The ideal would be option 4, but this might be hard or impossible, but should be explored. Option 3 is easier than 1 for the user, covers all known use-cases, but is still hard to verify. Option 2, I think, is out because it makes Gramps less powerful. Option 1 prevents some known use-cases. -Doug > Benny |
From: Gerald B. <ger...@gm...> - 2010-05-17 14:05:45
|
On Mon, May 17, 2010 at 8:22 AM, Doug Blank <dou...@gm...> wrote: > On Mon, May 17, 2010 at 4:32 AM, Benny Malengier > <ben...@gm...> wrote: >> 2010/5/12 Gerald Britton <ger...@gm...> > > [snip] > >>> The same thing is done for filters when you use the rule "people >>> matching filter x." If that is the first rule in a new filter "y", >>> then the other rules in "y" will only see records that pass filter >>> "x". The beauty here is that you can reverse the rules so the "people >>> matching filter" rule comes last. You have the flexibility to put it >>> together to get the results you want. >>> >> >> I agree here. There is no bug in the proxie databases, they work as they >> should. > > Yes, I agree that there is no bug in the proxies, nor in the filters. > > I've been continuing to play with proxies and filters, and I'm not > sure that just changing the order is the right thing to do. But we all > have to at least agree on what the issues are. > >> The proxies are not commutative however according to Doug, first filter, >> then private is different from first private then filter proxie (see the >> descendant of and then private versus private then descendant). Thinking >> about this, this seems indeed strange, as Gerald indicates, they should >> return the same result... > > This is easy to see that Filters/Proxies are not commutative: Consider > a database with three people: Person A who has a son, Person B. Person > B also has a son, Person C. Now mark Person B as private. > > If you apply the Private proxy first, then you effectively remove > Person B from the database, and you will not find any connection > between Person A and Person C. Thus, any filter that looks for a > relationship between A and C will not find one. Descendants of A will > not include C. This is how Gramps has worked for the last few years, > when you export with a Private Proxy. > > On the other hand, if you do not apply the Private proxy first, there > is no easy way to hide that relationship from the filters. You can try > to make selections based on one's Private status, but that isn't > considered when, for example, looking for descendants or ancestors. > > So, the first thing to realize is that filter-then-proxy is not > guaranteed to be the same as proxy-then-filter. They are not > commutative. > > The next thing to realize is that sometimes one may want to use > private people in a filter, before having them removed. Thus, always > applying the private proxy first may have effects on the filter that > you may not realize, until you run an export. > > The final thing to realize is that a private filter does not take the > place of the private proxy. Using a private filter only looks at a > single person. Combining a private filter with, say, a descendant > filter does not have any effect on limiting who is a descendant. As > far as I can see, filters are commutative, and thus cannot be used to > replace a proxy. > >> The change of Doug means private is applied last. There is no real reasoning >> on why one or the other should be first, ..., well, perhaps there is? If >> they really are not commutative, I think the order should be in the way that >> is most difficult (or impossible) to achieve via a normal filter setup. > > If Benny's criteria is used, then the way that Gramps is now is the > correct way: there is no easy way (that I see) to remove Person B > (private) and Person C (public descendant) using just filters. > > On the other hand, selecting the proxy first can remove people that > were important in constructing a filter, and a user might not notice > until the export has been made, and then verified by examining what > was exported. > > So what to do? I see four possibilities: > > 1) Leave as it is, Proxies first. To avoid having a Private proxy have > adverse affects, a user can opt to not use the proxy, and use a > private filter. I believe that a private filter is equivalent to a > private proxy last. But this method causes confusion, even among > long-time users (and developers) for why an exported group is what it > is. > > 2) Change to proxies last. This is too limiting---users don't have the > power that they need with just filters. > > 3) Allow each proxy to be applied before or after. Users would need to > know the implications. However, this is still confusing and hard to > verify. > > 4) Allow proxies to be used as a filter. I have no idea how this might > work, but it would allow users to verify the selection and final > output. Do you mean, "allow the logic of the proxies to be used in pre-defined filters"? If so, I can see the value in that, though the "private" proxy goes well beyond filtering. I would not like to see the actual modules available for use as filters, since that would likely require logic to be added to them of the sort: if I am a proxy: do this else: do that or would require the caller to be knowledgeable of the implementation proxy, which can lead to maintenance headaches. Also, the filter proxy already uses filters, so that would be redundant I suppose. > > The ideal would be option 4, but this might be hard or impossible, but > should be explored. Option 3 is easier than 1 for the user, covers all > known use-cases, but is still hard to verify. Option 2, I think, is > out because it makes Gramps less powerful. Option 1 prevents some > known use-cases. > > -Doug > >> Benny > > ------------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -- Gerald Britton |
From: Doug B. <dou...@gm...> - 2010-05-17 18:42:42
|
On Mon, May 17, 2010 at 10:05 AM, Gerald Britton <ger...@gm...> wrote: > On Mon, May 17, 2010 at 8:22 AM, Doug Blank <dou...@gm...> wrote: >> On Mon, May 17, 2010 at 4:32 AM, Benny Malengier >> <ben...@gm...> wrote: >>> 2010/5/12 Gerald Britton <ger...@gm...> >> >> [snip] >> >>>> The same thing is done for filters when you use the rule "people >>>> matching filter x." If that is the first rule in a new filter "y", >>>> then the other rules in "y" will only see records that pass filter >>>> "x". The beauty here is that you can reverse the rules so the "people >>>> matching filter" rule comes last. You have the flexibility to put it >>>> together to get the results you want. >>>> >>> >>> I agree here. There is no bug in the proxie databases, they work as they >>> should. >> >> Yes, I agree that there is no bug in the proxies, nor in the filters. >> >> I've been continuing to play with proxies and filters, and I'm not >> sure that just changing the order is the right thing to do. But we all >> have to at least agree on what the issues are. >> >>> The proxies are not commutative however according to Doug, first filter, >>> then private is different from first private then filter proxie (see the >>> descendant of and then private versus private then descendant). Thinking >>> about this, this seems indeed strange, as Gerald indicates, they should >>> return the same result... >> >> This is easy to see that Filters/Proxies are not commutative: Consider >> a database with three people: Person A who has a son, Person B. Person >> B also has a son, Person C. Now mark Person B as private. >> >> If you apply the Private proxy first, then you effectively remove >> Person B from the database, and you will not find any connection >> between Person A and Person C. Thus, any filter that looks for a >> relationship between A and C will not find one. Descendants of A will >> not include C. This is how Gramps has worked for the last few years, >> when you export with a Private Proxy. >> >> On the other hand, if you do not apply the Private proxy first, there >> is no easy way to hide that relationship from the filters. You can try >> to make selections based on one's Private status, but that isn't >> considered when, for example, looking for descendants or ancestors. >> >> So, the first thing to realize is that filter-then-proxy is not >> guaranteed to be the same as proxy-then-filter. They are not >> commutative. >> >> The next thing to realize is that sometimes one may want to use >> private people in a filter, before having them removed. Thus, always >> applying the private proxy first may have effects on the filter that >> you may not realize, until you run an export. >> >> The final thing to realize is that a private filter does not take the >> place of the private proxy. Using a private filter only looks at a >> single person. Combining a private filter with, say, a descendant >> filter does not have any effect on limiting who is a descendant. As >> far as I can see, filters are commutative, and thus cannot be used to >> replace a proxy. >> >>> The change of Doug means private is applied last. There is no real reasoning >>> on why one or the other should be first, ..., well, perhaps there is? If >>> they really are not commutative, I think the order should be in the way that >>> is most difficult (or impossible) to achieve via a normal filter setup. >> >> If Benny's criteria is used, then the way that Gramps is now is the >> correct way: there is no easy way (that I see) to remove Person B >> (private) and Person C (public descendant) using just filters. >> >> On the other hand, selecting the proxy first can remove people that >> were important in constructing a filter, and a user might not notice >> until the export has been made, and then verified by examining what >> was exported. >> >> So what to do? I see four possibilities: >> >> 1) Leave as it is, Proxies first. To avoid having a Private proxy have >> adverse affects, a user can opt to not use the proxy, and use a >> private filter. I believe that a private filter is equivalent to a >> private proxy last. But this method causes confusion, even among >> long-time users (and developers) for why an exported group is what it >> is. >> >> 2) Change to proxies last. This is too limiting---users don't have the >> power that they need with just filters. >> >> 3) Allow each proxy to be applied before or after. Users would need to >> know the implications. However, this is still confusing and hard to >> verify. >> >> 4) Allow proxies to be used as a filter. I have no idea how this might >> work, but it would allow users to verify the selection and final >> output. > > Do you mean, "allow the logic of the proxies to be used in pre-defined > filters"? If so, I can see the value in that, though the "private" > proxy goes well beyond filtering. To understand the proposed option 4, "allow proxies to be used as a filter" one needs to appreciate that the three non-filter based proxies (Private, Living, and Note) are more powerful than user-constructed filters. That is, they alter what is accessible. For example, no combination of filters will prevent you from being able to select the children of a private person in a descendant filter. Only a proxy can do that. What I am suggesting is some manner to put the power of the proxy into the hands of the user, so that they can mix proxies between/before/after filters. This does two things: 1) it allows users to interactively and easily inspect their application of proxies and filters to check for correctness (without having to export and then import), and 2) it gives users the most control over when and how the proxies get applied. Having thoroughly examined the two use-cases in this thread (Jerome's and Benny's) we can get by with our current sequence (proxies before filters). Benny's example is the default behavior when applying the Private proxy (eg, block access to children of private people when combined with a descendant filter). Jerome can get exactly what he wants (I think) by writing a more complicated filter. The easiest way to construct Jerome's filter is with three filters, and no proxies: 1) not an ancestor of X filter 2) not private filter 3) mark "all rules must apply" This can also be accomplished with one filter, 2 rules: 1) an ancestor of X rule 2) private rule 3) mark "at least one rule must apply" 4) mark "those that do not match" BTW, Jerome's selection could also be done perhaps easier if we had the ability to add the "not" to each rule rather than to the entire filter selection. For example, one could select: 1) not ancestors of X rule 2) not private rule 3) mark "all rules must apply" What does not work in this case is to select "not ancestor of X" filter with the Private proxy (as it is applied first), as that messes up the ancestors (because it happens to have a private person in the ancestor chain). This suggests Option 3, where Jerome could have gotten the output he wanted with a "not ancestor of X" with the Private proxy applied last. > I would not like to see the actual > modules available for use as filters, since that would likely require > logic to be added to them of the sort: > > if I am a proxy: > do this > else: > do that > > or would require the caller to be knowledgeable of the implementation > proxy, which can lead to maintenance headaches. Yeah, I can't see how we could mix proxies and filters together, other than having an interface like we do in export---allowing one to select the proxies and their ordering. One could do that in the filter sidebar... seeing as that would be complicated (and I have no interest in doing it) perhaps we can slightly tweak the export to do two fairly simple things: 1) allow proxies to be applied before/after the filter 2) right before the actual export, the display could show who would be selected These two things would go some distance to making the export more user friendly. It doesn't allow all use-cases (I can think of some, but they are not uses that people are asking for). -Doug > Also, the filter proxy already uses filters, so that would be > redundant I suppose. > > >> >> The ideal would be option 4, but this might be hard or impossible, but >> should be explored. Option 3 is easier than 1 for the user, covers all >> known use-cases, but is still hard to verify. Option 2, I think, is >> out because it makes Gramps less powerful. Option 1 prevents some >> known use-cases. >> >> -Doug >> >>> Benny >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > > > -- > Gerald Britton > |
From: Gerald B. <ger...@gm...> - 2010-05-17 19:26:18
|
On Mon, May 17, 2010 at 2:42 PM, Doug Blank <dou...@gm...> wrote: > On Mon, May 17, 2010 at 10:05 AM, Gerald Britton > <ger...@gm...> wrote: >> On Mon, May 17, 2010 at 8:22 AM, Doug Blank <dou...@gm...> wrote: >>> On Mon, May 17, 2010 at 4:32 AM, Benny Malengier >>> <ben...@gm...> wrote: >>>> 2010/5/12 Gerald Britton <ger...@gm...> >>> >>> [snip] >>> >>>>> The same thing is done for filters when you use the rule "people >>>>> matching filter x." If that is the first rule in a new filter "y", >>>>> then the other rules in "y" will only see records that pass filter >>>>> "x". The beauty here is that you can reverse the rules so the "people >>>>> matching filter" rule comes last. You have the flexibility to put it >>>>> together to get the results you want. >>>>> >>>> >>>> I agree here. There is no bug in the proxie databases, they work as they >>>> should. >>> >>> Yes, I agree that there is no bug in the proxies, nor in the filters. >>> >>> I've been continuing to play with proxies and filters, and I'm not >>> sure that just changing the order is the right thing to do. But we all >>> have to at least agree on what the issues are. >>> >>>> The proxies are not commutative however according to Doug, first filter, >>>> then private is different from first private then filter proxie (see the >>>> descendant of and then private versus private then descendant). Thinking >>>> about this, this seems indeed strange, as Gerald indicates, they should >>>> return the same result... >>> >>> This is easy to see that Filters/Proxies are not commutative: Consider >>> a database with three people: Person A who has a son, Person B. Person >>> B also has a son, Person C. Now mark Person B as private. >>> >>> If you apply the Private proxy first, then you effectively remove >>> Person B from the database, and you will not find any connection >>> between Person A and Person C. Thus, any filter that looks for a >>> relationship between A and C will not find one. Descendants of A will >>> not include C. This is how Gramps has worked for the last few years, >>> when you export with a Private Proxy. >>> >>> On the other hand, if you do not apply the Private proxy first, there >>> is no easy way to hide that relationship from the filters. You can try >>> to make selections based on one's Private status, but that isn't >>> considered when, for example, looking for descendants or ancestors. >>> >>> So, the first thing to realize is that filter-then-proxy is not >>> guaranteed to be the same as proxy-then-filter. They are not >>> commutative. >>> >>> The next thing to realize is that sometimes one may want to use >>> private people in a filter, before having them removed. Thus, always >>> applying the private proxy first may have effects on the filter that >>> you may not realize, until you run an export. >>> >>> The final thing to realize is that a private filter does not take the >>> place of the private proxy. Using a private filter only looks at a >>> single person. Combining a private filter with, say, a descendant >>> filter does not have any effect on limiting who is a descendant. As >>> far as I can see, filters are commutative, and thus cannot be used to >>> replace a proxy. >>> >>>> The change of Doug means private is applied last. There is no real reasoning >>>> on why one or the other should be first, ..., well, perhaps there is? If >>>> they really are not commutative, I think the order should be in the way that >>>> is most difficult (or impossible) to achieve via a normal filter setup. >>> >>> If Benny's criteria is used, then the way that Gramps is now is the >>> correct way: there is no easy way (that I see) to remove Person B >>> (private) and Person C (public descendant) using just filters. >>> >>> On the other hand, selecting the proxy first can remove people that >>> were important in constructing a filter, and a user might not notice >>> until the export has been made, and then verified by examining what >>> was exported. >>> >>> So what to do? I see four possibilities: >>> >>> 1) Leave as it is, Proxies first. To avoid having a Private proxy have >>> adverse affects, a user can opt to not use the proxy, and use a >>> private filter. I believe that a private filter is equivalent to a >>> private proxy last. But this method causes confusion, even among >>> long-time users (and developers) for why an exported group is what it >>> is. >>> >>> 2) Change to proxies last. This is too limiting---users don't have the >>> power that they need with just filters. >>> >>> 3) Allow each proxy to be applied before or after. Users would need to >>> know the implications. However, this is still confusing and hard to >>> verify. >>> >>> 4) Allow proxies to be used as a filter. I have no idea how this might >>> work, but it would allow users to verify the selection and final >>> output. >> >> Do you mean, "allow the logic of the proxies to be used in pre-defined >> filters"? If so, I can see the value in that, though the "private" >> proxy goes well beyond filtering. > > To understand the proposed option 4, "allow proxies to be used as a > filter" one needs to appreciate that the three non-filter based > proxies (Private, Living, and Note) are more powerful than > user-constructed filters. That is, they alter what is accessible. For > example, no combination of filters will prevent you from being able to > select the children of a private person in a descendant filter. Only a > proxy can do that. > > What I am suggesting is some manner to put the power of the proxy into > the hands of the user, so that they can mix proxies > between/before/after filters. This does two things: 1) it allows users > to interactively and easily inspect their application of proxies and > filters to check for correctness (without having to export and then > import), and 2) it gives users the most control over when and how the > proxies get applied. > > Having thoroughly examined the two use-cases in this thread (Jerome's > and Benny's) we can get by with our current sequence (proxies before > filters). Benny's example is the default behavior when applying the > Private proxy (eg, block access to children of private people when > combined with a descendant filter). Jerome can get exactly what he > wants (I think) by writing a more complicated filter. The easiest way > to construct Jerome's filter is with three filters, and no proxies: > > 1) not an ancestor of X filter > 2) not private filter > 3) mark "all rules must apply" > > This can also be accomplished with one filter, 2 rules: > > 1) an ancestor of X rule > 2) private rule > 3) mark "at least one rule must apply" > 4) mark "those that do not match" > > BTW, Jerome's selection could also be done perhaps easier if we had > the ability to add the "not" to each rule rather than to the entire > filter selection. For example, one could select: > > 1) not ancestors of X rule > 2) not private rule > 3) mark "all rules must apply" > > What does not work in this case is to select "not ancestor of X" > filter with the Private proxy (as it is applied first), as that messes > up the ancestors (because it happens to have a private person in the > ancestor chain). > > This suggests Option 3, where Jerome could have gotten the output he > wanted with a "not ancestor of X" with the Private proxy applied last. > >> I would not like to see the actual >> modules available for use as filters, since that would likely require >> logic to be added to them of the sort: >> >> if I am a proxy: >> do this >> else: >> do that >> >> or would require the caller to be knowledgeable of the implementation >> proxy, which can lead to maintenance headaches. > > Yeah, I can't see how we could mix proxies and filters together, other > than having an interface like we do in export---allowing one to select > the proxies and their ordering. One could do that in the filter > sidebar... seeing as that would be complicated (and I have no interest > in doing it) perhaps we can slightly tweak the export to do two fairly > simple things: > > 1) allow proxies to be applied before/after the filter The thing is, proxies are not really applied. They are like SQL views. e.g. -- define a view to restrict access to public data create view proxydb as select * from db where private <> TRUE; followed by: -- get data for report with optional filter select * from proxydb where <filter condition, possibly involving subqueries> ; The view controls what the main select statement sees. You can have multiple views chained together. However, if I understand your proposal, it would be to make the order of the views user-definable. I can see how that would empower different use cases. I'm just worried about how to present this to the user to make it obvious and unambiguous. > 2) right before the actual export, the display could show who would be selected Do you mean, should our default action be something like this: select * from (select * from (select * from (select * from (select * from db where <filter condition>) as filtered where <referenced>) as referenced where NOT <living>) as not_living where NOT <private>) as proxydb; ? Perhaps that is indeed correct. However, that means that every plugin (report, export, whatever) that can use proxies would have to change to enforce this ordering. Maybe we need a meta-proxy that takes in the desired proxies and filters and enforces this order. Even so, could it not be that some report might go through all that and then add further conditions that would depend on some data that had been filtered out? I suppose that, in such a case, it would be better not to use proxies at all. > > These two things would go some distance to making the export more user > friendly. It doesn't allow all use-cases (I can think of some, but > they are not uses that people are asking for). > > -Doug > >> Also, the filter proxy already uses filters, so that would be >> redundant I suppose. >> >> >>> >>> The ideal would be option 4, but this might be hard or impossible, but >>> should be explored. Option 3 is easier than 1 for the user, covers all >>> known use-cases, but is still hard to verify. Option 2, I think, is >>> out because it makes Gramps less powerful. Option 1 prevents some >>> known use-cases. >>> >>> -Doug >>> >>>> Benny >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >> >> >> >> -- >> Gerald Britton >> > -- Gerald Britton |
From: Benny M. <ben...@gm...> - 2010-05-18 07:10:34
|
2010/5/17 Doug Blank <dou...@gm...> > On Mon, May 17, 2010 at 10:05 AM, Gerald Britton > <ger...@gm...> wrote: > > On Mon, May 17, 2010 at 8:22 AM, Doug Blank <dou...@gm...> > wrote: > >> On Mon, May 17, 2010 at 4:32 AM, Benny Malengier > >> <ben...@gm...> wrote: > >>> 2010/5/12 Gerald Britton <ger...@gm...> > >> > >> [snip] > >> > >>>> The same thing is done for filters when you use the rule "people > >>>> matching filter x." If that is the first rule in a new filter "y", > >>>> then the other rules in "y" will only see records that pass filter > >>>> "x". The beauty here is that you can reverse the rules so the "people > >>>> matching filter" rule comes last. You have the flexibility to put it > >>>> together to get the results you want. > >>>> > >>> > >>> I agree here. There is no bug in the proxie databases, they work as > they > >>> should. > >> > >> Yes, I agree that there is no bug in the proxies, nor in the filters. > >> > >> I've been continuing to play with proxies and filters, and I'm not > >> sure that just changing the order is the right thing to do. But we all > >> have to at least agree on what the issues are. > >> > >>> The proxies are not commutative however according to Doug, first > filter, > >>> then private is different from first private then filter proxie (see > the > >>> descendant of and then private versus private then descendant). > Thinking > >>> about this, this seems indeed strange, as Gerald indicates, they should > >>> return the same result... > >> > >> This is easy to see that Filters/Proxies are not commutative: Consider > >> a database with three people: Person A who has a son, Person B. Person > >> B also has a son, Person C. Now mark Person B as private. > >> > >> If you apply the Private proxy first, then you effectively remove > >> Person B from the database, and you will not find any connection > >> between Person A and Person C. Thus, any filter that looks for a > >> relationship between A and C will not find one. Descendants of A will > >> not include C. This is how Gramps has worked for the last few years, > >> when you export with a Private Proxy. > >> > >> On the other hand, if you do not apply the Private proxy first, there > >> is no easy way to hide that relationship from the filters. You can try > >> to make selections based on one's Private status, but that isn't > >> considered when, for example, looking for descendants or ancestors. > >> > >> So, the first thing to realize is that filter-then-proxy is not > >> guaranteed to be the same as proxy-then-filter. They are not > >> commutative. > >> > >> The next thing to realize is that sometimes one may want to use > >> private people in a filter, before having them removed. Thus, always > >> applying the private proxy first may have effects on the filter that > >> you may not realize, until you run an export. > >> > >> The final thing to realize is that a private filter does not take the > >> place of the private proxy. Using a private filter only looks at a > >> single person. Combining a private filter with, say, a descendant > >> filter does not have any effect on limiting who is a descendant. As > >> far as I can see, filters are commutative, and thus cannot be used to > >> replace a proxy. > >> > >>> The change of Doug means private is applied last. There is no real > reasoning > >>> on why one or the other should be first, ..., well, perhaps there is? > If > >>> they really are not commutative, I think the order should be in the way > that > >>> is most difficult (or impossible) to achieve via a normal filter setup. > >> > >> If Benny's criteria is used, then the way that Gramps is now is the > >> correct way: there is no easy way (that I see) to remove Person B > >> (private) and Person C (public descendant) using just filters. > >> > >> On the other hand, selecting the proxy first can remove people that > >> were important in constructing a filter, and a user might not notice > >> until the export has been made, and then verified by examining what > >> was exported. > >> > >> So what to do? I see four possibilities: > >> > >> 1) Leave as it is, Proxies first. To avoid having a Private proxy have > >> adverse affects, a user can opt to not use the proxy, and use a > >> private filter. I believe that a private filter is equivalent to a > >> private proxy last. But this method causes confusion, even among > >> long-time users (and developers) for why an exported group is what it > >> is. > >> > >> 2) Change to proxies last. This is too limiting---users don't have the > >> power that they need with just filters. > >> > >> 3) Allow each proxy to be applied before or after. Users would need to > >> know the implications. However, this is still confusing and hard to > >> verify. > >> > >> 4) Allow proxies to be used as a filter. I have no idea how this might > >> work, but it would allow users to verify the selection and final > >> output. > > > > Do you mean, "allow the logic of the proxies to be used in pre-defined > > filters"? If so, I can see the value in that, though the "private" > > proxy goes well beyond filtering. > > To understand the proposed option 4, "allow proxies to be used as a > filter" one needs to appreciate that the three non-filter based > proxies (Private, Living, and Note) are more powerful than > user-constructed filters. That is, they alter what is accessible. For > example, no combination of filters will prevent you from being able to > select the children of a private person in a descendant filter. Only a > proxy can do that. > > What I am suggesting is some manner to put the power of the proxy into > the hands of the user, so that they can mix proxies > between/before/after filters. This does two things: 1) it allows users > to interactively and easily inspect their application of proxies and > filters to check for correctness (without having to export and then > import), and 2) it gives users the most control over when and how the > proxies get applied. > > Having thoroughly examined the two use-cases in this thread (Jerome's > and Benny's) we can get by with our current sequence (proxies before > filters). Benny's example is the default behavior when applying the > Private proxy (eg, block access to children of private people when > combined with a descendant filter). Jerome can get exactly what he > wants (I think) by writing a more complicated filter. The easiest way > to construct Jerome's filter is with three filters, and no proxies: > > 1) not an ancestor of X filter > 2) not private filter > 3) mark "all rules must apply" > > This can also be accomplished with one filter, 2 rules: > > 1) an ancestor of X rule > 2) private rule > 3) mark "at least one rule must apply" > 4) mark "those that do not match" > > BTW, Jerome's selection could also be done perhaps easier if we had > the ability to add the "not" to each rule rather than to the entire > filter selection. For example, one could select: > > 1) not ancestors of X rule > 2) not private rule > 3) mark "all rules must apply" > > What does not work in this case is to select "not ancestor of X" > filter with the Private proxy (as it is applied first), as that messes > up the ancestors (because it happens to have a private person in the > ancestor chain). > > This suggests Option 3, where Jerome could have gotten the output he > wanted with a "not ancestor of X" with the Private proxy applied last. > > > I would not like to see the actual > > modules available for use as filters, since that would likely require > > logic to be added to them of the sort: > > > > if I am a proxy: > > do this > > else: > > do that > > > > or would require the caller to be knowledgeable of the implementation > > proxy, which can lead to maintenance headaches. > > Yeah, I can't see how we could mix proxies and filters together, other > than having an interface like we do in export---allowing one to select > the proxies and their ordering. One could do that in the filter > sidebar... seeing as that would be complicated (and I have no interest > in doing it) perhaps we can slightly tweak the export to do two fairly > simple things: > > 1) allow proxies to be applied before/after the filter > 2) right before the actual export, the display could show who would be > selected > > These two things would go some distance to making the export more user > friendly. It doesn't allow all use-cases (I can think of some, but > they are not uses that people are asking for). > > -Doug > This tread is becoming difficult to follow :-) >From what I read, am I correct to assume you would undo the change in svn? So first private again, because the other behaviour can be obtained with filters? I agree with 1) above, but for users better to use another word (restricted view or so). For 2), more like a preview button, people with large databases would not like to wait to see the result. Benny > > > Also, the filter proxy already uses filters, so that would be > > redundant I suppose. > > > > > >> > >> The ideal would be option 4, but this might be hard or impossible, but > >> should be explored. Option 3 is easier than 1 for the user, covers all > >> known use-cases, but is still hard to verify. Option 2, I think, is > >> out because it makes Gramps less powerful. Option 1 prevents some > >> known use-cases. > >> > >> -Doug > >> > >>> Benny > >> > >> > ------------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Gramps-devel mailing list > >> Gra...@li... > >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > >> > > > > > > > > -- > > Gerald Britton > > > |
From: Doug B. <dou...@gm...> - 2010-05-18 10:37:48
|
On Tue, May 18, 2010 at 3:10 AM, Benny Malengier <ben...@gm...> wrote: > > > 2010/5/17 Doug Blank <dou...@gm...> >> >> On Mon, May 17, 2010 at 10:05 AM, Gerald Britton >> <ger...@gm...> wrote: >> > On Mon, May 17, 2010 at 8:22 AM, Doug Blank <dou...@gm...> >> > wrote: >> >> On Mon, May 17, 2010 at 4:32 AM, Benny Malengier >> >> <ben...@gm...> wrote: >> >>> 2010/5/12 Gerald Britton <ger...@gm...> >> >> >> >> [snip] >> >> >> >>>> The same thing is done for filters when you use the rule "people >> >>>> matching filter x." If that is the first rule in a new filter "y", >> >>>> then the other rules in "y" will only see records that pass filter >> >>>> "x". The beauty here is that you can reverse the rules so the >> >>>> "people >> >>>> matching filter" rule comes last. You have the flexibility to put it >> >>>> together to get the results you want. >> >>>> >> >>> >> >>> I agree here. There is no bug in the proxie databases, they work as >> >>> they >> >>> should. >> >> >> >> Yes, I agree that there is no bug in the proxies, nor in the filters. >> >> >> >> I've been continuing to play with proxies and filters, and I'm not >> >> sure that just changing the order is the right thing to do. But we all >> >> have to at least agree on what the issues are. >> >> >> >>> The proxies are not commutative however according to Doug, first >> >>> filter, >> >>> then private is different from first private then filter proxie (see >> >>> the >> >>> descendant of and then private versus private then descendant). >> >>> Thinking >> >>> about this, this seems indeed strange, as Gerald indicates, they >> >>> should >> >>> return the same result... >> >> >> >> This is easy to see that Filters/Proxies are not commutative: Consider >> >> a database with three people: Person A who has a son, Person B. Person >> >> B also has a son, Person C. Now mark Person B as private. >> >> >> >> If you apply the Private proxy first, then you effectively remove >> >> Person B from the database, and you will not find any connection >> >> between Person A and Person C. Thus, any filter that looks for a >> >> relationship between A and C will not find one. Descendants of A will >> >> not include C. This is how Gramps has worked for the last few years, >> >> when you export with a Private Proxy. >> >> >> >> On the other hand, if you do not apply the Private proxy first, there >> >> is no easy way to hide that relationship from the filters. You can try >> >> to make selections based on one's Private status, but that isn't >> >> considered when, for example, looking for descendants or ancestors. >> >> >> >> So, the first thing to realize is that filter-then-proxy is not >> >> guaranteed to be the same as proxy-then-filter. They are not >> >> commutative. >> >> >> >> The next thing to realize is that sometimes one may want to use >> >> private people in a filter, before having them removed. Thus, always >> >> applying the private proxy first may have effects on the filter that >> >> you may not realize, until you run an export. >> >> >> >> The final thing to realize is that a private filter does not take the >> >> place of the private proxy. Using a private filter only looks at a >> >> single person. Combining a private filter with, say, a descendant >> >> filter does not have any effect on limiting who is a descendant. As >> >> far as I can see, filters are commutative, and thus cannot be used to >> >> replace a proxy. >> >> >> >>> The change of Doug means private is applied last. There is no real >> >>> reasoning >> >>> on why one or the other should be first, ..., well, perhaps there is? >> >>> If >> >>> they really are not commutative, I think the order should be in the >> >>> way that >> >>> is most difficult (or impossible) to achieve via a normal filter >> >>> setup. >> >> >> >> If Benny's criteria is used, then the way that Gramps is now is the >> >> correct way: there is no easy way (that I see) to remove Person B >> >> (private) and Person C (public descendant) using just filters. >> >> >> >> On the other hand, selecting the proxy first can remove people that >> >> were important in constructing a filter, and a user might not notice >> >> until the export has been made, and then verified by examining what >> >> was exported. >> >> >> >> So what to do? I see four possibilities: >> >> >> >> 1) Leave as it is, Proxies first. To avoid having a Private proxy have >> >> adverse affects, a user can opt to not use the proxy, and use a >> >> private filter. I believe that a private filter is equivalent to a >> >> private proxy last. But this method causes confusion, even among >> >> long-time users (and developers) for why an exported group is what it >> >> is. >> >> >> >> 2) Change to proxies last. This is too limiting---users don't have the >> >> power that they need with just filters. >> >> >> >> 3) Allow each proxy to be applied before or after. Users would need to >> >> know the implications. However, this is still confusing and hard to >> >> verify. >> >> >> >> 4) Allow proxies to be used as a filter. I have no idea how this might >> >> work, but it would allow users to verify the selection and final >> >> output. >> > >> > Do you mean, "allow the logic of the proxies to be used in pre-defined >> > filters"? If so, I can see the value in that, though the "private" >> > proxy goes well beyond filtering. >> >> To understand the proposed option 4, "allow proxies to be used as a >> filter" one needs to appreciate that the three non-filter based >> proxies (Private, Living, and Note) are more powerful than >> user-constructed filters. That is, they alter what is accessible. For >> example, no combination of filters will prevent you from being able to >> select the children of a private person in a descendant filter. Only a >> proxy can do that. >> >> What I am suggesting is some manner to put the power of the proxy into >> the hands of the user, so that they can mix proxies >> between/before/after filters. This does two things: 1) it allows users >> to interactively and easily inspect their application of proxies and >> filters to check for correctness (without having to export and then >> import), and 2) it gives users the most control over when and how the >> proxies get applied. >> >> Having thoroughly examined the two use-cases in this thread (Jerome's >> and Benny's) we can get by with our current sequence (proxies before >> filters). Benny's example is the default behavior when applying the >> Private proxy (eg, block access to children of private people when >> combined with a descendant filter). Jerome can get exactly what he >> wants (I think) by writing a more complicated filter. The easiest way >> to construct Jerome's filter is with three filters, and no proxies: >> >> 1) not an ancestor of X filter >> 2) not private filter >> 3) mark "all rules must apply" >> >> This can also be accomplished with one filter, 2 rules: >> >> 1) an ancestor of X rule >> 2) private rule >> 3) mark "at least one rule must apply" >> 4) mark "those that do not match" >> >> BTW, Jerome's selection could also be done perhaps easier if we had >> the ability to add the "not" to each rule rather than to the entire >> filter selection. For example, one could select: >> >> 1) not ancestors of X rule >> 2) not private rule >> 3) mark "all rules must apply" >> >> What does not work in this case is to select "not ancestor of X" >> filter with the Private proxy (as it is applied first), as that messes >> up the ancestors (because it happens to have a private person in the >> ancestor chain). >> >> This suggests Option 3, where Jerome could have gotten the output he >> wanted with a "not ancestor of X" with the Private proxy applied last. >> >> > I would not like to see the actual >> > modules available for use as filters, since that would likely require >> > logic to be added to them of the sort: >> > >> > if I am a proxy: >> > do this >> > else: >> > do that >> > >> > or would require the caller to be knowledgeable of the implementation >> > proxy, which can lead to maintenance headaches. >> >> Yeah, I can't see how we could mix proxies and filters together, other >> than having an interface like we do in export---allowing one to select >> the proxies and their ordering. One could do that in the filter >> sidebar... seeing as that would be complicated (and I have no interest >> in doing it) perhaps we can slightly tweak the export to do two fairly >> simple things: >> >> 1) allow proxies to be applied before/after the filter >> 2) right before the actual export, the display could show who would be >> selected >> >> These two things would go some distance to making the export more user >> friendly. It doesn't allow all use-cases (I can think of some, but >> they are not uses that people are asking for). >> >> -Doug > > This tread is becoming difficult to follow :-) This thread was difficult to write! This is complicated. I'm glad we're taking this slow and thoughtful. > From what I read, am I correct to assume you would undo the change in svn? > So first private again, because the other behaviour can be obtained with > filters? Yes, even with the problems it raises, private proxy first has to be at least an option. > I agree with 1) above, but for users better to use another word (restricted > view or so). For 2), more like a preview button, people with large databases > would not like to wait to see the result. Perhaps for 2) we can give more details (eg, display who is selected) as we are exporting, and a way to cancel. I think "view" is the right word, in description, and also related to what Gerald said. We have effectively created a view: self.dbase = \ gen.proxy.ReferencedProxyDb( gen.proxy.LivingProxyDb( gen.proxy.PrivateProxyDb( gen.proxy.FilterProxyDb( gen.proxy.FilterProxyDb( self.dbase, option_box.cfilter), note_filter=option_box.nfilter ) ), gen.proxy.LivingProxyDb.MODE_INCLUDE_LAST_NAME_ONLY) ) A "View" (what Gerald called a meta-proxy) might be a useful object to have users construct in a future Gramps to get the full power of what is possible. We have all of the code to do it---we're just missing a UI. For now, I will undo the changes in trunk, and try an ordering choice. -Doug > Benny > >> >> > Also, the filter proxy already uses filters, so that would be >> > redundant I suppose. >> > >> > >> >> >> >> The ideal would be option 4, but this might be hard or impossible, but >> >> should be explored. Option 3 is easier than 1 for the user, covers all >> >> known use-cases, but is still hard to verify. Option 2, I think, is >> >> out because it makes Gramps less powerful. Option 1 prevents some >> >> known use-cases. >> >> >> >> -Doug >> >> >> >>> Benny >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> >> Gramps-devel mailing list >> >> Gra...@li... >> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> >> > >> > >> > >> > -- >> > Gerald Britton >> > > > |
From: jerome <rom...@ya...> - 2010-05-18 14:14:55
|
Hi, Maybe I have an other sample, not far away from my first problem, but now with crash ! My primary database under Gramps-3.2.3-SVN + "people having a common ancestors with" + private proxy : 168529: ERROR: gramps.py: line 138: Unhandled exception Traceback (most recent call last): File "share/gramps/ExportAssistant.py", line 496, in do_prepare success = self.save() File "share/gramps/ExportAssistant.py", line 607, in save self.callback) File "share/gramps/plugins/export/ExportXml.py", line 1175, in export_data database = gen.proxy.FilterProxyDb(database, option_box.cfilter) File "share/gramps/gen/proxy/filter.py", line 52, in __init__ self.db, self.db.iter_person_handles())) File "share/gramps/Filters/_GenericFilter.py", line 230, in apply rule.prepare(db) File "share/gramps/Filters/Rules/Person/_HasCommonAncestorWith.py", line 60, in prepare self.add_ancs(db, root_person) File "share/gramps/Filters/Rules/Person/_HasCommonAncestorWith.py", line 64, in add_ancs if person.handle not in self.ancestor_cache: AttributeError: 'NoneType' object has no attribute 'handle' I will try under trunk or with change on order ! Jérôme --- En date de : Mar 18.5.10, Doug Blank <dou...@gm...> a écrit : > De: Doug Blank <dou...@gm...> > Objet: Re: [Gramps-devel] Bug in Filters/Proxies? > À: "Benny Malengier" <ben...@gm...> > Cc: "Gramps Development List" <gra...@li...>, "Gerald Britton" <ger...@gm...> > Date: Mardi 18 mai 2010, 12h37 > On Tue, May 18, 2010 at 3:10 AM, > Benny Malengier > <ben...@gm...> > wrote: > > > > > > 2010/5/17 Doug Blank <dou...@gm...> > >> > >> On Mon, May 17, 2010 at 10:05 AM, Gerald Britton > >> <ger...@gm...> > wrote: > >> > On Mon, May 17, 2010 at 8:22 AM, Doug Blank > <dou...@gm...> > >> > wrote: > >> >> On Mon, May 17, 2010 at 4:32 AM, Benny > Malengier > >> >> <ben...@gm...> > wrote: > >> >>> 2010/5/12 Gerald Britton <ger...@gm...> > >> >> > >> >> [snip] > >> >> > >> >>>> The same thing is done for > filters when you use the rule "people > >> >>>> matching filter x." If that is > the first rule in a new filter "y", > >> >>>> then the other rules in "y" will > only see records that pass filter > >> >>>> "x". The beauty here is that > you can reverse the rules so the > >> >>>> "people > >> >>>> matching filter" rule comes last. > You have the flexibility to put it > >> >>>> together to get the results you > want. > >> >>>> > >> >>> > >> >>> I agree here. There is no bug in the > proxie databases, they work as > >> >>> they > >> >>> should. > >> >> > >> >> Yes, I agree that there is no bug in the > proxies, nor in the filters. > >> >> > >> >> I've been continuing to play with proxies > and filters, and I'm not > >> >> sure that just changing the order is the > right thing to do. But we all > >> >> have to at least agree on what the issues > are. > >> >> > >> >>> The proxies are not commutative > however according to Doug, first > >> >>> filter, > >> >>> then private is different from first > private then filter proxie (see > >> >>> the > >> >>> descendant of and then private versus > private then descendant). > >> >>> Thinking > >> >>> about this, this seems indeed > strange, as Gerald indicates, they > >> >>> should > >> >>> return the same result... > >> >> > >> >> This is easy to see that Filters/Proxies > are not commutative: Consider > >> >> a database with three people: Person A > who has a son, Person B. Person > >> >> B also has a son, Person C. Now mark > Person B as private. > >> >> > >> >> If you apply the Private proxy first, > then you effectively remove > >> >> Person B from the database, and you will > not find any connection > >> >> between Person A and Person C. Thus, any > filter that looks for a > >> >> relationship between A and C will not > find one. Descendants of A will > >> >> not include C. This is how Gramps has > worked for the last few years, > >> >> when you export with a Private Proxy. > >> >> > >> >> On the other hand, if you do not apply > the Private proxy first, there > >> >> is no easy way to hide that relationship > from the filters. You can try > >> >> to make selections based on one's Private > status, but that isn't > >> >> considered when, for example, looking for > descendants or ancestors. > >> >> > >> >> So, the first thing to realize is that > filter-then-proxy is not > >> >> guaranteed to be the same as > proxy-then-filter. They are not > >> >> commutative. > >> >> > >> >> The next thing to realize is that > sometimes one may want to use > >> >> private people in a filter, before having > them removed. Thus, always > >> >> applying the private proxy first may have > effects on the filter that > >> >> you may not realize, until you run an > export. > >> >> > >> >> The final thing to realize is that a > private filter does not take the > >> >> place of the private proxy. Using a > private filter only looks at a > >> >> single person. Combining a private filter > with, say, a descendant > >> >> filter does not have any effect on > limiting who is a descendant. As > >> >> far as I can see, filters are > commutative, and thus cannot be used to > >> >> replace a proxy. > >> >> > >> >>> The change of Doug means private is > applied last. There is no real > >> >>> reasoning > >> >>> on why one or the other should be > first, ..., well, perhaps there is? > >> >>> If > >> >>> they really are not commutative, I > think the order should be in the > >> >>> way that > >> >>> is most difficult (or impossible) to > achieve via a normal filter > >> >>> setup. > >> >> > >> >> If Benny's criteria is used, then the way > that Gramps is now is the > >> >> correct way: there is no easy way (that I > see) to remove Person B > >> >> (private) and Person C (public > descendant) using just filters. > >> >> > >> >> On the other hand, selecting the proxy > first can remove people that > >> >> were important in constructing a filter, > and a user might not notice > >> >> until the export has been made, and then > verified by examining what > >> >> was exported. > >> >> > >> >> So what to do? I see four possibilities: > >> >> > >> >> 1) Leave as it is, Proxies first. To > avoid having a Private proxy have > >> >> adverse affects, a user can opt to not > use the proxy, and use a > >> >> private filter. I believe that a private > filter is equivalent to a > >> >> private proxy last. But this method > causes confusion, even among > >> >> long-time users (and developers) for why > an exported group is what it > >> >> is. > >> >> > >> >> 2) Change to proxies last. This is too > limiting---users don't have the > >> >> power that they need with just filters. > >> >> > >> >> 3) Allow each proxy to be applied before > or after. Users would need to > >> >> know the implications. However, this is > still confusing and hard to > >> >> verify. > >> >> > >> >> 4) Allow proxies to be used as a filter. > I have no idea how this might > >> >> work, but it would allow users to verify > the selection and final > >> >> output. > >> > > >> > Do you mean, "allow the logic of the proxies > to be used in pre-defined > >> > filters"? If so, I can see the value in > that, though the "private" > >> > proxy goes well beyond filtering. > >> > >> To understand the proposed option 4, "allow > proxies to be used as a > >> filter" one needs to appreciate that the three > non-filter based > >> proxies (Private, Living, and Note) are more > powerful than > >> user-constructed filters. That is, they alter what > is accessible. For > >> example, no combination of filters will prevent > you from being able to > >> select the children of a private person in a > descendant filter. Only a > >> proxy can do that. > >> > >> What I am suggesting is some manner to put the > power of the proxy into > >> the hands of the user, so that they can mix > proxies > >> between/before/after filters. This does two > things: 1) it allows users > >> to interactively and easily inspect their > application of proxies and > >> filters to check for correctness (without having > to export and then > >> import), and 2) it gives users the most control > over when and how the > >> proxies get applied. > >> > >> Having thoroughly examined the two use-cases in > this thread (Jerome's > >> and Benny's) we can get by with our current > sequence (proxies before > >> filters). Benny's example is the default behavior > when applying the > >> Private proxy (eg, block access to children of > private people when > >> combined with a descendant filter). Jerome can get > exactly what he > >> wants (I think) by writing a more complicated > filter. The easiest way > >> to construct Jerome's filter is with three > filters, and no proxies: > >> > >> 1) not an ancestor of X filter > >> 2) not private filter > >> 3) mark "all rules must apply" > >> > >> This can also be accomplished with one filter, 2 > rules: > >> > >> 1) an ancestor of X rule > >> 2) private rule > >> 3) mark "at least one rule must apply" > >> 4) mark "those that do not match" > >> > >> BTW, Jerome's selection could also be done perhaps > easier if we had > >> the ability to add the "not" to each rule rather > than to the entire > >> filter selection. For example, one could select: > >> > >> 1) not ancestors of X rule > >> 2) not private rule > >> 3) mark "all rules must apply" > >> > >> What does not work in this case is to select "not > ancestor of X" > >> filter with the Private proxy (as it is applied > first), as that messes > >> up the ancestors (because it happens to have a > private person in the > >> ancestor chain). > >> > >> This suggests Option 3, where Jerome could have > gotten the output he > >> wanted with a "not ancestor of X" with the Private > proxy applied last. > >> > >> > I would not like to see the actual > >> > modules available for use as filters, since > that would likely require > >> > logic to be added to them of the sort: > >> > > >> > if I am a proxy: > >> > do this > >> > else: > >> > do that > >> > > >> > or would require the caller to be > knowledgeable of the implementation > >> > proxy, which can lead to maintenance > headaches. > >> > >> Yeah, I can't see how we could mix proxies and > filters together, other > >> than having an interface like we do in > export---allowing one to select > >> the proxies and their ordering. One could do that > in the filter > >> sidebar... seeing as that would be complicated > (and I have no interest > >> in doing it) perhaps we can slightly tweak the > export to do two fairly > >> simple things: > >> > >> 1) allow proxies to be applied before/after the > filter > >> 2) right before the actual export, the display > could show who would be > >> selected > >> > >> These two things would go some distance to making > the export more user > >> friendly. It doesn't allow all use-cases (I can > think of some, but > >> they are not uses that people are asking for). > >> > >> -Doug > > > > This tread is becoming difficult to follow :-) > > This thread was difficult to write! This is complicated. > I'm glad > we're taking this slow and thoughtful. > > > From what I read, am I correct to assume you would > undo the change in svn? > > So first private again, because the other behaviour > can be obtained with > > filters? > > Yes, even with the problems it raises, private proxy first > has to be > at least an option. > > > I agree with 1) above, but for users better to use > another word (restricted > > view or so). For 2), more like a preview button, > people with large databases > > would not like to wait to see the result. > > Perhaps for 2) we can give more details (eg, display who is > selected) > as we are exporting, and a way to cancel. > > I think "view" is the right word, in description, and also > related to > what Gerald said. We have effectively created a view: > > self.dbase = \ > gen.proxy.ReferencedProxyDb( > gen.proxy.LivingProxyDb( > gen.proxy.PrivateProxyDb( > gen.proxy.FilterProxyDb( > > gen.proxy.FilterProxyDb( > > self.dbase, > > option_box.cfilter), > > note_filter=option_box.nfilter > ) > ), > > gen.proxy.LivingProxyDb.MODE_INCLUDE_LAST_NAME_ONLY) > ) > > A "View" (what Gerald called a meta-proxy) might be a > useful object to > have users construct in a future Gramps to get the full > power of what > is possible. We have all of the code to do it---we're just > missing a > UI. > > For now, I will undo the changes in trunk, and try an > ordering choice. > > -Doug > > > Benny > > > >> > >> > Also, the filter proxy already uses filters, > so that would be > >> > redundant I suppose. > >> > > >> > > >> >> > >> >> The ideal would be option 4, but this > might be hard or impossible, but > >> >> should be explored. Option 3 is easier > than 1 for the user, covers all > >> >> known use-cases, but is still hard to > verify. Option 2, I think, is > >> >> out because it makes Gramps less > powerful. Option 1 prevents some > >> >> known use-cases. > >> >> > >> >> -Doug > >> >> > >> >>> Benny > >> >> > >> >> > >> >> > ------------------------------------------------------------------------------ > >> >> > >> >> > _______________________________________________ > >> >> Gramps-devel mailing list > >> >> Gra...@li... > >> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > >> >> > >> > > >> > > >> > > >> > -- > >> > Gerald Britton > >> > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Doug B. <dou...@gm...> - 2010-05-18 14:26:11
|
On Tue, May 18, 2010 at 10:14 AM, jerome <rom...@ya...> wrote: > Hi, > > > Maybe I have an other sample, not far away from my first problem, but now with crash ! > > My primary database under Gramps-3.2.3-SVN + "people having a common ancestors with" + private proxy : > > 168529: ERROR: gramps.py: line 138: Unhandled exception > Traceback (most recent call last): > File "share/gramps/ExportAssistant.py", line 496, in do_prepare > success = self.save() > File "share/gramps/ExportAssistant.py", line 607, in save > self.callback) > File "share/gramps/plugins/export/ExportXml.py", line 1175, in export_data > database = gen.proxy.FilterProxyDb(database, option_box.cfilter) > File "share/gramps/gen/proxy/filter.py", line 52, in __init__ > self.db, self.db.iter_person_handles())) > File "share/gramps/Filters/_GenericFilter.py", line 230, in apply > rule.prepare(db) > File "share/gramps/Filters/Rules/Person/_HasCommonAncestorWith.py", line 60, in prepare > self.add_ancs(db, root_person) > File "share/gramps/Filters/Rules/Person/_HasCommonAncestorWith.py", line 64, in add_ancs > if person.handle not in self.ancestor_cache: > AttributeError: 'NoneType' object has no attribute 'handle' > > > I will try under trunk or with change on order ! It looks like this will still crash in trunk, as it appears that the root_person is not visible. But these types of crashes don't have a direct bearing on the ordering issue: we don't want crashes like this, regardless. Please make a note of this on your issue: http://www.gramps-project.org/bugs/view.php?id=3878 and we'll continue to explore. -Doug > > Jérôme > > > > --- En date de : Mar 18.5.10, Doug Blank <dou...@gm...> a écrit : > >> De: Doug Blank <dou...@gm...> >> Objet: Re: [Gramps-devel] Bug in Filters/Proxies? >> À: "Benny Malengier" <ben...@gm...> >> Cc: "Gramps Development List" <gra...@li...>, "Gerald Britton" <ger...@gm...> >> Date: Mardi 18 mai 2010, 12h37 >> On Tue, May 18, 2010 at 3:10 AM, >> Benny Malengier >> <ben...@gm...> >> wrote: >> > >> > >> > 2010/5/17 Doug Blank <dou...@gm...> >> >> >> >> On Mon, May 17, 2010 at 10:05 AM, Gerald Britton >> >> <ger...@gm...> >> wrote: >> >> > On Mon, May 17, 2010 at 8:22 AM, Doug Blank >> <dou...@gm...> >> >> > wrote: >> >> >> On Mon, May 17, 2010 at 4:32 AM, Benny >> Malengier >> >> >> <ben...@gm...> >> wrote: >> >> >>> 2010/5/12 Gerald Britton <ger...@gm...> >> >> >> >> >> >> [snip] >> >> >> >> >> >>>> The same thing is done for >> filters when you use the rule "people >> >> >>>> matching filter x." If that is >> the first rule in a new filter "y", >> >> >>>> then the other rules in "y" will >> only see records that pass filter >> >> >>>> "x". The beauty here is that >> you can reverse the rules so the >> >> >>>> "people >> >> >>>> matching filter" rule comes last. >> You have the flexibility to put it >> >> >>>> together to get the results you >> want. >> >> >>>> >> >> >>> >> >> >>> I agree here. There is no bug in the >> proxie databases, they work as >> >> >>> they >> >> >>> should. >> >> >> >> >> >> Yes, I agree that there is no bug in the >> proxies, nor in the filters. >> >> >> >> >> >> I've been continuing to play with proxies >> and filters, and I'm not >> >> >> sure that just changing the order is the >> right thing to do. But we all >> >> >> have to at least agree on what the issues >> are. >> >> >> >> >> >>> The proxies are not commutative >> however according to Doug, first >> >> >>> filter, >> >> >>> then private is different from first >> private then filter proxie (see >> >> >>> the >> >> >>> descendant of and then private versus >> private then descendant). >> >> >>> Thinking >> >> >>> about this, this seems indeed >> strange, as Gerald indicates, they >> >> >>> should >> >> >>> return the same result... >> >> >> >> >> >> This is easy to see that Filters/Proxies >> are not commutative: Consider >> >> >> a database with three people: Person A >> who has a son, Person B. Person >> >> >> B also has a son, Person C. Now mark >> Person B as private. >> >> >> >> >> >> If you apply the Private proxy first, >> then you effectively remove >> >> >> Person B from the database, and you will >> not find any connection >> >> >> between Person A and Person C. Thus, any >> filter that looks for a >> >> >> relationship between A and C will not >> find one. Descendants of A will >> >> >> not include C. This is how Gramps has >> worked for the last few years, >> >> >> when you export with a Private Proxy. >> >> >> >> >> >> On the other hand, if you do not apply >> the Private proxy first, there >> >> >> is no easy way to hide that relationship >> from the filters. You can try >> >> >> to make selections based on one's Private >> status, but that isn't >> >> >> considered when, for example, looking for >> descendants or ancestors. >> >> >> >> >> >> So, the first thing to realize is that >> filter-then-proxy is not >> >> >> guaranteed to be the same as >> proxy-then-filter. They are not >> >> >> commutative. >> >> >> >> >> >> The next thing to realize is that >> sometimes one may want to use >> >> >> private people in a filter, before having >> them removed. Thus, always >> >> >> applying the private proxy first may have >> effects on the filter that >> >> >> you may not realize, until you run an >> export. >> >> >> >> >> >> The final thing to realize is that a >> private filter does not take the >> >> >> place of the private proxy. Using a >> private filter only looks at a >> >> >> single person. Combining a private filter >> with, say, a descendant >> >> >> filter does not have any effect on >> limiting who is a descendant. As >> >> >> far as I can see, filters are >> commutative, and thus cannot be used to >> >> >> replace a proxy. >> >> >> >> >> >>> The change of Doug means private is >> applied last. There is no real >> >> >>> reasoning >> >> >>> on why one or the other should be >> first, ..., well, perhaps there is? >> >> >>> If >> >> >>> they really are not commutative, I >> think the order should be in the >> >> >>> way that >> >> >>> is most difficult (or impossible) to >> achieve via a normal filter >> >> >>> setup. >> >> >> >> >> >> If Benny's criteria is used, then the way >> that Gramps is now is the >> >> >> correct way: there is no easy way (that I >> see) to remove Person B >> >> >> (private) and Person C (public >> descendant) using just filters. >> >> >> >> >> >> On the other hand, selecting the proxy >> first can remove people that >> >> >> were important in constructing a filter, >> and a user might not notice >> >> >> until the export has been made, and then >> verified by examining what >> >> >> was exported. >> >> >> >> >> >> So what to do? I see four possibilities: >> >> >> >> >> >> 1) Leave as it is, Proxies first. To >> avoid having a Private proxy have >> >> >> adverse affects, a user can opt to not >> use the proxy, and use a >> >> >> private filter. I believe that a private >> filter is equivalent to a >> >> >> private proxy last. But this method >> causes confusion, even among >> >> >> long-time users (and developers) for why >> an exported group is what it >> >> >> is. >> >> >> >> >> >> 2) Change to proxies last. This is too >> limiting---users don't have the >> >> >> power that they need with just filters. >> >> >> >> >> >> 3) Allow each proxy to be applied before >> or after. Users would need to >> >> >> know the implications. However, this is >> still confusing and hard to >> >> >> verify. >> >> >> >> >> >> 4) Allow proxies to be used as a filter. >> I have no idea how this might >> >> >> work, but it would allow users to verify >> the selection and final >> >> >> output. >> >> > >> >> > Do you mean, "allow the logic of the proxies >> to be used in pre-defined >> >> > filters"? If so, I can see the value in >> that, though the "private" >> >> > proxy goes well beyond filtering. >> >> >> >> To understand the proposed option 4, "allow >> proxies to be used as a >> >> filter" one needs to appreciate that the three >> non-filter based >> >> proxies (Private, Living, and Note) are more >> powerful than >> >> user-constructed filters. That is, they alter what >> is accessible. For >> >> example, no combination of filters will prevent >> you from being able to >> >> select the children of a private person in a >> descendant filter. Only a >> >> proxy can do that. >> >> >> >> What I am suggesting is some manner to put the >> power of the proxy into >> >> the hands of the user, so that they can mix >> proxies >> >> between/before/after filters. This does two >> things: 1) it allows users >> >> to interactively and easily inspect their >> application of proxies and >> >> filters to check for correctness (without having >> to export and then >> >> import), and 2) it gives users the most control >> over when and how the >> >> proxies get applied. >> >> >> >> Having thoroughly examined the two use-cases in >> this thread (Jerome's >> >> and Benny's) we can get by with our current >> sequence (proxies before >> >> filters). Benny's example is the default behavior >> when applying the >> >> Private proxy (eg, block access to children of >> private people when >> >> combined with a descendant filter). Jerome can get >> exactly what he >> >> wants (I think) by writing a more complicated >> filter. The easiest way >> >> to construct Jerome's filter is with three >> filters, and no proxies: >> >> >> >> 1) not an ancestor of X filter >> >> 2) not private filter >> >> 3) mark "all rules must apply" >> >> >> >> This can also be accomplished with one filter, 2 >> rules: >> >> >> >> 1) an ancestor of X rule >> >> 2) private rule >> >> 3) mark "at least one rule must apply" >> >> 4) mark "those that do not match" >> >> >> >> BTW, Jerome's selection could also be done perhaps >> easier if we had >> >> the ability to add the "not" to each rule rather >> than to the entire >> >> filter selection. For example, one could select: >> >> >> >> 1) not ancestors of X rule >> >> 2) not private rule >> >> 3) mark "all rules must apply" >> >> >> >> What does not work in this case is to select "not >> ancestor of X" >> >> filter with the Private proxy (as it is applied >> first), as that messes >> >> up the ancestors (because it happens to have a >> private person in the >> >> ancestor chain). >> >> >> >> This suggests Option 3, where Jerome could have >> gotten the output he >> >> wanted with a "not ancestor of X" with the Private >> proxy applied last. >> >> >> >> > I would not like to see the actual >> >> > modules available for use as filters, since >> that would likely require >> >> > logic to be added to them of the sort: >> >> > >> >> > if I am a proxy: >> >> > do this >> >> > else: >> >> > do that >> >> > >> >> > or would require the caller to be >> knowledgeable of the implementation >> >> > proxy, which can lead to maintenance >> headaches. >> >> >> >> Yeah, I can't see how we could mix proxies and >> filters together, other >> >> than having an interface like we do in >> export---allowing one to select >> >> the proxies and their ordering. One could do that >> in the filter >> >> sidebar... seeing as that would be complicated >> (and I have no interest >> >> in doing it) perhaps we can slightly tweak the >> export to do two fairly >> >> simple things: >> >> >> >> 1) allow proxies to be applied before/after the >> filter >> >> 2) right before the actual export, the display >> could show who would be >> >> selected >> >> >> >> These two things would go some distance to making >> the export more user >> >> friendly. It doesn't allow all use-cases (I can >> think of some, but >> >> they are not uses that people are asking for). >> >> >> >> -Doug >> > >> > This tread is becoming difficult to follow :-) >> >> This thread was difficult to write! This is complicated. >> I'm glad >> we're taking this slow and thoughtful. >> >> > From what I read, am I correct to assume you would >> undo the change in svn? >> > So first private again, because the other behaviour >> can be obtained with >> > filters? >> >> Yes, even with the problems it raises, private proxy first >> has to be >> at least an option. >> >> > I agree with 1) above, but for users better to use >> another word (restricted >> > view or so). For 2), more like a preview button, >> people with large databases >> > would not like to wait to see the result. >> >> Perhaps for 2) we can give more details (eg, display who is >> selected) >> as we are exporting, and a way to cancel. >> >> I think "view" is the right word, in description, and also >> related to >> what Gerald said. We have effectively created a view: >> >> self.dbase = \ >> gen.proxy.ReferencedProxyDb( >> gen.proxy.LivingProxyDb( >> gen.proxy.PrivateProxyDb( >> gen.proxy.FilterProxyDb( >> >> gen.proxy.FilterProxyDb( >> >> self.dbase, >> >> option_box.cfilter), >> >> note_filter=option_box.nfilter >> ) >> ), >> >> gen.proxy.LivingProxyDb.MODE_INCLUDE_LAST_NAME_ONLY) >> ) >> >> A "View" (what Gerald called a meta-proxy) might be a >> useful object to >> have users construct in a future Gramps to get the full >> power of what >> is possible. We have all of the code to do it---we're just >> missing a >> UI. >> >> For now, I will undo the changes in trunk, and try an >> ordering choice. >> >> -Doug >> >> > Benny >> > >> >> >> >> > Also, the filter proxy already uses filters, >> so that would be >> >> > redundant I suppose. >> >> > >> >> > >> >> >> >> >> >> The ideal would be option 4, but this >> might be hard or impossible, but >> >> >> should be explored. Option 3 is easier >> than 1 for the user, covers all >> >> >> known use-cases, but is still hard to >> verify. Option 2, I think, is >> >> >> out because it makes Gramps less >> powerful. Option 1 prevents some >> >> >> known use-cases. >> >> >> >> >> >> -Doug >> >> >> >> >> >>> Benny >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> >> >> >> _______________________________________________ >> >> >> Gramps-devel mailing list >> >> >> Gra...@li... >> >> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Gerald Britton >> >> > >> > >> > >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > > > |
From: jerome <rom...@ya...> - 2010-05-18 14:56:04
|
> It looks like this will still crash in trunk, as it appears > that the root_person is not visible. your are right, root_person is not visible, maybe because private.proxy has hidden this private person ... No more crash is root_person is no more private ! > File "share/gramps/gen/proxy/filter.py", line 52, in > __init__ > > self.db, self.db.iter_person_handles())) Agreed, it is the proxy design but Aunt Martha could have strange output or crash with current proxies use on Exporter :( Jérôme --- En date de : Mar 18.5.10, Doug Blank <dou...@gm...> a écrit : > De: Doug Blank <dou...@gm...> > Objet: Re: [Gramps-devel] Bug in Filters/Proxies? > À: "jerome" <rom...@ya...> > Cc: "Benny Malengier" <ben...@gm...>, "Gramps Development List" <gra...@li...>, "Gerald Britton" <ger...@gm...> > Date: Mardi 18 mai 2010, 16h26 > On Tue, May 18, 2010 at 10:14 AM, > jerome <rom...@ya...> > wrote: > > Hi, > > > > > > Maybe I have an other sample, not far away from my > first problem, but now with crash ! > > > > My primary database under Gramps-3.2.3-SVN + "people > having a common ancestors with" + private proxy : > > > > 168529: ERROR: gramps.py: line 138: Unhandled > exception > > Traceback (most recent call last): > > File "share/gramps/ExportAssistant.py", line 496, in > do_prepare > > success = self.save() > > File "share/gramps/ExportAssistant.py", line 607, in > save > > self.callback) > > File "share/gramps/plugins/export/ExportXml.py", > line 1175, in export_data > > database = gen.proxy.FilterProxyDb(database, > option_box.cfilter) > > File "share/gramps/gen/proxy/filter.py", line 52, in > __init__ > > self.db, self.db.iter_person_handles())) > > File "share/gramps/Filters/_GenericFilter.py", line > 230, in apply > > rule.prepare(db) > > File > "share/gramps/Filters/Rules/Person/_HasCommonAncestorWith.py", > line 60, in prepare > > self.add_ancs(db, root_person) > > File > "share/gramps/Filters/Rules/Person/_HasCommonAncestorWith.py", > line 64, in add_ancs > > if person.handle not in self.ancestor_cache: > > AttributeError: 'NoneType' object has no attribute > 'handle' > > > > > > I will try under trunk or with change on order ! > > It looks like this will still crash in trunk, as it appears > that the > root_person is not visible. > > But these types of crashes don't have a direct bearing on > the ordering > issue: we don't want crashes like this, regardless. Please > make a note > of this on your issue: > > http://www.gramps-project.org/bugs/view.php?id=3878 > > and we'll continue to explore. > > -Doug > > > > > Jérôme > > > > ------------------------------------------------------------------------------ > >> >> >> > >> >> >> > >> _______________________________________________ > >> >> >> Gramps-devel mailing list > >> >> >> Gra...@li... > >> >> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > Gerald Britton > >> >> > > >> > > >> > > >> > >> > ------------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Gramps-devel mailing list > >> Gra...@li... > >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > >> > > > > > > > > > |
From: Nick H. <nic...@ho...> - 2010-05-18 14:41:03
|
In reading this thread, I am concerned that this may be getting too complicated for the average user. Do we really want to expose the concept of both a proxy (or view) and a filter to the end user? Using the A, B, C descendants example, in selecting an option to "exclude private data" I would expect to see person A and C. If the user doesn't want person C then they should mark them as private. This could be achieved by applying the proxy last. I would consider the current results as a bug. I can see why applying the proxy first produces different results, and in some circumstances why this may be useful, but surely this approach would be confusing for "Aunt Martha" and may lead to unexpected results. Does "proxy first" really have to be an option? I should add that I don't use this functionality much myself, but an "apply proxies before or after" option doesn't seem like a neat solution to me. Regards, Nick. Doug Blank wrote: > On Tue, May 18, 2010 at 3:10 AM, Benny Malengier > <ben...@gm...> wrote: > >> 2010/5/17 Doug Blank <dou...@gm...> >> >>> On Mon, May 17, 2010 at 10:05 AM, Gerald Britton >>> <ger...@gm...> wrote: >>> >>>> On Mon, May 17, 2010 at 8:22 AM, Doug Blank <dou...@gm...> >>>> wrote: >>>> >>>>> On Mon, May 17, 2010 at 4:32 AM, Benny Malengier >>>>> <ben...@gm...> wrote: >>>>> >>>>>> 2010/5/12 Gerald Britton <ger...@gm...> >>>>>> >>>>> [snip] >>>>> >>>>> >>>>>>> The same thing is done for filters when you use the rule "people >>>>>>> matching filter x." If that is the first rule in a new filter "y", >>>>>>> then the other rules in "y" will only see records that pass filter >>>>>>> "x". The beauty here is that you can reverse the rules so the >>>>>>> "people >>>>>>> matching filter" rule comes last. You have the flexibility to put it >>>>>>> together to get the results you want. >>>>>>> >>>>>>> >>>>>> I agree here. There is no bug in the proxie databases, they work as >>>>>> they >>>>>> should. >>>>>> >>>>> Yes, I agree that there is no bug in the proxies, nor in the filters. >>>>> >>>>> I've been continuing to play with proxies and filters, and I'm not >>>>> sure that just changing the order is the right thing to do. But we all >>>>> have to at least agree on what the issues are. >>>>> >>>>> >>>>>> The proxies are not commutative however according to Doug, first >>>>>> filter, >>>>>> then private is different from first private then filter proxie (see >>>>>> the >>>>>> descendant of and then private versus private then descendant). >>>>>> Thinking >>>>>> about this, this seems indeed strange, as Gerald indicates, they >>>>>> should >>>>>> return the same result... >>>>>> >>>>> This is easy to see that Filters/Proxies are not commutative: Consider >>>>> a database with three people: Person A who has a son, Person B. Person >>>>> B also has a son, Person C. Now mark Person B as private. >>>>> >>>>> If you apply the Private proxy first, then you effectively remove >>>>> Person B from the database, and you will not find any connection >>>>> between Person A and Person C. Thus, any filter that looks for a >>>>> relationship between A and C will not find one. Descendants of A will >>>>> not include C. This is how Gramps has worked for the last few years, >>>>> when you export with a Private Proxy. >>>>> >>>>> On the other hand, if you do not apply the Private proxy first, there >>>>> is no easy way to hide that relationship from the filters. You can try >>>>> to make selections based on one's Private status, but that isn't >>>>> considered when, for example, looking for descendants or ancestors. >>>>> >>>>> So, the first thing to realize is that filter-then-proxy is not >>>>> guaranteed to be the same as proxy-then-filter. They are not >>>>> commutative. >>>>> >>>>> The next thing to realize is that sometimes one may want to use >>>>> private people in a filter, before having them removed. Thus, always >>>>> applying the private proxy first may have effects on the filter that >>>>> you may not realize, until you run an export. >>>>> >>>>> The final thing to realize is that a private filter does not take the >>>>> place of the private proxy. Using a private filter only looks at a >>>>> single person. Combining a private filter with, say, a descendant >>>>> filter does not have any effect on limiting who is a descendant. As >>>>> far as I can see, filters are commutative, and thus cannot be used to >>>>> replace a proxy. >>>>> >>>>> >>>>>> The change of Doug means private is applied last. There is no real >>>>>> reasoning >>>>>> on why one or the other should be first, ..., well, perhaps there is? >>>>>> If >>>>>> they really are not commutative, I think the order should be in the >>>>>> way that >>>>>> is most difficult (or impossible) to achieve via a normal filter >>>>>> setup. >>>>>> >>>>> If Benny's criteria is used, then the way that Gramps is now is the >>>>> correct way: there is no easy way (that I see) to remove Person B >>>>> (private) and Person C (public descendant) using just filters. >>>>> >>>>> On the other hand, selecting the proxy first can remove people that >>>>> were important in constructing a filter, and a user might not notice >>>>> until the export has been made, and then verified by examining what >>>>> was exported. >>>>> >>>>> So what to do? I see four possibilities: >>>>> >>>>> 1) Leave as it is, Proxies first. To avoid having a Private proxy have >>>>> adverse affects, a user can opt to not use the proxy, and use a >>>>> private filter. I believe that a private filter is equivalent to a >>>>> private proxy last. But this method causes confusion, even among >>>>> long-time users (and developers) for why an exported group is what it >>>>> is. >>>>> >>>>> 2) Change to proxies last. This is too limiting---users don't have the >>>>> power that they need with just filters. >>>>> >>>>> 3) Allow each proxy to be applied before or after. Users would need to >>>>> know the implications. However, this is still confusing and hard to >>>>> verify. >>>>> >>>>> 4) Allow proxies to be used as a filter. I have no idea how this might >>>>> work, but it would allow users to verify the selection and final >>>>> output. >>>>> >>>> Do you mean, "allow the logic of the proxies to be used in pre-defined >>>> filters"? If so, I can see the value in that, though the "private" >>>> proxy goes well beyond filtering. >>>> >>> To understand the proposed option 4, "allow proxies to be used as a >>> filter" one needs to appreciate that the three non-filter based >>> proxies (Private, Living, and Note) are more powerful than >>> user-constructed filters. That is, they alter what is accessible. For >>> example, no combination of filters will prevent you from being able to >>> select the children of a private person in a descendant filter. Only a >>> proxy can do that. >>> >>> What I am suggesting is some manner to put the power of the proxy into >>> the hands of the user, so that they can mix proxies >>> between/before/after filters. This does two things: 1) it allows users >>> to interactively and easily inspect their application of proxies and >>> filters to check for correctness (without having to export and then >>> import), and 2) it gives users the most control over when and how the >>> proxies get applied. >>> >>> Having thoroughly examined the two use-cases in this thread (Jerome's >>> and Benny's) we can get by with our current sequence (proxies before >>> filters). Benny's example is the default behavior when applying the >>> Private proxy (eg, block access to children of private people when >>> combined with a descendant filter). Jerome can get exactly what he >>> wants (I think) by writing a more complicated filter. The easiest way >>> to construct Jerome's filter is with three filters, and no proxies: >>> >>> 1) not an ancestor of X filter >>> 2) not private filter >>> 3) mark "all rules must apply" >>> >>> This can also be accomplished with one filter, 2 rules: >>> >>> 1) an ancestor of X rule >>> 2) private rule >>> 3) mark "at least one rule must apply" >>> 4) mark "those that do not match" >>> >>> BTW, Jerome's selection could also be done perhaps easier if we had >>> the ability to add the "not" to each rule rather than to the entire >>> filter selection. For example, one could select: >>> >>> 1) not ancestors of X rule >>> 2) not private rule >>> 3) mark "all rules must apply" >>> >>> What does not work in this case is to select "not ancestor of X" >>> filter with the Private proxy (as it is applied first), as that messes >>> up the ancestors (because it happens to have a private person in the >>> ancestor chain). >>> >>> This suggests Option 3, where Jerome could have gotten the output he >>> wanted with a "not ancestor of X" with the Private proxy applied last. >>> >>> >>>> I would not like to see the actual >>>> modules available for use as filters, since that would likely require >>>> logic to be added to them of the sort: >>>> >>>> if I am a proxy: >>>> do this >>>> else: >>>> do that >>>> >>>> or would require the caller to be knowledgeable of the implementation >>>> proxy, which can lead to maintenance headaches. >>>> >>> Yeah, I can't see how we could mix proxies and filters together, other >>> than having an interface like we do in export---allowing one to select >>> the proxies and their ordering. One could do that in the filter >>> sidebar... seeing as that would be complicated (and I have no interest >>> in doing it) perhaps we can slightly tweak the export to do two fairly >>> simple things: >>> >>> 1) allow proxies to be applied before/after the filter >>> 2) right before the actual export, the display could show who would be >>> selected >>> >>> These two things would go some distance to making the export more user >>> friendly. It doesn't allow all use-cases (I can think of some, but >>> they are not uses that people are asking for). >>> >>> -Doug >>> >> This tread is becoming difficult to follow :-) >> > > This thread was difficult to write! This is complicated. I'm glad > we're taking this slow and thoughtful. > > >> From what I read, am I correct to assume you would undo the change in svn? >> So first private again, because the other behaviour can be obtained with >> filters? >> > > Yes, even with the problems it raises, private proxy first has to be > at least an option. > > >> I agree with 1) above, but for users better to use another word (restricted >> view or so). For 2), more like a preview button, people with large databases >> would not like to wait to see the result. >> > > Perhaps for 2) we can give more details (eg, display who is selected) > as we are exporting, and a way to cancel. > > I think "view" is the right word, in description, and also related to > what Gerald said. We have effectively created a view: > > self.dbase = \ > gen.proxy.ReferencedProxyDb( > gen.proxy.LivingProxyDb( > gen.proxy.PrivateProxyDb( > gen.proxy.FilterProxyDb( > gen.proxy.FilterProxyDb( > self.dbase, > option_box.cfilter), > note_filter=option_box.nfilter > ) > ), > gen.proxy.LivingProxyDb.MODE_INCLUDE_LAST_NAME_ONLY) > ) > > A "View" (what Gerald called a meta-proxy) might be a useful object to > have users construct in a future Gramps to get the full power of what > is possible. We have all of the code to do it---we're just missing a > UI. > > For now, I will undo the changes in trunk, and try an ordering choice. > > -Doug > > >> Benny >> >> >>>> Also, the filter proxy already uses filters, so that would be >>>> redundant I suppose. >>>> >>>> >>>> >>>>> The ideal would be option 4, but this might be hard or impossible, but >>>>> should be explored. Option 3 is easier than 1 for the user, covers all >>>>> known use-cases, but is still hard to verify. Option 2, I think, is >>>>> out because it makes Gramps less powerful. Option 1 prevents some >>>>> known use-cases. >>>>> >>>>> -Doug >>>>> >>>>> >>>>>> Benny >>>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Gramps-devel mailing list >>>>> Gra...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>> >>>>> >>>> >>>> -- >>>> Gerald Britton >>>> >>>> >> > > ------------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > |
From: Doug B. <dou...@gm...> - 2010-05-18 15:26:13
|
On Tue, May 18, 2010 at 10:40 AM, Nick Hall <nic...@ho...> wrote: > In reading this thread, I am concerned that this may be getting too > complicated for the average user. Do we really want to expose the concept > of both a proxy (or view) and a filter to the end user? We already do, implicitly. I think the Private proxy is the only one that may need to be handled in this way, and only when you use a filter, so it is: ( ) Include Private Objects ( ) Remove Private Objects before filter ( ) Remove Private Objects after filter > Using the A, B, C descendants example, in selecting an option to "exclude > private data" I would expect to see person A and C. If the user doesn't > want person C then they should mark them as private. This could be achieved > by applying the proxy last. I would consider the current results as a bug. > > I can see why applying the proxy first produces different results, and in > some circumstances why this may be useful, but surely this approach would be > confusing for "Aunt Martha" and may lead to unexpected results. Does "proxy > first" really have to be an option? One compelling argument is that this is the way that Gramps has always operated, and people (such as Gerald) have constructed filters that depend on this operation. If we remove the private-proxy-first option, users would need to do what you suggest: mark everyone past the private person as private, too. Another argument is that what one considers private can change depending on the use of the output. For example, in one export, you might want to consider C and all of their family as off-limits. However, you might want to then turn around and create an export that has D (say, C's spouse) as private, and all of their family as off-limits. This would require a lot of work from the user to be able to do this without private-proxy-first. > I should add that I don't use this functionality much myself, but an "apply > proxies before or after" option doesn't seem like a neat solution to me. Yes, looking for the best solution, consider ease-of-use, power, and flexibility. -Doug > Regards, > > > Nick. > > > Doug Blank wrote: >> >> On Tue, May 18, 2010 at 3:10 AM, Benny Malengier >> <ben...@gm...> wrote: >> >>> >>> 2010/5/17 Doug Blank <dou...@gm...> >>> >>>> >>>> On Mon, May 17, 2010 at 10:05 AM, Gerald Britton >>>> <ger...@gm...> wrote: >>>> >>>>> >>>>> On Mon, May 17, 2010 at 8:22 AM, Doug Blank <dou...@gm...> >>>>> wrote: >>>>> >>>>>> >>>>>> On Mon, May 17, 2010 at 4:32 AM, Benny Malengier >>>>>> <ben...@gm...> wrote: >>>>>> >>>>>>> >>>>>>> 2010/5/12 Gerald Britton <ger...@gm...> >>>>>>> >>>>>> >>>>>> [snip] >>>>>> >>>>>> >>>>>>>> >>>>>>>> The same thing is done for filters when you use the rule "people >>>>>>>> matching filter x." If that is the first rule in a new filter "y", >>>>>>>> then the other rules in "y" will only see records that pass filter >>>>>>>> "x". The beauty here is that you can reverse the rules so the >>>>>>>> "people >>>>>>>> matching filter" rule comes last. You have the flexibility to put >>>>>>>> it >>>>>>>> together to get the results you want. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I agree here. There is no bug in the proxie databases, they work as >>>>>>> they >>>>>>> should. >>>>>>> >>>>>> >>>>>> Yes, I agree that there is no bug in the proxies, nor in the filters. >>>>>> >>>>>> I've been continuing to play with proxies and filters, and I'm not >>>>>> sure that just changing the order is the right thing to do. But we all >>>>>> have to at least agree on what the issues are. >>>>>> >>>>>> >>>>>>> >>>>>>> The proxies are not commutative however according to Doug, first >>>>>>> filter, >>>>>>> then private is different from first private then filter proxie (see >>>>>>> the >>>>>>> descendant of and then private versus private then descendant). >>>>>>> Thinking >>>>>>> about this, this seems indeed strange, as Gerald indicates, they >>>>>>> should >>>>>>> return the same result... >>>>>>> >>>>>> >>>>>> This is easy to see that Filters/Proxies are not commutative: Consider >>>>>> a database with three people: Person A who has a son, Person B. Person >>>>>> B also has a son, Person C. Now mark Person B as private. >>>>>> >>>>>> If you apply the Private proxy first, then you effectively remove >>>>>> Person B from the database, and you will not find any connection >>>>>> between Person A and Person C. Thus, any filter that looks for a >>>>>> relationship between A and C will not find one. Descendants of A will >>>>>> not include C. This is how Gramps has worked for the last few years, >>>>>> when you export with a Private Proxy. >>>>>> >>>>>> On the other hand, if you do not apply the Private proxy first, there >>>>>> is no easy way to hide that relationship from the filters. You can try >>>>>> to make selections based on one's Private status, but that isn't >>>>>> considered when, for example, looking for descendants or ancestors. >>>>>> >>>>>> So, the first thing to realize is that filter-then-proxy is not >>>>>> guaranteed to be the same as proxy-then-filter. They are not >>>>>> commutative. >>>>>> >>>>>> The next thing to realize is that sometimes one may want to use >>>>>> private people in a filter, before having them removed. Thus, always >>>>>> applying the private proxy first may have effects on the filter that >>>>>> you may not realize, until you run an export. >>>>>> >>>>>> The final thing to realize is that a private filter does not take the >>>>>> place of the private proxy. Using a private filter only looks at a >>>>>> single person. Combining a private filter with, say, a descendant >>>>>> filter does not have any effect on limiting who is a descendant. As >>>>>> far as I can see, filters are commutative, and thus cannot be used to >>>>>> replace a proxy. >>>>>> >>>>>> >>>>>>> >>>>>>> The change of Doug means private is applied last. There is no real >>>>>>> reasoning >>>>>>> on why one or the other should be first, ..., well, perhaps there is? >>>>>>> If >>>>>>> they really are not commutative, I think the order should be in the >>>>>>> way that >>>>>>> is most difficult (or impossible) to achieve via a normal filter >>>>>>> setup. >>>>>>> >>>>>> >>>>>> If Benny's criteria is used, then the way that Gramps is now is the >>>>>> correct way: there is no easy way (that I see) to remove Person B >>>>>> (private) and Person C (public descendant) using just filters. >>>>>> >>>>>> On the other hand, selecting the proxy first can remove people that >>>>>> were important in constructing a filter, and a user might not notice >>>>>> until the export has been made, and then verified by examining what >>>>>> was exported. >>>>>> >>>>>> So what to do? I see four possibilities: >>>>>> >>>>>> 1) Leave as it is, Proxies first. To avoid having a Private proxy have >>>>>> adverse affects, a user can opt to not use the proxy, and use a >>>>>> private filter. I believe that a private filter is equivalent to a >>>>>> private proxy last. But this method causes confusion, even among >>>>>> long-time users (and developers) for why an exported group is what it >>>>>> is. >>>>>> >>>>>> 2) Change to proxies last. This is too limiting---users don't have the >>>>>> power that they need with just filters. >>>>>> >>>>>> 3) Allow each proxy to be applied before or after. Users would need to >>>>>> know the implications. However, this is still confusing and hard to >>>>>> verify. >>>>>> >>>>>> 4) Allow proxies to be used as a filter. I have no idea how this might >>>>>> work, but it would allow users to verify the selection and final >>>>>> output. >>>>>> >>>>> >>>>> Do you mean, "allow the logic of the proxies to be used in pre-defined >>>>> filters"? If so, I can see the value in that, though the "private" >>>>> proxy goes well beyond filtering. >>>>> >>>> >>>> To understand the proposed option 4, "allow proxies to be used as a >>>> filter" one needs to appreciate that the three non-filter based >>>> proxies (Private, Living, and Note) are more powerful than >>>> user-constructed filters. That is, they alter what is accessible. For >>>> example, no combination of filters will prevent you from being able to >>>> select the children of a private person in a descendant filter. Only a >>>> proxy can do that. >>>> >>>> What I am suggesting is some manner to put the power of the proxy into >>>> the hands of the user, so that they can mix proxies >>>> between/before/after filters. This does two things: 1) it allows users >>>> to interactively and easily inspect their application of proxies and >>>> filters to check for correctness (without having to export and then >>>> import), and 2) it gives users the most control over when and how the >>>> proxies get applied. >>>> >>>> Having thoroughly examined the two use-cases in this thread (Jerome's >>>> and Benny's) we can get by with our current sequence (proxies before >>>> filters). Benny's example is the default behavior when applying the >>>> Private proxy (eg, block access to children of private people when >>>> combined with a descendant filter). Jerome can get exactly what he >>>> wants (I think) by writing a more complicated filter. The easiest way >>>> to construct Jerome's filter is with three filters, and no proxies: >>>> >>>> 1) not an ancestor of X filter >>>> 2) not private filter >>>> 3) mark "all rules must apply" >>>> >>>> This can also be accomplished with one filter, 2 rules: >>>> >>>> 1) an ancestor of X rule >>>> 2) private rule >>>> 3) mark "at least one rule must apply" >>>> 4) mark "those that do not match" >>>> >>>> BTW, Jerome's selection could also be done perhaps easier if we had >>>> the ability to add the "not" to each rule rather than to the entire >>>> filter selection. For example, one could select: >>>> >>>> 1) not ancestors of X rule >>>> 2) not private rule >>>> 3) mark "all rules must apply" >>>> >>>> What does not work in this case is to select "not ancestor of X" >>>> filter with the Private proxy (as it is applied first), as that messes >>>> up the ancestors (because it happens to have a private person in the >>>> ancestor chain). >>>> >>>> This suggests Option 3, where Jerome could have gotten the output he >>>> wanted with a "not ancestor of X" with the Private proxy applied last. >>>> >>>> >>>>> >>>>> I would not like to see the actual >>>>> modules available for use as filters, since that would likely require >>>>> logic to be added to them of the sort: >>>>> >>>>> if I am a proxy: >>>>> do this >>>>> else: >>>>> do that >>>>> >>>>> or would require the caller to be knowledgeable of the implementation >>>>> proxy, which can lead to maintenance headaches. >>>>> >>>> >>>> Yeah, I can't see how we could mix proxies and filters together, other >>>> than having an interface like we do in export---allowing one to select >>>> the proxies and their ordering. One could do that in the filter >>>> sidebar... seeing as that would be complicated (and I have no interest >>>> in doing it) perhaps we can slightly tweak the export to do two fairly >>>> simple things: >>>> >>>> 1) allow proxies to be applied before/after the filter >>>> 2) right before the actual export, the display could show who would be >>>> selected >>>> >>>> These two things would go some distance to making the export more user >>>> friendly. It doesn't allow all use-cases (I can think of some, but >>>> they are not uses that people are asking for). >>>> >>>> -Doug >>>> >>> >>> This tread is becoming difficult to follow :-) >>> >> >> This thread was difficult to write! This is complicated. I'm glad >> we're taking this slow and thoughtful. >> >> >>> >>> From what I read, am I correct to assume you would undo the change in >>> svn? >>> So first private again, because the other behaviour can be obtained with >>> filters? >>> >> >> Yes, even with the problems it raises, private proxy first has to be >> at least an option. >> >> >>> >>> I agree with 1) above, but for users better to use another word >>> (restricted >>> view or so). For 2), more like a preview button, people with large >>> databases >>> would not like to wait to see the result. >>> >> >> Perhaps for 2) we can give more details (eg, display who is selected) >> as we are exporting, and a way to cancel. >> >> I think "view" is the right word, in description, and also related to >> what Gerald said. We have effectively created a view: >> >> self.dbase = \ >> gen.proxy.ReferencedProxyDb( >> gen.proxy.LivingProxyDb( >> gen.proxy.PrivateProxyDb( >> gen.proxy.FilterProxyDb( >> gen.proxy.FilterProxyDb( >> self.dbase, >> option_box.cfilter), >> note_filter=option_box.nfilter >> ) >> ), >> gen.proxy.LivingProxyDb.MODE_INCLUDE_LAST_NAME_ONLY) >> ) >> >> A "View" (what Gerald called a meta-proxy) might be a useful object to >> have users construct in a future Gramps to get the full power of what >> is possible. We have all of the code to do it---we're just missing a >> UI. >> >> For now, I will undo the changes in trunk, and try an ordering choice. >> >> -Doug >> >> >>> >>> Benny >>> >>> >>>>> >>>>> Also, the filter proxy already uses filters, so that would be >>>>> redundant I suppose. >>>>> >>>>> >>>>> >>>>>> >>>>>> The ideal would be option 4, but this might be hard or impossible, but >>>>>> should be explored. Option 3 is easier than 1 for the user, covers all >>>>>> known use-cases, but is still hard to verify. Option 2, I think, is >>>>>> out because it makes Gramps less powerful. Option 1 prevents some >>>>>> known use-cases. >>>>>> >>>>>> -Doug >>>>>> >>>>>> >>>>>>> >>>>>>> Benny >>>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> _______________________________________________ >>>>>> Gramps-devel mailing list >>>>>> Gra...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Gerald Britton >>>>> >>>>> >>> >>> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> >> > |
From: Nick H. <nic...@ho...> - 2010-05-18 16:32:02
|
Doug Blank wrote: > On Tue, May 18, 2010 at 10:40 AM, Nick Hall <nic...@ho...> wrote: > >> In reading this thread, I am concerned that this may be getting too >> complicated for the average user. Do we really want to expose the concept >> of both a proxy (or view) and a filter to the end user? >> > > We already do, implicitly. I think the Private proxy is the only one > that may need to be handled in this way, and only when you use a > filter, so it is: > > ( ) Include Private Objects > ( ) Remove Private Objects before filter > ( ) Remove Private Objects after filter > > There is no problem doing it implicitly like this. The user is not exposed to the implementation. The options you have listed here are unambiguous. >> Using the A, B, C descendants example, in selecting an option to "exclude >> private data" I would expect to see person A and C. If the user doesn't >> want person C then they should mark them as private. This could be achieved >> by applying the proxy last. I would consider the current results as a bug. >> >> I can see why applying the proxy first produces different results, and in >> some circumstances why this may be useful, but surely this approach would be >> confusing for "Aunt Martha" and may lead to unexpected results. Does "proxy >> first" really have to be an option? >> > > One compelling argument is that this is the way that Gramps has always > operated, and people (such as Gerald) have constructed filters that > depend on this operation. If we remove the private-proxy-first option, > users would need to do what you suggest: mark everyone past the > private person as private, too. > > In general, I would recommend fixing a bug even if some code relies on a side effect of the bug. I don't think that the proxy-first option would be the functionality that most people would expect. > Another argument is that what one considers private can change > depending on the use of the output. For example, in one export, you > might want to consider C and all of their family as off-limits. > However, you might want to then turn around and create an export that > has D (say, C's spouse) as private, and all of their family as > off-limits. This would require a lot of work from the user to be able > to do this without private-proxy-first. > > This is a better argument. I can see why people would find this useful. If I understand you correctly, the export is descendants of A. In one case you want to also exclude descendants of C, and in the other descendants of D. An easy way to do this is to change the private flag from C to D. The only way I use the private flag is more static - I don't change private flags for a particular export. Do we want to encourage users to change private flags for a particular export? The alternative would be to create more complicated filters. Would this be too difficult for the average user? >> I should add that I don't use this functionality much myself, but an "apply >> proxies before or after" option doesn't seem like a neat solution to me. >> > > Yes, looking for the best solution, consider ease-of-use, power, and > flexibility. > > I'm sure that you'll come up with a good solution. I just wanted to remind people of new and Aunt Martha type users and to avoid adding complexity if it is not needed. Nick. > -Doug > > >> Regards, >> >> >> Nick. >> >> >> Doug Blank wrote: >> >>> On Tue, May 18, 2010 at 3:10 AM, Benny Malengier >>> <ben...@gm...> wrote: >>> >>> >>>> 2010/5/17 Doug Blank <dou...@gm...> >>>> >>>> >>>>> On Mon, May 17, 2010 at 10:05 AM, Gerald Britton >>>>> <ger...@gm...> wrote: >>>>> >>>>> >>>>>> On Mon, May 17, 2010 at 8:22 AM, Doug Blank <dou...@gm...> >>>>>> wrote: >>>>>> >>>>>> >>>>>>> On Mon, May 17, 2010 at 4:32 AM, Benny Malengier >>>>>>> <ben...@gm...> wrote: >>>>>>> >>>>>>> >>>>>>>> 2010/5/12 Gerald Britton <ger...@gm...> >>>>>>>> >>>>>>>> >>>>>>> [snip] >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> The same thing is done for filters when you use the rule "people >>>>>>>>> matching filter x." If that is the first rule in a new filter "y", >>>>>>>>> then the other rules in "y" will only see records that pass filter >>>>>>>>> "x". The beauty here is that you can reverse the rules so the >>>>>>>>> "people >>>>>>>>> matching filter" rule comes last. You have the flexibility to put >>>>>>>>> it >>>>>>>>> together to get the results you want. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> I agree here. There is no bug in the proxie databases, they work as >>>>>>>> they >>>>>>>> should. >>>>>>>> >>>>>>>> >>>>>>> Yes, I agree that there is no bug in the proxies, nor in the filters. >>>>>>> >>>>>>> I've been continuing to play with proxies and filters, and I'm not >>>>>>> sure that just changing the order is the right thing to do. But we all >>>>>>> have to at least agree on what the issues are. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> The proxies are not commutative however according to Doug, first >>>>>>>> filter, >>>>>>>> then private is different from first private then filter proxie (see >>>>>>>> the >>>>>>>> descendant of and then private versus private then descendant). >>>>>>>> Thinking >>>>>>>> about this, this seems indeed strange, as Gerald indicates, they >>>>>>>> should >>>>>>>> return the same result... >>>>>>>> >>>>>>>> >>>>>>> This is easy to see that Filters/Proxies are not commutative: Consider >>>>>>> a database with three people: Person A who has a son, Person B. Person >>>>>>> B also has a son, Person C. Now mark Person B as private. >>>>>>> >>>>>>> If you apply the Private proxy first, then you effectively remove >>>>>>> Person B from the database, and you will not find any connection >>>>>>> between Person A and Person C. Thus, any filter that looks for a >>>>>>> relationship between A and C will not find one. Descendants of A will >>>>>>> not include C. This is how Gramps has worked for the last few years, >>>>>>> when you export with a Private Proxy. >>>>>>> >>>>>>> On the other hand, if you do not apply the Private proxy first, there >>>>>>> is no easy way to hide that relationship from the filters. You can try >>>>>>> to make selections based on one's Private status, but that isn't >>>>>>> considered when, for example, looking for descendants or ancestors. >>>>>>> >>>>>>> So, the first thing to realize is that filter-then-proxy is not >>>>>>> guaranteed to be the same as proxy-then-filter. They are not >>>>>>> commutative. >>>>>>> >>>>>>> The next thing to realize is that sometimes one may want to use >>>>>>> private people in a filter, before having them removed. Thus, always >>>>>>> applying the private proxy first may have effects on the filter that >>>>>>> you may not realize, until you run an export. >>>>>>> >>>>>>> The final thing to realize is that a private filter does not take the >>>>>>> place of the private proxy. Using a private filter only looks at a >>>>>>> single person. Combining a private filter with, say, a descendant >>>>>>> filter does not have any effect on limiting who is a descendant. As >>>>>>> far as I can see, filters are commutative, and thus cannot be used to >>>>>>> replace a proxy. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> The change of Doug means private is applied last. There is no real >>>>>>>> reasoning >>>>>>>> on why one or the other should be first, ..., well, perhaps there is? >>>>>>>> If >>>>>>>> they really are not commutative, I think the order should be in the >>>>>>>> way that >>>>>>>> is most difficult (or impossible) to achieve via a normal filter >>>>>>>> setup. >>>>>>>> >>>>>>>> >>>>>>> If Benny's criteria is used, then the way that Gramps is now is the >>>>>>> correct way: there is no easy way (that I see) to remove Person B >>>>>>> (private) and Person C (public descendant) using just filters. >>>>>>> >>>>>>> On the other hand, selecting the proxy first can remove people that >>>>>>> were important in constructing a filter, and a user might not notice >>>>>>> until the export has been made, and then verified by examining what >>>>>>> was exported. >>>>>>> >>>>>>> So what to do? I see four possibilities: >>>>>>> >>>>>>> 1) Leave as it is, Proxies first. To avoid having a Private proxy have >>>>>>> adverse affects, a user can opt to not use the proxy, and use a >>>>>>> private filter. I believe that a private filter is equivalent to a >>>>>>> private proxy last. But this method causes confusion, even among >>>>>>> long-time users (and developers) for why an exported group is what it >>>>>>> is. >>>>>>> >>>>>>> 2) Change to proxies last. This is too limiting---users don't have the >>>>>>> power that they need with just filters. >>>>>>> >>>>>>> 3) Allow each proxy to be applied before or after. Users would need to >>>>>>> know the implications. However, this is still confusing and hard to >>>>>>> verify. >>>>>>> >>>>>>> 4) Allow proxies to be used as a filter. I have no idea how this might >>>>>>> work, but it would allow users to verify the selection and final >>>>>>> output. >>>>>>> >>>>>>> >>>>>> Do you mean, "allow the logic of the proxies to be used in pre-defined >>>>>> filters"? If so, I can see the value in that, though the "private" >>>>>> proxy goes well beyond filtering. >>>>>> >>>>>> >>>>> To understand the proposed option 4, "allow proxies to be used as a >>>>> filter" one needs to appreciate that the three non-filter based >>>>> proxies (Private, Living, and Note) are more powerful than >>>>> user-constructed filters. That is, they alter what is accessible. For >>>>> example, no combination of filters will prevent you from being able to >>>>> select the children of a private person in a descendant filter. Only a >>>>> proxy can do that. >>>>> >>>>> What I am suggesting is some manner to put the power of the proxy into >>>>> the hands of the user, so that they can mix proxies >>>>> between/before/after filters. This does two things: 1) it allows users >>>>> to interactively and easily inspect their application of proxies and >>>>> filters to check for correctness (without having to export and then >>>>> import), and 2) it gives users the most control over when and how the >>>>> proxies get applied. >>>>> >>>>> Having thoroughly examined the two use-cases in this thread (Jerome's >>>>> and Benny's) we can get by with our current sequence (proxies before >>>>> filters). Benny's example is the default behavior when applying the >>>>> Private proxy (eg, block access to children of private people when >>>>> combined with a descendant filter). Jerome can get exactly what he >>>>> wants (I think) by writing a more complicated filter. The easiest way >>>>> to construct Jerome's filter is with three filters, and no proxies: >>>>> >>>>> 1) not an ancestor of X filter >>>>> 2) not private filter >>>>> 3) mark "all rules must apply" >>>>> >>>>> This can also be accomplished with one filter, 2 rules: >>>>> >>>>> 1) an ancestor of X rule >>>>> 2) private rule >>>>> 3) mark "at least one rule must apply" >>>>> 4) mark "those that do not match" >>>>> >>>>> BTW, Jerome's selection could also be done perhaps easier if we had >>>>> the ability to add the "not" to each rule rather than to the entire >>>>> filter selection. For example, one could select: >>>>> >>>>> 1) not ancestors of X rule >>>>> 2) not private rule >>>>> 3) mark "all rules must apply" >>>>> >>>>> What does not work in this case is to select "not ancestor of X" >>>>> filter with the Private proxy (as it is applied first), as that messes >>>>> up the ancestors (because it happens to have a private person in the >>>>> ancestor chain). >>>>> >>>>> This suggests Option 3, where Jerome could have gotten the output he >>>>> wanted with a "not ancestor of X" with the Private proxy applied last. >>>>> >>>>> >>>>> >>>>>> I would not like to see the actual >>>>>> modules available for use as filters, since that would likely require >>>>>> logic to be added to them of the sort: >>>>>> >>>>>> if I am a proxy: >>>>>> do this >>>>>> else: >>>>>> do that >>>>>> >>>>>> or would require the caller to be knowledgeable of the implementation >>>>>> proxy, which can lead to maintenance headaches. >>>>>> >>>>>> >>>>> Yeah, I can't see how we could mix proxies and filters together, other >>>>> than having an interface like we do in export---allowing one to select >>>>> the proxies and their ordering. One could do that in the filter >>>>> sidebar... seeing as that would be complicated (and I have no interest >>>>> in doing it) perhaps we can slightly tweak the export to do two fairly >>>>> simple things: >>>>> >>>>> 1) allow proxies to be applied before/after the filter >>>>> 2) right before the actual export, the display could show who would be >>>>> selected >>>>> >>>>> These two things would go some distance to making the export more user >>>>> friendly. It doesn't allow all use-cases (I can think of some, but >>>>> they are not uses that people are asking for). >>>>> >>>>> -Doug >>>>> >>>>> >>>> This tread is becoming difficult to follow :-) >>>> >>>> >>> This thread was difficult to write! This is complicated. I'm glad >>> we're taking this slow and thoughtful. >>> >>> >>> >>>> From what I read, am I correct to assume you would undo the change in >>>> svn? >>>> So first private again, because the other behaviour can be obtained with >>>> filters? >>>> >>>> >>> Yes, even with the problems it raises, private proxy first has to be >>> at least an option. >>> >>> >>> >>>> I agree with 1) above, but for users better to use another word >>>> (restricted >>>> view or so). For 2), more like a preview button, people with large >>>> databases >>>> would not like to wait to see the result. >>>> >>>> >>> Perhaps for 2) we can give more details (eg, display who is selected) >>> as we are exporting, and a way to cancel. >>> >>> I think "view" is the right word, in description, and also related to >>> what Gerald said. We have effectively created a view: >>> >>> self.dbase = \ >>> gen.proxy.ReferencedProxyDb( >>> gen.proxy.LivingProxyDb( >>> gen.proxy.PrivateProxyDb( >>> gen.proxy.FilterProxyDb( >>> gen.proxy.FilterProxyDb( >>> self.dbase, >>> option_box.cfilter), >>> note_filter=option_box.nfilter >>> ) >>> ), >>> gen.proxy.LivingProxyDb.MODE_INCLUDE_LAST_NAME_ONLY) >>> ) >>> >>> A "View" (what Gerald called a meta-proxy) might be a useful object to >>> have users construct in a future Gramps to get the full power of what >>> is possible. We have all of the code to do it---we're just missing a >>> UI. >>> >>> For now, I will undo the changes in trunk, and try an ordering choice. >>> >>> -Doug >>> >>> >>> >>>> Benny >>>> >>>> >>>> >>>>>> Also, the filter proxy already uses filters, so that would be >>>>>> redundant I suppose. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> The ideal would be option 4, but this might be hard or impossible, but >>>>>>> should be explored. Option 3 is easier than 1 for the user, covers all >>>>>>> known use-cases, but is still hard to verify. Option 2, I think, is >>>>>>> out because it makes Gramps less powerful. Option 1 prevents some >>>>>>> known use-cases. >>>>>>> >>>>>>> -Doug >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Benny >>>>>>>> >>>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Gramps-devel mailing list >>>>>>> Gra...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> Gerald Britton >>>>>> >>>>>> >>>>>> >>>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >>> >>> >>> > > > |
From: Doug B. <dou...@gm...> - 2010-05-18 17:13:09
|
On Tue, May 18, 2010 at 12:31 PM, Nick Hall <nic...@ho...> wrote: > > > Doug Blank wrote: >> >> On Tue, May 18, 2010 at 10:40 AM, Nick Hall <nic...@ho...> >> wrote: >> >>> >>> In reading this thread, I am concerned that this may be getting too >>> complicated for the average user. Do we really want to expose the >>> concept >>> of both a proxy (or view) and a filter to the end user? >>> >> >> We already do, implicitly. I think the Private proxy is the only one >> that may need to be handled in this way, and only when you use a >> filter, so it is: >> >> ( ) Include Private Objects >> ( ) Remove Private Objects before filter >> ( ) Remove Private Objects after filter >> >> > > There is no problem doing it implicitly like this. The user is not exposed > to the implementation. The options you have listed here are unambiguous. > >>> Using the A, B, C descendants example, in selecting an option to "exclude >>> private data" I would expect to see person A and C. If the user doesn't >>> want person C then they should mark them as private. This could be >>> achieved >>> by applying the proxy last. I would consider the current results as a >>> bug. >>> >>> I can see why applying the proxy first produces different results, and in >>> some circumstances why this may be useful, but surely this approach would >>> be >>> confusing for "Aunt Martha" and may lead to unexpected results. Does >>> "proxy >>> first" really have to be an option? >>> >> >> One compelling argument is that this is the way that Gramps has always >> operated, and people (such as Gerald) have constructed filters that >> depend on this operation. If we remove the private-proxy-first option, >> users would need to do what you suggest: mark everyone past the >> private person as private, too. >> >> > > In general, I would recommend fixing a bug even if some code relies on a > side effect of the bug. I don't think that the proxy-first option would be > the functionality that most people would expect. > >> Another argument is that what one considers private can change >> depending on the use of the output. For example, in one export, you >> might want to consider C and all of their family as off-limits. >> However, you might want to then turn around and create an export that >> has D (say, C's spouse) as private, and all of their family as >> off-limits. This would require a lot of work from the user to be able >> to do this without private-proxy-first. >> >> > > This is a better argument. I can see why people would find this useful. > > If I understand you correctly, the export is descendants of A. In one case > you want to also exclude descendants of C, and in the other descendants of > D. An easy way to do this is to change the private flag from C to D. > > The only way I use the private flag is more static - I don't change private > flags for a particular export. Do we want to encourage users to change > private flags for a particular export? > > The alternative would be to create more complicated filters. Would this be > too difficult for the average user? As far as I can figure out, it is impossible to construct filters that have the same effect as private-proxy-first. >>> I should add that I don't use this functionality much myself, but an >>> "apply >>> proxies before or after" option doesn't seem like a neat solution to me. >>> >> >> Yes, looking for the best solution, consider ease-of-use, power, and >> flexibility. > > I'm sure that you'll come up with a good solution. I just wanted to remind > people of new and Aunt Martha type users and to avoid adding complexity if > it is not needed. Actually, I don't really want to work on this problem... I thought that I would step in and help Jerome. So if someone has an idea, or has a vested interested, please jump in! -Doug > > Nick. > > >> -Doug >> >> >>> >>> Regards, >>> >>> >>> Nick. >>> >>> >>> Doug Blank wrote: >>> >>>> >>>> On Tue, May 18, 2010 at 3:10 AM, Benny Malengier >>>> <ben...@gm...> wrote: >>>> >>>> >>>>> >>>>> 2010/5/17 Doug Blank <dou...@gm...> >>>>> >>>>> >>>>>> >>>>>> On Mon, May 17, 2010 at 10:05 AM, Gerald Britton >>>>>> <ger...@gm...> wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> On Mon, May 17, 2010 at 8:22 AM, Doug Blank <dou...@gm...> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Mon, May 17, 2010 at 4:32 AM, Benny Malengier >>>>>>>> <ben...@gm...> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 2010/5/12 Gerald Britton <ger...@gm...> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> [snip] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> The same thing is done for filters when you use the rule "people >>>>>>>>>> matching filter x." If that is the first rule in a new filter >>>>>>>>>> "y", >>>>>>>>>> then the other rules in "y" will only see records that pass filter >>>>>>>>>> "x". The beauty here is that you can reverse the rules so the >>>>>>>>>> "people >>>>>>>>>> matching filter" rule comes last. You have the flexibility to put >>>>>>>>>> it >>>>>>>>>> together to get the results you want. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> I agree here. There is no bug in the proxie databases, they work as >>>>>>>>> they >>>>>>>>> should. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Yes, I agree that there is no bug in the proxies, nor in the >>>>>>>> filters. >>>>>>>> >>>>>>>> I've been continuing to play with proxies and filters, and I'm not >>>>>>>> sure that just changing the order is the right thing to do. But we >>>>>>>> all >>>>>>>> have to at least agree on what the issues are. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> The proxies are not commutative however according to Doug, first >>>>>>>>> filter, >>>>>>>>> then private is different from first private then filter proxie >>>>>>>>> (see >>>>>>>>> the >>>>>>>>> descendant of and then private versus private then descendant). >>>>>>>>> Thinking >>>>>>>>> about this, this seems indeed strange, as Gerald indicates, they >>>>>>>>> should >>>>>>>>> return the same result... >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> This is easy to see that Filters/Proxies are not commutative: >>>>>>>> Consider >>>>>>>> a database with three people: Person A who has a son, Person B. >>>>>>>> Person >>>>>>>> B also has a son, Person C. Now mark Person B as private. >>>>>>>> >>>>>>>> If you apply the Private proxy first, then you effectively remove >>>>>>>> Person B from the database, and you will not find any connection >>>>>>>> between Person A and Person C. Thus, any filter that looks for a >>>>>>>> relationship between A and C will not find one. Descendants of A >>>>>>>> will >>>>>>>> not include C. This is how Gramps has worked for the last few years, >>>>>>>> when you export with a Private Proxy. >>>>>>>> >>>>>>>> On the other hand, if you do not apply the Private proxy first, >>>>>>>> there >>>>>>>> is no easy way to hide that relationship from the filters. You can >>>>>>>> try >>>>>>>> to make selections based on one's Private status, but that isn't >>>>>>>> considered when, for example, looking for descendants or ancestors. >>>>>>>> >>>>>>>> So, the first thing to realize is that filter-then-proxy is not >>>>>>>> guaranteed to be the same as proxy-then-filter. They are not >>>>>>>> commutative. >>>>>>>> >>>>>>>> The next thing to realize is that sometimes one may want to use >>>>>>>> private people in a filter, before having them removed. Thus, always >>>>>>>> applying the private proxy first may have effects on the filter that >>>>>>>> you may not realize, until you run an export. >>>>>>>> >>>>>>>> The final thing to realize is that a private filter does not take >>>>>>>> the >>>>>>>> place of the private proxy. Using a private filter only looks at a >>>>>>>> single person. Combining a private filter with, say, a descendant >>>>>>>> filter does not have any effect on limiting who is a descendant. As >>>>>>>> far as I can see, filters are commutative, and thus cannot be used >>>>>>>> to >>>>>>>> replace a proxy. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> The change of Doug means private is applied last. There is no real >>>>>>>>> reasoning >>>>>>>>> on why one or the other should be first, ..., well, perhaps there >>>>>>>>> is? >>>>>>>>> If >>>>>>>>> they really are not commutative, I think the order should be in the >>>>>>>>> way that >>>>>>>>> is most difficult (or impossible) to achieve via a normal filter >>>>>>>>> setup. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> If Benny's criteria is used, then the way that Gramps is now is the >>>>>>>> correct way: there is no easy way (that I see) to remove Person B >>>>>>>> (private) and Person C (public descendant) using just filters. >>>>>>>> >>>>>>>> On the other hand, selecting the proxy first can remove people that >>>>>>>> were important in constructing a filter, and a user might not notice >>>>>>>> until the export has been made, and then verified by examining what >>>>>>>> was exported. >>>>>>>> >>>>>>>> So what to do? I see four possibilities: >>>>>>>> >>>>>>>> 1) Leave as it is, Proxies first. To avoid having a Private proxy >>>>>>>> have >>>>>>>> adverse affects, a user can opt to not use the proxy, and use a >>>>>>>> private filter. I believe that a private filter is equivalent to a >>>>>>>> private proxy last. But this method causes confusion, even among >>>>>>>> long-time users (and developers) for why an exported group is what >>>>>>>> it >>>>>>>> is. >>>>>>>> >>>>>>>> 2) Change to proxies last. This is too limiting---users don't have >>>>>>>> the >>>>>>>> power that they need with just filters. >>>>>>>> >>>>>>>> 3) Allow each proxy to be applied before or after. Users would need >>>>>>>> to >>>>>>>> know the implications. However, this is still confusing and hard to >>>>>>>> verify. >>>>>>>> >>>>>>>> 4) Allow proxies to be used as a filter. I have no idea how this >>>>>>>> might >>>>>>>> work, but it would allow users to verify the selection and final >>>>>>>> output. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Do you mean, "allow the logic of the proxies to be used in >>>>>>> pre-defined >>>>>>> filters"? If so, I can see the value in that, though the "private" >>>>>>> proxy goes well beyond filtering. >>>>>>> >>>>>>> >>>>>> >>>>>> To understand the proposed option 4, "allow proxies to be used as a >>>>>> filter" one needs to appreciate that the three non-filter based >>>>>> proxies (Private, Living, and Note) are more powerful than >>>>>> user-constructed filters. That is, they alter what is accessible. For >>>>>> example, no combination of filters will prevent you from being able to >>>>>> select the children of a private person in a descendant filter. Only a >>>>>> proxy can do that. >>>>>> >>>>>> What I am suggesting is some manner to put the power of the proxy into >>>>>> the hands of the user, so that they can mix proxies >>>>>> between/before/after filters. This does two things: 1) it allows users >>>>>> to interactively and easily inspect their application of proxies and >>>>>> filters to check for correctness (without having to export and then >>>>>> import), and 2) it gives users the most control over when and how the >>>>>> proxies get applied. >>>>>> >>>>>> Having thoroughly examined the two use-cases in this thread (Jerome's >>>>>> and Benny's) we can get by with our current sequence (proxies before >>>>>> filters). Benny's example is the default behavior when applying the >>>>>> Private proxy (eg, block access to children of private people when >>>>>> combined with a descendant filter). Jerome can get exactly what he >>>>>> wants (I think) by writing a more complicated filter. The easiest way >>>>>> to construct Jerome's filter is with three filters, and no proxies: >>>>>> >>>>>> 1) not an ancestor of X filter >>>>>> 2) not private filter >>>>>> 3) mark "all rules must apply" >>>>>> >>>>>> This can also be accomplished with one filter, 2 rules: >>>>>> >>>>>> 1) an ancestor of X rule >>>>>> 2) private rule >>>>>> 3) mark "at least one rule must apply" >>>>>> 4) mark "those that do not match" >>>>>> >>>>>> BTW, Jerome's selection could also be done perhaps easier if we had >>>>>> the ability to add the "not" to each rule rather than to the entire >>>>>> filter selection. For example, one could select: >>>>>> >>>>>> 1) not ancestors of X rule >>>>>> 2) not private rule >>>>>> 3) mark "all rules must apply" >>>>>> >>>>>> What does not work in this case is to select "not ancestor of X" >>>>>> filter with the Private proxy (as it is applied first), as that messes >>>>>> up the ancestors (because it happens to have a private person in the >>>>>> ancestor chain). >>>>>> >>>>>> This suggests Option 3, where Jerome could have gotten the output he >>>>>> wanted with a "not ancestor of X" with the Private proxy applied last. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> I would not like to see the actual >>>>>>> modules available for use as filters, since that would likely require >>>>>>> logic to be added to them of the sort: >>>>>>> >>>>>>> if I am a proxy: >>>>>>> do this >>>>>>> else: >>>>>>> do that >>>>>>> >>>>>>> or would require the caller to be knowledgeable of the implementation >>>>>>> proxy, which can lead to maintenance headaches. >>>>>>> >>>>>>> >>>>>> >>>>>> Yeah, I can't see how we could mix proxies and filters together, other >>>>>> than having an interface like we do in export---allowing one to select >>>>>> the proxies and their ordering. One could do that in the filter >>>>>> sidebar... seeing as that would be complicated (and I have no interest >>>>>> in doing it) perhaps we can slightly tweak the export to do two fairly >>>>>> simple things: >>>>>> >>>>>> 1) allow proxies to be applied before/after the filter >>>>>> 2) right before the actual export, the display could show who would be >>>>>> selected >>>>>> >>>>>> These two things would go some distance to making the export more user >>>>>> friendly. It doesn't allow all use-cases (I can think of some, but >>>>>> they are not uses that people are asking for). >>>>>> >>>>>> -Doug >>>>>> >>>>>> >>>>> >>>>> This tread is becoming difficult to follow :-) >>>>> >>>>> >>>> >>>> This thread was difficult to write! This is complicated. I'm glad >>>> we're taking this slow and thoughtful. >>>> >>>> >>>> >>>>> >>>>> From what I read, am I correct to assume you would undo the change in >>>>> svn? >>>>> So first private again, because the other behaviour can be obtained >>>>> with >>>>> filters? >>>>> >>>>> >>>> >>>> Yes, even with the problems it raises, private proxy first has to be >>>> at least an option. >>>> >>>> >>>> >>>>> >>>>> I agree with 1) above, but for users better to use another word >>>>> (restricted >>>>> view or so). For 2), more like a preview button, people with large >>>>> databases >>>>> would not like to wait to see the result. >>>>> >>>>> >>>> >>>> Perhaps for 2) we can give more details (eg, display who is selected) >>>> as we are exporting, and a way to cancel. >>>> >>>> I think "view" is the right word, in description, and also related to >>>> what Gerald said. We have effectively created a view: >>>> >>>> self.dbase = \ >>>> gen.proxy.ReferencedProxyDb( >>>> gen.proxy.LivingProxyDb( >>>> gen.proxy.PrivateProxyDb( >>>> gen.proxy.FilterProxyDb( >>>> gen.proxy.FilterProxyDb( >>>> self.dbase, >>>> option_box.cfilter), >>>> note_filter=option_box.nfilter >>>> ) >>>> ), >>>> gen.proxy.LivingProxyDb.MODE_INCLUDE_LAST_NAME_ONLY) >>>> ) >>>> >>>> A "View" (what Gerald called a meta-proxy) might be a useful object to >>>> have users construct in a future Gramps to get the full power of what >>>> is possible. We have all of the code to do it---we're just missing a >>>> UI. >>>> >>>> For now, I will undo the changes in trunk, and try an ordering choice. >>>> >>>> -Doug >>>> >>>> >>>> >>>>> >>>>> Benny >>>>> >>>>> >>>>> >>>>>>> >>>>>>> Also, the filter proxy already uses filters, so that would be >>>>>>> redundant I suppose. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> The ideal would be option 4, but this might be hard or impossible, >>>>>>>> but >>>>>>>> should be explored. Option 3 is easier than 1 for the user, covers >>>>>>>> all >>>>>>>> known use-cases, but is still hard to verify. Option 2, I think, is >>>>>>>> out because it makes Gramps less powerful. Option 1 prevents some >>>>>>>> known use-cases. >>>>>>>> >>>>>>>> -Doug >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Benny >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Gramps-devel mailing list >>>>>>>> Gra...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Gerald Britton >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Gramps-devel mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>> >>>> >>>> >>>> >> >> >> > |
From: Benny M. <ben...@gm...> - 2010-05-18 20:11:59
|
2010/5/18 Nick Hall <nic...@ho...> > > > Doug Blank wrote: > >> On Tue, May 18, 2010 at 10:40 AM, Nick Hall <nic...@ho...> >> wrote: >> >> >>> In reading this thread, I am concerned that this may be getting too >>> complicated for the average user. Do we really want to expose the >>> concept >>> of both a proxy (or view) and a filter to the end user? >>> >>> >> >> We already do, implicitly. I think the Private proxy is the only one >> that may need to be handled in this way, and only when you use a >> filter, so it is: >> >> ( ) Include Private Objects >> ( ) Remove Private Objects before filter >> ( ) Remove Private Objects after filter >> >> >> > > There is no problem doing it implicitly like this. The user is not exposed > to the implementation. The options you have listed here are unambiguous. > > > Using the A, B, C descendants example, in selecting an option to "exclude >>> private data" I would expect to see person A and C. If the user doesn't >>> want person C then they should mark them as private. This could be >>> achieved >>> by applying the proxy last. I would consider the current results as a >>> bug. >>> >>> I can see why applying the proxy first produces different results, and in >>> some circumstances why this may be useful, but surely this approach would >>> be >>> confusing for "Aunt Martha" and may lead to unexpected results. Does >>> "proxy >>> first" really have to be an option? >>> >>> >> >> One compelling argument is that this is the way that Gramps has always >> operated, and people (such as Gerald) have constructed filters that >> depend on this operation. If we remove the private-proxy-first option, >> users would need to do what you suggest: mark everyone past the >> private person as private, too. >> >> >> > > In general, I would recommend fixing a bug even if some code relies on a > side effect of the bug. I don't think that the proxy-first option would be > the functionality that most people would expect. If you want to keep it private that C is a descendant of B (child reference can be made private), then you _don't_ want to expose this in eg a descendant report you want to give to somebody. So I do not agree with your interpretation of this as a bug. The proxy sees another database, where all private info is removed. It works as created. Changing private flag on objects should never be needed, so suggesting users to change private flags is not the way to go. As far as I see it, these are the use-cases: 1/ this is private, I really don't want anybody to know about this info. So eg ex-wifes, estranged brothers, illegal children. In all these cases, nothing should seep out to the outside world by accident. The consequences of such accidents lead to huge problems. I am very happy no users complained anymore the last two years about this on the user list. This is why the private proxie was created, and it seems to work excellent in doing this. 2/I don't want to see living people. Then all should be removed of those. The 'bug' of Jerome is hence no bug. If one is allowed to know about a private person, then it should not be set as private. Furthermore, for his own use, a researcher should never use the private flag, so if a researcher wants to know if somebody is family, ..., he should not activate the private exclusion. Benny > > Another argument is that what one considers private can change >> depending on the use of the output. For example, in one export, you >> might want to consider C and all of their family as off-limits. >> However, you might want to then turn around and create an export that >> has D (say, C's spouse) as private, and all of their family as >> off-limits. This would require a lot of work from the user to be able >> to do this without private-proxy-first. >> >> >> > > This is a better argument. I can see why people would find this useful. > > If I understand you correctly, the export is descendants of A. In one case > you want to also exclude descendants of C, and in the other descendants of > D. An easy way to do this is to change the private flag from C to D. > > The only way I use the private flag is more static - I don't change private > flags for a particular export. Do we want to encourage users to change > private flags for a particular export? > > The alternative would be to create more complicated filters. Would this be > too difficult for the average user? > > > I should add that I don't use this functionality much myself, but an >>> "apply >>> proxies before or after" option doesn't seem like a neat solution to me. >>> >>> >> >> Yes, looking for the best solution, consider ease-of-use, power, and >> flexibility. >> >> >> > > I'm sure that you'll come up with a good solution. I just wanted to remind > people of new and Aunt Martha type users and to avoid adding complexity if > it is not needed. > > > Nick. > > > > -Doug >> >> >> >>> Regards, >>> >>> >>> Nick. >>> >>> >>> Doug Blank wrote: >>> >>> >>>> On Tue, May 18, 2010 at 3:10 AM, Benny Malengier >>>> <ben...@gm...> wrote: >>>> >>>> >>>> >>>>> 2010/5/17 Doug Blank <dou...@gm...> >>>>> >>>>> >>>>> >>>>>> On Mon, May 17, 2010 at 10:05 AM, Gerald Britton >>>>>> <ger...@gm...> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Mon, May 17, 2010 at 8:22 AM, Doug Blank <dou...@gm...> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Mon, May 17, 2010 at 4:32 AM, Benny Malengier >>>>>>>> <ben...@gm...> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 2010/5/12 Gerald Britton <ger...@gm...> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> [snip] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> The same thing is done for filters when you use the rule "people >>>>>>>>>> matching filter x." If that is the first rule in a new filter >>>>>>>>>> "y", >>>>>>>>>> then the other rules in "y" will only see records that pass filter >>>>>>>>>> "x". The beauty here is that you can reverse the rules so the >>>>>>>>>> "people >>>>>>>>>> matching filter" rule comes last. You have the flexibility to put >>>>>>>>>> it >>>>>>>>>> together to get the results you want. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I agree here. There is no bug in the proxie databases, they work as >>>>>>>>> they >>>>>>>>> should. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Yes, I agree that there is no bug in the proxies, nor in the >>>>>>>> filters. >>>>>>>> >>>>>>>> I've been continuing to play with proxies and filters, and I'm not >>>>>>>> sure that just changing the order is the right thing to do. But we >>>>>>>> all >>>>>>>> have to at least agree on what the issues are. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> The proxies are not commutative however according to Doug, first >>>>>>>>> filter, >>>>>>>>> then private is different from first private then filter proxie >>>>>>>>> (see >>>>>>>>> the >>>>>>>>> descendant of and then private versus private then descendant). >>>>>>>>> Thinking >>>>>>>>> about this, this seems indeed strange, as Gerald indicates, they >>>>>>>>> should >>>>>>>>> return the same result... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> This is easy to see that Filters/Proxies are not commutative: >>>>>>>> Consider >>>>>>>> a database with three people: Person A who has a son, Person B. >>>>>>>> Person >>>>>>>> B also has a son, Person C. Now mark Person B as private. >>>>>>>> >>>>>>>> If you apply the Private proxy first, then you effectively remove >>>>>>>> Person B from the database, and you will not find any connection >>>>>>>> between Person A and Person C. Thus, any filter that looks for a >>>>>>>> relationship between A and C will not find one. Descendants of A >>>>>>>> will >>>>>>>> not include C. This is how Gramps has worked for the last few years, >>>>>>>> when you export with a Private Proxy. >>>>>>>> >>>>>>>> On the other hand, if you do not apply the Private proxy first, >>>>>>>> there >>>>>>>> is no easy way to hide that relationship from the filters. You can >>>>>>>> try >>>>>>>> to make selections based on one's Private status, but that isn't >>>>>>>> considered when, for example, looking for descendants or ancestors. >>>>>>>> >>>>>>>> So, the first thing to realize is that filter-then-proxy is not >>>>>>>> guaranteed to be the same as proxy-then-filter. They are not >>>>>>>> commutative. >>>>>>>> >>>>>>>> The next thing to realize is that sometimes one may want to use >>>>>>>> private people in a filter, before having them removed. Thus, always >>>>>>>> applying the private proxy first may have effects on the filter that >>>>>>>> you may not realize, until you run an export. >>>>>>>> >>>>>>>> The final thing to realize is that a private filter does not take >>>>>>>> the >>>>>>>> place of the private proxy. Using a private filter only looks at a >>>>>>>> single person. Combining a private filter with, say, a descendant >>>>>>>> filter does not have any effect on limiting who is a descendant. As >>>>>>>> far as I can see, filters are commutative, and thus cannot be used >>>>>>>> to >>>>>>>> replace a proxy. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> The change of Doug means private is applied last. There is no real >>>>>>>>> reasoning >>>>>>>>> on why one or the other should be first, ..., well, perhaps there >>>>>>>>> is? >>>>>>>>> If >>>>>>>>> they really are not commutative, I think the order should be in the >>>>>>>>> way that >>>>>>>>> is most difficult (or impossible) to achieve via a normal filter >>>>>>>>> setup. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> If Benny's criteria is used, then the way that Gramps is now is the >>>>>>>> correct way: there is no easy way (that I see) to remove Person B >>>>>>>> (private) and Person C (public descendant) using just filters. >>>>>>>> >>>>>>>> On the other hand, selecting the proxy first can remove people that >>>>>>>> were important in constructing a filter, and a user might not notice >>>>>>>> until the export has been made, and then verified by examining what >>>>>>>> was exported. >>>>>>>> >>>>>>>> So what to do? I see four possibilities: >>>>>>>> >>>>>>>> 1) Leave as it is, Proxies first. To avoid having a Private proxy >>>>>>>> have >>>>>>>> adverse affects, a user can opt to not use the proxy, and use a >>>>>>>> private filter. I believe that a private filter is equivalent to a >>>>>>>> private proxy last. But this method causes confusion, even among >>>>>>>> long-time users (and developers) for why an exported group is what >>>>>>>> it >>>>>>>> is. >>>>>>>> >>>>>>>> 2) Change to proxies last. This is too limiting---users don't have >>>>>>>> the >>>>>>>> power that they need with just filters. >>>>>>>> >>>>>>>> 3) Allow each proxy to be applied before or after. Users would need >>>>>>>> to >>>>>>>> know the implications. However, this is still confusing and hard to >>>>>>>> verify. >>>>>>>> >>>>>>>> 4) Allow proxies to be used as a filter. I have no idea how this >>>>>>>> might >>>>>>>> work, but it would allow users to verify the selection and final >>>>>>>> output. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Do you mean, "allow the logic of the proxies to be used in >>>>>>> pre-defined >>>>>>> filters"? If so, I can see the value in that, though the "private" >>>>>>> proxy goes well beyond filtering. >>>>>>> >>>>>>> >>>>>>> >>>>>> To understand the proposed option 4, "allow proxies to be used as a >>>>>> filter" one needs to appreciate that the three non-filter based >>>>>> proxies (Private, Living, and Note) are more powerful than >>>>>> user-constructed filters. That is, they alter what is accessible. For >>>>>> example, no combination of filters will prevent you from being able to >>>>>> select the children of a private person in a descendant filter. Only a >>>>>> proxy can do that. >>>>>> >>>>>> What I am suggesting is some manner to put the power of the proxy into >>>>>> the hands of the user, so that they can mix proxies >>>>>> between/before/after filters. This does two things: 1) it allows users >>>>>> to interactively and easily inspect their application of proxies and >>>>>> filters to check for correctness (without having to export and then >>>>>> import), and 2) it gives users the most control over when and how the >>>>>> proxies get applied. >>>>>> >>>>>> Having thoroughly examined the two use-cases in this thread (Jerome's >>>>>> and Benny's) we can get by with our current sequence (proxies before >>>>>> filters). Benny's example is the default behavior when applying the >>>>>> Private proxy (eg, block access to children of private people when >>>>>> combined with a descendant filter). Jerome can get exactly what he >>>>>> wants (I think) by writing a more complicated filter. The easiest way >>>>>> to construct Jerome's filter is with three filters, and no proxies: >>>>>> >>>>>> 1) not an ancestor of X filter >>>>>> 2) not private filter >>>>>> 3) mark "all rules must apply" >>>>>> >>>>>> This can also be accomplished with one filter, 2 rules: >>>>>> >>>>>> 1) an ancestor of X rule >>>>>> 2) private rule >>>>>> 3) mark "at least one rule must apply" >>>>>> 4) mark "those that do not match" >>>>>> >>>>>> BTW, Jerome's selection could also be done perhaps easier if we had >>>>>> the ability to add the "not" to each rule rather than to the entire >>>>>> filter selection. For example, one could select: >>>>>> >>>>>> 1) not ancestors of X rule >>>>>> 2) not private rule >>>>>> 3) mark "all rules must apply" >>>>>> >>>>>> What does not work in this case is to select "not ancestor of X" >>>>>> filter with the Private proxy (as it is applied first), as that messes >>>>>> up the ancestors (because it happens to have a private person in the >>>>>> ancestor chain). >>>>>> >>>>>> This suggests Option 3, where Jerome could have gotten the output he >>>>>> wanted with a "not ancestor of X" with the Private proxy applied last. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I would not like to see the actual >>>>>>> modules available for use as filters, since that would likely require >>>>>>> logic to be added to them of the sort: >>>>>>> >>>>>>> if I am a proxy: >>>>>>> do this >>>>>>> else: >>>>>>> do that >>>>>>> >>>>>>> or would require the caller to be knowledgeable of the implementation >>>>>>> proxy, which can lead to maintenance headaches. >>>>>>> >>>>>>> >>>>>>> >>>>>> Yeah, I can't see how we could mix proxies and filters together, other >>>>>> than having an interface like we do in export---allowing one to select >>>>>> the proxies and their ordering. One could do that in the filter >>>>>> sidebar... seeing as that would be complicated (and I have no interest >>>>>> in doing it) perhaps we can slightly tweak the export to do two fairly >>>>>> simple things: >>>>>> >>>>>> 1) allow proxies to be applied before/after the filter >>>>>> 2) right before the actual export, the display could show who would be >>>>>> selected >>>>>> >>>>>> These two things would go some distance to making the export more user >>>>>> friendly. It doesn't allow all use-cases (I can think of some, but >>>>>> they are not uses that people are asking for). >>>>>> >>>>>> -Doug >>>>>> >>>>>> >>>>>> >>>>> This tread is becoming difficult to follow :-) >>>>> >>>>> >>>>> >>>> This thread was difficult to write! This is complicated. I'm glad >>>> we're taking this slow and thoughtful. >>>> >>>> >>>> >>>> >>>>> From what I read, am I correct to assume you would undo the change in >>>>> svn? >>>>> So first private again, because the other behaviour can be obtained >>>>> with >>>>> filters? >>>>> >>>>> >>>>> >>>> Yes, even with the problems it raises, private proxy first has to be >>>> at least an option. >>>> >>>> >>>> >>>> >>>>> I agree with 1) above, but for users better to use another word >>>>> (restricted >>>>> view or so). For 2), more like a preview button, people with large >>>>> databases >>>>> would not like to wait to see the result. >>>>> >>>>> >>>>> >>>> Perhaps for 2) we can give more details (eg, display who is selected) >>>> as we are exporting, and a way to cancel. >>>> >>>> I think "view" is the right word, in description, and also related to >>>> what Gerald said. We have effectively created a view: >>>> >>>> self.dbase = \ >>>> gen.proxy.ReferencedProxyDb( >>>> gen.proxy.LivingProxyDb( >>>> gen.proxy.PrivateProxyDb( >>>> gen.proxy.FilterProxyDb( >>>> gen.proxy.FilterProxyDb( >>>> self.dbase, >>>> option_box.cfilter), >>>> note_filter=option_box.nfilter >>>> ) >>>> ), >>>> gen.proxy.LivingProxyDb.MODE_INCLUDE_LAST_NAME_ONLY) >>>> ) >>>> >>>> A "View" (what Gerald called a meta-proxy) might be a useful object to >>>> have users construct in a future Gramps to get the full power of what >>>> is possible. We have all of the code to do it---we're just missing a >>>> UI. >>>> >>>> For now, I will undo the changes in trunk, and try an ordering choice. >>>> >>>> -Doug >>>> >>>> >>>> >>>> >>>>> Benny >>>>> >>>>> >>>>> >>>>> >>>>>> Also, the filter proxy already uses filters, so that would be >>>>>>> redundant I suppose. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> The ideal would be option 4, but this might be hard or impossible, >>>>>>>> but >>>>>>>> should be explored. Option 3 is easier than 1 for the user, covers >>>>>>>> all >>>>>>>> known use-cases, but is still hard to verify. Option 2, I think, is >>>>>>>> out because it makes Gramps less powerful. Option 1 prevents some >>>>>>>> known use-cases. >>>>>>>> >>>>>>>> -Doug >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Benny >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Gramps-devel mailing list >>>>>>>> Gra...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Gerald Britton >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Gramps-devel mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>> >>>> >>>> >>>> >>>> >>> >> >> >> > |
From: Gerald B. <ger...@gm...> - 2010-05-18 20:30:58
|
This is more or less how I felt about this from the get-go. However, I do understand that in some cases, you may or may not get what you want. e.g. Say you want to filter out private records and living people. If you stack the proxies: living private real database the living proxy may not have as much data to work with to determine if someone is living and should be excluded. OTOH if you stack them: private living real database the living proxy has free reign to exclude living folks. The private proxy is at the top and so may exclude others as well. Whether either approach is incorrect is up for discussion. I can see it both ways. However, if you add a filter proxy to the mix, then all bets are off. I don't think that anyone can say that one combination is correct and another combination is incorrect. It's all in the eye of the beholder. Doug is wondering if we should let the user specify proxy order. I'm wondering if it is worth the effort. On Tue, May 18, 2010 at 4:11 PM, Benny Malengier <ben...@gm...> wrote: > > > 2010/5/18 Nick Hall <nic...@ho...> >> >> >> Doug Blank wrote: >>> >>> On Tue, May 18, 2010 at 10:40 AM, Nick Hall <nic...@ho...> >>> wrote: >>> >>>> >>>> In reading this thread, I am concerned that this may be getting too >>>> complicated for the average user. Do we really want to expose the >>>> concept >>>> of both a proxy (or view) and a filter to the end user? >>>> >>> >>> We already do, implicitly. I think the Private proxy is the only one >>> that may need to be handled in this way, and only when you use a >>> filter, so it is: >>> >>> ( ) Include Private Objects >>> ( ) Remove Private Objects before filter >>> ( ) Remove Private Objects after filter >>> >>> >> >> There is no problem doing it implicitly like this. The user is not >> exposed to the implementation. The options you have listed here are >> unambiguous. >> >>>> Using the A, B, C descendants example, in selecting an option to >>>> "exclude >>>> private data" I would expect to see person A and C. If the user doesn't >>>> want person C then they should mark them as private. This could be >>>> achieved >>>> by applying the proxy last. I would consider the current results as a >>>> bug. >>>> >>>> I can see why applying the proxy first produces different results, and >>>> in >>>> some circumstances why this may be useful, but surely this approach >>>> would be >>>> confusing for "Aunt Martha" and may lead to unexpected results. Does >>>> "proxy >>>> first" really have to be an option? >>>> >>> >>> One compelling argument is that this is the way that Gramps has always >>> operated, and people (such as Gerald) have constructed filters that >>> depend on this operation. If we remove the private-proxy-first option, >>> users would need to do what you suggest: mark everyone past the >>> private person as private, too. >>> >>> >> >> In general, I would recommend fixing a bug even if some code relies on a >> side effect of the bug. I don't think that the proxy-first option would be >> the functionality that most people would expect. > > If you want to keep it private that C is a descendant of B (child reference > can be made private), then you _don't_ want to expose this in eg a > descendant report you want to give to somebody. > > So I do not agree with your interpretation of this as a bug. The proxy sees > another database, where all private info is removed. It works as created. > > Changing private flag on objects should never be needed, so suggesting users > to change private flags is not the way to go. > > As far as I see it, these are the use-cases: > > 1/ this is private, I really don't want anybody to know about this info. So > eg ex-wifes, estranged brothers, illegal children. In all these cases, > nothing should seep out to the outside world by accident. The consequences > of such accidents lead to huge problems. I am very happy no users complained > anymore the last two years about this on the user list. This is why the > private proxie was created, and it seems to work excellent in doing this. > > 2/I don't want to see living people. Then all should be removed of those. > > The 'bug' of Jerome is hence no bug. If one is allowed to know about a > private person, then it should not be set as private. Furthermore, for his > own use, a researcher should never use the private flag, so if a researcher > wants to know if somebody is family, ..., he should not activate the private > exclusion. > > Benny > >> >> >>> Another argument is that what one considers private can change >>> depending on the use of the output. For example, in one export, you >>> might want to consider C and all of their family as off-limits. >>> However, you might want to then turn around and create an export that >>> has D (say, C's spouse) as private, and all of their family as >>> off-limits. This would require a lot of work from the user to be able >>> to do this without private-proxy-first. >>> >>> >> >> This is a better argument. I can see why people would find this useful. >> >> If I understand you correctly, the export is descendants of A. In one >> case you want to also exclude descendants of C, and in the other descendants >> of D. An easy way to do this is to change the private flag from C to D. >> >> The only way I use the private flag is more static - I don't change >> private flags for a particular export. Do we want to encourage users to >> change private flags for a particular export? >> >> The alternative would be to create more complicated filters. Would this >> be too difficult for the average user? >> >>>> I should add that I don't use this functionality much myself, but an >>>> "apply >>>> proxies before or after" option doesn't seem like a neat solution to me. >>>> >>> >>> Yes, looking for the best solution, consider ease-of-use, power, and >>> flexibility. >>> >>> >> >> I'm sure that you'll come up with a good solution. I just wanted to >> remind people of new and Aunt Martha type users and to avoid adding >> complexity if it is not needed. >> >> >> Nick. >> >> >>> -Doug >>> >>> >>>> >>>> Regards, >>>> >>>> >>>> Nick. >>>> >>>> >>>> Doug Blank wrote: >>>> >>>>> >>>>> On Tue, May 18, 2010 at 3:10 AM, Benny Malengier >>>>> <ben...@gm...> wrote: >>>>> >>>>> >>>>>> >>>>>> 2010/5/17 Doug Blank <dou...@gm...> >>>>>> >>>>>> >>>>>>> >>>>>>> On Mon, May 17, 2010 at 10:05 AM, Gerald Britton >>>>>>> <ger...@gm...> wrote: >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Mon, May 17, 2010 at 8:22 AM, Doug Blank <dou...@gm...> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, May 17, 2010 at 4:32 AM, Benny Malengier >>>>>>>>> <ben...@gm...> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2010/5/12 Gerald Britton <ger...@gm...> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> [snip] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The same thing is done for filters when you use the rule "people >>>>>>>>>>> matching filter x." If that is the first rule in a new filter >>>>>>>>>>> "y", >>>>>>>>>>> then the other rules in "y" will only see records that pass >>>>>>>>>>> filter >>>>>>>>>>> "x". The beauty here is that you can reverse the rules so the >>>>>>>>>>> "people >>>>>>>>>>> matching filter" rule comes last. You have the flexibility to >>>>>>>>>>> put >>>>>>>>>>> it >>>>>>>>>>> together to get the results you want. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I agree here. There is no bug in the proxie databases, they work >>>>>>>>>> as >>>>>>>>>> they >>>>>>>>>> should. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yes, I agree that there is no bug in the proxies, nor in the >>>>>>>>> filters. >>>>>>>>> >>>>>>>>> I've been continuing to play with proxies and filters, and I'm not >>>>>>>>> sure that just changing the order is the right thing to do. But we >>>>>>>>> all >>>>>>>>> have to at least agree on what the issues are. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> The proxies are not commutative however according to Doug, first >>>>>>>>>> filter, >>>>>>>>>> then private is different from first private then filter proxie >>>>>>>>>> (see >>>>>>>>>> the >>>>>>>>>> descendant of and then private versus private then descendant). >>>>>>>>>> Thinking >>>>>>>>>> about this, this seems indeed strange, as Gerald indicates, they >>>>>>>>>> should >>>>>>>>>> return the same result... >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> This is easy to see that Filters/Proxies are not commutative: >>>>>>>>> Consider >>>>>>>>> a database with three people: Person A who has a son, Person B. >>>>>>>>> Person >>>>>>>>> B also has a son, Person C. Now mark Person B as private. >>>>>>>>> >>>>>>>>> If you apply the Private proxy first, then you effectively remove >>>>>>>>> Person B from the database, and you will not find any connection >>>>>>>>> between Person A and Person C. Thus, any filter that looks for a >>>>>>>>> relationship between A and C will not find one. Descendants of A >>>>>>>>> will >>>>>>>>> not include C. This is how Gramps has worked for the last few >>>>>>>>> years, >>>>>>>>> when you export with a Private Proxy. >>>>>>>>> >>>>>>>>> On the other hand, if you do not apply the Private proxy first, >>>>>>>>> there >>>>>>>>> is no easy way to hide that relationship from the filters. You can >>>>>>>>> try >>>>>>>>> to make selections based on one's Private status, but that isn't >>>>>>>>> considered when, for example, looking for descendants or ancestors. >>>>>>>>> >>>>>>>>> So, the first thing to realize is that filter-then-proxy is not >>>>>>>>> guaranteed to be the same as proxy-then-filter. They are not >>>>>>>>> commutative. >>>>>>>>> >>>>>>>>> The next thing to realize is that sometimes one may want to use >>>>>>>>> private people in a filter, before having them removed. Thus, >>>>>>>>> always >>>>>>>>> applying the private proxy first may have effects on the filter >>>>>>>>> that >>>>>>>>> you may not realize, until you run an export. >>>>>>>>> >>>>>>>>> The final thing to realize is that a private filter does not take >>>>>>>>> the >>>>>>>>> place of the private proxy. Using a private filter only looks at a >>>>>>>>> single person. Combining a private filter with, say, a descendant >>>>>>>>> filter does not have any effect on limiting who is a descendant. As >>>>>>>>> far as I can see, filters are commutative, and thus cannot be used >>>>>>>>> to >>>>>>>>> replace a proxy. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> The change of Doug means private is applied last. There is no real >>>>>>>>>> reasoning >>>>>>>>>> on why one or the other should be first, ..., well, perhaps there >>>>>>>>>> is? >>>>>>>>>> If >>>>>>>>>> they really are not commutative, I think the order should be in >>>>>>>>>> the >>>>>>>>>> way that >>>>>>>>>> is most difficult (or impossible) to achieve via a normal filter >>>>>>>>>> setup. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> If Benny's criteria is used, then the way that Gramps is now is the >>>>>>>>> correct way: there is no easy way (that I see) to remove Person B >>>>>>>>> (private) and Person C (public descendant) using just filters. >>>>>>>>> >>>>>>>>> On the other hand, selecting the proxy first can remove people that >>>>>>>>> were important in constructing a filter, and a user might not >>>>>>>>> notice >>>>>>>>> until the export has been made, and then verified by examining what >>>>>>>>> was exported. >>>>>>>>> >>>>>>>>> So what to do? I see four possibilities: >>>>>>>>> >>>>>>>>> 1) Leave as it is, Proxies first. To avoid having a Private proxy >>>>>>>>> have >>>>>>>>> adverse affects, a user can opt to not use the proxy, and use a >>>>>>>>> private filter. I believe that a private filter is equivalent to a >>>>>>>>> private proxy last. But this method causes confusion, even among >>>>>>>>> long-time users (and developers) for why an exported group is what >>>>>>>>> it >>>>>>>>> is. >>>>>>>>> >>>>>>>>> 2) Change to proxies last. This is too limiting---users don't have >>>>>>>>> the >>>>>>>>> power that they need with just filters. >>>>>>>>> >>>>>>>>> 3) Allow each proxy to be applied before or after. Users would need >>>>>>>>> to >>>>>>>>> know the implications. However, this is still confusing and hard to >>>>>>>>> verify. >>>>>>>>> >>>>>>>>> 4) Allow proxies to be used as a filter. I have no idea how this >>>>>>>>> might >>>>>>>>> work, but it would allow users to verify the selection and final >>>>>>>>> output. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Do you mean, "allow the logic of the proxies to be used in >>>>>>>> pre-defined >>>>>>>> filters"? If so, I can see the value in that, though the "private" >>>>>>>> proxy goes well beyond filtering. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> To understand the proposed option 4, "allow proxies to be used as a >>>>>>> filter" one needs to appreciate that the three non-filter based >>>>>>> proxies (Private, Living, and Note) are more powerful than >>>>>>> user-constructed filters. That is, they alter what is accessible. For >>>>>>> example, no combination of filters will prevent you from being able >>>>>>> to >>>>>>> select the children of a private person in a descendant filter. Only >>>>>>> a >>>>>>> proxy can do that. >>>>>>> >>>>>>> What I am suggesting is some manner to put the power of the proxy >>>>>>> into >>>>>>> the hands of the user, so that they can mix proxies >>>>>>> between/before/after filters. This does two things: 1) it allows >>>>>>> users >>>>>>> to interactively and easily inspect their application of proxies and >>>>>>> filters to check for correctness (without having to export and then >>>>>>> import), and 2) it gives users the most control over when and how the >>>>>>> proxies get applied. >>>>>>> >>>>>>> Having thoroughly examined the two use-cases in this thread (Jerome's >>>>>>> and Benny's) we can get by with our current sequence (proxies before >>>>>>> filters). Benny's example is the default behavior when applying the >>>>>>> Private proxy (eg, block access to children of private people when >>>>>>> combined with a descendant filter). Jerome can get exactly what he >>>>>>> wants (I think) by writing a more complicated filter. The easiest way >>>>>>> to construct Jerome's filter is with three filters, and no proxies: >>>>>>> >>>>>>> 1) not an ancestor of X filter >>>>>>> 2) not private filter >>>>>>> 3) mark "all rules must apply" >>>>>>> >>>>>>> This can also be accomplished with one filter, 2 rules: >>>>>>> >>>>>>> 1) an ancestor of X rule >>>>>>> 2) private rule >>>>>>> 3) mark "at least one rule must apply" >>>>>>> 4) mark "those that do not match" >>>>>>> >>>>>>> BTW, Jerome's selection could also be done perhaps easier if we had >>>>>>> the ability to add the "not" to each rule rather than to the entire >>>>>>> filter selection. For example, one could select: >>>>>>> >>>>>>> 1) not ancestors of X rule >>>>>>> 2) not private rule >>>>>>> 3) mark "all rules must apply" >>>>>>> >>>>>>> What does not work in this case is to select "not ancestor of X" >>>>>>> filter with the Private proxy (as it is applied first), as that >>>>>>> messes >>>>>>> up the ancestors (because it happens to have a private person in the >>>>>>> ancestor chain). >>>>>>> >>>>>>> This suggests Option 3, where Jerome could have gotten the output he >>>>>>> wanted with a "not ancestor of X" with the Private proxy applied >>>>>>> last. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> I would not like to see the actual >>>>>>>> modules available for use as filters, since that would likely >>>>>>>> require >>>>>>>> logic to be added to them of the sort: >>>>>>>> >>>>>>>> if I am a proxy: >>>>>>>> do this >>>>>>>> else: >>>>>>>> do that >>>>>>>> >>>>>>>> or would require the caller to be knowledgeable of the >>>>>>>> implementation >>>>>>>> proxy, which can lead to maintenance headaches. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Yeah, I can't see how we could mix proxies and filters together, >>>>>>> other >>>>>>> than having an interface like we do in export---allowing one to >>>>>>> select >>>>>>> the proxies and their ordering. One could do that in the filter >>>>>>> sidebar... seeing as that would be complicated (and I have no >>>>>>> interest >>>>>>> in doing it) perhaps we can slightly tweak the export to do two >>>>>>> fairly >>>>>>> simple things: >>>>>>> >>>>>>> 1) allow proxies to be applied before/after the filter >>>>>>> 2) right before the actual export, the display could show who would >>>>>>> be >>>>>>> selected >>>>>>> >>>>>>> These two things would go some distance to making the export more >>>>>>> user >>>>>>> friendly. It doesn't allow all use-cases (I can think of some, but >>>>>>> they are not uses that people are asking for). >>>>>>> >>>>>>> -Doug >>>>>>> >>>>>>> >>>>>> >>>>>> This tread is becoming difficult to follow :-) >>>>>> >>>>>> >>>>> >>>>> This thread was difficult to write! This is complicated. I'm glad >>>>> we're taking this slow and thoughtful. >>>>> >>>>> >>>>> >>>>>> >>>>>> From what I read, am I correct to assume you would undo the change in >>>>>> svn? >>>>>> So first private again, because the other behaviour can be obtained >>>>>> with >>>>>> filters? >>>>>> >>>>>> >>>>> >>>>> Yes, even with the problems it raises, private proxy first has to be >>>>> at least an option. >>>>> >>>>> >>>>> >>>>>> >>>>>> I agree with 1) above, but for users better to use another word >>>>>> (restricted >>>>>> view or so). For 2), more like a preview button, people with large >>>>>> databases >>>>>> would not like to wait to see the result. >>>>>> >>>>>> >>>>> >>>>> Perhaps for 2) we can give more details (eg, display who is selected) >>>>> as we are exporting, and a way to cancel. >>>>> >>>>> I think "view" is the right word, in description, and also related to >>>>> what Gerald said. We have effectively created a view: >>>>> >>>>> self.dbase = \ >>>>> gen.proxy.ReferencedProxyDb( >>>>> gen.proxy.LivingProxyDb( >>>>> gen.proxy.PrivateProxyDb( >>>>> gen.proxy.FilterProxyDb( >>>>> gen.proxy.FilterProxyDb( >>>>> self.dbase, >>>>> option_box.cfilter), >>>>> note_filter=option_box.nfilter >>>>> ) >>>>> ), >>>>> gen.proxy.LivingProxyDb.MODE_INCLUDE_LAST_NAME_ONLY) >>>>> ) >>>>> >>>>> A "View" (what Gerald called a meta-proxy) might be a useful object to >>>>> have users construct in a future Gramps to get the full power of what >>>>> is possible. We have all of the code to do it---we're just missing a >>>>> UI. >>>>> >>>>> For now, I will undo the changes in trunk, and try an ordering choice. >>>>> >>>>> -Doug >>>>> >>>>> >>>>> >>>>>> >>>>>> Benny >>>>>> >>>>>> >>>>>> >>>>>>>> >>>>>>>> Also, the filter proxy already uses filters, so that would be >>>>>>>> redundant I suppose. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> The ideal would be option 4, but this might be hard or impossible, >>>>>>>>> but >>>>>>>>> should be explored. Option 3 is easier than 1 for the user, covers >>>>>>>>> all >>>>>>>>> known use-cases, but is still hard to verify. Option 2, I think, is >>>>>>>>> out because it makes Gramps less powerful. Option 1 prevents some >>>>>>>>> known use-cases. >>>>>>>>> >>>>>>>>> -Doug >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Benny >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Gramps-devel mailing list >>>>>>>>> Gra...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Gerald Britton >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Gramps-devel mailing list >>>>> Gra...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > -- Gerald Britton |
From: Nick H. <nic...@ho...> - 2010-05-18 23:10:53
|
Benny Malengier wrote: > > > 2010/5/18 Nick Hall <nic...@ho... > <mailto:nic...@ho...>> > > > > Doug Blank wrote: > > On Tue, May 18, 2010 at 10:40 AM, Nick Hall > <nic...@ho... <mailto:nic...@ho...>> wrote: > > > In reading this thread, I am concerned that this may be > getting too > complicated for the average user. Do we really want to > expose the concept > of both a proxy (or view) and a filter to the end user? > > > > We already do, implicitly. I think the Private proxy is the > only one > that may need to be handled in this way, and only when you use a > filter, so it is: > > ( ) Include Private Objects > ( ) Remove Private Objects before filter > ( ) Remove Private Objects after filter > > > > > There is no problem doing it implicitly like this. The user is > not exposed to the implementation. The options you have listed > here are unambiguous. > > > Using the A, B, C descendants example, in selecting an > option to "exclude > private data" I would expect to see person A and C. If > the user doesn't > want person C then they should mark them as private. This > could be achieved > by applying the proxy last. I would consider the current > results as a bug. > > I can see why applying the proxy first produces different > results, and in > some circumstances why this may be useful, but surely this > approach would be > confusing for "Aunt Martha" and may lead to unexpected > results. Does "proxy > first" really have to be an option? > > > > One compelling argument is that this is the way that Gramps > has always > operated, and people (such as Gerald) have constructed filters > that > depend on this operation. If we remove the private-proxy-first > option, > users would need to do what you suggest: mark everyone past the > private person as private, too. > > > > > In general, I would recommend fixing a bug even if some code > relies on a side effect of the bug. I don't think that the > proxy-first option would be the functionality that most people > would expect. > > > If you want to keep it private that C is a descendant of B (child > reference can be made private), then you _don't_ want to expose this > in eg a descendant report you want to give to somebody. > Thanks, this is a good example. I was thinking more along the lines of exports and the private flag on person objects. If the person objects for A, B and C are public but the child reference between B and C is private then C should not appear on a descendant report for A. > So I do not agree with your interpretation of this as a bug. The proxy > sees another database, where all private info is removed. It works as > created. Yes, I agree with you now. I can see why it was done this way. > > Changing private flag on objects should never be needed, so suggesting > users to change private flags is not the way to go. Yes, if you change a private flag you may forget to change it back. I thought that Doug was suggesting this in his example, but I probably misunderstood what he meant. > > As far as I see it, these are the use-cases: > > 1/ this is private, I really don't want anybody to know about this > info. So eg ex-wifes, estranged brothers, illegal children. In all > these cases, nothing should seep out to the outside world by accident. > The consequences of such accidents lead to huge problems. I am very > happy no users complained anymore the last two years about this on the > user list. This is why the private proxie was created, and it seems to > work excellent in doing this. > > 2/I don't want to see living people. Then all should be removed of those. > > The 'bug' of Jerome is hence no bug. If one is allowed to know about a > private person, then it should not be set as private. Furthermore, for > his own use, a researcher should never use the private flag, so if a > researcher wants to know if somebody is family, ..., he should not > activate the private exclusion. > These were the kind of use-cases I was thinking of. I still have a concern that we may still be making things too complicated for the average user. Suppose we give the options "Remove Private Objects before filter" and "Remove Private Objects after filter" - if the user doesn't appreciate the difference they may select the wrong one by mistake and inadvertently expose data they didn't mean to. Nick. > Benny > > > > Another argument is that what one considers private can change > depending on the use of the output. For example, in one > export, you > might want to consider C and all of their family as off-limits. > However, you might want to then turn around and create an > export that > has D (say, C's spouse) as private, and all of their family as > off-limits. This would require a lot of work from the user to > be able > to do this without private-proxy-first. > > > > > This is a better argument. I can see why people would find this > useful. > > If I understand you correctly, the export is descendants of A. In > one case you want to also exclude descendants of C, and in the > other descendants of D. An easy way to do this is to change the > private flag from C to D. > > The only way I use the private flag is more static - I don't > change private flags for a particular export. Do we want to > encourage users to change private flags for a particular export? > > The alternative would be to create more complicated filters. > Would this be too difficult for the average user? > > > I should add that I don't use this functionality much > myself, but an "apply > proxies before or after" option doesn't seem like a neat > solution to me. > > > > Yes, looking for the best solution, consider ease-of-use, > power, and > flexibility. > > > > > I'm sure that you'll come up with a good solution. I just wanted > to remind people of new and Aunt Martha type users and to avoid > adding complexity if it is not needed. > > > Nick. > > > > -Doug > > > > Regards, > > > Nick. > > > Doug Blank wrote: > > > On Tue, May 18, 2010 at 3:10 AM, Benny Malengier > <ben...@gm... > <mailto:ben...@gm...>> wrote: > > > > 2010/5/17 Doug Blank <dou...@gm... > <mailto:dou...@gm...>> > > > > On Mon, May 17, 2010 at 10:05 AM, Gerald Britton > <ger...@gm... > <mailto:ger...@gm...>> wrote: > > > > On Mon, May 17, 2010 at 8:22 AM, Doug > Blank <dou...@gm... > <mailto:dou...@gm...>> > wrote: > > > > On Mon, May 17, 2010 at 4:32 AM, Benny > Malengier > <ben...@gm... > <mailto:ben...@gm...>> wrote: > > > > 2010/5/12 Gerald Britton > <ger...@gm... > <mailto:ger...@gm...>> > > > > [snip] > > > > > The same thing is done for > filters when you use the rule > "people > matching filter x." If that > is the first rule in a new > filter "y", > then the other rules in "y" > will only see records that > pass filter > "x". The beauty here is that > you can reverse the rules so the > "people > matching filter" rule comes > last. You have the > flexibility to put > it > together to get the results > you want. > > > > > I agree here. There is no bug in > the proxie databases, they work as > they > should. > > > > Yes, I agree that there is no bug in > the proxies, nor in the filters. > > I've been continuing to play with > proxies and filters, and I'm not > sure that just changing the order is > the right thing to do. But we all > have to at least agree on what the > issues are. > > > > > The proxies are not commutative > however according to Doug, first > filter, > then private is different from > first private then filter proxie (see > the > descendant of and then private > versus private then descendant). > Thinking > about this, this seems indeed > strange, as Gerald indicates, they > should > return the same result... > > > > This is easy to see that > Filters/Proxies are not commutative: > Consider > a database with three people: Person A > who has a son, Person B. Person > B also has a son, Person C. Now mark > Person B as private. > > If you apply the Private proxy first, > then you effectively remove > Person B from the database, and you > will not find any connection > between Person A and Person C. Thus, > any filter that looks for a > relationship between A and C will not > find one. Descendants of A will > not include C. This is how Gramps has > worked for the last few years, > when you export with a Private Proxy. > > On the other hand, if you do not apply > the Private proxy first, there > is no easy way to hide that > relationship from the filters. You can try > to make selections based on one's > Private status, but that isn't > considered when, for example, looking > for descendants or ancestors. > > So, the first thing to realize is that > filter-then-proxy is not > guaranteed to be the same as > proxy-then-filter. They are not > commutative. > > The next thing to realize is that > sometimes one may want to use > private people in a filter, before > having them removed. Thus, always > applying the private proxy first may > have effects on the filter that > you may not realize, until you run an > export. > > The final thing to realize is that a > private filter does not take the > place of the private proxy. Using a > private filter only looks at a > single person. Combining a private > filter with, say, a descendant > filter does not have any effect on > limiting who is a descendant. As > far as I can see, filters are > commutative, and thus cannot be used to > replace a proxy. > > > > > The change of Doug means private > is applied last. There is no real > reasoning > on why one or the other should be > first, ..., well, perhaps there is? > If > they really are not commutative, I > think the order should be in the > way that > is most difficult (or impossible) > to achieve via a normal filter > setup. > > > > If Benny's criteria is used, then the > way that Gramps is now is the > correct way: there is no easy way > (that I see) to remove Person B > (private) and Person C (public > descendant) using just filters. > > On the other hand, selecting the proxy > first can remove people that > were important in constructing a > filter, and a user might not notice > until the export has been made, and > then verified by examining what > was exported. > > So what to do? I see four possibilities: > > 1) Leave as it is, Proxies first. To > avoid having a Private proxy have > adverse affects, a user can opt to not > use the proxy, and use a > private filter. I believe that a > private filter is equivalent to a > private proxy last. But this method > causes confusion, even among > long-time users (and developers) for > why an exported group is what it > is. > > 2) Change to proxies last. This is too > limiting---users don't have the > power that they need with just filters. > > 3) Allow each proxy to be applied > before or after. Users would need to > know the implications. However, this > is still confusing and hard to > verify. > > 4) Allow proxies to be used as a > filter. I have no idea how this might > work, but it would allow users to > verify the selection and final > output. > > > > Do you mean, "allow the logic of the > proxies to be used in pre-defined > filters"? If so, I can see the value in > that, though the "private" > proxy goes well beyond filtering. > > > > To understand the proposed option 4, "allow > proxies to be used as a > filter" one needs to appreciate that the three > non-filter based > proxies (Private, Living, and Note) are more > powerful than > user-constructed filters. That is, they alter > what is accessible. For > example, no combination of filters will > prevent you from being able to > select the children of a private person in a > descendant filter. Only a > proxy can do that. > > What I am suggesting is some manner to put the > power of the proxy into > the hands of the user, so that they can mix > proxies > between/before/after filters. This does two > things: 1) it allows users > to interactively and easily inspect their > application of proxies and > filters to check for correctness (without > having to export and then > import), and 2) it gives users the most > control over when and how the > proxies get applied. > > Having thoroughly examined the two use-cases > in this thread (Jerome's > and Benny's) we can get by with our current > sequence (proxies before > filters). Benny's example is the default > behavior when applying the > Private proxy (eg, block access to children of > private people when > combined with a descendant filter). Jerome can > get exactly what he > wants (I think) by writing a more complicated > filter. The easiest way > to construct Jerome's filter is with three > filters, and no proxies: > > 1) not an ancestor of X filter > 2) not private filter > 3) mark "all rules must apply" > > This can also be accomplished with one filter, > 2 rules: > > 1) an ancestor of X rule > 2) private rule > 3) mark "at least one rule must apply" > 4) mark "those that do not match" > > BTW, Jerome's selection could also be done > perhaps easier if we had > the ability to add the "not" to each rule > rather than to the entire > filter selection. For example, one could select: > > 1) not ancestors of X rule > 2) not private rule > 3) mark "all rules must apply" > > What does not work in this case is to select > "not ancestor of X" > filter with the Private proxy (as it is > applied first), as that messes > up the ancestors (because it happens to have a > private person in the > ancestor chain). > > This suggests Option 3, where Jerome could > have gotten the output he > wanted with a "not ancestor of X" with the > Private proxy applied last. > > > > > I would not like to see the actual > modules available for use as filters, > since that would likely require > logic to be added to them of the sort: > > if I am a proxy: > do this > else: > do that > > or would require the caller to be > knowledgeable of the implementation > proxy, which can lead to maintenance > headaches. > > > > Yeah, I can't see how we could mix proxies and > filters together, other > than having an interface like we do in > export---allowing one to select > the proxies and their ordering. One could do > that in the filter > sidebar... seeing as that would be complicated > (and I have no interest > in doing it) perhaps we can slightly tweak the > export to do two fairly > simple things: > > 1) allow proxies to be applied before/after > the filter > 2) right before the actual export, the display > could show who would be > selected > > These two things would go some distance to > making the export more user > friendly. It doesn't allow all use-cases (I > can think of some, but > they are not uses that people are asking for). > > -Doug > > > > This tread is becoming difficult to follow :-) > > > > This thread was difficult to write! This is > complicated. I'm glad > we're taking this slow and thoughtful. > > > > > >From what I read, am I correct to assume you > would undo the change in > svn? > So first private again, because the other > behaviour can be obtained with > filters? > > > > Yes, even with the problems it raises, private proxy > first has to be > at least an option. > > > > > I agree with 1) above, but for users better to use > another word > (restricted > view or so). For 2), more like a preview button, > people with large > databases > would not like to wait to see the result. > > > > Perhaps for 2) we can give more details (eg, display > who is selected) > as we are exporting, and a way to cancel. > > I think "view" is the right word, in description, and > also related to > what Gerald said. We have effectively created a view: > > self.dbase = \ > gen.proxy.ReferencedProxyDb( > gen.proxy.LivingProxyDb( > gen.proxy.PrivateProxyDb( > gen.proxy.FilterProxyDb( > gen.proxy.FilterProxyDb( > self.dbase, > option_box.cfilter), > note_filter=option_box.nfilter > ) > ), > gen.proxy.LivingProxyDb.MODE_INCLUDE_LAST_NAME_ONLY) > ) > > A "View" (what Gerald called a meta-proxy) might be a > useful object to > have users construct in a future Gramps to get the > full power of what > is possible. We have all of the code to do it---we're > just missing a > UI. > > For now, I will undo the changes in trunk, and try an > ordering choice. > > -Doug > > > > > Benny > > > > > Also, the filter proxy already uses > filters, so that would be > redundant I suppose. > > > > > > The ideal would be option 4, but this > might be hard or impossible, but > should be explored. Option 3 is easier > than 1 for the user, covers all > known use-cases, but is still hard to > verify. Option 2, I think, is > out because it makes Gramps less > powerful. Option 1 prevents some > known use-cases. > > -Doug > > > > > Benny > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > <mailto:Gra...@li...> > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > > -- > Gerald Britton > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > <mailto:Gra...@li...> > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > > > > > > > |
From: Doug B. <dou...@gm...> - 2010-05-19 00:02:43
|
On Tue, May 18, 2010 at 7:10 PM, Nick Hall <nic...@ho...> wrote: > > > Benny Malengier wrote: >> >> >> 2010/5/18 Nick Hall <nic...@ho... >> <mailto:nic...@ho...>> >> >> >> >> Doug Blank wrote: >> >> On Tue, May 18, 2010 at 10:40 AM, Nick Hall >> <nic...@ho... <mailto:nic...@ho...>> wrote: >> >> In reading this thread, I am concerned that this may be >> getting too >> complicated for the average user. Do we really want to >> expose the concept >> of both a proxy (or view) and a filter to the end user? >> >> >> We already do, implicitly. I think the Private proxy is the >> only one >> that may need to be handled in this way, and only when you use a >> filter, so it is: >> >> ( ) Include Private Objects >> ( ) Remove Private Objects before filter >> ( ) Remove Private Objects after filter >> >> >> >> There is no problem doing it implicitly like this. The user is >> not exposed to the implementation. The options you have listed >> here are unambiguous. >> >> >> Using the A, B, C descendants example, in selecting an >> option to "exclude >> private data" I would expect to see person A and C. If >> the user doesn't >> want person C then they should mark them as private. This >> could be achieved >> by applying the proxy last. I would consider the current >> results as a bug. >> >> I can see why applying the proxy first produces different >> results, and in >> some circumstances why this may be useful, but surely this >> approach would be >> confusing for "Aunt Martha" and may lead to unexpected >> results. Does "proxy >> first" really have to be an option? >> >> >> One compelling argument is that this is the way that Gramps >> has always >> operated, and people (such as Gerald) have constructed filters >> that >> depend on this operation. If we remove the private-proxy-first >> option, >> users would need to do what you suggest: mark everyone past the >> private person as private, too. >> >> >> >> In general, I would recommend fixing a bug even if some code >> relies on a side effect of the bug. I don't think that the >> proxy-first option would be the functionality that most people >> would expect. >> >> >> If you want to keep it private that C is a descendant of B (child >> reference can be made private), then you _don't_ want to expose this in eg a >> descendant report you want to give to somebody. >> > > Thanks, this is a good example. I was thinking more along the lines of > exports and the private flag on person objects. > > If the person objects for A, B and C are public but the child reference > between B and C is private then C should not appear on a descendant report > for A. > >> So I do not agree with your interpretation of this as a bug. The proxy >> sees another database, where all private info is removed. It works as >> created. > > Yes, I agree with you now. I can see why it was done this way. > >> >> Changing private flag on objects should never be needed, so suggesting >> users to change private flags is not the way to go. > > Yes, if you change a private flag you may forget to change it back. I > thought that Doug was suggesting this in his example, but I probably > misunderstood what he meant. No, you understood my example. As far as I know, this is the only way I know to create a "view" where you effectively remove a connection through someone. >> >> As far as I see it, these are the use-cases: >> >> 1/ this is private, I really don't want anybody to know about this info. >> So eg ex-wifes, estranged brothers, illegal children. In all these cases, >> nothing should seep out to the outside world by accident. The consequences >> of such accidents lead to huge problems. I am very happy no users complained >> anymore the last two years about this on the user list. This is why the >> private proxie was created, and it seems to work excellent in doing this. >> >> 2/I don't want to see living people. Then all should be removed of those. >> >> The 'bug' of Jerome is hence no bug. If one is allowed to know about a >> private person, then it should not be set as private. Furthermore, for his >> own use, a researcher should never use the private flag, so if a researcher >> wants to know if somebody is family, ..., he should not activate the private >> exclusion. >> > > These were the kind of use-cases I was thinking of. > > I still have a concern that we may still be making things too complicated > for the average user. Suppose we give the options "Remove Private Objects > before filter" and "Remove Private Objects after filter" - if the user > doesn't appreciate the difference they may select the wrong one by mistake > and inadvertently expose data they didn't mean to. If that is the consensus, then I'll gladly revert the changes in trunk to the way that it was and quit trying to "fix" the issue. I hope everyone now understands how Gramps works a bit better, and when to use (and not use) the Private proxy and filter combination. Summary: do not use the Private proxy if your filter depends on private objects---be aware that what you select via the export (with filter and private proxy) is not the same as what you see interactively with the filter. -Doug > > Nick. > >> Benny >> >> >> >> Another argument is that what one considers private can change >> depending on the use of the output. For example, in one >> export, you >> might want to consider C and all of their family as off-limits. >> However, you might want to then turn around and create an >> export that >> has D (say, C's spouse) as private, and all of their family as >> off-limits. This would require a lot of work from the user to >> be able >> to do this without private-proxy-first. >> >> >> >> This is a better argument. I can see why people would find this >> useful. >> >> If I understand you correctly, the export is descendants of A. In >> one case you want to also exclude descendants of C, and in the >> other descendants of D. An easy way to do this is to change the >> private flag from C to D. >> >> The only way I use the private flag is more static - I don't >> change private flags for a particular export. Do we want to >> encourage users to change private flags for a particular export? >> >> The alternative would be to create more complicated filters. >> Would this be too difficult for the average user? >> >> >> I should add that I don't use this functionality much >> myself, but an "apply >> proxies before or after" option doesn't seem like a neat >> solution to me. >> >> >> Yes, looking for the best solution, consider ease-of-use, >> power, and >> flexibility. >> >> >> >> I'm sure that you'll come up with a good solution. I just wanted >> to remind people of new and Aunt Martha type users and to avoid >> adding complexity if it is not needed. >> >> >> Nick. >> >> >> >> -Doug >> >> >> Regards, >> >> >> Nick. >> >> >> Doug Blank wrote: >> >> On Tue, May 18, 2010 at 3:10 AM, Benny Malengier >> <ben...@gm... >> <mailto:ben...@gm...>> wrote: >> >> >> 2010/5/17 Doug Blank <dou...@gm... >> <mailto:dou...@gm...>> >> >> >> On Mon, May 17, 2010 at 10:05 AM, Gerald Britton >> <ger...@gm... >> <mailto:ger...@gm...>> wrote: >> >> >> On Mon, May 17, 2010 at 8:22 AM, Doug >> Blank <dou...@gm... >> <mailto:dou...@gm...>> >> wrote: >> >> >> On Mon, May 17, 2010 at 4:32 AM, Benny >> Malengier >> <ben...@gm... >> <mailto:ben...@gm...>> wrote: >> >> >> 2010/5/12 Gerald Britton >> <ger...@gm... >> <mailto:ger...@gm...>> >> >> >> [snip] >> >> >> >> The same thing is done for >> filters when you use the rule >> "people >> matching filter x." If that >> is the first rule in a new >> filter "y", >> then the other rules in "y" >> will only see records that >> pass filter >> "x". The beauty here is that >> you can reverse the rules so the >> "people >> matching filter" rule comes >> last. You have the >> flexibility to put >> it >> together to get the results >> you want. >> >> >> >> I agree here. There is no bug in >> the proxie databases, they work as >> they >> should. >> >> >> Yes, I agree that there is no bug in >> the proxies, nor in the filters. >> >> I've been continuing to play with >> proxies and filters, and I'm not >> sure that just changing the order is >> the right thing to do. But we all >> have to at least agree on what the >> issues are. >> >> >> >> The proxies are not commutative >> however according to Doug, first >> filter, >> then private is different from >> first private then filter proxie (see >> the >> descendant of and then private >> versus private then descendant). >> Thinking >> about this, this seems indeed >> strange, as Gerald indicates, they >> should >> return the same result... >> >> >> This is easy to see that >> Filters/Proxies are not commutative: >> Consider >> a database with three people: Person A >> who has a son, Person B. Person >> B also has a son, Person C. Now mark >> Person B as private. >> >> If you apply the Private proxy first, >> then you effectively remove >> Person B from the database, and you >> will not find any connection >> between Person A and Person C. Thus, >> any filter that looks for a >> relationship between A and C will not >> find one. Descendants of A will >> not include C. This is how Gramps has >> worked for the last few years, >> when you export with a Private Proxy. >> >> On the other hand, if you do not apply >> the Private proxy first, there >> is no easy way to hide that >> relationship from the filters. You can try >> to make selections based on one's >> Private status, but that isn't >> considered when, for example, looking >> for descendants or ancestors. >> >> So, the first thing to realize is that >> filter-then-proxy is not >> guaranteed to be the same as >> proxy-then-filter. They are not >> commutative. >> >> The next thing to realize is that >> sometimes one may want to use >> private people in a filter, before >> having them removed. Thus, always >> applying the private proxy first may >> have effects on the filter that >> you may not realize, until you run an >> export. >> >> The final thing to realize is that a >> private filter does not take the >> place of the private proxy. Using a >> private filter only looks at a >> single person. Combining a private >> filter with, say, a descendant >> filter does not have any effect on >> limiting who is a descendant. As >> far as I can see, filters are >> commutative, and thus cannot be used to >> replace a proxy. >> >> >> >> The change of Doug means private >> is applied last. There is no real >> reasoning >> on why one or the other should be >> first, ..., well, perhaps there is? >> If >> they really are not commutative, I >> think the order should be in the >> way that >> is most difficult (or impossible) >> to achieve via a normal filter >> setup. >> >> >> If Benny's criteria is used, then the >> way that Gramps is now is the >> correct way: there is no easy way >> (that I see) to remove Person B >> (private) and Person C (public >> descendant) using just filters. >> >> On the other hand, selecting the proxy >> first can remove people that >> were important in constructing a >> filter, and a user might not notice >> until the export has been made, and >> then verified by examining what >> was exported. >> >> So what to do? I see four possibilities: >> >> 1) Leave as it is, Proxies first. To >> avoid having a Private proxy have >> adverse affects, a user can opt to not >> use the proxy, and use a >> private filter. I believe that a >> private filter is equivalent to a >> private proxy last. But this method >> causes confusion, even among >> long-time users (and developers) for >> why an exported group is what it >> is. >> >> 2) Change to proxies last. This is too >> limiting---users don't have the >> power that they need with just filters. >> >> 3) Allow each proxy to be applied >> before or after. Users would need to >> know the implications. However, this >> is still confusing and hard to >> verify. >> >> 4) Allow proxies to be used as a >> filter. I have no idea how this might >> work, but it would allow users to >> verify the selection and final >> output. >> >> >> Do you mean, "allow the logic of the >> proxies to be used in pre-defined >> filters"? If so, I can see the value in >> that, though the "private" >> proxy goes well beyond filtering. >> >> >> To understand the proposed option 4, "allow >> proxies to be used as a >> filter" one needs to appreciate that the three >> non-filter based >> proxies (Private, Living, and Note) are more >> powerful than >> user-constructed filters. That is, they alter >> what is accessible. For >> example, no combination of filters will >> prevent you from being able to >> select the children of a private person in a >> descendant filter. Only a >> proxy can do that. >> >> What I am suggesting is some manner to put the >> power of the proxy into >> the hands of the user, so that they can mix >> proxies >> between/before/after filters. This does two >> things: 1) it allows users >> to interactively and easily inspect their >> application of proxies and >> filters to check for correctness (without >> having to export and then >> import), and 2) it gives users the most >> control over when and how the >> proxies get applied. >> >> Having thoroughly examined the two use-cases >> in this thread (Jerome's >> and Benny's) we can get by with our current >> sequence (proxies before >> filters). Benny's example is the default >> behavior when applying the >> Private proxy (eg, block access to children of >> private people when >> combined with a descendant filter). Jerome can >> get exactly what he >> wants (I think) by writing a more complicated >> filter. The easiest way >> to construct Jerome's filter is with three >> filters, and no proxies: >> >> 1) not an ancestor of X filter >> 2) not private filter >> 3) mark "all rules must apply" >> >> This can also be accomplished with one filter, >> 2 rules: >> >> 1) an ancestor of X rule >> 2) private rule >> 3) mark "at least one rule must apply" >> 4) mark "those that do not match" >> >> BTW, Jerome's selection could also be done >> perhaps easier if we had >> the ability to add the "not" to each rule >> rather than to the entire >> filter selection. For example, one could select: >> >> 1) not ancestors of X rule >> 2) not private rule >> 3) mark "all rules must apply" >> >> What does not work in this case is to select >> "not ancestor of X" >> filter with the Private proxy (as it is >> applied first), as that messes >> up the ancestors (because it happens to have a >> private person in the >> ancestor chain). >> >> This suggests Option 3, where Jerome could >> have gotten the output he >> wanted with a "not ancestor of X" with the >> Private proxy applied last. >> >> >> >> I would not like to see the actual >> modules available for use as filters, >> since that would likely require >> logic to be added to them of the sort: >> >> if I am a proxy: >> do this >> else: >> do that >> >> or would require the caller to be >> knowledgeable of the implementation >> proxy, which can lead to maintenance >> headaches. >> >> >> Yeah, I can't see how we could mix proxies and >> filters together, other >> than having an interface like we do in >> export---allowing one to select >> the proxies and their ordering. One could do >> that in the filter >> sidebar... seeing as that would be complicated >> (and I have no interest >> in doing it) perhaps we can slightly tweak the >> export to do two fairly >> simple things: >> >> 1) allow proxies to be applied before/after >> the filter >> 2) right before the actual export, the display >> could show who would be >> selected >> >> These two things would go some distance to >> making the export more user >> friendly. It doesn't allow all use-cases (I >> can think of some, but >> they are not uses that people are asking for). >> >> -Doug >> >> >> This tread is becoming difficult to follow :-) >> >> >> This thread was difficult to write! This is >> complicated. I'm glad >> we're taking this slow and thoughtful. >> >> >> >> >From what I read, am I correct to assume you >> would undo the change in >> svn? >> So first private again, because the other >> behaviour can be obtained with >> filters? >> >> >> Yes, even with the problems it raises, private proxy >> first has to be >> at least an option. >> >> >> >> I agree with 1) above, but for users better to use >> another word >> (restricted >> view or so). For 2), more like a preview button, >> people with large >> databases >> would not like to wait to see the result. >> >> >> Perhaps for 2) we can give more details (eg, display >> who is selected) >> as we are exporting, and a way to cancel. >> >> I think "view" is the right word, in description, and >> also related to >> what Gerald said. We have effectively created a view: >> >> self.dbase = \ >> gen.proxy.ReferencedProxyDb( >> gen.proxy.LivingProxyDb( >> gen.proxy.PrivateProxyDb( >> gen.proxy.FilterProxyDb( >> gen.proxy.FilterProxyDb( >> self.dbase, >> option_box.cfilter), >> note_filter=option_box.nfilter >> ) >> ), >> gen.proxy.LivingProxyDb.MODE_INCLUDE_LAST_NAME_ONLY) >> ) >> >> A "View" (what Gerald called a meta-proxy) might be a >> useful object to >> have users construct in a future Gramps to get the >> full power of what >> is possible. We have all of the code to do it---we're >> just missing a >> UI. >> >> For now, I will undo the changes in trunk, and try an >> ordering choice. >> >> -Doug >> >> >> >> Benny >> >> >> >> Also, the filter proxy already uses >> filters, so that would be >> redundant I suppose. >> >> >> >> >> The ideal would be option 4, but this >> might be hard or impossible, but >> should be explored. Option 3 is easier >> than 1 for the user, covers all >> known use-cases, but is still hard to >> verify. Option 2, I think, is >> out because it makes Gramps less >> powerful. Option 1 prevents some >> known use-cases. >> >> -Doug >> >> >> >> Benny >> >> >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> <mailto:Gra...@li...> >> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> >> >> -- >> Gerald Britton >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> <mailto:Gra...@li...> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> >> >> >> >> >> >> > |
From: Doug B. <dou...@gm...> - 2010-05-21 10:53:52
Attachments:
Screenshot-Export Assistant - Gramps.png
|
Jérôme identified one last issue that can't be worked around: I had said that a private-filter-last is equivalent to a private-proxy-last. That is true (I think), for people. However, that does nothing to protect private objects other than people. For example, if you have a private event, then a private-filter (on people) will of course not filter that out. We are therefore stuck in the situation that somethings can only be done with private-proxy before filter-proxy, and somethings can only be done with private-proxy after filter-proxy. It seems that the only way to allow both is to have an interface that allows the user to order proxies. Attached you will find a screen shot of the ExportOptions screen with the bare minimum needed to allow this. You can run this code on a Gedcom export via the latest patch on issue 3878 [1]. The idea is that a user need not be aware of these issues, and blindly use the export options, and it will work identically as before. However, if they need to change the order, they can. While in this code, I moved all of the logic to ExportOptions (rather than having it in ExportGedcom, etc.) Some other enhancements to be done, given that everyone is happy with this solution: * save the order selected in config * allow more options (for example, living could allow removal or name replacement) * have all export places use this logic (all exports, and some reports) With the ordering now under the users control, there are more things now possible with Gramps. For example, you could use the living proxy as a way of removing people before a user filter is applied, or have filters based on the name [Living]. But the real use for this is just to solve the above described issue. Feedback, of course, welcomed. If no one has an objection, I'll apply this to trunk, and work on the enhancements. -Doug [1] - http://www.gramps-project.org/bugs/view.php?id=3878 |
From: Gerald B. <ger...@gm...> - 2010-05-21 13:12:47
|
On Fri, May 21, 2010 at 6:53 AM, Doug Blank <dou...@gm...> wrote: > Jérôme identified one last issue that can't be worked around: I had > said that a private-filter-last is equivalent to a private-proxy-last. > That is true (I think), for people. However, that does nothing to > protect private objects other than people. For example, if you have a > private event, then a private-filter (on people) will of course not > filter that out. Yes, this is a current limitation. The user cannot construct a filter that filters out more than one object type. One possible solution would be to allow the specification of multiple filters (by object type) in the export dialog. Another would be a way to build a hyper-filter that consists of one or more filters from any of the object types. Such a hyper-filter could potentially be used in other situations as well (e.g. reports). > > We are therefore stuck in the situation that somethings can only be > done with private-proxy before filter-proxy, and somethings can only > be done with private-proxy after filter-proxy. It seems that the only > way to allow both is to have an interface that allows the user to > order proxies. I would be concerned that the Aunt Martha's of the world would not be able to make heads of tails of this. > > Attached you will find a screen shot of the ExportOptions screen with > the bare minimum needed to allow this. You can run this code on a > Gedcom export via the latest patch on issue 3878 [1]. The idea is that > a user need not be aware of these issues, and blindly use the export > options, and it will work identically as before. However, if they need > to change the order, they can. > > While in this code, I moved all of the logic to ExportOptions (rather > than having it in ExportGedcom, etc.) Some other enhancements to be > done, given that everyone is happy with this solution: > > * save the order selected in config > * allow more options (for example, living could allow removal or name > replacement) > * have all export places use this logic (all exports, and some reports) > If we go this way, it should not be limited to exports. At a minimum it should be available for use in reports as well, I feel. > With the ordering now under the users control, there are more things > now possible with Gramps. For example, you could use the living proxy > as a way of removing people before a user filter is applied, or have > filters based on the name [Living]. But the real use for this is just > to solve the above described issue. > > Feedback, of course, welcomed. If no one has an objection, I'll apply > this to trunk, and work on the enhancements. I'm concerned that we're going to a lot of trouble to cover a corner case. There are other ways to handle this for more geeky users (e.g. 2-pass. Filter out stuff, export to a temporary db, import that db, then export that again with private proxy. Why must we do this in one pass?) As Benny mentioned, this has not come up before on the users' mailing list, which might indicate that there is no pent-up demand for such a facility. > > -Doug > > [1] - http://www.gramps-project.org/bugs/view.php?id=3878 > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > -- Gerald Britton |
From: derHeinzi <hei...@ya...> - 2010-05-19 07:56:05
|
Nick Hall-6 wrote: > > I still have a concern that we may still be making things too > complicated for the average user. Suppose we give the options "Remove > Private Objects before filter" and "Remove Private Objects after filter" > - if the user doesn't appreciate the difference they may select the > wrong one by mistake and inadvertently expose data they didn't mean to. > > Nick. > Yes, I agree here. Would it be an option to apply both filter orders and evaluate the difference between both results, if a difference is found present the difference to the user in an easy to read layout with a short explanation and ask if this data should be included or excluded? Just a thought. Heinz -- View this message in context: http://gramps.1791082.n4.nabble.com/Bug-in-Filters-Proxies-tp2173142p2222431.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: Nick H. <nic...@ho...> - 2010-05-21 14:01:32
|
Gerald, I agree with your comments. This seems too complicated for Aunt Martha, and provides functionality that I don't think most people need. Perhaps this functionality belongs in an Advanced Export add-on? Nick. Gerald Britton wrote: > On Fri, May 21, 2010 at 6:53 AM, Doug Blank <dou...@gm...> wrote: > >> Jérôme identified one last issue that can't be worked around: I had >> said that a private-filter-last is equivalent to a private-proxy-last. >> That is true (I think), for people. However, that does nothing to >> protect private objects other than people. For example, if you have a >> private event, then a private-filter (on people) will of course not >> filter that out. >> > > Yes, this is a current limitation. The user cannot construct a filter > that filters out more than one object type. One possible solution > would be to allow the specification of multiple filters (by object > type) in the export dialog. Another would be a way to build a > hyper-filter that consists of one or more filters from any of the > object types. Such a hyper-filter could potentially be used in other > situations as well (e.g. reports). > > >> We are therefore stuck in the situation that somethings can only be >> done with private-proxy before filter-proxy, and somethings can only >> be done with private-proxy after filter-proxy. It seems that the only >> way to allow both is to have an interface that allows the user to >> order proxies. >> > > I would be concerned that the Aunt Martha's of the world would not be > able to make heads of tails of this. > > >> Attached you will find a screen shot of the ExportOptions screen with >> the bare minimum needed to allow this. You can run this code on a >> Gedcom export via the latest patch on issue 3878 [1]. The idea is that >> a user need not be aware of these issues, and blindly use the export >> options, and it will work identically as before. However, if they need >> to change the order, they can. >> >> While in this code, I moved all of the logic to ExportOptions (rather >> than having it in ExportGedcom, etc.) Some other enhancements to be >> done, given that everyone is happy with this solution: >> >> * save the order selected in config >> * allow more options (for example, living could allow removal or name >> replacement) >> * have all export places use this logic (all exports, and some reports) >> >> > > If we go this way, it should not be limited to exports. At a minimum > it should be available for use in reports as well, I feel. > > >> With the ordering now under the users control, there are more things >> now possible with Gramps. For example, you could use the living proxy >> as a way of removing people before a user filter is applied, or have >> filters based on the name [Living]. But the real use for this is just >> to solve the above described issue. >> >> Feedback, of course, welcomed. If no one has an objection, I'll apply >> this to trunk, and work on the enhancements. >> > > I'm concerned that we're going to a lot of trouble to cover a corner > case. There are other ways to handle this for more geeky users (e.g. > 2-pass. Filter out stuff, export to a temporary db, import that db, > then export that again with private proxy. Why must we do this in one > pass?) As Benny mentioned, this has not come up before on the users' > mailing list, which might indicate that there is no pent-up demand for > such a facility. > > >> -Doug >> >> [1] - http://www.gramps-project.org/bugs/view.php?id=3878 >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> >> > > > > |
From: Doug B. <dou...@gm...> - 2010-05-21 15:30:42
|
On Fri, May 21, 2010 at 10:01 AM, Nick Hall <nic...@ho...> wrote: > Gerald, > > I agree with your comments. > > This seems too complicated for Aunt Martha, and provides functionality that > I don't think most people need. > > Perhaps this functionality belongs in an Advanced Export add-on? I think that the problem does come up in user's minds occasionally (if they notice) but they may just get confused, and either not report it, or might just stop using Gramps. I have seen questions in the past that I just couldn't answer... I sure didn't understand this until now. If users have a problem, we would still have to explain what the issue is, with these options or without. The question of why they don't get the right output might be more likely if we standardize filters across all exports and reports. However, with the ordering options, when a user encounters the issue of wrong data selection, we now have a solution. And this does open up some additional uses that weren't previously possible. In any event, I think we could easily hide the arrow buttons via an "Advanced Options" button. In the advanced options, we might also provide a "Preview" that would show exactly the objects and counts of each that would be selected. This will require some documentation, no doubt. It seems like we ought to explain how the proxy and filters work better anyway, and perhaps these options can help explain the issues better. Thanks for the feedback! -Doug > Nick. > > > Gerald Britton wrote: >> >> On Fri, May 21, 2010 at 6:53 AM, Doug Blank <dou...@gm...> wrote: >> >>> >>> Jérôme identified one last issue that can't be worked around: I had >>> said that a private-filter-last is equivalent to a private-proxy-last. >>> That is true (I think), for people. However, that does nothing to >>> protect private objects other than people. For example, if you have a >>> private event, then a private-filter (on people) will of course not >>> filter that out. >>> >> >> Yes, this is a current limitation. The user cannot construct a filter >> that filters out more than one object type. One possible solution >> would be to allow the specification of multiple filters (by object >> type) in the export dialog. Another would be a way to build a >> hyper-filter that consists of one or more filters from any of the >> object types. Such a hyper-filter could potentially be used in other >> situations as well (e.g. reports). >> >> >>> >>> We are therefore stuck in the situation that somethings can only be >>> done with private-proxy before filter-proxy, and somethings can only >>> be done with private-proxy after filter-proxy. It seems that the only >>> way to allow both is to have an interface that allows the user to >>> order proxies. >>> >> >> I would be concerned that the Aunt Martha's of the world would not be >> able to make heads of tails of this. >> >> >>> >>> Attached you will find a screen shot of the ExportOptions screen with >>> the bare minimum needed to allow this. You can run this code on a >>> Gedcom export via the latest patch on issue 3878 [1]. The idea is that >>> a user need not be aware of these issues, and blindly use the export >>> options, and it will work identically as before. However, if they need >>> to change the order, they can. >>> >>> While in this code, I moved all of the logic to ExportOptions (rather >>> than having it in ExportGedcom, etc.) Some other enhancements to be >>> done, given that everyone is happy with this solution: >>> >>> * save the order selected in config >>> * allow more options (for example, living could allow removal or name >>> replacement) >>> * have all export places use this logic (all exports, and some reports) >>> >>> >> >> If we go this way, it should not be limited to exports. At a minimum >> it should be available for use in reports as well, I feel. >> >> >>> >>> With the ordering now under the users control, there are more things >>> now possible with Gramps. For example, you could use the living proxy >>> as a way of removing people before a user filter is applied, or have >>> filters based on the name [Living]. But the real use for this is just >>> to solve the above described issue. >>> >>> Feedback, of course, welcomed. If no one has an objection, I'll apply >>> this to trunk, and work on the enhancements. >>> >> >> I'm concerned that we're going to a lot of trouble to cover a corner >> case. There are other ways to handle this for more geeky users (e.g. >> 2-pass. Filter out stuff, export to a temporary db, import that db, >> then export that again with private proxy. Why must we do this in one >> pass?) As Benny mentioned, this has not come up before on the users' >> mailing list, which might indicate that there is no pent-up demand for >> such a facility. >> >> >>> >>> -Doug >>> >>> [1] - http://www.gramps-project.org/bugs/view.php?id=3878 >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >>> >>> >> >> >> >> > |
From: jerome <rom...@ya...> - 2010-05-21 18:18:51
|
I also remember users keeping default Export options (flag) and asked why some people are missing or with [Living] given name ! Issues on Exporter are not always reported to the mailing lists ... I sometimes answered on a "french" forum, see : http://forum.geneanet.org/index.php?topic=397012.0 http://forum.geneanet.org/index.php?topic=389790.0 http://forum.geneanet.org/index.php?topic=282839.0 http://www.gramps-project.org/bugs/view.php?id=3142 Finaly, I have added some additionnals details on wiki manual : 'do not keep default options on Exporter if your need to make a backup'... True, if current options are not always "accessibles", maybe to add new ones makes it even less usable (meaning "user friendly", "intuitive"). :( > This will require some documentation, no doubt. It seems > like we ought > to explain how the proxy and filters work better anyway, > and perhaps > these options can help explain the issues better. Yes, and as the main problem is the wrong data (I removed generated file), I suppose a broken feature should be fixed or limited ... Doug, thank you, your patch works fine, but I followed the thread... so, I know how it should be used ! If I were reducer, I will say "Aunt Martha does not use filters and private records". The fear is to see comments like: "I do not use it because". If I understand correctly preview counter might check filtered people (family ?) 'with' versus 'without' private flag. But counter should not be on an "Advanced Options" (user needs to be informed), only button to advanced options access (if user needs it) ? Maybe a simple total on the ExportOptions dialog. I wonder how to quickly display the value (persons/families, maybe also notes), additionnal could be the related primary objects. Honestly if I did not have the problem myself I do not know if I will try to find the cause ! I will say: "What I am doing wrong" that's a gramps' thing (proxies, iteration), a thing for advanced users, I do not need to go further... I do not tried yet, but if I get this problem on Export (plugin), maybe this could also happen on NarrativeWeb. We got some issues (filtering, privacy) last months. I wonder if I should not be able to also get a wrong output on NarrativeWeb report ? Thank you ! Jérôme --- En date de : Ven 21.5.10, Doug Blank <dou...@gm...> a écrit : > De: Doug Blank <dou...@gm...> > Objet: Re: [Gramps-devel] Bug in Filters/Proxies? > À: "Nick Hall" <nic...@ho...> > Cc: "Gramps Development List" <gra...@li...>, "Gerald Britton" <ger...@gm...> > Date: Vendredi 21 mai 2010, 17h30 > On Fri, May 21, 2010 at 10:01 AM, > Nick Hall <nic...@ho...> > wrote: > > Gerald, > > > > I agree with your comments. > > > > This seems too complicated for Aunt Martha, and > provides functionality that > > I don't think most people need. > > > > Perhaps this functionality belongs in an Advanced > Export add-on? > > I think that the problem does come up in user's minds > occasionally (if > they notice) but they may just get confused, and either not > report it, > or might just stop using Gramps. I have seen questions in > the past > that I just couldn't answer... I sure didn't understand > this until > now. > > If users have a problem, we would still have to explain > what the issue > is, with these options or without. The question of why they > don't get > the right output might be more likely if we standardize > filters across > all exports and reports. However, with the ordering > options, when a > user encounters the issue of wrong data selection, we now > have a > solution. And this does open up some additional uses that > weren't > previously possible. > > In any event, I think we could easily hide the arrow > buttons via an > "Advanced Options" button. In the advanced options, we > might also > provide a "Preview" that would show exactly the objects and > counts of > each that would be selected. > > This will require some documentation, no doubt. It seems > like we ought > to explain how the proxy and filters work better anyway, > and perhaps > these options can help explain the issues better. > > Thanks for the feedback! > > -Doug > > > Nick. > > > > > > Gerald Britton wrote: > >> > >> On Fri, May 21, 2010 at 6:53 AM, Doug Blank <dou...@gm...> > wrote: > >> > >>> > >>> Jérôme identified one last issue that can't > be worked around: I had > >>> said that a private-filter-last is equivalent > to a private-proxy-last. > >>> That is true (I think), for people. However, > that does nothing to > >>> protect private objects other than people. For > example, if you have a > >>> private event, then a private-filter (on > people) will of course not > >>> filter that out. > >>> > >> > >> Yes, this is a current limitation. The user > cannot construct a filter > >> that filters out more than one object type. One > possible solution > >> would be to allow the specification of multiple > filters (by object > >> type) in the export dialog. Another would be a > way to build a > >> hyper-filter that consists of one or more filters > from any of the > >> object types. Such a hyper-filter could > potentially be used in other > >> situations as well (e.g. reports). > >> > >> > >>> > >>> We are therefore stuck in the situation that > somethings can only be > >>> done with private-proxy before filter-proxy, > and somethings can only > >>> be done with private-proxy after filter-proxy. > It seems that the only > >>> way to allow both is to have an interface that > allows the user to > >>> order proxies. > >>> > >> > >> I would be concerned that the Aunt Martha's of the > world would not be > >> able to make heads of tails of this. > >> > >> > >>> > >>> Attached you will find a screen shot of the > ExportOptions screen with > >>> the bare minimum needed to allow this. You can > run this code on a > >>> Gedcom export via the latest patch on issue > 3878 [1]. The idea is that > >>> a user need not be aware of these issues, and > blindly use the export > >>> options, and it will work identically as > before. However, if they need > >>> to change the order, they can. > >>> > >>> While in this code, I moved all of the logic > to ExportOptions (rather > >>> than having it in ExportGedcom, etc.) Some > other enhancements to be > >>> done, given that everyone is happy with this > solution: > >>> > >>> * save the order selected in config > >>> * allow more options (for example, living > could allow removal or name > >>> replacement) > >>> * have all export places use this logic (all > exports, and some reports) > >>> > >>> > >> > >> If we go this way, it should not be limited to > exports. At a minimum > >> it should be available for use in reports as well, > I feel. > >> > >> > >>> > >>> With the ordering now under the users control, > there are more things > >>> now possible with Gramps. For example, you > could use the living proxy > >>> as a way of removing people before a user > filter is applied, or have > >>> filters based on the name [Living]. But the > real use for this is just > >>> to solve the above described issue. > >>> > >>> Feedback, of course, welcomed. If no one has > an objection, I'll apply > >>> this to trunk, and work on the enhancements. > >>> > >> > >> I'm concerned that we're going to a lot of trouble > to cover a corner > >> case. There are other ways to handle this for > more geeky users (e.g. > >> 2-pass. Filter out stuff, export to a temporary > db, import that db, > >> then export that again with private proxy. Why > must we do this in one > >> pass?) As Benny mentioned, this has not come up > before on the users' > >> mailing list, which might indicate that there is > no pent-up demand for > >> such a facility. > >> > >> > >>> > >>> -Doug > >>> > >>> [1] - http://www.gramps-project.org/bugs/view.php?id=3878 > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> > >>> > >>> > _______________________________________________ > >>> Gramps-devel mailing list > >>> Gra...@li... > >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel > >>> > >>> > >>> > >> > >> > >> > >> > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: jerome <rom...@ya...> - 2010-05-22 06:49:26
|
Hi, Not a rule|generality, but if filtered database has more people/families with private.proxy than without, then maybe user needs to change Filters/Proxies order on Exporter ? Could be a warning pop-up or be hidden for the user ! if len(person_handler) is greater on PrivateProxyDb(filtered_database) than (filtered_database), then change the order filter/private_proxy. It sounds strange, but a broken filter _often_ returns more data (no more active filter). It should be easy for the user to understand that : * using living proxy first, will check living people and Gramps will match more [Living] people. * using private proxy will hide all private records and stop iteration on filter. * number of person_handle on filtered database should be greater without private proxy. Maybe just 'Do not include unlinked records' should not move : cannot be the first one, right ? Regards, Jérôme --- En date de : Ven 21.5.10, Doug Blank <dou...@gm...> a écrit : > De: Doug Blank <dou...@gm...> > Objet: Re: [Gramps-devel] Bug in Filters/Proxies? > À: "Nick Hall" <nic...@ho...> > Cc: "Gramps Development List" <gra...@li...>, "Gerald Britton" <ger...@gm...> > Date: Vendredi 21 mai 2010, 17h30 > On Fri, May 21, 2010 at 10:01 AM, > Nick Hall <nic...@ho...> > wrote: > > Gerald, > > > > I agree with your comments. > > > > This seems too complicated for Aunt Martha, and > provides functionality that > > I don't think most people need. > > > > Perhaps this functionality belongs in an Advanced > Export add-on? > > I think that the problem does come up in user's minds > occasionally (if > they notice) but they may just get confused, and either not > report it, > or might just stop using Gramps. I have seen questions in > the past > that I just couldn't answer... I sure didn't understand > this until > now. > > If users have a problem, we would still have to explain > what the issue > is, with these options or without. The question of why they > don't get > the right output might be more likely if we standardize > filters across > all exports and reports. However, with the ordering > options, when a > user encounters the issue of wrong data selection, we now > have a > solution. And this does open up some additional uses that > weren't > previously possible. > > In any event, I think we could easily hide the arrow > buttons via an > "Advanced Options" button. In the advanced options, we > might also > provide a "Preview" that would show exactly the objects and > counts of > each that would be selected. > > This will require some documentation, no doubt. It seems > like we ought > to explain how the proxy and filters work better anyway, > and perhaps > these options can help explain the issues better. > > Thanks for the feedback! > > -Doug > > > Nick. > > > > > > Gerald Britton wrote: > >> > >> On Fri, May 21, 2010 at 6:53 AM, Doug Blank <dou...@gm...> > wrote: > >> > >>> > >>> Jérôme identified one last issue that can't > be worked around: I had > >>> said that a private-filter-last is equivalent > to a private-proxy-last. > >>> That is true (I think), for people. However, > that does nothing to > >>> protect private objects other than people. For > example, if you have a > >>> private event, then a private-filter (on > people) will of course not > >>> filter that out. > >>> > >> > >> Yes, this is a current limitation. The user > cannot construct a filter > >> that filters out more than one object type. One > possible solution > >> would be to allow the specification of multiple > filters (by object > >> type) in the export dialog. Another would be a > way to build a > >> hyper-filter that consists of one or more filters > from any of the > >> object types. Such a hyper-filter could > potentially be used in other > >> situations as well (e.g. reports). > >> > >> > >>> > >>> We are therefore stuck in the situation that > somethings can only be > >>> done with private-proxy before filter-proxy, > and somethings can only > >>> be done with private-proxy after filter-proxy. > It seems that the only > >>> way to allow both is to have an interface that > allows the user to > >>> order proxies. > >>> > >> > >> I would be concerned that the Aunt Martha's of the > world would not be > >> able to make heads of tails of this. > >> > >> > >>> > >>> Attached you will find a screen shot of the > ExportOptions screen with > >>> the bare minimum needed to allow this. You can > run this code on a > >>> Gedcom export via the latest patch on issue > 3878 [1]. The idea is that > >>> a user need not be aware of these issues, and > blindly use the export > >>> options, and it will work identically as > before. However, if they need > >>> to change the order, they can. > >>> > >>> While in this code, I moved all of the logic > to ExportOptions (rather > >>> than having it in ExportGedcom, etc.) Some > other enhancements to be > >>> done, given that everyone is happy with this > solution: > >>> > >>> * save the order selected in config > >>> * allow more options (for example, living > could allow removal or name > >>> replacement) > >>> * have all export places use this logic (all > exports, and some reports) > >>> > >>> > >> > >> If we go this way, it should not be limited to > exports. At a minimum > >> it should be available for use in reports as well, > I feel. > >> > >> > >>> > >>> With the ordering now under the users control, > there are more things > >>> now possible with Gramps. For example, you > could use the living proxy > >>> as a way of removing people before a user > filter is applied, or have > >>> filters based on the name [Living]. But the > real use for this is just > >>> to solve the above described issue. > >>> > >>> Feedback, of course, welcomed. If no one has > an objection, I'll apply > >>> this to trunk, and work on the enhancements. > >>> > >> > >> I'm concerned that we're going to a lot of trouble > to cover a corner > >> case. There are other ways to handle this for > more geeky users (e.g. > >> 2-pass. Filter out stuff, export to a temporary > db, import that db, > >> then export that again with private proxy. Why > must we do this in one > >> pass?) As Benny mentioned, this has not come up > before on the users' > >> mailing list, which might indicate that there is > no pent-up demand for > >> such a facility. > >> > >> > >>> > >>> -Doug > >>> > >>> [1] - http://www.gramps-project.org/bugs/view.php?id=3878 > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> > >>> > >>> > _______________________________________________ > >>> Gramps-devel mailing list > >>> Gra...@li... > >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel > >>> > >>> > >>> > >> > >> > >> > >> > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |