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

List:       quanta-devel
Subject:    Re: [quanta-devel] how to proceed with Quanta?
From:       Jens Herden <jens () kdewebdev ! org>
Date:       2005-12-11 23:51:49
Message-ID: 200512120651.55759.jens () kdewebdev ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi,


> >    1. develop on what we have now (Kuanta) and release an
> > intermediate version that runs on KDE 3.
>
> I would like to go this way. KDevelop is also planning an intermediate
> release, why not do together?

yes, we could do this together but I do not see any need to do so. Kuanta 
should work on older KDevelop versions as well, shouldn't it?


> >    2. switch to KDE 4 and try to improve KDevelop 4 and Quanta 4 as
> > quickly as possible.
>
> This is also good, but it is more risky. You need to update kdelibs
> frequently and be prepared to debug and fix bugs there as well. But it
> has the advantage that we can spend more time on the KDE4 version. And
> with a fast PC frequent updates and lots of compiling will be less of
> an issue (for me).
>
> > I am in favor of 1, I would like to see a version of Quanta with the
> > KDevelop framework for KDE 3.
>
> So let's do it as fast as we can and switch to 2.

I do not agree on "as fast as we can" because I think we should use the 
opportunity of getting feedback for Kuanta. That means we should implement 
some new code to see what is broken early enough. If we wait with the radical 
changes in the code and introduce them in Quanta 4 only we get only feedback 
about ported old code from Quanta 3 to Kuanta. 
So my suggestion is to do some of the radical changes before we release 
Kuanta. So Kuanta would be the layground for our architecture changes.


> > So the question is what would be needed for a Kuanta release? Or less
> > specific what are the current plans for the next steps?
>
> I started to fix some issue from our TODO files, but there is more to do
> with porting existing functionality. So first decide a deadline for
> release and after decide what is really needed for such a release, what
> will be included.

I would not decide a deadline, I'd rather think about what we need and 
implement this. We can release when we think it is ready.


> > I can share with you what is in my mind in the moment. I am thinking
> > about the internal structure. That means about adopting KDOM2/KHTML2
> > and a new parser. This would be a major change in the architecture of
> > Quanta and I think having this in a pre-release would alow some
> > people to test it before we push it in Quanta 4.
>
> I don't oppose to this, but you know, there are also many other things
> missing from Kuanta at this moment.

Yes I know, but these are the changes that needs to be done for Quanta 4 and 
if we do them early they can be tested more intensive.


Jens

[Attachment #5 (application/pgp-signature)]

_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel


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