Add dummy preference descriptions to open AI config widget

[colin-grant-work]

What it does

Fixes #15160 by adding preferences whose descriptions redirect users to the config widget to enable them to perform more advanced AI configuration.

Fixes #15165 by generating section names differently depending on presence or absence of layout item and by using the preference tree label provider's logic for label generation.

How to test

1. Open the settings and look for settings under 'AI Features ... Agents', 'AI Features ... Models', and 'AI Features ... Prompt Templates'
2. You will find a dummy preference with a link to open the configuration widget.
3. Click the link, and the config widget should open.

The third segment (details) is to work around #15165

Follow-ups

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[sdirix]

It fulfills the purpose but I'm not so happy about the result as the "Edit in settings.json" is wildly misleading.

We might need to register a custom preference render to avoid producing it.

And if we're doing that, we could instead have a custom renderer for these sections and within there render the hint. This would allow us to avoid declaring a non-existing preference.

Generally speaking, supporting a description text for sections would be nice but might be out of scope for this issue.

[colin-grant-work]

Generally speaking, supporting a description text for sections would be nice but might be out of scope for this issue.

I had the same thought. One easy workaround would be a special renderer for preferences with declared type null that just doesn't have any interactable at all.

[colin-grant-work]

I've pushed a commit that adds a renderer for preferences whose only declared type is null and confirmed that that includes only the three that I've added here so that only the message appears.

[sdirix]

I'm a bit torn because it works, however in the end it's still a hack.

It's a hack because we have many unintended side effects:

• we register preferences although there are none
• we offer these preferences in the JSON Editor for autocomplete etc.
• we offer UI to copy the preferences name, id, etc. although they are useless
• they influence search in the preferences UI

Of course the overall impact is minimal, and I also don't see any collateral as I can't think of a real world use case for preferences of type null.

---

Overall it would be much nicer to enrich sections to allow optional descriptions. Then we could add this text to these sections and avoid registering additional preferences.

---

However I don't want to block the merge if we want to tackle this in a follow up then

[colin-grant-work]

@sdirix, since your comments

• Add schema for agent settings #15175 has been merged that contributes a schema for some of the preferences discussed here that we want to use for validation but not for configuration. I have added functionality to the preference UI that checks for a hidden field on a given schema property and hides that property if found. The new preferences from Add schema for agent settings #15175 should not be visible.
• I have fixed the bug in Two-segment preferences not rendered if first segment is group #15165 with respect to AI Feature preferences, but not generally.

Regarding your comments:

• we register preferences although there are none

• we offer these preferences in the JSON Editor for autocomplete etc.

• we offer UI to copy the preferences name, id, etc. although they are useless

• These are true and not ideal, but as a workaround, I think this is expedient, and I don't think it will hurt anybody.

• they influence search in the preferences UI

• This one is correct, and in my opinion, desirable, because we do want people to see these if they search for something relevant. That's really the idea behind the PR: if users go looking in the settings view, we want them to see these and be redirected to the appropriate view. This is also an argument against using a heading + rendered description, because only leaf items and not headings get rendered in search results, so implementing these as leaf items, even though they're 'dummies' makes them more discoverable.

[sdirix]

We should not get rid of the AI subsections:

I think they are necessary for quick access and as an overview over the AI features.

[colin-grant-work]

We should not get rid of the AI subsections:

Quite right, looks like leaving things in a skeletal state in #14048 created a number of issues in the preference system. I'll fill out the children that should have been added then.

[sdirix]

If we remove settings: ['ai-features.*'] from the preference layout again, then the sections are back. Or do you prefer a manual approach?

[colin-grant-work]

I'll do both: #13819 assumes that everything should be in the layout provider, and so broke sections that didn't manually specify all their children, because two-segment sections aren't rendered and intermediate labels aren't split correctly ('CodeCompletion' instead of Code Completion).

Manual specification has the advantage of better NLS support, but now I'm frustrated enough with the problems that I'll go and fix the automatic generation more thoroughly, as well, rather than plastering over it with the ['ai-features.*'] rule - shouldn't take long.

[sdirix]

Works for me. Thanks! 👍

---

Coming back to the original topic of this PR: Using pseudo-preferences to achieve UI changes feels like we're working around the system rather than with it. This approach brings some minor but notable side effects that aren't ideal from a technical standpoint.

That said, the user experience benefits are significant enough that I'll approve this PR. I do think we should consider a cleaner solution in the future that accomplishes the same UI improvements without repurposing our preference system in ways it wasn't designed for.