2010/1/7 Doug Blank <doug.blank@...>:
> On Thu, Jan 7, 2010 at 5:05 PM, Jon Clements <joncle@...> wrote:
>> Putting this back on list as it appears I forgot to copy the list last
>> Arghh, it's too late for my brain to be processing all this (just had a
>> 10 min discussion regarding previous email!).
>> I'm perfectly happy to do an RFE and might even adhoc some code (for
>> immediate use) in regards to bulk setting a privacy flag based on the
>> current filter -- however, I can't help but feel this could be made much
>> more general and useful...
>> Maybe simple things like, I want all the CLEMENTS families to be marked
>> as TODO (or mark all BRITTON as complete), or all people with a
>> birthdate within the last 20 years to be set as private. (Maybe not
>> great examples, I admit).
> Yes, that would be useful. However, our database doesn't really have a
> schema, so general types of functions like this are hard to do. But, you can
> take a look at some existing code that does something similar. I was just
> working on a bulk Attribute editor:
I also think we should do this as a plugin. It can be a tool, or it
can be a bulk edit view. Trying to adapt the present views to do bulk
update would be too much features in my opinion. A better way is to
have a view with at the top a filter selector as the filter sidebar, a
part with edit actions to perform on the result of the filter, a way
to overview the changes that will be done, and an ok button to approve
A tool is perfect for this, if you want it inside of gramps, then a view.
>> I suppose it could be expressed as UPDATE persons SET
>> something=something_else WHERE filter
>> I'm not sure however, how many attributes would make sense in bulk
>> updating though... but something to think about perhaps?
> Yes. This is a common issue, and there isn't a good way to address this.
> Although I have also been playing around with a mock SQL interface to our
> data here:
> that might be able to be adjusted for updates. You can "select person from
> people where person.get_primary_name().get_surname().startswith("B");" or
> "select person from people where person.private;"
>> Also, if one goes that far, perhaps being able to "invert a
>> selection/filter" would be nice... similar to Nautilus/Explorer kinda
>> My friend also suggested that perhaps in the Person view it would be
>> nice to see "little icons" similar to Tbird/Outlook etc... where you can
>> see it's todo/complete/private status. (He doesn't want much does he!)
> That's a good idea.
You mean instead of the colors, use some icons? Some extra columns,
... . Yes, it is an option.
>> -- I can't help out here, because I refuse to do GUI's mostly, and my
>> experience is with wxwindows/qt, not GTK.
>> At the moment, if my friend wants updates done, I do the following:
>> 1) Export database as XML
>> 2) Load XML with a SQL engine on top
>> 3) Perform whatever operations
>> 4) Dump back out as XML
>> 5) Reload to GRAMPS
>> Hardly perfect, not particulary efficient, but gets things done
>> quickly... (but obviously users are not going to do this...)
> This would be useful to document. Can you put a page on the wiki , or
> send me the directions (what programs, details, etc)?
Well, Gerald mentioned to use sed, I'd also like to see a sed command
that can do what he says (changing privacy based on output CSV of a
filter result) :-D
If you make a bulk attribute edit addon, we could generalize on that:
select object type, select filter, select type of action of which one
would be attribute edit. This would then set the dialog of changes
that can be done, eg for attribute change
1/remove attribute of type ...,
2/add attribute with key=.. and val=...
3/change attribute of type ... to type ...
Then process the changes that would happen
Then allow user to remove lines that will change
Then allow user to Cancel or to Proceed and do the changes.
The Placecompletion tool has this functionality already but then for
places. Perhaps we should try to roll these kind of tools in a single