[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Formula Shape - Inferred rows
From:       Alfredo Beaumont <alfredo.beaumont () gmail ! com>
Date:       2007-07-14 17:07:12
Message-ID: 200707141907.13317.alfredo.beaumont () gmail ! com
[Download RAW message or body]

La, 2007eko Uztren 14a(e)an, Martin Pfeiffer(e)k idatzi zuen:
> So first let's cool down, and be rational.
>
> > WTF? You end up discussion by removing InferredRowElement inheritance ?
> > You still fail to see that your code is *broken* ?
>
> I did not end up the discussion, I just wanted to give you an idea of how
> it works without InferredRowElement as you did not seem to read my diff
> carefully.
> I am tired of explaining you the meaning of the paragraph in the spec so
> please give me an example or better write a test that does not work with
> the current row inheritance, this would be productive.

<mstyle>
 <mrow>
  <mi>x</mi>
 </mrow>
</mstyle>

> > > > To be fair, I don't really understand why we are investing time in
> > > > such discussions about rewritting code that already works, for little
> > > > or no
> >
> > gain, when we are so delayed in our release schedule. Thus, I would like
> > to
> >
> > > end this discussion. If you are really convinced it's going to be a
> > > simpler and easier to understand and maintain, and you are going to
> > > write all of it, just do it and commit.
> > > Ok I will write it.
> >
> > I meant write *all* of it and *then* commit it, not the other way around.
> > You again reverted my changes without providing any solution and without
> > even fixing the segmentation faults I told you your code cause. We are
> > again at the beginning.
>
> Alfreado, fixing seg faults and so is nothing that brings us further in the
> development acutally we need to implement the element classes to support
> stuff and we need provide a GUI this is what I did partially ( see
> RootElement, FormulaToolOptions... ) the other stuff is nothing that really
> brings us further it is more a design thing that need to be solved.
> I commited the stuff in single commits so that they can be reverted, man it
> is not that much work to change it again, and if you don't want to do it I
> will do it if it is proven that something does not work.

I have reverted it a pair of times already, because it has not been proven to 
work. The real problem I see is that currently KFormula is full of unfinished 
or broken code and I am unable to avoid this to increase. I cannot see a 
clear line of work I can feel confortable with. I think you have a much 
better idea of the design of the app and where it's going and I think you 
should take over KFormula's maintainership.

Cheers
-- 
Alfredo Beaumont Sainz
http://www.alfredobeaumont.org/blog.cgi
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]