Thu, Jan 23
Wed, Jan 22
The changes suggested by Yuri Chornoivan were made.
This can be solved much more easily without breaking translations by adding entities into index.docbook header (~line 27):
Tue, Jan 21
Sun, Jan 19
Sat, Jan 18
Fri, Jan 17
Thu, Jan 16
No one any opinion? Guess most people have not run into the need to do pre-processor switches for the doc generation, and also never seen DOXYGEN_SHOULD_SKIP_THIS before.
Wed, Jan 15
The base of the idea is good, although after applying changes... Krusader users are not able to keep using the handy Ctrl+↑ and Ctrl+↓ to move focus even if they redefine the Move Focus Up and Move Focus Down keys :-?
- Fix wording
Thanks for fixing this minor typo.
Last night's run of api.kde.org generation with kapidox locally patched with this change worked again,
So unless there are objections will push then latest next WE, though happy to have people give green light before :)
Tue, Jan 14
fix comment locale -> filesystem encoding
D22836 was tried before to fix this, but later it was found this still did not work on api.kde.org. At that time I had added some local patches on api.kde.org itself, but not getting further at one point forgot about things sadly.
Brown paper bag for me: if one changes code, they should also see to trigger
that code, in this case passing the --depdiagram-dot-dir arg to
For now, given @bcooksley's comment going to try some simple change to 'from kapidox.depdiagram import gvutils', this is a pattern found elsewhere in the old code. Will do a local patch to the checkout on the server and see if this has any effect on next cron job run. So far that also worked for all the 3 situations I tested (local python3 & python2, python2 on server test env).
To add to my confusion, running the unpatched version works with my local 2.7.17 python interpreter (checked with print (sys.version)) and worse, running things manually on api.kde.org in some test subdir also works with its 2.7.15...
Because the very user api.kde.org right now in production still uses python2 sadly. And replacing that server with something modern is sadly not a few-hours job, still waiting for someone to spend the weeks on getting a substitution done.
Why should Python 2 continue to be supported, after its EOL on 2020-01-01?
D26652 now up as proposal to fix this
No python developer myself, but from patterns seen I guess the imports should have some
if sys.version_info.major < 3: // python2 import style else: // python3 import style
Hi. Sadly api.kde.org failed to pick this change up until yesterday, as I had forgotten a change in the local checkout on my last work on the server, which then blocked the update via scripted git pull.
That I fixed partially yesterday, making sure latest KApiDox is run on api.kde.org, but that showed that gentoo(?) server running api.kde.org does not like yet this new code:
Traceback (most recent call last): File "/home/api/kapidox/src/kapidox_generate", line 110, in <module> main() File "/home/api/kapidox/src/kapidox_generate", line 106, in main copyright=kde_copyright) File "/home/api/kapidox/src/kapidox/hlfunctions.py", line 108, in do_it dot_files, tmp_dir) File "/home/api/kapidox/src/kapidox/generator.py", line 646, in generate_diagram with_qt=with_qt) File "/home/api/kapidox/src/kapidox/depdiagram/generate.py", line 156, in generate db.populate(dot_files, with_qt=with_qt) File "/home/api/kapidox/src/kapidox/depdiagram/frameworkdb.py", line 175, in populate fw = parser.parse(tier, dot_file) File "/home/api/kapidox/src/kapidox/depdiagram/frameworkdb.py", line 115, in parse dot_data = preprocess(dot_file) File "/home/api/kapidox/src/kapidox/depdiagram/frameworkdb.py", line 75, in preprocess for node_handle in gvutils.get_node_list(graph_handle): NameError: global name 'gvutils' is not defined
Sun, Jan 12
Some similar macro definitions used by other projects, as I found by doing some random grepping over my system includes:
- Q_QDOC & Q_CLANG_QDOC
- BOOST_DOXYGEN_INVOKED & lots of similar
Sat, Jan 11
Thanks for the review :)
Accepted if you amend the commit message; the full log from the build generation is probably overkill.
Thu, Jan 9
Should be fixed in stable for now.
Very few people know about this problem (es, nl, pt, pt_BR). And even some those who do know just forgot to update the docbook (de, uk). Some docbooks cannot be updated because the translations are now incomplete (et, fr, ru). Thus there should be some coordinated effort to fix this from the translator side.
I guess the translators need to re-generate them
The localized man pages are still broken in 19.12.1 - what does it need to happen for them to pick up the change?