Initial support for hookup of projects with general (web) services
Needs ReviewPublic

Authored by kossebau on Feb 20 2017, 1:04 AM.

Details

Reviewers
mwolff
Group Reviewers
KDevelop
Summary

For a project there can be lots of other activities besides actual
code development, building and running/debugging. There are
things like issue tracking, task organization, schedules, CI servers,
communication, documentation, localization, and more. Which usually
are organized with central services, either accessed via web browsers
or specific clients (e.g. irc, mailinglist).
For more _I_ in IDE it would be attractive to integrate more with those
services when useful.

This patch adds a new lib KDevPlatformServices, to start support for
connecting to such services and collecting any related classes & interfaces.
Any plugin providing support for a given type of service would implement
the new interface IProjectServiceHookup, next to IPlugin.
The new plugin kdevprojectservicehookupmanager will collect any such
plugins and enable to add to a project multiple hookup configurations
using any of the available plugins.
Each IProjectServiceHookup plugin would implement all kind of other
interfaces, matching the capabilities of the respective service.
And when their interface is used, they would respond using the
respective configurations for the loaded projects.

There are three service hookup plugins in this patch:

  • gitlab
  • phabricator
  • cgit

Initially they all only implement the new IProjectServiceUrlMapper
interface. This one maps urls to locations/items in services and
locations/items in the local project. Initially this only covers
getting matching urls for the current document + cursor position
in a repo browsing service. The interface is planned to be extended
to also cover the reverse and other items, like commits/change sets.

A new plugin kdevprojectserviceurlmapper, also in this patch, makes
use of this interface and integrates a submenu into the editor context
menu, to open for the curremt document and cursor position the matching
link of a repo browsing service in the browser or at least copy the link
to the clipboard, to use it e.g. in a chat.

Future plans:
Project providers, like the KDE provider, would automatically
configure any known service hookup. No idea yet how to do that
in a cross-plugin agnostic way. Unless the repo provider is
part of a service suite, like github: there the provider plugin
can be extended into a IProjectServiceHookup one and handle all
this internally.

Diff Detail

Repository
R32 KDevelop
Branch
addServiceLocationMapping
Lint
No Linters Available
Unit
No Unit Test Coverage
kossebau created this revision.Feb 20 2017, 1:04 AM
Restricted Application added a subscriber: kdevelop-devel. · View Herald TranscriptFeb 20 2017, 1:04 AM

Editing service hookups per project:

Using kdevprojectserviceurlmapper in the editor context menu;

mwolff requested changes to this revision.Feb 21 2017, 10:33 PM
mwolff added a subscriber: mwolff.

Tons of new files and not a single test? Can you add some?

I don't have the time to review all the files, but some remarks from looking at the images and reading your commit message:

  • what other things do you want to integrate?
  • i.e. for the current feature of getting a remote link to the current file this sounds like overkill

In general, what do you plan to use this for? I mean the joy of git is that it's distributed. When would I ever need to go to the remote website for the current file? I can simply checkout a branch locally and look at that, no?

This revision now requires changes to proceed.Feb 21 2017, 10:33 PM
kossebau updated this revision to Diff 22422.Nov 16 2017, 12:42 AM

update to current master, add url mapping for vcs revisions

In D4672#88425, @mwolff wrote:

Tons of new files and not a single test? Can you add some?

Yes, haven't yet thought about unit tests, given the whole API is candidate for discussion.

I don't have the time to review all the files, but some remarks from looking at the images and reading your commit message:

  • what other things do you want to integrate?

Ideally (and optionally per plugin) anything from project management which somehow is reflected in the code (repository).
Like

  • bug ids in comments -> translated into links into the (web) UI of the issue tracker tool (or even fetching of bug metadata for tooltip)
  • keywords in commit messages -> translated into links into web UI of related (web) services or local client tools
  • version tags -> milestone tracker/project management tool
  • CI -> seeing current state in a tool view
  • author data -> PIM cpnnector showing more info about person or allowing to contact
  • filing tasks and todos -> invoke tools directly from IDE, without having to first hunt down the tools and find the correct folder for the project

Especially when working on multiple projects at the same time or switching between some often, having the project content in the IDE enriched with related project data can improve developer life a lot. I do not have a master plan here, so far things are driven by a "oh-it-would-be-so-useful-to-have-this-instead-of-all-manual-pain".

In general, what do you plan to use this for? I mean the joy of git is that it's distributed. When would I ever need to go to the remote website for the current file? I can simply checkout a branch locally and look at that, no?

The url mapping comes useful when working remotely with other people on the same files. E.g. when you look at the code and have a question or comment on something, when you communicate with the remote mates (e.g. in chat or central document/notes), you want to have a unique id of the content, which ideally can be automatically processed., so people can just click the id.
Or when you use the web UI of the main repository to make comments on code (think phabricator), it's nice to get your IDE pass you directly to the place in the webUI.
Same with the revision url mapping I added in the latest version.

Another use case yet to be explored would be custom kdevelop:// urls. So if multiple people use kdevelop, they could use such urls to create pointers into the content of a project, and then pass the url around e.g. on irc, and one would just click the link and get e.g. some text area shown and highlighted which the other person is talking about: "hey jane, in kdevelop://project_foo/src/pluginA/worker.cpp?11-15 isn't that inverted logic?"
Though the same can also be achieved with mapping to/from a central Web UI, which would also allow others without kdevelop to follow: "hey jane, in https://phab.foo.bar/src/pluginA/worker.cpp?11-15 isn't that inverted logic?"
And the url mapping plugins would care for creating the urls and mapping the urls back into content positions, so the user does not have to type anything.

I know there have been times in my developer life where this feature of url mapping would have been very handy. Also in KDE development community setup I can see at least myself making use of it now and then, including kdevelop development :)

apol added a subscriber: apol.Nov 16 2017, 12:02 PM

Maybe instead of having all of the configuration UI's a better first approach would be to detect the plugins we can use from what's in the repository?

For example github we can detect by checking .git/config or, well, git remote show origin. With phabricator we can look for the .arcconfig file.

In D4672#168433, @apol wrote:

Maybe instead of having all of the configuration UI's a better first approach would be to detect the plugins we can use from what's in the repository?

For example github we can detect by checking .git/config or, well, git remote show origin. With phabricator we can look for the .arcconfig file.

Yes, reading existing data should be done when possible, good hint. I had not yet invested in such data finding code, so far concentrated on the service/plugin APIs to develop some sane structures.

A use-case I have in mind though is also supporting multiple instances of services. I have worked in setups with a private and public instance of same service, for keeping private/customer data separate from public/community data. So the data about services in the repo was not complete, and one would still need a UI to enter service data.

But pre-filling with detected existing data is a good idea, agreed.

Ok, so thinking about the ideas you propose, I can see how this could become useful over time. It certainly is visionary :) I still don't have the time for an in-depth review though - sorry for that. But this overall sounds like a bigger feature set that should be rather developed in a feature branch, no? Phabricator is bad for reviewing something like this, imo.