Create Task
Maniphest T7148

how can krita become its own separate API docs area outside of calligra
Closed, ResolvedPublic
Actions

Description

Right now the Krita API docs are generated as part of the Calligra doxgen process.

https://api.kde.org/bundled-apps-api/calligra-apidocs/krita/html/

The developers were having a conversation in IRC if there is some way to take us out of there since Krita is not part of Calligra any longer. The main advantage being that people don't have to see classes and code that isn't part of Krita.

A couple different solutions were discussed:

  1. Moving Krita to its own doxygen area
  2. having a different process outside the normal kde API generation process

None of us were sure though of what would be the least work for you for this request. The main thing we don't want is someone manually generating and uploading the documentation in the end. We are hoping you could give us some recommendations/thoughts on how to separate our API docs area out of calligra.

Details

Commits
R883:1500566: Move Krita to extragear-graphics in Summit too
R883:1500565: Move Krita to extragear-graphics
R247:ff1d44799d3e: Move Krita out of Calligra in the structure. Ref T7148

Related Objects

Restricted Application added a subscriber: sysadmin. · View Herald TranscriptOct 6 2017, 4:38 PM
bcooksley changed the visibility from "Custom Policy" to "Public (No Login Required)".Oct 14 2017, 9:37 PM
bcooksley changed the edit policy from "Custom Policy" to "All Users".
bcooksley added a subscriber: rempt.
bcooksley added a subscriber: bcooksley.

I'd suggest we move Krita in the logical structure to accomplish this.

Currently it lives in calligra/ which is why it shows up underneath Calligra. While this was accurate historically, given it's now separate i'd suggest we move it to extragear/graphics/

Does this sound okay?

rempt added a comment.Oct 15 2017, 7:55 AM

Yes, extragear/graphics is fine with me.

bcooksley added subscribers: ltoscano, aacid.Oct 15 2017, 9:26 AM

Luigi & Albert, what's the best way to coordinate this move in the structure with you so you can sort things on the translations side?

ltoscano added a comment.Oct 15 2017, 9:28 AM

As long as it's done before 01:30 CEST when scripty starts, it's not complicated.

I guess that we can apply it retroactively also to the stable branch (which is already 3.x).

bcooksley added a comment.Oct 15 2017, 9:35 AM

Perfect, i'll move it shortly.

ltoscano added a comment.Oct 15 2017, 11:51 AM

Translations moved (yay, reference to phabricator tickets in SVN too now!)

rempt added a comment.Oct 16 2017, 11:05 AM

What should I change to make createtarball fetch the translations again?

This definition

[krita]
gitModule = yes
gitTag = v3.3.1
mainmodule = extragear/graphics/
submodule = krita
version = 3.3.1
translations= yes
docs = no
kde_release = no

doesn't seem to work.

rempt added a comment.Oct 16 2017, 11:17 AM

eek...

commit R37:4453c042a691
Author: l10n daemon script <scripty@kde.org>
Date: Mon Oct 16 03:26:47 2017 +0200

GIT_SILENT made messages (after extraction)

messed up the repo considerably, almost everything is gone.

bcooksley added a comment.Oct 19 2017, 8:26 AM

Sorry, i'm not familiar with the createtarball script.

ltoscano added a comment.Oct 19 2017, 10:25 AM
In T7148#114173, @rempt wrote:

What should I change to make createtarball fetch the translations again?

Are you using create_tarball_kf5? create_tarball does not properly support Qt5/Frameworks applications.

Going forward the proper way is use releaseme.

rempt added a comment.Oct 19 2017, 10:45 AM

Yes, create_tarball_kf5 . I don't think I've seen releaseme...