From koffice-devel Thu Sep 23 21:35:04 2010 From: "Carlos Licea" Date: Thu, 23 Sep 2010 21:35:04 +0000 To: koffice-devel Subject: Re: Review Request: Layout, first paragraph bottom position fix Message-Id: <20100923213504.19708.19213 () vidsolbach ! de> X-MARC-Message: https://marc.info/?l=koffice-devel&m=128527774323447 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1030327527==" --===============1030327527== Content-Type: multipart/alternative; boundary="===============7907008327078239400==" --===============7907008327078239400== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > On 2010-09-10 15:41:36, Thomas Zander wrote: > > Please provide a unit test to show the problem. > = > Thomas Zander wrote: > Thanks for explaining how to load a document and see it fail; this is= black box testing and useless for regression testing or showing the actual= bug in the code. Please provide a unit test to show the problem. > = > Pavol Korinek wrote: > To simulate this problem I had to combine tests for application (KWTe= xtDocumentLayout) and pluggin (Layout.cpp) which means don't write test for= some unit or function, but test for whole layout. It's not possible to mix= them also, because they are invisible one to each other. Also to create Mo= ck object of KWTextDocumentLayout or Layout.cpp for this test is not possib= le, because part of functionality which I need is connected to so many othe= r fuctionallity, that it's not possible to cut some. At least if I was succ= essfull with this test, and had sucessfull simulation, than run of such tes= t, was like run application with test data and check output. I suggest more= people to check KWTextDocumentLayout logic and check if firstParagraph boo= lean value, should be set to true, when new shape comes into play. > = > Thomas Zander wrote: > The Layout plugin and the KWTextDocumentLayout are indeed two separat= e units, and should be tested separately. This is possibly by defining the= interactions between the two and figuring out what you expect to happen wh= ich doesn't happen right now. > After defining the interaction and deciding which of the two sides is= buggy (either the provider of the API or the user of the API) you write a = unit test based on that conclusion; you either write a test that tests the = provider of the API or you write a test testing the consumer of the API. > = > In your explanation it seems you don't have a clear picture yet of th= e contract of the APIs since you say you need both at the same time. That m= ay be a good place to start. > = > Also, I think there are various partners listed on the Qt website tha= t provide training for writing unit tests, if you and your company lacks th= at knowledge please consider contacting them. I'm have to be honest in that= I don't really have the time to explain those concepts in my spare time, f= or free, to a for-pay subcontractor. > = > Carlos Licea wrote: > Thomas, please, please, behave as good as you can. If you lack the te= mper please consider contacting a counselor; I, as a paid consultant, can't= go consulting emotions, while I'm at my work, for free. > = > Your reviews, not matter how good or right they are, lose much streng= th when you act in this way. We all can be rude, let's try not to. > = > Thomas Zander wrote: > Hey Carlos, > = > the story is easier than assuming I'm unstable and not making sense; = there is a perfectly logical reason for the sentence I wrote. > The facts are that Matus doesn't have the experience in writing unit = tests that show the bug is actually where he thinks it is and I'm getting e= mails from his customer that I should teach him this to be able to work on = KOffice. > = > I'm just being very clear I have no intention of teaching Matus how t= o write unit tests for the simple reason he is a consultant that is hired f= or his expertise and I'm a volunteer programmer working on KWord for fun. > = > Compare this to someone trying to fix your car and you having to teac= h him how to do his job. I bet you would not put in your time to do that ei= ther. > = > As a smart man wrote; "focus is deciding what not to do". And I want = to focus on the fun things and get KWord better prepared for the next 10 ye= ars of its lifetime :) I do understand your reasoning and I do agree that a test is, probably, the= best thing to do, so that the expected behavior gets documented. My point = is not that you're "unstable," but that we don't need to be rude in order t= o archive great software. - Carlos ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5305/#review7526 ----------------------------------------------------------- On 2010-09-13 07:19:03, Pavol Korinek wrote: > = > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/5305/ > ----------------------------------------------------------- > = > (Updated 2010-09-13 07:19:03) > = > = > Review request for KOffice. > = > = > Summary > ------- > = > We use shape (m_state->shape) height to set 'end bottom position' when fi= rst paragraph occurs. When m_state->shape is new one, then we should set ne= w 'end bottom position'. It can be done by set firstParagraph to true on ne= w shape. This was investigated to solve: https://bugs.kde.org/show_bug.cgi?= id=3D239703 > = > = > Diffs > ----- > = > /trunk/koffice/kword/part/frames/KWTextDocumentLayout.cpp 1172979 = > = > Diff: http://svn.reviewboard.kde.org/r/5305/diff > = > = > Testing > ------- > = > = > Thanks, > = > Pavol > = > --===============7907008327078239400== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
This is an automatically generated e-mail. To reply, visit: http://svn.reviewb= oard.kde.org/r/5305/

On September 10th, 2010, 3:41 p.m., Thomas = Zander wrote:

Please pr=
ovide a unit test to show the problem.

On September 13th, 2010, 8:44 a.m., Thomas Zander wrote:

Thanks fo=
r explaining how to load a document and see it fail; this is black box test=
ing and useless for regression testing or showing the actual bug in the cod=
e. Please provide a unit test to show the problem.

On September 17th, 2010, 1:42 p.m., Pavol Korinek wrote:

To simula=
te this problem I had to combine tests for application (KWTextDocumentLayou=
t) and pluggin (Layout.cpp) which means don't write test for some unit =
or function, but test for whole layout. It's not possible to mix them a=
lso, because they are invisible one to each other. Also to create Mock obje=
ct of KWTextDocumentLayout or Layout.cpp for this test is not possible, bec=
ause part of functionality which I need is connected to so many other fucti=
onallity, that it's not possible to cut some. At least if I was success=
full with this test, and had sucessfull simulation, than run of such test, =
was like run application with test data and check output. I suggest more pe=
ople to check KWTextDocumentLayout logic and check if firstParagraph boolea=
n value, should be set to true, when new shape comes into play.

On September 21st, 2010, 3:38 p.m., Thomas Zander wrote:

The Layou=
t plugin and the KWTextDocumentLayout are indeed two separate units, and sh=
ould be tested separately.  This is possibly by defining the interactions b=
etween the two and figuring out what you expect to happen which doesn't=
 happen right now.
After defining the interaction and deciding which of the two sides is buggy=
 (either the provider of the API or the user of the API) you write a unit t=
est based on that conclusion; you either write a test that tests the provid=
er of the API or you write a test testing the consumer of the API.

In your explanation it seems you don't have a clear picture yet of the =
contract of the APIs since you say you need both at the same time. That may=
 be a good place to start.

Also, I think there are various partners listed on the Qt website that prov=
ide training for writing unit tests, if you and your company lacks that kno=
wledge please consider contacting them. I'm have to be honest in that I=
 don't really have the time to explain those concepts in my spare time,=
 for free, to a for-pay subcontractor.

On September 23rd, 2010, 5:42 a.m., Carlos Licea wrote:

Thomas, p=
lease, please, behave as good as you can. If you lack the temper please con=
sider contacting a counselor; I, as a paid consultant, can't go consult=
ing emotions, while I'm at my work, for free.

Your reviews, not matter how good or right they are, lose much strength whe=
n you act in this way. We all can be rude, let's try not to.

On September 23rd, 2010, 8:44 a.m., Thomas Zander wrote:

Hey Carlo=
s,

the story is easier than assuming I'm unstable and not making sense; th=
ere is a perfectly logical reason for the sentence I wrote.
The facts are that Matus doesn't have the experience in writing unit te=
sts that show the bug is actually where he thinks it is and I'm getting=
 emails from his customer that I should teach him this to be able to work o=
n KOffice.

I'm just being very clear I have no intention of teaching Matus how to =
write unit tests for the simple reason he is a consultant that is hired for=
 his expertise and I'm a volunteer programmer working on KWord for fun.

Compare this to someone trying to fix your car and you having to teach him =
how to do his job. I bet you would not put in your time to do that either.

As a smart man wrote; "focus is deciding what not to do". And I w=
ant to focus on the fun things and get KWord better prepared for the next 1=
0 years of its lifetime :)
I do unders=
tand your reasoning and I do agree that a test is, probably, the best thing=
 to do, so that the expected behavior gets documented. My point is not that=
 you're "unstable," but that we don't need to be rude in =
order to archive great software.

- Carlos


On September 13th, 2010, 7:19 a.m., Pavol Korinek wrote:

Review request for KOffice.
By Pavol Korinek.

Updated 2010-09-13 07:19:03

Descripti= on 

We use shape (m_state->shape) height to set 'end bott=
om position' when first paragraph occurs. When m_state->shape is new=
 one, then we should set new 'end bottom position'. It can be done =
by set firstParagraph to true on new shape. This was investigated to solve:=
 https://bugs.kde.org/show_bug.cgi?id=3D239703

Diffs=

  • /trunk/koffice/kword/part/frames/KWTextDocumentLayout.cpp (1172979)

View Diff
--===============7907008327078239400==-- --===============1030327527== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ koffice-devel mailing list koffice-devel@kde.org https://mail.kde.org/mailman/listinfo/koffice-devel --===============1030327527==--