- User Since
- Sep 12 2015, 12:37 PM (227 w, 4 d)
Thu, Dec 26
One minor correction then you can ship it
Dec 5 2019
If we want to generate the doc of the libs one by one, it means that we need to have the order of generation.
Dec 4 2019
Dec 3 2019
Another idea about the issue raised for "tweaking the csss/html" :
Very interesting ideas!
Dec 1 2019
If it still works it's OK to push.
Nov 19 2019
BTW is it an external api or the project internal doxygen? If the latter, it should not be generated by apidox here
This will fail as the group applications is not defined anywhere. A repo should define a group so that other repositories use it
Nov 11 2019
OK... it seems you have been very precise plan and that what I've been trying to do was wrong or not manageable.
In terms of generating the front page, this responsibility would now be handled exclusively by Part 2, and would be done in realtime on the frontend server, based on the API Documentation that has been uploaded to it - hence why I suggested use of PHP. KApiDox would not be involved in this at all.
Nov 10 2019
Oh and I forgot. Not only KF5 and small projects' documentation are generated by KApiDox.
some answers about what already exists and what is difficult in the proposition you made.
This is solved in kapidox anyway.
Oct 13 2019
Sep 16 2019
Jul 12 2019
Nice! Thx Harald!
Apr 21 2019
Would there be a way to have two repos?
Just my 2 cents : I would rename "for users" to something more obvious like User support or something better and have the Get Involved bellow (before Donate). The reason for the last item is that I think that this websites target is more potentiel users than contributors.
Dec 11 2018
Great work. It looks very pro and classy.
Nov 23 2018
Nov 22 2018
The root cause is that we build twice the same elements instead of having one share lib used on the two contexts.
Nov 21 2018
Well it's not really a dependency, is it? They only use the same sources to build up two different views of the same widget. This patch is hacky as the original cmakefile... I understand the need but can't the patch fix the root cause instead?
Nov 11 2018
Oct 31 2018
OK fine, ship it
Oct 30 2018
Seems ok to me but as I haven't checked on my Nextcloud instance, so I can't really say it's good.
Just to be sure: you just factored both treatment in one? Or do I miss something?
I haven't tried the code but it seems good to me. And way more understandable.
Oct 21 2018
D16013 implemented the same idea in a better way
Oct 17 2018
... I'm specifically write about the month view, but it holds also for the other views
Aug 22 2018
Solved BY T9459
Aug 21 2018
Aug 20 2018
Fix as dfaure said
Added licences and add some changes to fit what was done on D14955
Added Licence, made it compile within the whole project and fix issues raised by dfaure.
I think it could be nice that you leave the ticket visible by people (to keep track of the decision)
@bencreasy no problem. I opened a ticket to tell that it still isn't obvious for everyone. This means we need more work on this :)
See T9354 for still common misconceptions about Techbase. Something must be done about that so that people are not confused anymore
And you are right Techbase pages which are related to on boarding new contributors, do bug tracking etc are stale because they should be deleted. Techbase is for external devs, technical users, but not us as the kde community
No, Techbase is not related to development within the kde community. But if for example the Cantata dev (who is not a KDE guy) wants to use our libs, he doesn't care about how we commits and dev. What he wants is how to compile the code, how to find help, who to contact if he finds a bug etc....
Aug 19 2018
If you agree on that I'll open the sysadmin ticket that would be needed
IMO the policy link should be removed, but the contribute link should be updated.
Aug 15 2018
For memo, an extract of the email I wrote:
Jun 12 2018
@dvratil: can you add this to the next bugfix patch ?
Jun 11 2018
Fix code as asked by @dvratil
Jun 10 2018
Apr 12 2018
Mar 14 2018
Thx for this change