[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:       Andras Mantia <amantia () kde ! org>
Date:       2005-12-17 18:08:09
Message-ID: 200512172008.10518.amantia () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


<offtopic>
Finally, I've compiled almost everything I need. If somebody thinks an 
RPM distribution doesn't need you to compile things is wrong. It also 
seems that SuSE 10 has some problems regarding 64bit packages, mainly 
some library .so links are missing. This doesn't make my life easier. 
And of course no real multimedia packages there. That was the biggest 
pain: compile mplayer in a way it can use the 32bit win32 codecs. This 
means I had to compile as a 32bit application on a 64bit platform. I 
finally succeed after several hours and several google searches. Here 
the problem is mplayer itself, not SUSE.
 gcc bugs doesn't help either compiling from source.
 I still miss some applications, but they are not that important now and 
once my new billing session starts I will download them. And I have ALL 
KDE packages compiled now. I also have to update SUSE as well, as now 
it is a stock version without security fixes...
</offtopic>

On Thursday 15 December 2005 19:26, Jens Herden wrote:
> Even if we have to modify KDevelop I see no need to make the Kuanta
> release at the same time. 

I just said to coordinate with them, so if they plan to release earlier, 
like in January, we can use that version as a base as well. Or if they 
plan to do only mid-2006, we don't care about it.

> 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.

Sometimes changes are needed. Mostly when there is a bug, like it was 
also when we started kdevquanta in the plugin loading code of KDevelop.

> I agree that any delay is not good. But starting earlier does not
> reduce the work ;-) 
No, but it has the advantages that we gather more experience with 
Qt/KDE4 and we can really use the new technologies they have instead of 
doing a simple, but dumb port.

> So whatever we do for Quanta in KDE 3 is not lost 
> because we will use it for Quanta 4. 

Sure, that's right.

> Starting later to port to KDE 4 would also mean that we would have a
> more stable base to develop on.
That's true. But I'm not convinced that we should just wait until the 
others do what they want. They are interesting changes in KTextEditor, 
for example, including the possibility to do syntax highlighting, many 
interfaces were restructured or even dropped and we must find in time 
what we need and what is missing. So I think actively taking part in 
kdelibs4 development is good for Quanta.

> And of course we can not port everything, we have to decide what.
Right.

> 3 month sounds somehow OK for me. Do you know about any release plans
> of KDevelop?
Not yet, I/we should check their homepage or ask.

> But we were sitting together and we could concentrate on it!
Yes, but if there is a todo list, it helps to concentrate more even if 
we are not together.

> 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.

Whatever. ;-)

> 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?

I don't know how it works at all...

> > Or even how the autocompletion is done.
>
> I do not get this.

Autocompletion takes the possible values from the structure groups. I'm 
wondering if it is the right way to do or we can build some good data 
structure for the autocompletion alone.

> > 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.

There are two problematic applications:
- kfilereplace
- kimagemapeditor

I will help with the first one, especially that I already started to 
clean up locally, so it does not use processEvent() calls and doesn't 
not enter a deadlock. The latter is more interesting. I'm sure if I 
give a go-ahead on kdelibs that it can be ported, people will do it. 
But that will be really a dumb port.

> So I suggest that we try to get a rework of the parser done first.

And who starts it? ;-) Ok, the problem is that working on the parser is 
not that easy in a team. But for example I could do the parsing part 
and you could think about how to store the result in KDOM.

> 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.

WYSIWYAG? or WYSIWYNG? ;-) (A=Almost, N=Never)
Well, the short version might not sound that good, but Visual Page 
Layout is OK. 
How about something like VIsualPageEditing (VIPE)? Or something similar 
with more vocals in it? 

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org

[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]