Re: Flrig "Developers guide" ?
> 2b. Re: Flrig "Developers guide" ?
> Posted by: "Robert Stiles" kk5vd@... kk5vd
> Date: Thu May 7, 2015 6:03 pm ((PDT))
> Unfortunately documentation and programming are two separate full time
> jobs. Are their any volunteers? The best and mostly likely outcome is
> take the time to learn the code and while you are at it, use the
> multitude of Doxygen statements and annotate the source code.
<Snipped for brevity!>
Yes, I agree that it takes time, where I change or add things I do also leave
comments, as much for my own use as anyone elses.
Sadly like many, I rarely have "enough of the right sort of contiguious time" for
anything like that.
I'm not looking for a full line by line description by any means, just an overall
guide as to how the various parts of the program fit together, in a "what call's
what" way. In particular, how things "happen" when someone clicks on a
button. As at present, it's less than obvious.
Sadly, in the FLOS world, I have also come across the tendancy to actively strip
all comments from source code that is published! That doesn't exactly
encourage people to document their work for release.
As to Doxygen. Ugh! Had to use that at work one time while maintaining Dutch
written C++ instrument driver code (as a result, I fully appreciate the meaning
of the phrase "Double Dutch"!)
Doxygen's output may look impressive, but unless you already know how the
code works, it's next to useless for a part time coder to learn how things work
together, you're far better off aching the brain reading the raw code for that I
admit, but that as you say takes time.
I also vividly recall, though it was easy to find out what resources were used by a
particular block of code (forward viewing) but it was nigh on impossible to look
backwards, to find out what depended on a particular routine or function
(backward viewing in effect.) If that has changed for the better, please let me
know. (Off list perhaps.)
Back in my technical college days, we were taught that "the program" is in the
comments. Such that, it then allows anyone to code it (or re-code it) in the
language of choice. (K&R Ansi C back then, I still have the book of course.)
The problem with C/C++ code written/contributed by many, is there are so
many ways to do the same thing, coupled with it's all to well documented ability
to obfuscate the actual intended code function, so one spends more time reverse
engineering it, just to find out what goes on. That's not a bad thing, but it takes
a huge ammount of time.
However, Flrig etc is not that bad in that respect, it just needs an overall guide,
but that needs to be created by someone who already knows how it all works,
sadly, that's not me.
Yes, I have also in the past (on the machine that the drive died on) done a full
install of the relevant FLTK suite, and tried some of the demo's etc. OK, some
work, many don't (not updated as FLTK as evolved I think.) Plus, the docs are
also not up to date either. (An all too common "feature" in the FLOS world I
Remember the old addage. "The jobs not complete untill the paperwork is
done." Speaking of paperwork, I have lots to do, that results in me getting
Flrig coding etc, currently is only an hour or so a day, and for the next week and
a bit, it will be 0 hours a day due to traveling to the US for work. Hopefully I'll
get to Dayton this year...
Posted by: "Dave B" <g8kbvdave@...>