Just to clearfy... (again) i was asking Pritpal's for some
doccumentation or a more easy to track code.
El 20/05/2010 12:32 p.m., Richard Acosta escribió:
I can't find feet and head watching the whole code at the same place,
it is hard for me to track it down as i could find talking to other
people, is still too hard for many.
This time, as a suggestion. Pritpal, when you could make some time
for it, please, write a manual, a reference guide or something
alike. Your tool as i've seen is a very powerfull one, but too
hard to track the code.
I'm still stuck on procedural programming, so it's harder to me to
track OOp.
At this moment i'm printing demowvg.prg and start cutting it to see if
i can track things better, but i guess is not the ideal approach to
have a wall with paper pieces only to try to follow some code.
I have the best intentions, if i could make anything to help, i would.
Best regards.
El 27/05/2010 08:15 p.m., do...@people.net.au escribió:
Hi all
There has been a lot of discussion about Harbour documentation (or the
lack of it) of late.
Realistically it must be holding people back from using what is a
wonderful product. And many users would be more productive with better
documentation.
It is also quite understandable because:
1. The developers of the product are very busy continuing to develop
Harbour for all of us
2. They are probably not the ideal people to write polished documentation
although anyone who sets out to write such documentation would presumably
want their input
3. Documentation should ideally cover
--- multiple supported operating systems
--- multiple gui and character front ends
--- multiple data and index formats and access methods
because most users will want to use a gui front end and a data base back
end. Covering all that would be a nightmare for an individual as there
are so many options.
If we consider the Harbour "core" then the problem is much smaller (but
will still leave the average new adopter confused about gui front end and
data back end). We have
1. Clipper documentation (of various sorts). This is helpful but
doesn't cover the myriad of Harbour extensions.
2. xHarbour documentation (on line and commercial). This is probably
more helpful but remains confusing as there are significant differences
between the two dialects and was very much developed for Windows users
although xHarbour came in a Linux version.
3. Pritpal's hbide (not yet really a newbie option , certainly at this
stage?) and a windows only program
4. The existing Harbour documentation and changelog etc. This is useful
but incomplete and awkward to find information assuming it is covered.
Part of the problem is that users want to access the documentation in
different ways on different platforms.
As I see it we need three things.
Firstly we need to agree on a base format for the documentation
content. This should directly or indirectly support multiple front ends
so that users can ultimately print documentation out or access it
electronically as suits them which could be on line or offline. We
should be able to write a program to convert existing content to that
format. It should also be extensible to cover areas such as
contributions, utilities etc and make organising and finding information
easy.
Secondly we need people to write the content. One of the biggest issues
there is that, as far as I can see, the first issue hasn't really been
resolved. Writing documentation isn't easy and takes a lot of time.
Potential writers want to do the job once and see their work used or there
is no motivation at all.
Thirdly we need people to write front ends / converters as required so
that the documentation can be accessed in the ways users want on their
platform of choice. I note that hbide will be a great tool for many, but
adequate alternative tools (not so Harbour oriented) do exist. I would
rate improved documentation as a much higher priority.
Addressing the first issue I believe we should consider a format that
Harbour supports "out of the box". XML would seem to be ideal choice and
very flexible. Alternately .dbf files with .dbts.
I would certainly consider contributing to a documentation project but it
would need to have a clear mission and format behind it.
Regards
xProgrammer
_______________________________________________
Harbour-users mailing list (attachment size limit: 40KB)
Harbour-users@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour-users
_______________________________________________
Harbour-users mailing list (attachment size limit: 40KB)
Harbour-users@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour-users