Re: [Gramps-devel] Re : Prototype for tagging functionality (GEPS 011)

[Benny M. <ben...@gm...>]

2010/7/12 Nick Hall <nic...@ho...>

>
>
> Benny Malengier wrote:
>
>>
>>
>> 2010/7/11 Nick Hall <nic...@ho... <mailto:
>> nic...@ho...>>
>>
>>
>>
>>
>>    In the prototype, for tags I use custom attributes with an empty
>>    string
>>    as the value.
>>
>>    > I suggest two possible approaches:
>>    > (1) Change reports and web output so that it does not output
>>    things that
>>    > start with underscore (e.g. _Census, or _order, or _FAMOUS).
>>    this is not
>>    > very flexible, and the gramplets that set these things would
>>    need to be
>>    > changed to use the new attribute names.
>>    >
>>    >
>>
>>    I almost did this for the prototype. For tagging, I think that we
>>    would
>>    be better adding another field to the primary objects to store the
>>    tags.
>>    I have listed reasons for this in the GEPS.
>>
>>    I can see why this might be useful in other situations though.
>>
>>    In the Census addons the order attribute is set to private. Is the
>>    private status of attributes ignored in reports and narrative web
>>    output? Would we be better fixing this?
>>
>>
>>
>> Nick, can you add some screenshots to the GEPS or the bug ticket?
>>
>
> I see that Jerome has done this already.
>
>
>
>> Some things about tags:
>>
>> 1/it has been mentioned before and has support
>>
>> 2/what was agreed upon was to remove note type, and replace it by note
>> tags. As a consequence, we thought about tags as a list of types. So eg,
>> NoteTags = list of NoteTag, where NoteTag is a structure like NoteType, so
>> we have predefined ones and custom ones.
>>
>>
> Where is this discussion?  I can't find the thread in the mailing list.
>

Can't seem to find it. Must have been before my use of gmail, although I
expect it was 2008. Anyway, you can find it in the TODO file in svn:

 * before release on multiple notes:
    --> in note: also public/private on GUI - DONE
    --> on upgrade, the notetype should correspond to the object the note is
made
            from, so notetype SOURCE, SOURCEREF, ..., this gives information
on
            orphaned notes.(DONE for GRDB)
        TODO: change notetype into note tags, so people can give notes
multiple tags,
              Like this all source notes can have tag source, but also tag
'family history' (Discussion Alex/Benny)


The discussion was in the line of: how can a note have a specific type? We
want to be able to add different types/markers/tags to them.
So, it seems more usefull to have just tags one can add to a note. You are
right that this is a bit like an attribute with only a key.

I was thinking of a simple solution where the user could tag any object with
> one or more text tags.  I was going to use the same set of tags across all
> object types without any pre-defined tags.  It didn't occur to me to replace
> existing functionality like Note Type.  In fact, I didn't think that tags
> would be particularly useful for notes, I was concentrating on tagging
> people.
>
>
>  Nobody thought about how to enter them, I'd like to see a screenshot of
>> your suggestion, eg for the note tags in the note editor.
>>
>
> The prototype uses attributes to store the tags and just uses the standard
> editor functionality.  I did make a note in the GEPS that we would need to
> extend the editor functionality if we chose to store the tags in the primary
> objects.


We must be careful not to mix  meaning, so just adding tags to attributes
seems like a no-no to me. Tags is something that would be nice to see when
you arrive on an editor.


>  The removal of notetype does mean we need an upgrade structure for when we
>> introduce tags.
>>
>
> Do we really need to remove the Note Type?


If it is the best thing to do, yes :-)
Let's see how this evolves, but if the difference with some of the types or
the markers, becomes difficult to explain, we should simplify things for us
and for the users.


>
>  We should consider simplification also of markers: do we need to keep
>> markers if we have tags? Will that not confuse users? Or are the use cases
>> really different?
>>
>>
> I thought of this and included it to the design questions on the GEPS.  I
> didn't provide an answer though. :)
>
>
>  3/tags should indeed be a database structure. I would suggest you do:
>>
>
> I'm glad you said this, because I was thinking this way myself.
>
>
>
>> a/ in gen.lib add Tag as inheriting from grampstype, then add a TabBase
>> class which objects must derive from that have tags. TabBase is just an
>> object with a tag_list, and serialize/deserialize of that.
>>
>>
> I would like to take a look at the gen.lib code.  I'll try and write a
> TagBase class.
>
> It would be good for Tags to inherit from GrampsType, but I need to store
> colours associated with the tags.  After I look at the GrampsType class, I
> will have a better idea how tags will fit into this framework.


No, you cannot store a colour in the Tag if it is a secondary object
included  in the other objects. Changing a colour would be a huge amount of
work like that.

To have colors, we would need to create a Tag table (let's call it an
auxilary object to give it a name opposed to primary object), create there
objects with id, tag name (english/localized), colour, and then create a
TagBase for objects having tags, and just store the id of the tag in the
object.

Alternative is to have Tags as GrampsType, as I said before, and then have a
meta table incidating what colour to attach to a Tag of a certain name (see
eg how group name is stored in the meta table).

Benny


>
>  b/ select one of the objects, eg note, and do the databae change for that.
>> You can count on me and Doug for help there.
>>
>>
> The prototype works with people only, so I will continue down this route.
>
>
>  c/ once the database structure is done for one object, you can do the
>> interface changes needed in that object to add and remove tags, and how to
>> show them in the lists, ...
>>
>
> I have some ideas about how to edit tags in the editors.  As you say, I can
> start on this after the database changes.
>
>
>
>> I would suggest you do it for note. Before a commit of database changes,
>> it is required however to do a mail to the mailing lists indicating trunk
>> will become for testing purposes only and can destroy data.
>>
>
> I will keep it as a patch for the moment.   Thanks for reminding me about
> mailing to the list.
>
>
> Regards,
>
>
> Nick.
>
>
>> Greetings,
>> Benny
>>
>>
>>         Nick.
>>
>>    > (2) Change reports and web output so that there is a list of
>>    attribute names
>>    > or key names that are not output. This list would need to be
>>    input in the
>>    > options page. This is rather more flexible, and would not need
>>    any change to
>>    > the existing code that creates the attributes.
>>    >
>>    >
>>
>