I absolutely despise corporate speak and acronyms.
I was doing that because the autosuggest on the python interpreter didn’t handle the indentation well. See a comparison without alignment and with alignment here: > https://imgur.com/a/eNCOoaN
By the way, I think the Python console tooltips could probably be formatted in monospace so that the docstring looks better. This would have to be done somewhere in the C++ code.
And also, it should probably cut text that is too long. I have added docstrings that are pretty big, so obviously they don’t fit on screen when displayed fully. That’s not the intention of course, the idea is that a system like Doxygen or Sphinx correctly parses the docstring and produces good documentation. That we have these tooltips in the Python console is a nice convenience but we shouldn’t worry too much about them; the correct docstring in the Python code is more important.
And just a nitpick, I wouldn’t add brackets like Part::Feature to the docstrings. I would just leave it as Part::Feature. This is what I do in my docstrings. The idea is that Doxygen can identify these strings, and immediately link to the appropriate documentation where this Part::Feature class is defined.
Lets bring it down a notch, shall we? MVP isn’t just corporate speak. It’s very much used in the business/entrepreneurial/startup world to convey a specific state of a product, in this case software.
That’s the thing. Those acronyms are used as mechanisms to try to sound smarter. Why do you think they are so popular in business speak? Because the business is all hot air, and you need something to impress people by using fancy words that nobody else gets. I prefer clean, direct communication instead of turning everything into KPIs, MVPs, ADs, OMs, STASTAs, or whatever.
A note about doxygen/sphynx, I tried sphynx some time ago (everything is still there in the /Doc folder) also because I felt doxygen was too ill-suited for python docs… But quickly came to the same shortcomings: For ex. sphynx is unable to document classes spawn on the fly by C++ code, for example the Document Object. So we ended up setting up dummy objects (in Mod/TemplatePyMod), but it removed all the point of auto doc generation…
And after a while, since sphynx wasn’t able to do much more than doxygen anyway, and its main advantage was a better output/styling, but discovered you could apply css styles to the doxygen output, and therefore do quite a lot of styling there too, I saw lees the point of keeping using sphynx, and stopped caring about it
Clearly this is not the context that you’re referring to. The acronym here is being used in an informational way. Stated plainly, DavidD is saying that he will inform us when he has something that is attention-worthy. Instead of saying that whole sentence, it’s condensed. That’s fine. He’s not flexing his ego around being disrespectful fueled by some insecurity or whatever. This is a public forum and people convey themselves in different ways. Please refrain from conveying some of your beliefs and judgments i.e.
in a way that could potentially inhibit creativity and cooperation. It’s not necessary. I get it that you want clear and concise communication but it doesn’t work when others can perceive it as ‘browbeating’ it in to them.
Yes, he’s not flexing, but that’s why I hate corporate speech, people flex all the time and gatekeep by using lingo. Keep it simple! Is it too much to ask?
Which reminds me, Kunda, stop using “AKA” in the wiki, it looks horrible and unprofessional! Also, think of all those French and Italian people who don’t know every single acronym used in English. This is also why I dislike acronyms, because even if they are obvious to you, they may not be obvious to every reader; think of your readers!
I think Sphinx may have improved quite a lot since the last time you tried it, so testing Sphinx again is warranted. If it can produce better documentation than Doxygen, it would be really useful. But more than the system, I think just adding docstrings to most functions is what really matters. Those can be extracted by Doxygen, and even if they don’t look very good, it’s very useful to have that information as part of the documentation.
And about the TemplatePyMod, regardless of whether it’s repeating information, I think it’s great, because it really showcases how a DocumentObject should be defined, and the general structure of a workbench. At some point this should be documented much better in the wiki. I think writing some manual documentation is unavoidable. We can parse most things automatically by Doxygen or Sphinx, but at some point we always have to make manual additions.
Fair enough, I take your point. However, I respond better to requests than commands. Would it harm you to use ‘Please’ in your post and too be a little less forceful? There is a difference between assertiveness and overbearing.
Slower than I’d like, but it’s certainly getting faster as I understand more. I’ve got docstrings for Wall, IFC, Floor, Component, Project, and I’m currently working on Site’s interesting compass system. It’s a little vague what each of the compasses are supposed to be pointing towards so I want to be certain I understand what’s going on before I enshrine my misunderstandings in docstring form.
Unfortunately, my uni studies are picking back up earlier than expected, so I’ll have to get my IRL commitments in order before I continue. Very frustrating.
Then consider making PRs more often than just all at once.thatbway your patches won’t rot due to other commitments. Even if, as you said, encode your misunderstandings into your patches - it’s still better than not submitting any patches at all. Someone else may be available to correct some of the inconsistencies if there are any
