JDevlieghere wrote: > > My understanding is that the constructor conveys whether something is an > > "aggregate" progress event or not and they're broadcast differently so that > > the listener can decide how they want to receive these "aggregate" events. > > My idea is the user decides how to listen to the events by which > `SBDebugger::eBroadcastBit` (`SBDebugger::eBroadcastBitProgress` or > `SBDebugger::eBroadcastBitProgressByCategory`) they listen to, and we will > deliver the events accordingly.
I think we're saying the same thing? > Yeah, with category, we will see "Indexing symbol table" and then we might > have both "a.out" and "b.out" details from two different categories needing > to be displayed. The debugger event that gets sent for > `eBroadcastBitProgressByCategory` might need some new accessors to account > for this. That's a great suggestion. I hadn't considered also doing grouping by category for events that have details, but you're right that there's really no reason not to. In that case we don't need to change the constructor at all, and this is all controlled by the broadcast bit, which makes things even simpler. https://github.com/llvm/llvm-project/pull/81026 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
