* [Wish List Request 636] Named List programmable access

[tatewise]

Problem:

Currently, there are no data references or functions that access Named Lists apart from the three functions =HasNoteInList(...), =IsInList(...) and =IsLinkedFromList(...) which only return a boolean result.
There are no programmable mechanisms for automatically adding records to a list, removing records from a list, and managing list properties such as list and record local note text.

By contrast, Record Flags are not only supported by the =HasFlag(...) function but also have data references %INDI._FLGS...% that allow them to be added and removed by plugins.

Proposal:

Named Lists should have data references &/or functions to support adding records, removing records, managing list properties such as local notes and list order, and creating/deleting Named Lists.
The objectives include:

1. Allow the Named List local note text to be retrieved in Expressions just like any other Notes.
2. Allow the Named List member record local note text to be retrieved in Expressions just like other Notes.
3. Allow the Named List records, local notes, and other properties to be fully managed by plugins.

[ColeValleyGirl]

I'd vote for this.

[Mark1834]

I raised this with CP back in July last year. Their response then was It is true that for historical reasons, named lists are not currently handled like most data in your projects. We are considering changing the way they are handled to make them more consistent with other data in an FH project. If we do that, this would also make them accessible to plugins.

It feels like the sort of change that wouldn't happen until FH7.1 or FH8, but I would certainly vote for it in the meantime. It's been 5 months since FH7.0.22 was released, so maybe we won't have too long to wait before we find out...

[tatewise]

Without prejudicing what CP may implement, I think each Named List should become a new record type.
They currently use a custom _LIST tag in the Header record.
So the new Named List record type could be represented in GEDCOM as 0 @L9@ _LIST
It would have a TEXT tag for the Named List Note and other tags to hold options like Keep Current List Order.
It would hold multiple instances of any other record tags INDI, FAM, NOTE, etc, to hold links to the members.
Each of those tags would have a NOTE subsidiary tag for the member's local Note text.

Then the data reference %_LIST.INDI[3].NOTE2% would refer to the 3rd Individual record member's Note.

Furthermore, since they are standard GEDCOM record links, the Links count for each record would include Named List membership, which they currently do not!
A consequence of those currently omitted Links counts is that records which are members of a Named List, but otherwise unconnected, will be deleted from exported GEDCOM and by the Split Tree Helper if the option to delete with no links to them is chosen. Should this problem be raised as a separate Wish List Request?

[tatewise]

Wish List Ref 636 Named List programmable access has been created.

[ColeValleyGirl]

A bit hasty, Mike? Less than a week isn't much time for discussion.

[tatewise]

I felt that 3 key players supporting it and being on CP list already was justification enough.

[ColeValleyGirl]

I'd have liked some time to consider your suggested implementation, which may not form part of the Wish List item itself but is linked from it. I don't think you've paid enough attention to the UI implications.

[tatewise]

To be honest, I did not pay any attention to UI implications, because CP have probably already resolved them and IMO the current UI is perfectly adequate so why change it.

[ColeValleyGirl]

To be honest, I did not pay any attention to UI implications, because CP have probably already resolved them and IMO the current UI is perfectly adequate so why change it.

I agree, but by making Named Lists a new record type, they'd either have to appear in the Records Window in addition to the Named List pane, which could be a source of confusion, or be the only Record type that didn't appear in the Records Window, which could be a source of different confusion.

We hear lots of complaints about the FH UI being inconsistent; introducing a new Record type with a different UI wouldn't improve that.

On a procedural point, if somebody posts a substantive contribution to a Wish List discussion after somebody has expressed support, I don't think it can be assumed that support is still in place.

[tatewise]

I take your point and apologise
My objective was to clear Wish List entries quickly but perhaps too quickly.

CP could presumably let users choose whether to keep the old Named Lists pane or add a Records Window tab.
However, the Add to Current List button for adding Records (in bulk) to a Named List relies on a Records Window tab being open alongside the Named Lists pane. So that UI would probably need to be retained anyway.

It is similar to Media records that have a Records Window tab and a Media Window UI as well, or Place records that have a Records Window tab and a Map Window as well.

Many new users often don't realise that a tab can exist for every record type, so not having a tab for Named Lists would not be so inconsistent.

[ColeValleyGirl]

You're right that some record types already have two UI windows. It would probably be easier for new users if they didn't but that's another discussion.

I don't think we can rely on user ignorance to make the UI make sense

[Mark1834]

I hope they don’t use Media as a template - I still find the dual routes in horribly confusing.

My feeling is that the original posting summarised what was wanted clearly, and later discussion drifted into suggesting how. CP will have the best view of how to balance the needs of the tiny minority of users who write plugins, the extra facilities it will potentially give to plugin users, but without complicating the UI for the large number of punters who don’t use any plugins. That probably needs their detailed knowledge of FH’s internal structure, which is closed to users.

[ColeValleyGirl]

I hope they don’t use Media as a template - I still find the dual routes in horribly confusing.

My feeling is that the original posting summarised what was wanted clearly, and later discussion drifted into suggesting how. CP will have the best view of how to balance the needs of the tiny minority of users who write plugins, the extra facilities it will potentially give to plugin users, but without complicating the UI for the large number of punters who don’t use any plugins. That probably needs their detailed knowledge of FH’s internal structure, which is closed to users.

Yes!!!!