The "not useless" probably fall under 2 categories:
1. Field label with no printf style arguments, usually for a byte array. Popular ones would be "Data", "Padding" or "Reserved". I know these aren't filterable, but sometimes I like (understand) how it's displayed (just highlighting bytes) in the tree over how a byte array is displayed (showing all bytes, which can be a bit much for larger byte fields)
2. Label that should really be expert info.
There are still 527 files in the dissector directory that include proto_tree_add_text (simple grep) out of 1649 (which includes header files). 10 remain on the checkAPIs.pl "naughty list" (> 50% proto_tree_add_xxx calls are proto_tree_add_text), and there are 28 remaining if you apply my "aggressive" algorithm (which enforces a lower percentage of proto_tree_add_text calls the more overall proto_tree_add_xxx calls there are, originally aimed at "having subtree labels is okay, but that shouldn't account for that many calls").
Overall I've been working more on the "naughty" ones than dissectors that have only a handful of proto_tree_add_text calls, and perhaps the soft-deprecation will bring more attention/fixes to the dissectors that do only have a few. Having proto_tree_add_text eradicated before the 2.0 release would be nice (just to say "all fields are filterable"), but probably a bit aggressive.
-----Original Message-----
From: Evan Huus <eapache@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Wed, Jul 9, 2014 11:33 pm
Subject: Re: [Wireshark-dev] proto_tree_add_subtree[_format]