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 >>> >>> >>> >> >> >> >> > |