[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-15 17:26:14
Message-ID: 200512160026.19658.jens () kdewebdev ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


> > > 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?
>
> That's a bonus, but I don't see it as a requirement. It might happen
> that we need a change in KDevelop to make things right. In that case we
> should just do it and require the new KDevelop. Otherwise I think
> targetting KDevelop from KDE 3.5 is fine. When we are at the point to
> release Kuanta, KDE 3.5 will be already out since some months, so
> getting binaries for most distros should be no problem.

Even if we have to modify KDevelop I see no need to make the Kuanta release at 
the same time. I see no problem in making it later. But I also think we 
should avoid changes in KDevelop for now and do this in KDevelop 4 whereever 
possible.


> > > 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.
>
> But we need time to do the actual KDE4 port as well. People are porting
> applications and libraries since months and still, it is far from being
> usable. Most of the KDE projects are working on the KDE4 version right
> now. I think KDevelop and Quanta are the exceptions from those who
> usually ship together with the main KDE releases. I think delaying the
> port and doing in 3 months is not good.

I agree that any delay is not good. But starting earlier does not reduce the 
work ;-) So whatever we do for Quanta in KDE 3 is not lost because we will 
use it for Quanta 4. We do not gain anything if we start early with porting 
but we loose the opportunity that people can test some major changes in the 
architecture. That is why I think we should make a rather late release of 
Kuanta. 
Starting later to port to KDE 4 would also mean that we would have a more 
stable base to develop on.


> > 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.
>
> This all depends when will KDE 4 appear and what is the release schedule
> for it. If it has a longer alpha/beta period, we might get more
> feedback. Also there is no guarantee people will switch to Kuanta,
> especially that I'm sure we cannot port everything right now, and this
> will mean the old Quanta will be more usable for many.

For sure the people who really work with Quanta will not try Kuanta. And of 
course we can not port everything, we have to decide what. 

> > 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.
>
> I don't oppose, but we need still need a deadline and some kind of
> roadmap. 

Yes.

> I suggest to release sometime in February or March. This gives 
> us 3 months to do it. 

3 month sounds somehow OK for me. Do you know about any release plans of 
KDevelop?

> The current Kuanta was done in 6 weeks (ok,let's 
> say 4-5), so this should be enough. 

But we were sitting together and we could concentrate on it!

> Also let's try to make a plan how 
> and who will do what. First what should we do:
> 1) a new parser which does not use string search, but does a char by
> char parsing. Jens is convinced that this will be faster. This should
> not affect how the parsing result is stored, so in theory we can have
> both parsers in parallel.
> 2) store the parsing result in a KDOM tree. This should not depend on
> the parser itself. So *in theory* 1 and 2 can be done independently.

I do not agree that they are independently. I believe that we can not do one 
of it without touching the other. So I would prefer to try to do this 
together.

> 3) once 2 is done, port or rewrite VPL

I hope we can drop most of the code here! At least everything that is related 
to gluing the two trees together.


> The above are the main arhitectural changes. Of course 1) can be broken
> is several subitems, like rethinking how we proceed with included files
> and so. 

Yes indeed, I was also thinking about this. Maybe it is even a good idea to 
look into Robertos new parser for some parts, like script languages or pure 
CSS files? 

> Or even how the autocompletion is done. 

I do not get this.

> A unitt est for the  
> parser is also a must. It's just too easy to brake something and not
> notice without an automated test.

Yes. 

> Than there are the missing pieces and bugs in the current port, see the
> TODO.

true.

> Than there are the other kdewebdev applications. Who will port them to
> KDE4? Will we keep them? Are the maintainers or original authors of
> those applications still around and wanting to take care of them? If
> not, we need to find manpower to do it or - sad, but true - drop them.

Dropping would be pretty sad. 


> > 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.
>
> It will never be ready. ;-)

Also true.

So I suggest that we try to get a rework of the parser done first. Together 
with an improved preview it could be enough for a release. 
If we have time we can do VPL as well. Oh BTW, we should create a better word 
for this. VPL is just not nice. 

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]