I've used #file and #brief to give my files happy little brief descriptions in Doxygen, as below:
Now, I would like my directories, such as common, shown in the image, to also have happy little brief descriptions. How can I achieve this?
Related
Many people document applications in the source files themselves, e.g. https://github.com/docopt/docopt.cpp . In the spirit of DRY (don't repeat yourself), I would like source documentation to appear in my README.md on GitHub (auto-generated from the source.) I see many user-community questions about including README.md in output documentation, but nothing about going the other way, src documentation -> README.md. doxygen seems like the tool that should own this space, but has no output formatters for markdown files.
Does it make sense to anybody else to create an output formatter for markdown?
Apparently it does make sense, and has been proposed before, as well as some bolt-on solutions developed: https://github.com/doxygen/doxygen/issues/6760
I'm about to submit this project but I want to make sure the Github page looks good before I do. For some reason, not all the languages are showing up and I don't know why. I've tried to find ways to edit this under settings but I've yet to find anything.
As you see in the images below, on the homepage it says the Repo is 100% Jupyter notebooks, but if you click on "languages" you'll see that there are python and csv files as well that seem to be unaccounted for.
If anyone knows how I can change this please let me know. It's not very important but I think it'd look much nicer if the breakdown of languages was more accurate. Thank you!
GitHub uses Linguist to figure out which languages are part of your project. It has a languages.yml file to defined the multitude of languages to look for. Some are markup languages (like jupyter notebook), some programming languages, etc.
That percentage you see is calculated based on the bytes of code for each language. The more you have of one type, the higher the percentage.
Note, however, that this library excludes all files that it determines to be binary data, vendor code, generated code, documentation, or defined as data (in your case csv) or prose (think markdown), whilst taking into account any overrides.
IF your python code is small enough, even in 2 files, it won't get show up. Just write more python if you want it to show up.
The second screenshot provided is when you click on the languages and it's purpose is exactly what you are looking for - to give better details on the current project and what it comprises of in detail. This language bar is just an overview. It need not be 100% accurate.
FIY - It also matters which is your main branch, since it takes that into account.
Conclusion - don't worry about it. Whoever needs to see it, will see what your project has in terms of contents.
I have not used either of them till yet. I looked at their websites and found their brief descriptions:
Github Gist:
Instantly share code, notes, and snippets.
Pastebin:
Pastebin is a website where you can store any text online for easy sharing. The website is mainly used by programmers to store pieces of sources code or configuration information, but anyone is more than welcome to paste any type of text. The idea behind the site is to make it more convenient for people to share large amounts of text online.
Apart from the explicit mentioning of "anyone is welcome to paste any type of text" in Pastebin's description, I see no difference in what they are used for.
I'd appreciate if someone could point me the differences between them.
Gists are way more 'advanced', since Pastebin is very simple and user-friendly.
At very least, gists are used to be shared mostly with coworkers, while pastebin is heavily being used for wide-usage or for private usage.
https://help.github.com/articles/forking-and-cloning-gists/
I am trying to link two doxygen html documentations. To this end, I generated the first documentation for package A using GENERATE_TAGFILE, then I set in the Doxyfile of package B TAGFILES = "pathtotagfile = relpathtodocumentation". This seems to work properly, since there are no warnings. However, I the connection of the two packages is not as deep as I would like it to be.
Using doxygen 1.8.13, I only see links to the external files. Can I configure that classes and namespaces also list external stuff? I have set ALLEXTERNALS, EXTERNAL_GROUPS and EXTERNAL_PAGES to YES, but still I only see external files.
Using doxygen 1.8.4, external packages appear under Related Pages, but this seems to have been changed. I would have appreciated this. Can I reenable it in the latest version?
I also welcome hints at how Link to external documentation works. The doxygen help is a bit short here.
I am porting doxygen documentation from visual studio c# project to java eclipse project.
Can you please suggest tutorials or some guides for mapping the one style of comments
to the other?
For example, how do I translate this doxygen comment to javadoc comment?
/// the custom solution data type, derived from Solution
Thanks
Speaking from the perspective of one who has tried to map from doxygen (in C) to javadoc I think you will find this direction remarkably difficult, especially if you have much narrative in your original commentary. I find javadoc dreadfully lacking in most of the capabilities of doxygen, so really only the absolute minimum commentary can be usefully transferred - things like #param, #return etc. I've never found any good tutorials, or even any bad ones. I suspect this isn't something people do by choice.
Consider whether you could continue to use doxygen. Doxygen interprets all the javadoc commands (at least all the ones I've come across), and you can benignly add doxygen '\'-style commands into the java commentary without upsetting any existing javadoc processing.
Edit: Just to clarify that point slightly. Javadoc won't have warnings or errors as a result of using \command entries, but the \command text will emerge in the javadoc output as text.
The downside, of course, is that javadoc is needed if you want pop-ups in your IDE (e.g. Eclipse) so if that's a requirement then using doxygen instead won't be much use. However, if you just need to create good quality HTML documentation / manuals with diagrams and narrative then it might be an option.