Alright! Ship it

Don't use file as a variable name as it's a python keyword.

In D28811#649209, @ognarb wrote:

I now generate the CSS from aether-sass. The code can be found https://invent.kde.org/websites/aether-sass/-/blob/master/css/aether-sidebar.scss. And all tree wikis are using it.

@ochurlaud should I create a sysadmin request for you to get access to the repo in invent so that you can edit it if you need?

OK it's clearer:

Except these clarifications, I'm not against this change

I really dislike how you close brackets in css : it's more dense and harder to read.

OK for me

In D28712#645095, @ognarb wrote:

Not tested yet but I like the style :) Though to be more consistent with the style used in other KDE websites, I would change the background color to #fff and use #f8f9fa for the sidebar.

I also saw some alignment issues with the method args:

I will give a more in-depth review tomorrow.

Nice work. This is a ship it for me!

One minor correction then you can ship it

If we want to generate the doc of the libs one by one, it means that we need to have the order of generation.

In T12004#212701, @bcooksley wrote:

Unfortunately we can't reuse the metadata that the CI system and kdesrc-build use, as some Frameworks have two libraries in them - with one often not having the GUI components in it (and thus having a much smaller dependency graph). We also don't record any information about anything external to KDE (like Qt).

Another idea about the issue raised for "tweaking the csss/html" :

Very interesting ideas!

If it still works it's OK to push.

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

In T12004#207786, @bcooksley wrote:

Frameworks would be listed on the main index page, as it is our principal product and what the vast majority of visitors to api.kde.org will be interested in.

As for PIM, it would be listed in amongst all the other projects that decided to have API Documentation generated for them.

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.

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.

In D24568#546289, @kossebau wrote:

There is also https://techbase.kde.org/Policies/Frameworks_Coding_Style which though missed the move from techbase to community, other than the other policies.

I suspect that page should be moved over now as well, to become the real KF coding style page (so that "kdelibs" named one is no longer needed).

@nalvarez @ochurlaud Do you remember why this page was not moved?

Nice! Thx Harald!

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.

Great work. It looks very pro and classy.

The root cause is that we build twice the same elements instead of having one share lib used on the two contexts.

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?

OK fine, ship it

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.

D16013 implemented the same idea in a better way

... I'm specifically write about the month view, but it holds also for the other views

In D6368#344479, @ngraham wrote:

I'm not on board with making the roundrects into flat squares. A little bit of corner rounding is a nice touch. If we remove all visual ornamentation, we make our design look cold, barren, and amateurish IMHO.

Solved BY T9459

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.

In D14955#312279, @aacid wrote:

-1

The example is not getting compiled it will rot

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....

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.

For memo, an extract of the email I wrote:

@dvratil: can you add this to the next bugfix patch ?

Fix code as asked by @dvratil

Thx for this change