Can this be done without need to patch all the addons? Like, by default consider they match all the tags?

In D3076#72739, @Sergey Sharybin (sergey) wrote:

Can this be done without need to patch all the addons? Like, by default consider they match all the tags?

If the addon developers do nothing, the add-ons will always show, since - like Blender's panels, they have no ui_tag.
We could leave this as-is and only have intrusive add-ons used this feature (for e.g. this isn't especially helpful for exporters that only add a single menu item).

We could try having something like the hack in this patch implemented a little more nicely although I don't really like meddling with classes automatically based on a global state - it will backfire if an addon imports classes from another add-on, we can try workaround by detecting class modules, but this feels a bit weak.

Having to modify addons might not be so bad. Since it's quite common for UI heavy addons to share a base class with a generic poll function / space type, this can include a ui_tag too.

I am completely lost now. There is no "Use Tags" in workspace, there is no "Use tags" in addons settings, and no tags control in the addon properties. So how does it work now?

@Sergey Sharybin (sergey) there is a 'use_tags' in workspace, with its new panel in buttons, if I can still read code correctly…

@Campbell Barton (campbellbarton) Patch globally looks OK to me. Only thing I find a tad disappointing is the limitation to a single tag per UI item (panel, menu, etc.).

In my understanding, tags would be used to much more than 'just' filtering addons per workspaces, they could also filtering different levels of complexity (e.g. an addon - or even own UI and operators - could define different panels for an 'advanced' and a 'beginner' UI, a same addon could define different parts of itself for different types of data and/or workflows, etc.). That would imho imply that a single panel could have several tags (e.g. `{'ADVANCED', 'MESH', 'MY_ADDON', 'NORMALS_EDITING'} for a panel regrouping advanced tools in mesh editing). One could of course add a all this as a single super-specialized tag, but…

I guess we can extend current code to that later though, if/when needed.

As I understand it, the idea is that users can create workspaces and choose which addons they want in each.

With that in mind, I don't really understand why this uses generic tags. If we want to have a UI where users can reliably select an addon to be part of some workspaces, then all the panels and menus of that addon must have a the tag equal to the addon name, otherwise that UI breaks. So to me it seems more logical to explicitly name this bl_addon or bl_owner or something, not a tag.

If we want some kind of grouping of addons or automatic matching with workspaces, it seems better to define tags in the addon bl_info.

As for the add-ons side, I think that the concept of the filtering location and what is supported (one workspace or multiple ones) for individual add-ons is more important than the concrete default way.

There is already the panel location altering code for the Toolbar region like in T50726. Things can be more automated there too as it needs preferences defined and adds boiler plate code to each add-on, but it can be looked as a proof of concept for add-on makers for something similar - depending of what is allowed by the API. Like a dropdown list of workspaces in add-on preferences :)

I tested with my own addon (Object Collections) and it worked fine, nice work. However I could not disable the OBJ i/o.

As for UI, shouldn't we disable the list of Addons when use_ui_tags is False?
Also If we are to keep the name Show/Hide Add-On's it should at least be Show/Hide Add-ons. That said I think it may be better to call it Filter Add-ons.

• Currently each UI element has a single identifier, this is only using the add-on name by convention - we could have arbitrary categories easily (the UI currently only shows addon tags, that can be changed trivially).

• Brecht noted, this could be called bl_owner, seems reasonable since tags hint at allowing multiple.
  
  If this feature is kept _only_ for add-ons, then agree this would be better located in bl_info, or we try do it automatic.

• Bastien mentions this could allow for multiple tags. In principle I'm not against this but wonder if we would really end up making use. It's a bit heavy to add a set of strings to each manipulator/menu/panel type - then do a union-test between the two - to check if we draw a panel - for eg (perhaps the result could be cached, but still).
  
  An issue with having more fine grained & flexible control is IMHO - users aren't going want to do tedious per-add-on, per-panel, per-keymap configuration of multiple tags.
  
  If the intent is to have tags be hidden from the users, to implement something more simple, then we could look into how that would work.
  
  OTOH, if we only end up using this for toggling addons per workspace, IMHO it's overkill

• Dalai: Currently this doesn't remove items, will add support for this.
  
  Term 'filter' in code context makes sense, I thought in graphical application it might be confused with image-filter. Show/Hide is a more obvious.

Besides possible naming/ui improvements, think this patch is ready to land.

LGTM!