Improve structure and visual identity in Doxygen comments in- and out -of code. Without structure ... entropy. #73140
Labels
No Label
Meta
Good First Issue
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Eevee & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds, Tests & Devices
Module
Python API
Module
Rendering & Cycles
Module
Sculpt, Paint & Texture
Module
User Interface
Module
VFX & Video
Priority
High
Priority
Low
Priority
Normal
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Information from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender-manual#73140
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Building the Doxygen material today and attempting to use it for whatever purpose is not completely working.
The structure is collapsed to long lists of pages and modules not easily readable. The reason is how doxygen tags are used.
It is an essential value that goes missing, since there are a lot of good information there but it is not easy to navigate.
I propose to:
The result is a structure that explains itself and therefore, with a little review-help, continuously improves instead of decays.
I have started but not contributed yet, please promote this task!
Added subscriber: @JonasPrintzen
Added subscriber: @grosgood
@JonasPrintzen
Welcome to the project. I trust you have gone through the Build Blender exercise, have issued ##make doc_doxy## and have been disenchanted with the result. In my opinion, this is a consequence of:
As to the first point, I think this task is more at the design - todo level, meaning it is of the more ambitious sort. [Cambell's suggestions ]] about keeping your first efforts focused on a individually manageable effort is key: one or two pilot templates to illustrate Doxygen's potential to the community at large may be a more realistic scoping for this task. My second point is in play, because this community already has a way to deliver code documentation to the project through [ https:*devtalk.blender.org/t/feature-patch-description-requirements/10775/21|diff patches , which translate to commit messages and become metadata in the code repository - documentation about code, and automagically linked to the code in the repository. "And now you want us to write templates too??". may very well be the protest here. To that extent, the very idea of including templated code documentation would have to be argued here. That is beyond the scope of this task, but I think it is the 800 lb. gorilla currently sitting in the room.
However you scope this task, I hope you stay at it in some form or another. Literate programmers are few and far in between. Every project could use a couple.
Added subscribers: @jesterking, @dfelinto, @ideasman42
I am thinking about a small scope adjustment or clarification based on diverse input.
My goal should be to figure out how to make it so compelling to use that it makes more sense
to put your thoughts about API and structure in the Doxygen form than another. I will provide
examples of the 5 archetypes I have in mind by documenting what I can and ask for feedback.
With a little effort there will be examples easy enough to follow ...
Planning to submit a patch with the first structure and visual setup within a day or two.
Added subscriber: @Blendify
That sounds great I am excited to see what will come of this. I think if you help provide a good structure and good examples. Other developers will be more likely to use doxygen and we can "inforce" to patches to properly document code.
Ready with a first patch to get visuals and some structure in place.
I have been reading about submitting patches and tried the page https://developer.blender.org/differential/diff/create/ but I can't answer all questions needed to get through the process.
EDITED: Now I think I managed to create a diff, D6625.
@Blendify, @grosgood
My patch touches only ./doc/doxygen and comments in three other headers for examples.
Cheers!
Patch D6625 created.
Question:
I am trying to bind the patch D6625 to this issue. I can't find it.
Hint's anone?
@JonasPrintzen
Forgive me. I am being dense over your terminology. I don't understand "bind the patch to this issue."
By "bind" do you mean "cross reference"? Perhaps it wasn't clear when you were in the midst of writing your last comment, but cross-references to the differential and this task were automatically created. Notations like ##Tnnnnn## and ##Dnnnn## are translated into HTML links to the target items. The 'book' icon in the banner of the text editor box, second from the right, places The Remarkup Reference Guide in another browser window. Then you can do all kinds of tricks in comments.
I can't fathom what you might mean otherwise.
I note you made me a reviewer to the D6625. I would recommend @ideasman42 instead. Target file [Doxyfile ]] has been recently touched by a number of his commits, which makes him an 'interested party.' In contrast, I do not have a great deal of practical experience with Doxygen. Familiarize yourself with the source listings in [ https:*developer.blender.org/diffusion/|Diffusion if you haven't already done so. That place maps lines of code to the changing commits - and, by extension, who did the commits. If you are not sure who to invite for a review on a Differential, Diffusion will give you hints by telling you whose recent commits have changed the file. Ditto ##git blame## and ##git log -L ...##.
Good work. Looking forward to what develops here.
Hi @JonasPrintzen, thanks for submitting the patch the way you did it correctly. I bound the differential to the task for you. You can do this from the revision:
Edit Related Objects --> Edit Tasks...
Changed status from 'Needs Triage' to: 'Confirmed'
My absence is forced.
Will return and simplify according to feedback.
Removed Python project since it's not closely related.
Added subscriber: @maryrobinson
This comment was removed by @maryrobinson