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 d3ded11, and require the model in the view to be a filter, we could probably just call refilter() 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, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.