[Daniel-ADFA]

Plugin-contributed sidebar and toolbar items now route long-press and hover through the plugin's own tooltip category (plugin_), so they resolve to entries the plugin installs via DocumentationExtension. Adds PluginTooltipButton.directPath to bypass plugin// URI scoping (for example, to point at a shared i/plugins-adfa.html), and tooltipTag on MenuItem/NavigationItem so one tooltip entry can serve both surfaces.

Fixes plugin manager icons: PluginMetadata now carries the iconDayPath and iconNightPath that PluginLoader extracts at install time, instead of always being null. Extracts pluginCategory() and pluginTooltipTag() helpers so the "plugin_" prefix and "." tag shape live in one place.

[coderabbitai]

📝 Walkthrough

Release Notes

New Features

• Plugin Tooltip Categorization: Plugin-contributed sidebar and toolbar items now route tooltip lookups through a plugin-specific category (plugin_<pluginId>), enabling plugins to install custom tooltips via DocumentationExtension without colliding with built-in IDE documentation
• DirectPath URI Option: Added directPath boolean parameter to PluginTooltipButton to bypass automatic plugin/<pluginId>/ URI scoping, allowing tooltips to reference shared documentation paths (e.g., i/plugins-adfa.html)
• Unified Tooltip Tags: Added optional tooltipTag property to both MenuItem and NavigationItem, enabling a single tooltip entry to serve both sidebar/navigation and toolbar/menu surfaces by specifying the same tag on both items
• Plugin Icon Metadata: Fixed plugin manager icons by extracting iconDayPath and iconNightPath from loaded plugins into PluginMetadata, ensuring icons are properly resolved at install time

Implementation Improvements

• Centralized Helpers: Extracted pluginCategory(pluginId: String) and pluginTooltipTag(pluginId, itemId) helper functions to consolidate the "plugin_" prefix pattern and tooltip tag naming convention across the codebase
• Unified Tooltip Display: Generalized tooltip rendering in EditorHandlerActivity and EditorSidebarFragment to use TooltipManager.showTooltip() with explicit category parameter instead of specialized category-specific methods

Breaking Changes ⚠️

• PluginActionItem Constructor: Now requires a pluginId: String parameter; previously the constructor did not accept this parameter
• PluginSidebarActionItem Constructor: pluginId parameter changed from nullable (String? = null) to required non-null (String); code instantiating this class directly must be updated
• ActionItem Interface: Added new method retrieveTooltipCategory(): String with default implementation; implementations may override to customize tooltip routing

Potential Risks

• Null Handling: EditorSidebarActions.kt uses pluginId ?: "" fallback when plugin ID is not found, which could mask cases where plugin identification truly fails; empty string may result in malformed tooltip categories (plugin_)
• Plugin Compatibility: Existing third-party plugins that directly instantiate PluginActionItem or PluginSidebarActionItem will fail to compile or initialize due to constructor signature changes; plugin authors must be notified to update their code
• Silent Fallbacks: The use of empty string fallback for missing plugin IDs may cause tooltip lookups to silently fail without clear error diagnostics

Walkthrough

The PR introduces a tooltip categorization system enabling actions to route tooltip lookups to category-specific rows. It adds retrieveTooltipCategory() to ActionItem, updates plugin action items to track plugin IDs and override tooltip metadata, adds helper functions for plugin-scoped tooltip naming, and refactors tooltip display calls throughout the app to use explicit categories instead of hardcoded IDE-only tooltips.

Changes

Cohort / File(s)	Summary
Tooltip Infrastructure actions/src/main/java/.../ActionItem.kt, plugin-manager/.../PluginTooltipNaming.kt	Added retrieveTooltipCategory() method to ActionItem defaulting to IDE category; introduced shared helper functions pluginCategory() and pluginTooltipTag() for consistent plugin tooltip naming.
Action Item Implementations app/src/main/java/.../PluginActionItem.kt, app/src/main/java/.../PluginSidebarActionItem.kt	Updated constructors to require non-null pluginId and added tooltip category/tag overrides using plugin-scoped metadata and fallback to computed names.
UI Integration & Tooltip Routing app/src/main/java/.../EditorHandlerActivity.kt, app/src/main/java/.../EditorSidebarFragment.kt, app/src/main/java/.../EditorActivityActions.kt, app/src/main/java/.../EditorSidebarActions.kt	Updated tooltip display calls to use TooltipManager.showTooltip with explicit category parameter retrieved from actions; modified tooltip setup to accept and forward category.
Plugin API Extensions plugin-api/src/main/kotlin/.../UIExtension.kt, plugin-api/src/main/kotlin/.../DocumentationExtension.kt	Added optional tooltipTag property to MenuItem and NavigationItem; added directPath boolean parameter to PluginTooltipButton for URI resolution control.
Plugin Manager & Services plugin-manager/.../PluginManager.kt, plugin-manager/.../PluginDocumentationManager.kt, plugin-manager/.../IdeTooltipServiceImpl.kt	Refactored icon path handling via LoadedPlugin.toPluginMetadata() helper; updated tooltip category computation to use shared pluginCategory() helper; added directPath parameter handling in URI resolution.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• ADFA-3148: Refactor APK Analyzer plugin with Material table UI and ViewModel #1117 — Modifies PluginSidebarActionItem and editor/sidebar action integration to thread pluginId and tooltip metadata through the UI layer.
• ADFA-2867: Migrate plugin tooltips into documentation.db #1019 — Introduces plugin tooltip categorization with shared helpers and adjusts tooltip display to use plugin-scoped categories.
• ADFA-3747: Git UI tooltips #1224 — Modifies tooltip usage and definitions, updating tooltip call sites that overlap with this refactor's shift from showIdeCategoryTooltip to showTooltip.

Suggested reviewers

• itsaky-adfa
• dara-abijo-adfa

Poem

🐰 Tooltips dance in categories now,
Plugin-scoped and organized, wow!
From IDE to plugin realms they route,
Each action knows its tooltip route,
Organized whispers, no longer astray! 📚✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 21.74% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main changes: adding plugin sidebar/toolbar tooltips and the directPath URI option for tooltips.
Description check	✅ Passed	The description clearly explains the primary changes across multiple areas: tooltip routing for plugins, directPath support, tooltipTag properties, and icon metadata fixes.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ADFA-3777

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Review rate limit: 0/1 reviews remaining, refill in 60 minutes.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

app/src/main/java/com/itsaky/androidide/utils/EditorSidebarActions.kt (1)

243-257: ⚠️ Potential issue | 🟠 Major

Don't register plugin sidebar items with an empty fallback ID.

If getPluginIdForInstance() returns null, the empty-string fallback will feed malformed values into PluginSidebarActionItem and SidebarSlotManager.getDeclaredSlots(...), which can break tooltip routing and the sidebar slot check. Skip unresolved plugins instead.

Suggested fix

-                val pluginId = pluginManager.getPluginIdForInstance(plugin as com.itsaky.androidide.plugins.IPlugin)
-                val declaredSlots = SidebarSlotManager.getDeclaredSlots(pluginId ?: "")
+                val pluginId = pluginManager.getPluginIdForInstance(
+                    plugin as com.itsaky.androidide.plugins.IPlugin
+                ) ?: run {
+                    Log.w("plugin_debug", "Skipping sidebar items for plugin without a registered ID: ${plugin.javaClass.simpleName}")
+                    return@forEach
+                }
+                val declaredSlots = SidebarSlotManager.getDeclaredSlots(pluginId)
@@
-                    val action = PluginSidebarActionItem(context, navItem, order++, pluginId ?: "")
+                    val action = PluginSidebarActionItem(context, navItem, order++, pluginId)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/com/itsaky/androidide/utils/EditorSidebarActions.kt` around
lines 243 - 257, The code currently uses
pluginManager.getPluginIdForInstance(plugin ...) and falls back to an empty
string which leads to malformed values; change the loop to skip any plugin where
pluginManager.getPluginIdForInstance(...) returns null: call
pluginManager.getPluginIdForInstance(plugin as
com.itsaky.androidide.plugins.IPlugin) into a val pluginId and if pluginId ==
null return@forEach (or continue), then pass pluginId (non-null) into
SidebarSlotManager.getDeclaredSlots(...) and PluginSidebarActionItem(...) and
perform the sideMenuItems size check only for resolved pluginId values.

plugin-api/src/main/kotlin/com/itsaky/androidide/plugins/extensions/UIExtension.kt (1)

52-68: ⚠️ Potential issue | 🔴 Critical

Binary compatibility break for precompiled plugins confirmed.

Lines 66 and 100 add tooltipTag parameter to MenuItem and NavigationItem data classes. In Kotlin/JVM, this changes constructor signatures and breaks already-compiled plugins at runtime (NoSuchMethodError) unless compiled with @JvmOverloads. Since no @JvmOverloads annotation is present, precompiled third-party plugins depending on this API will fail.

Internal plugins (markdown-preview-plugin, keystore-generator-plugin, apk-viewer-plugin) built from source can recompile, but external/third-party plugins compiled against earlier versions will break. No API version enforcement exists in PluginLoader to prevent loading incompatible plugins.

Recommend either:

1. Add @JvmOverloads annotation to affected data classes
2. Add explicit API-version checking in plugin loading
3. Document breaking change prominently for plugin developers

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@plugin-api/src/main/kotlin/com/itsaky/androidide/plugins/extensions/UIExtension.kt`
around lines 52 - 68, Adding the nullable tooltipTag parameter to the data
classes breaks binary compatibility for precompiled plugins; update the MenuItem
and NavigationItem constructors to preserve JVM overloads by annotating the
classes' primary constructors with `@JvmOverloads` so callers compiled against the
old constructors still resolve, and ensure the new nullable parameter has a
default value (tooltipTag: String? = null) in the declarations (refer to
MenuItem and NavigationItem) so JVM overloads are generated for all constructor
arities; alternatively, if you opt not to use `@JvmOverloads`, add explicit
API-version checking in the plugin loading path to reject incompatible plugins
instead.

🧹 Nitpick comments (1)

plugin-manager/src/main/kotlin/com/itsaky/androidide/plugins/manager/core/PluginManager.kt (1)

1491-1495: Narrow the helper's visibility.

This extension is only used inside PluginManager.kt, so making it private would reduce the public surface area and avoid having two toPluginMetadata() helpers in the same file.

♻️ Proposed tweak

-fun LoadedPlugin.toPluginMetadata(): PluginMetadata =
+private fun LoadedPlugin.toPluginMetadata(): PluginMetadata =
     manifest.toPluginMetadata().copy(
         iconDayPath = iconDayPath,
         iconNightPath = iconNightPath,
     )

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@plugin-manager/src/main/kotlin/com/itsaky/androidide/plugins/manager/core/PluginManager.kt`
around lines 1491 - 1495, The LoadedPlugin.toPluginMetadata() extension is only
used within PluginManager.kt, so narrow its visibility by marking the extension
function private (i.e., change its declaration to a private extension) to reduce
public surface and avoid duplicate helpers; locate the
LoadedPlugin.toPluginMetadata() extension in PluginManager.kt and make it
private while preserving its current behavior and return value.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/java/com/itsaky/androidide/utils/EditorActivityActions.kt`:
- Around line 186-190: The code currently falls back to an empty pluginId when
pluginManager.getPluginIdForInstance(plugin as
com.itsaky.androidide.plugins.IPlugin) returns null, which registers actions
with malformed metadata; instead, detect a null pluginId and skip registering
that plugin's contributions entirely (do not construct PluginActionItem or
iterate its getMainMenuItems()), logging or silently ignoring as appropriate;
update the block around pluginManager.getPluginIdForInstance,
PluginActionItem(...) and plugin.getMainMenuItems() so registration only
proceeds when a non-null, non-empty pluginId is returned.

In
`@plugin-api/src/main/kotlin/com/itsaky/androidide/plugins/extensions/DocumentationExtension.kt`:
- Around line 110-118: The PluginTooltipButton data class gained a fourth
parameter directPath, breaking binary compatibility with the previous 3-arg
constructor; add a secondary constructor on PluginTooltipButton with the
original three parameters (label: String, uri: String, order: Int) that
delegates to the primary constructor and supplies false for directPath (e.g.
constructor(label: String, uri: String, order: Int) : this(label, uri, order,
false)) so existing binaries keep working.

---

Outside diff comments:
In `@app/src/main/java/com/itsaky/androidide/utils/EditorSidebarActions.kt`:
- Around line 243-257: The code currently uses
pluginManager.getPluginIdForInstance(plugin ...) and falls back to an empty
string which leads to malformed values; change the loop to skip any plugin where
pluginManager.getPluginIdForInstance(...) returns null: call
pluginManager.getPluginIdForInstance(plugin as
com.itsaky.androidide.plugins.IPlugin) into a val pluginId and if pluginId ==
null return@forEach (or continue), then pass pluginId (non-null) into
SidebarSlotManager.getDeclaredSlots(...) and PluginSidebarActionItem(...) and
perform the sideMenuItems size check only for resolved pluginId values.

In
`@plugin-api/src/main/kotlin/com/itsaky/androidide/plugins/extensions/UIExtension.kt`:
- Around line 52-68: Adding the nullable tooltipTag parameter to the data
classes breaks binary compatibility for precompiled plugins; update the MenuItem
and NavigationItem constructors to preserve JVM overloads by annotating the
classes' primary constructors with `@JvmOverloads` so callers compiled against the
old constructors still resolve, and ensure the new nullable parameter has a
default value (tooltipTag: String? = null) in the declarations (refer to
MenuItem and NavigationItem) so JVM overloads are generated for all constructor
arities; alternatively, if you opt not to use `@JvmOverloads`, add explicit
API-version checking in the plugin loading path to reject incompatible plugins
instead.

---

Nitpick comments:
In
`@plugin-manager/src/main/kotlin/com/itsaky/androidide/plugins/manager/core/PluginManager.kt`:
- Around line 1491-1495: The LoadedPlugin.toPluginMetadata() extension is only
used within PluginManager.kt, so narrow its visibility by marking the extension
function private (i.e., change its declaration to a private extension) to reduce
public surface and avoid duplicate helpers; locate the
LoadedPlugin.toPluginMetadata() extension in PluginManager.kt and make it
private while preserving its current behavior and return value.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 12083327-9d44-45b8-8fc2-8d787902002c

📥 Commits

Reviewing files that changed from the base of the PR and between 24f0b89 and 1c00b4a.

📒 Files selected for processing (13)

• actions/src/main/java/com/itsaky/androidide/actions/ActionItem.kt
• app/src/main/java/com/itsaky/androidide/actions/PluginActionItem.kt
• app/src/main/java/com/itsaky/androidide/actions/PluginSidebarActionItem.kt
• app/src/main/java/com/itsaky/androidide/activities/editor/EditorHandlerActivity.kt
• app/src/main/java/com/itsaky/androidide/fragments/sidebar/EditorSidebarFragment.kt
• app/src/main/java/com/itsaky/androidide/utils/EditorActivityActions.kt
• app/src/main/java/com/itsaky/androidide/utils/EditorSidebarActions.kt
• plugin-api/src/main/kotlin/com/itsaky/androidide/plugins/extensions/DocumentationExtension.kt
• plugin-api/src/main/kotlin/com/itsaky/androidide/plugins/extensions/UIExtension.kt
• plugin-manager/src/main/kotlin/com/itsaky/androidide/plugins/manager/PluginTooltipNaming.kt
• plugin-manager/src/main/kotlin/com/itsaky/androidide/plugins/manager/core/PluginManager.kt
• plugin-manager/src/main/kotlin/com/itsaky/androidide/plugins/manager/documentation/PluginDocumentationManager.kt
• plugin-manager/src/main/kotlin/com/itsaky/androidide/plugins/manager/services/IdeTooltipServiceImpl.kt

[jatezzz]

Please take a look to coderabbit comments