…XML to add Reference/Location defaulting (changes listed below)

CHANGES
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* All changed areas marked with DB$ (start/end)

* Added error handler "DisplayLogError()".
  When invoked this will display errors in a popup and
  show exception details in the log (gramps51.log).

* DisplayLogError() used:
    * On XML SYNTAX Error in any of the forms configuration files.
      This shows the file name and what the DOM reports as the issue.
    * If no "<form>" tags exist in a file.
    * If a "section" is missing a "role" attribute (or it's empty).
    * If a "section" is missing a "type" attribute (or it's invalid).

* Some debug messages are now produced by Forms.
  -d "Form Gramplet"

* The environment variable "G.FORMS" can now specify extra Form XML files that
  should be loaded, these are loaded before the inbuilt ones in the order
  specified.
  SET G.FORMS=SameDirAsDefined.xml;xml\InAnXmlSubDirectoryFromDefined.xml
  SET G.FORMS=[G.FORMS]\Australia, Queensland - Birth, Death and Marriages Register.xml;[G.FORMS]\Graves - Find-a-Grave.xml

* If there is no date or reference in the event an error message will be
  displayed for you to fix that.  If for some reason your form doesn't need
  them then I'd suggest giving them default values date='today' and
  reference='none required'.

* I display a message (and abort the save) in at least one error
  situation (person unchosen) where in the past it just quietly closed.
  Because of my other improvement to default a 'person" you should only
  see this on 'multi' or 'family'.

* The created event how has the "Description" field filled in with
  the reference followed by " @ " then the name of the source followed by
  " [form]".

* For section "type=person" [others later...], you no longer have to remember
  if you have selected someone or worry that you selected the wrong person
  as the state is now displayed:
      * Initially "no one selected yet" (in italics)
      * After person creation/selection the name is displayed [small bold]

* For section "type=person" [maybe 'multi' later...], the selected person becomes
  the default person (don't need to go though person selection dialog).
  If multiple people selected then the first is used.
  This occurs exactly once per form.
  [Bug] Currently doesn't work well for multiple sections/people, all will
        have same person preloaded (still better than before).

* The "title" attribute of the "<section>" tag has been improved.
  If not specified (or blank) then the "role" tag's value will be used.
  Also, that way, a title is always displayed, in the past you could have
  completely anonymous sections on the form!!!!

* The value for the "type" attribute of a "section" is now case insensitive
  ('Person' == 'person').

* Fixed the Location "+" & "use existing" location button order so it is not
  only consistent with the rest of the form but with Gramps in general.

* The "Headings" tab is no longer displayed if there are no headings, if it
  exists then you should remember to swap to it and fill it in.

* The following applies to the existing 'date' and the new
  'location' & 'reference' values (rather than creating a lot of xml attributes):

  # If no "=" exists in the string then it is the "default" value, this makes
    the 'date' value backwards compatible for existing forms.

  # If you want a default value to contain a "=" sign you need to put
    "default=" in front of it.  This works since for each pair only the first
    "=" is used to separate the key from the value.

  # If "=" is anywhere in the value you provide then its contents are one or
    more "key=value" pairs separated by "; "
    (semi-colon followed by a single space, all other spaces significant).

  # The order you supply keys is irrelevant.

  # Incorrectly specified keys will be reported in the log (gramps51.log).

  # Unspecified keys will default to some value (generally '').

* New "location" attribute on the "<form>" tag:
    * Example: location="label=Where in QLD?; default=Queensland, Australia"

    * [Key: default] You can now specify a default location.
      If the location (place) is pre-existing then it will be used, otherwise it
      will be created (and given the type "_FORM" so you can find and update it easily).

    * [Key: label] You can replace the label "Location:" with your own text to better inform
      the user as to the form's intention.

* New "reference" attribute on the "<form>" tag:
    * Example: reference='label=QLD [B]DM #'

    * [Key: label] You can replace "Reference:" with your own text to better inform the user
      as to the form's intention.

    * [Key: default] Can now specify a default Reference
      (or perhaps a default prefix you want used).
      You can replace or edit the value.

* The "date" attribute of the "<form>" tag:
    * Example: date='label=Date of Birth'
    * Example: date='label=Discovery Date; default=today; ro=N'

    * [Key: label] You can replace "Date:" with your own text to better inform the user
      as to the form's intention.

    * [Key: default] The default date which can take "today" or "." to represent
      todays date or any valid values like "after 1777".

    * [Key: ro] The value should be "Y" (yes) or "N" (no) as to whether the date
      displayed in the form is read-only or can be modified by the user.
      It defaults to "Y" to be backwards compatible with existing functionality.
      This is of course ignored if no "default" date was provided, as you will
      need to enter it!

    * Tooltips on date fields in form (for read-only & not).

    * In the date entry field you can type "." as shorthand for 'today', which
      you could always type, it was just longer!
      If "." used the field will still be highlighted in red.

* Made the source selection buttons (NEW/EDIT) slightly larger to make
  clicking them easier



TODO:
~~~~~~~~~~~~~~~~~~~~~~~
* Optional Form Help (how to fill in THIS form)
  Maybe in a column on the right (HTML?)
  Probably in a separate .html file (name = form id or maybe title or both)

* More validation of input. Ability to have integer, required attributes etc.

* [DO MULTI/FAMILY]
  For section type=person, you no longer have to remember if you have
  selected someone or worry that you selected the wrong person
  as the state is now displayed:
      * Initially "no one selected yet" (in italics)
      * Afer person creation/selection the name is displayed [small bold]

* If # selected people = #sections then grab their names (defaulting)
  How do I get the selected information (when multiple selection)?

* Prevent use OK unless all people selected - HOW TO CANCEL Button press?

* [bug] In headings tab, type in data in a field, don't leave it and press OK,
  that field's data is lost.

* The "Heading" tag should be deleted and handled like all other fields,
  these fields should be placed in a "heading" section and handled just
  like any other exception (except that you can't choose people/family).
  That way the UI is also less confusing and the user doesn't need to go
  to 2 tabs to find everything. It also means all the "column"
  formatting also applies to headings.


Facts / Pre-existing-Issues
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* size tag in "column" not used by Form, seems to have been obsoleted
* title tag in "form" is not used by Form, seems to have been obsoleted,
  still required! Should fix this
* HeadingsTab.is_empty() doesn't work, always returns True


CAN'T WORK IT OUT (YET):
~~~~~~~~~~~~~~~~~~~~~~~~
* How to add selected people as "main participants"?
  ?: from ...utils.db import get_participant_from_event
     MAYBE: set_participant?

SAMPLES:
~~~~~~~~~
Australia, Queensland - Birth, Death and Marriages Register.xml
Graves - Find-a-Grave.xml

I assume I will also need to submit these separately if the changes are accepted and update the WIKI documentation.

The environment variable "G.FORMSX" can now specify XML files to be excluded if you don't need them.
This may improve performance or be useful in testing situations.  It will certainly remove some debugging output.
        SET G.FORMSX=form_be.xml;form_ca.xml;form_dk.xml;form_fr.xml;form_gb.xml;form_pl.xml;form_us.xml

Now that I've tried Github, I also removed my DB$ comments as Github seems to have quite good difference handling...

Also stupid mistake, my code was based on the distributed plugin code which is NEWER than the master code so I changed fixed the differences between the two.  The version was therefore updated from 2.0.24 to 2.0.20 (2.0.19 in master)

Correct Line: if str(attr.get_type()) == DEFINITION_KEY:

…ions

* Oops form wouldn't load if the environment variables didn't exist

* If a form "id" is duplicated this will be logged as a warning and the  loading of that form aborted (the first occurance will be retained).
  It will also tell you in which file it was originally loaded.

* If the "Select Form" would be empty a message explaining the issue  and how to resolve is logged and displayed to the user.

* If headings tab exists a validation message is displayed if it was  never visited.

* New optional help files get displayed if they exist.
    * They contain text in pango format.
    * Newlines are significant
    * A new paragraph = 2 x newlines
    * You can break up a long line by terminating the continuing line with
      a backslash (\). All whitespace before the backslash is retained.

* Help is always added if there are headings to be entered.

* The height and width of the 'select form' dialog can be overriden by the user   using the "G.FORM.SF.H" and "G.FORM.SF.W" environment variables.   Defaults to original values (height too small for my liking) of 350 & 400.

* All forms env vars now begin with "G.FORM", so renamed existing:
    * "G.FORMS"  to "G.FORM.I"
    * "G.FORMSX" to "G.FORM.X"

* The "basename" of masks listed the inclusion & exclusion
  environment variables can now be a glob to match "MyForms\*.xml" etc

* The existing Form hardcoding could be removed with "form_*.xml"

As suggested filemasks are now used to load standard forms and I changed the definition list to include templates for similar form types.  I now include my (currently 4) XML documents as standard (also as suggested).

# Files which may contain form definitions
definition_files = [ 'test*.xml',       # Test forms have precidence (all but the first duplicate ID's are now ignored)
                     'custom*.xml',     # User's own forms although mainly for backwards compatibility as the envvar "G.FORM.I" can be used to define your own forms.
                     'bdm*.xml',        # Birth Death, marriages registries
                     'graves*.xml',     # Graves/Death sites (findagrave.com, billiongraves.com and similar)
                     ##################
                     'census*.xml',     # Most forms are census related
                     'form*.xml'        # Legacy naming

Solves this problem:
On Mon, 18 May 2020 at 01:39, Paul Culley <[email protected]> wrote:
I assume that you mean multiple columns in the EditForm window, 'Details' tab.  The current code doesn't seem to support an easy way to have multiple columns spread over more than one row.  The whole tab appears to use a Gtk Grid, with the top row as column headers and subsequent rows for the data.

You would have to redesign that part of the code to utilize the grid differently.  Maybe in the set_columns routines you could detect too many columns and cause the the excess to start another pair of rows.  This would work for the types that are not EntryGrid, which seems to support many rows for each set of headers; I think that would need more work.

Good luck
Paul C.

On Sat, May 16, 2020 at 4:31 PM Keith Jacobs <[email protected]> wrote:
I have written a new form definition that has ten consecutive columns
which I would like to split over two lines but have not managed to find
out how to do it online.

So I'd be grateful if someone with such knowledge could explain how to
do it.

--
Regards
Keith Jacobs

Not sure why missed on previous upload/commit.

Solves this issue:
On Mon, 18 May 2020 at 01:39, Paul Culley <[email protected]> wrote:
I assume that you mean multiple columns in the EditForm window, 'Details' tab.  The current code doesn't seem to support an easy way to have multiple columns spread over more than one row.  The whole tab appears to use a Gtk Grid, with the top row as column headers and subsequent rows for the data.

You would have to redesign that part of the code to utilize the grid differently.  Maybe in the set_columns routines you could detect too many columns and cause the the excess to start another pair of rows.  This would work for the types that are not EntryGrid, which seems to support many rows for each set of headers; I think that would need more work.

Good luck
Paul C.

On Sat, May 16, 2020 at 4:31 PM Keith Jacobs <[email protected]> wrote:
I have written a new form definition that has ten consecutive columns
which I would like to split over two lines but have not managed to find
out how to do it online.

So I'd be grateful if someone with such knowledge could explain how to
do it.

--
Regards
Keith Jacobs

…uestion per line

Previous lower limit was 2 due to a weird visual issue otherwise, now fixed

* New validation:  XML TITLE FIELD MUST CONTAIN A '/' FOR A FAMILY

* Now using gramps locate information and renamed base help directory to "help"

* I'd broken some of my error handling, now fixed again.