> Still thinking a bit about the symbol tree - it would be nice not to have a > separate tab that users have to switch to. What about: > > * allowing the plugin to access the GtkTreeView of the symbol tree so it can > put whatever it wants there
Could the extension be called once (per document, and probably when changing filetype) to create the TreeView? This could allow the extension answer `GtkWidget *create_tag_view(GeanyDocument, …)`, returning a `GtkTreeView` with whatever renderers and model it wants. > * have some "filter-modified" event so the plugin knows when the filter > changed If we reimplement the feature using `GtkTreeModelFilter` instead of the custom code from d3ded11ad2c8caeb0dd4aef2fcff517c5672b2e2, and require the model in the view to be a filter, we could probably just call [`refilter()`](https://docs.gtk.org/gtk3/method.TreeModelFilter.refilter.html) and give access to the entry data somehow. Or require the plugin to manually listen to `changed` itself like we do. In any case, the plugin need to have access to the filter value, so either have an event like you said, or a mean to access it at will. > […] > In theory this should be all it's needed but something else may appear during > implementation. How does it sound? Good if it's not too hard to implement the details like activating a row, navigating them an whatnot, but I guess we don't have much custom stuff apart knowing where to go, which is exactly what the extension *would* know how to do. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#issuecomment-2161541163 You are receiving this because you are subscribed to this thread. Message ID: <geany/geany/pull/3849/[email protected]>
