2013/6/4 Tim Lyons <guy.linton@gmail.com>
Benny Malengier wrote
> Ok, about the code in the GEP 18, some things.
>
> 1/I intend to merge the given and surname author fields to a single author
> in bibtex style.
> That means, the code will assume different authors are joined with ' & '
> in
> the attribute and in style: surname, given
> I would use & to join authors to make it international instead of the
> bibtex 'and'.
> The GUI might still show surname and given fields though for simplicity to
> the users, the storage would be in a single attribute though.
>
> 2/I will split in the csv the field column in two columns: field attribute
> and field description.
>
> This will allow to merge many of the attributes now in the EE csv. Eg, all
> different author forms, and all different title forms will be one, but
> allow for a different description in the GUI when entering data.
>
> 3/in light of above, the EE styles will already be much clearer when seen
> as attributes in Gramps. Reusing attributes will also allow to easily
> change template, and not needing to retype fields.
> Other styles are welcome though. If you make other styles, keep in mind
> that editing the csv is dangerous if above changes are not yet
> done/committed by me.
> Adding the new styles you might want via the template editor later and
> copying it over from the template editor to the code before release, might
> also be easier than editing the csv directly.

Sorry, can't resist commenting though I know it will be of little use. I
have tried out the GEP-016 UI.

I am not sure why editing the existing templates, or merging fields is
necessary or desirable. If we want to claim EE, then we should use it.
Anyway, if we have a template editor, then the built-in templates become
less important.

Not true. The csv is not made by Mills, but by somebody trying to interpret it. That is great help to us, but does not mean that person is correct.
The person splits author in fields, gives title different names. Why? Because his design is bad, not because Mill requires it.
So, I design the fields different, but the result should be the same as in EE.

Second, we write software, and we need some generic rules we can follow. Best is if those rules are simple. So I defined some rules which are supportable by Gramps, and then a fraction of the references needed to be done different. Those references will not look exactly like in EE, because EE is a human writing citations, not a computer based on simple rules.

Surely it is just a matter of how the UI is arranged which should ensure
that the EE styles and attributes can be clearly seen. Clearly, the existing
arrangement where the Attribute editing pane brings up a huge list of
possible attribute names, is not workable (in my system, the list only shows
the top screenful of double column attributes and I can't seem to scroll to
get anything else).

I did not decide yet if hiding the attributes is needed in the attribute editor.First, I don't think the user needs to use the attribate section at all if he uses the templates tab. So will he be bothered by the long list?
Second, the event type list is also too long, it would be nicer to try to device a general solution
Third, merging attributes will reduce the number again.
As said, not being able to scrol is a GTK bug.On second click it works.

However, I don't imagine that users would want to select the EE attributes
directly. Hence, perhaps the Attribute editor should only display 'normal'
and custom attributes directly (e.g. they could be attributes with numbers
below 100). If the user wanted to select EE attributes, then a different
dialogue could be presented - very inconvenient, but very rare.

Did you try gep branch 18? I would think you are trying trunk.

I haven't seen EE, so I don't know, but I imagine that some of the
attributes that apparently are being considered for merge actually have
different descriptions.

I note that in the simple citations website (and in many other form filling
applications) there is a feint description of what goes in the field that
(usually) disappears when you click on that field to edit. Is that facility
available for use by Gramps? I imagine that apparently duplicate fields
might have different entries in such a prompt, and hence the reason to
retain such duplicates.

This is possible, see the fields in the edit person name section. However, somebody has to write all those descriptions.... I was thinking about tooltips now, as those can also be seen if the field already has data.

So, rather than trying to adapt the EE templates, and in line with your
request to refrain from further comment on the templates, could I suggest
carrying on with the UI - for example perhaps the citation editing or
template editing and add-on.

The GUI is what I'm working on. The GEP 18 branch it is going forward, but still much to do. The source section of the source editor shows already how it will end up, but template setting is not finished.

Benny

TL;DR at this stage, the UI rather than work on changing EE templates.

Regards,
Tim.



--
View this message in context: http://gramps.1791082.n4.nabble.com/New-SrcAttribute-and-Evidence-Style-tp4660442p4660627.html
Sent from the GRAMPS - Dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Gramps-devel mailing list
Gramps-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gramps-devel