Attribute names are being truncated when viewed in the key attribute view pane. I need multiple words in the attribute names to account for ambiguity, homographs, polysemy and the sort when creating them. Considering key attributes cannot be grouped in hierarchies, I need as much space to disambiguate semantic meaning, source kind/place…So, my question, is there a character max for key attribute display?
The KA table is drawn the width of the text pane. The table divides space equally between the two columns with icons (for URLs, dates, etc.) being drawn in the attribute name column’s space. How long are your attribute names? I can’t get attribute names to truncate. Anyway, the simplest answer is to drag the text pane wider as both name and value columns will expand proportionately.
If the table is truncated vertically - i.e. not all expected attributes show - then you’ll need to scroll the table. If I recall, the table shows up to 15 KAs and if there are more you need to scroll the KA table to see them - they are there, you just can’t see more than 15 at once. MY current qualitative work involves a lot of KAs and I’ve not found the use of the KAs table scroll to be onerous. Generally, moving from note to note (with similar KAs) the table retains its scroll position.
Attribute name will show full length in the Get Info pop-up window but will not show full length in the main key attribute window.
Well, I was wrong, it looks like the left column of the KA table has a (fixed?) maximum width. This truncates attributes at c.23 characters (c.21 if a value is applied as the label gets bolded):
You could try altering $KeyAttributeFontSize. Here I’ve reduced it from default 11pt to 8pt:
However, it both needs good eyesight and still doesn’t cope with your very long attribute names. I think showing longer names isn’t possible (writing as at v8.0.0) but you could write to support and propose a feature request to accommodate longer names.
If it were me, I’d also consider shortening names. Many can be shortened without losing meaning. For instance Holonym, Hyponym and Meronym all use a repeated -nym suffix which I’m sure can easily be inferred when reading the attribute names:
Here, I’ve reset the KA font size to default but added attributes with shortened names. It seems that if you stay under 21 characters, you should be fine for now. See here for considerations when renaming existing user attributes.
Ty so much for helping me with this trivial matter. I did eventually abbreviate attribute names but some are impossible to shorten without loosing meaning. I will write @tech support indeed.
While at it I have one more question for you. I’ve created some prototype sets but it seems I can only use one prototype per note. Is it possible to somehow inherit attributes from different prototypes? I’ve tried nesting prototypes and set a note to the level 1 prototype note but it seems it only inherits that note only. I know you can inherit children notes when setting a note to the prototype with the children in it. Maybe the same hierarchical concept exists but instead of inheriting children notes it just inherits children attributes?
Notes can only use a single prototype at a time (that assignment is stored in $Prototype). A prototype can inherit attributes (including $KeyAttributes) from other attributes. A note or prototype can’t dynamically inherit from multiple prototypes though you could sort of mimic that if a prototype used an edict or rule to generate a new KA list. Thus prototype ‘C’ might use values from both ‘A’ and ‘B’:
$KeyAttributes = $KeyAttributes("A") + $KeyAttributes("B");
I hesitate to mention such an approach because what may be done is not necessarily what should be done. The latter method could quickly lead to a byzantine set of interconnected prototypes open lots of scope for unexpected results.
Aside, it does feel that you’re using attribute to store metadata that might be more useful as attribute values. This is because it is easier to query/manipulate attribute values. It’s hard to suggest more finite things without more sight of the project, but encapsulating relationships in attribute names means you can’t query that relationship very easily. It has the smell of a solution that might be improved by some re-factoring. That said, if it works for you, don’t be put off, though if hitting road-blocks like above be open the the fact you may be building a structure the app simply can’t support (at least in the way you desire). Happily, Tinderbox is very forgiving of re-formalisation, so it doesn’t punish unexpected false starts.