[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-18 15:50:01
Message-ID: 200707181750.02551.alfredo.beaumont () gmail ! com
[Download RAW message or body]

La, 2007eko Uztren 14a(e)an, Alfredo Beaumont(e)k idatzi zuen:
> 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.

Any news on this ?
-- 
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]