Adding a subtree requires (up to) 2 additional arguments (ett and if proto_item* is still going to be used), and I just thought it would be "API bloat" to add a proto_tree_add_item_with_subtree (and all of the other possible combinations). proto_item_add_subtree still has its uses ;)
Next piece of functionality that I would like to target is using proto_tree_add_bitmask a lot more as that is another reason for a lot of the subtrees (some that I left with proto_tree_add_text so I would remember that's what they're there for), and it would make the dissector code itself a lot smaller/simpler.
-----Original Message-----
From: Alexis La Goutte <alexis.lagoutte@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Thu, Jul 10, 2014 6:45 am
Subject: Re: [Wireshark-dev] proto_tree_add_subtree[_format]
On Thu, Jul 10, 2014 at 5:29 AM, Evan Huus <eapache@xxxxxxxxx> wrote:
> On Wed, Jul 9, 2014 at 10:06 PM, <mmann78@xxxxxxxxxxxx> wrote:
>>
>> I finished the conversion of proto_tree_add_text calls that were acting as
>> "subtree labels" into proto_tree_add_subtree[_format]. This removed almost
>> 4000 calls in the dissector directory (over 4000 if you include the plugins)
>> and brings the current total proto_tree_add_text count in the dissector
>> directory to 5831 (6586 over entire wireshark master trunk). Of the 5831,
>> checkAPIs.pl considers 4690 to be "useless". (I believe the criteria being
>> using printf style arguments and no return value (like when it's intended as
>> a subtree label)).
Thanks Michael for the big work.. :-)
>
>
> What about the last ~1000 "not useless" ones? How are they used?
>
>>
>> Since "subtree label" is the last "legimate" reason to use
it is no possible to add subtree also with hf field ?
>> proto_tree_add_text, should it be added as a "soft-deprecated API" to
>> checkAPIs script?
>
>
> If there really are no remaining legitimate uses, then +1.
+1
>
>>
>> I wasn't sure if that was just being too obnoxious at the moment. It may
>> need its own "paragraph" with suggestions on what to use instead (make field
>> filterable, expert info, subtree label)
>
>
> Obnoxious would be hard-deprecated :)
>
> How many actual c-files are those remaining add_text elements in? I imagine
> the majority of dissectors are now completely "clean" so it wouldn't be too
> bad.
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe