Hi all,
On 2010-12-02 at 21:59 +0100, Thorsten Behrens wrote:
So just in case, let's agree to disagree keep the patches coming!
:)
As a conclusion, what about to combine Miklos' check for the missing
documentation with a commit hook, so that it does not allow you to
commit _new_ files
Jan Holesovsky wrote:
As a conclusion, what about to combine Miklos' check for the missing
documentation with a commit hook, so that it does not allow you to
commit _new_ files without (at least the high level) documentation? ;-)
Hi Kendy,
I find it surprising me actually saying this, but -
On Fri, Dec 03, 2010 at 11:14:54AM +0100, Thorsten Behrens
t...@documentfoundation.org wrote:
I find it surprising me actually saying this, but - for the while, I
think this would be crossing the line of solving a social problem
by technical means. ;)
Additionally I'm not aware of a method to
On 03/12/10 12:11, Miklos Vajna wrote:
On Fri, Dec 03, 2010 at 11:14:54AM +0100, Thorsten Behrens
t...@documentfoundation.org wrote:
I find it surprising me actually saying this, but - for the while, I
think this would be crossing the line of solving a social problem
by technical means. ;)
Hi Miklos, Thorsten,
On 2010-12-03 at 13:11 +0100, Miklos Vajna wrote:
I find it surprising me actually saying this, but - for the while, I
think this would be crossing the line of solving a social problem
by technical means. ;)
Additionally I'm not aware of a method to tell doxygen to
On Fri, Dec 03, 2010 at 03:04:55PM +0100, Jan Holesovsky ke...@suse.cz wrote:
That's why I highlighted that this would be done only with _new_ files,
ie. the files that have have been git add'ed, and did not exist in the
repository before. And we can further limit that only to .hxx/.h.
Ah,
Hi Miklos,
On 2010-12-03 at 16:19 +0100, Miklos Vajna wrote:
That's why I highlighted that this would be done only with _new_ files,
ie. the files that have have been git add'ed, and did not exist in the
repository before. And we can further limit that only to .hxx/.h.
Ah, that makes a
On Fri, 2010-12-03 at 10:23 +0100, Jan Holesovsky wrote:
Hi all,
On 2010-12-02 at 21:59 +0100, Thorsten Behrens wrote:
So just in case, let's agree to disagree keep the patches coming!
:)
As a conclusion, what about to combine Miklos' check for the missing
documentation with a
On Fri, 2010-12-03 at 11:08 -0500, Kohei Yoshida wrote:
On Fri, 2010-12-03 at 10:23 +0100, Jan Holesovsky wrote:
Hi all,
On 2010-12-02 at 21:59 +0100, Thorsten Behrens wrote:
So just in case, let's agree to disagree keep the patches coming!
:)
As a conclusion, what about to
On Fri, Dec 03, 2010 at 11:14:12AM -0500, Kohei Yoshida kyosh...@novell.com
wrote:
My rationale: Many times when I work on feature branches, I commit stuff
but intentionally not provide documentation because the role of the
class/method/whatever may change during the course of the
Jan Holesovsky wrote:
As to the crossing the line - the first time it won't let you commit,
and you'll be angry, the second time it won't let you commit, and you'll
just fix that, and the third time you'll comment just naturally, and
won't even hit the check :-) This worked with the warnings
Hi Lubos,
you wrote:
I'm not asking for anything ridiculous like having a paragraph
explaining every line, I'm saying that everything non-trivial
should have at least some documentation
Good, then we're mostly on the same page. Then we're both talking
about mission statements, higher-level
On Tue, 30 Nov 2010 18:50:17 +0100, Lubos Lunak l.lu...@suse.cz wrote:
On Tuesday 30 of November 2010, Thorsten Behrens wrote:
Additionally, I think most classes don't necessarily need detailed
docs for all methods in the first place (which may also hurt later
merging from OOo), but would
After having years of experience using a nice, intuitive
and well-documented APIs (Qt,KDE),
But surely you should realize the causality here? It is exactly your years of
experience with them that makes Qt and KDE seem nice and intuitive.
It is extremely hard, probably impossible, to come up
Sebastian Spaeth wrote:
What does bFull mean? Not so quick? What portions will be formatted if
this is FALSE? Looking at the function it either calls
pImpEditEngine-FormatFullDoc();
or
pImpEditEngine-FormatDoc();
What the heck is the difference between those functions? Now I have to
On Wednesday 01 of December 2010, Tor Lillqvist wrote:
After having years of experience using a nice, intuitive
and well-documented APIs (Qt,KDE),
But surely you should realize the causality here? It is exactly your years
of experience with them that makes Qt and KDE seem nice and
On Tuesday 30 of November 2010, Thorsten Behrens wrote:
Hi Lubos,
adding documentation for what you describe doesn't help much, if at
all. Core API is reasonably documented, see offapi/udkapi/sal/basegfx.
What is core API then? Do things under e.g. libs-core count as well? If yes,
then just
On Wednesday 01 of December 2010, Thorsten Behrens wrote:
see? That's what I meant, documentation for most of the higher-level
methods is either
a) superficial
b) so much prose that you're better off debugging the code in the
first place
(bFull has *a lot* of side effects, and no, I did
Personally I think it would be very nice if source files had just a few
lines of comment telling what they are about, from a very high perspective.
Every time I am searching for the implementation of some functionality in
the OOo/LO codebase, I find myself looking at source files with vaguely
Beware - I am a newcomer - maybe my point of view is quite wrong due to
lack of understanding. But then at least I will understand something
better :- )
My first remark: stepping in seems to me to be very difficult despite
the very friendly behaviour of people here.
un-documented code-base is
Why not drop merging from OOO after LibO 3.3?
Because there is still a significant number of people working on OOo, and they
are in many cases the best experts there are on the code they are working on,
and they are doing significant and useful improvements? Because there is no
licensing
Miklos Vajna wrote:
Does the idea sounds sane, OK to push?
Totally! Would you maybe also be interested to work on an improved
start page / index, e.g. like this here:
http://www.informatik.uni-hamburg.de/~meine/hg/vigra/file/bf402d01f821/docsrc/index.dxx
(see
On Tue, Nov 30, 2010 at 04:21:08PM +0100, Thorsten Behrens
t...@documentfoundation.org wrote:
Miklos Vajna wrote:
Does the idea sounds sane, OK to push?
Totally!
OK, pushed.
Would you maybe also be interested to work on an improved
start page / index, e.g. like this here:
Lubos Lunak wrote:
On Tuesday 30 of November 2010, Thorsten Behrens wrote:
Additionally, I think most classes don't necessarily need detailed
docs for all methods in the first place (which may also hurt later
merging from OOo), but would already benefit from a two-line
mission statement
24 matches
Mail list logo
