Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TimelineItem command callback values are now useless for "foreign" extensions #177319

Open
eamodio opened this issue Mar 16, 2023 · 3 comments
Open
Assignees
Labels
feature-request Request for new features or functionality timeline Timeline view issues
Milestone

Comments

@eamodio
Copy link
Contributor

eamodio commented Mar 16, 2023

refs: gitkraken/vscode-gitlens#2576

This PR #169621 stopped providing TimelineItem instances in the callback of commands on items. GitLens was reliant on that to provide additional features on GitTimelineItems, e.g. Open Commit on Remote.

I was trying to see if there was a way to still provide this GL feature, but now the only thing returned in the callback is a Uri to the file -- not a git: url with the sha or any other context.

Can the Uri that is returned be a qualified git: scheme Uri with the SHA embedded, or better yet some additional context object that would provide more details on the timeline item itself (so this wouldn't be specific for just Git based timeline entries)?

Thanks!

/cc @jrieken @lramos15

@lramos15
Copy link
Member

The reason for this change is we don't have other places that we expose extension objects to other extensions. This seemed like an oversight rather than a feature. I think the proposed fix would probably come from some sort of API with the built-in git extension not the API. An extension should opt-in to have its objects modified

@eamodio
Copy link
Contributor Author

eamodio commented Mar 25, 2023

While I understand that you'd like to avoid giving out "live" objects, that doesn't have to impede providing the data/information from those objects. With the #169621 change, extensions can no longer get any meaningful information about a timeline item.

There doesn't need to be a new API or anything. You can either provide a plain object with some relevant metadata about the timeline item itself (e.g. its public properties?) OR at a VERY least provide a Uri that actually provides context for the actual timeline item selected.

Also the idea of not providing live objects in callbacks is actually provided elsewhere -- TreeViewItem callbacks provide the TreeItem itself. Which is exactly what the Timeline was modeled on.

@jrieken
Copy link
Member

jrieken commented Mar 28, 2023

some relevant metadata about the timeline item itself (e.g. its public properties?)

Yeah, that is the plan. Give 3rd party extensions a clone that is the public API and give the origin extension its instance (with extra props etc). Tho, for the timeline we can only do that once it is finalised.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality timeline Timeline view issues
Projects
None yet
Development

No branches or pull requests

5 participants