You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Jupyterlab supports a very wide varity of files and file viewers. Currently the API for commenting is usable for creating third party extensions, but the use is very limited and not very easy to integrate.
The press release mentions how comments can be on "anything". It also introduces the idea of a comment's "target". Simply put, the "target" of the comment is the thing which the comment is about. If you target a single line of code in your comment, it is because you want to address something about that line of code in your comment. The target is stored with the comment so that in the future you can see which things every comment targets.
As such, there are many kinds of "targets" (the press release enumerates several). It is reasonable to expect a heavy user of JupyterLab will have comments on many different targets -- possibly many hundred targets if they work with a team.
It would be ugly and distracting to show on the screen the target of every comment all at once. There will be too many. Thus, we must figure out a good UI/UX design to show only the targets which are most relevant for the user for their current context.
Everything about JupyterLab is extendable. It's a tenet on which JupyterLab software architecture is founded.
Thus, as we introduce the idea of a "target" for a comment, it should be such that other extensions can add new targets. For this, we need to design an API so that the targeting system is extendable.
The text was updated successfully, but these errors were encountered:
Jupyterlab supports a very wide varity of files and file viewers. Currently the API for commenting is usable for creating third party extensions, but the use is very limited and not very easy to integrate.
The press release mentions how comments can be on "anything". It also introduces the idea of a comment's "target". Simply put, the "target" of the comment is the thing which the comment is about. If you target a single line of code in your comment, it is because you want to address something about that line of code in your comment. The target is stored with the comment so that in the future you can see which things every comment targets.
As such, there are many kinds of "targets" (the press release enumerates several). It is reasonable to expect a heavy user of JupyterLab will have comments on many different targets -- possibly many hundred targets if they work with a team.
It would be ugly and distracting to show on the screen the target of every comment all at once. There will be too many. Thus, we must figure out a good UI/UX design to show only the targets which are most relevant for the user for their current context.
Everything about JupyterLab is extendable. It's a tenet on which JupyterLab software architecture is founded.
Thus, as we introduce the idea of a "target" for a comment, it should be such that other extensions can add new targets. For this, we need to design an API so that the targeting system is extendable.
The text was updated successfully, but these errors were encountered: