Editing service hookups per project:

Using kdevprojectserviceurlmapper in the editor context menu;

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 :)

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.