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

List:       konq-e
Subject:    Re: Project: Konqueror/Embedded for Qtopia
From:       Eva Brucherseifer <eva.brucherseifer () basyskom ! de>
Date:       2006-01-16 17:05:51
Message-ID: 200601161805.51806.eva.brucherseifer () basyskom ! de
[Download RAW message or body]

Hi Luciano,

Am Donnerstag 12 Januar 2006 16:14 schrieb Luciano Montanaro:
> On Thursday 12 January 2006 13:11, Eva Brucherseifer wrote:
> > Hi everybody,
> >
> > I am glad to announce, that basysKom (my company) concluded a contract to
> > port the current version of Konqueror/Embedded based on KDE 3.5 to Qtopia
> > PDA Edition 2.2 (based on Qt 2.3.12) and to add a customized GUI with a
> > number of additional features.
>
> Hi Eva, welcome to the list!

thanks :-)

>
> > Currently Konqueror/Embedded is developed in the kdenox module in SVN. It
> > works together with the current version in the 3.5 branch. In order to
> > compile Konq/E a script is applied which copies over a number of files,
> > patches some of them and further more there exist dropin replacements.
> >
> > The whole development setup is somewhat difficult, because we have to
> > deal with different Qt versions in parallel and also the desktop/embedded
> > environment which is based on patches. We want to suggest the following
> > setup:
> >
> > - we continue to work with the 3.5 branch of kdelibs, as it is mostly
> > stable - we develop new features for the 3.5 version of Konq/E first.
>
> That's the only option for now, since kdelibs 4 is not yet in dependable
> state. In the longer term keeping I hope Qtopia will be ported to Qt4...

exactly. Our timeframe doesn't allow to wait.

>
> > This allows us to copy over code from konqueror and to adapt it.
>
> Umh, the cut and paste work code could go in the src and dropin
> directories.
>
> > - for the qt2 port we generate a set of compat implementations to
> > minimize #ifdef-ed code and a series of patches for the kdesrc code. We
> > are doing an initial port right now.
>
> That's ok, maybe a "qt2dropin" directory should be added to the repository?

That's how we started it for now:
A subdir in dropin and #ifdef'ed sources for dropin and src. 
For kdelibs we are patching so far. Some changes might be checked into kdelibs 
itself, but I don't want to break anything.

>
> > - for easier development, we suggest to generate a kdenox branch. This
> > way we don't interfere with other people using kdenox. Into this branch
> > we would to check in the complete sources (also the one copied from
> > kdelibs). From there we would create patches for the current version of
> > kdenox.
>
> Do you mean a branch named kdenox-new-gui (for example) with a kdelibs and
> kdenox subdirectory, or do you have some different setup in mind?

Well, originally I just wanted to have branched kdenox directory with a 
src-new-gui sub-sub-...-dir.

It basically depends on how many people are working on kdenox right now and if 
they depend on a working system. We don't want to break things for other 
people. 

> Also some more of the patches could be integrated in mainstream kdelibs,
> to minimize the adaptation work after each kdelibs release. Some of the
> patches have been merged in "regular" kdelibs, while some of the others
> need some more work.

the 3.5 branch is a deadend though. Development continues in trunk and I 
wonder wether anyone will sync back the branch changes. To be honest, I don't 
expect this to happen.

Of course we could occupy kdelibs for our own use ;-)

Some changes don't make sense to integrate into kdelibs though. Many of our 
changes for Qt2 depend on compat code in dropin. Other changes shouldn't be a 
problem, because it's just cosmetics like changing size() to count(). Of 
course size() is more logical, but in Qt2 there is only count().

What do you think?

>
> > - wrt the GUI implementation and most of the GUI features we are not sure
> > yet. I wonder of how much use this is to other users of Konq/E. Either we
> > create an alternative src directory. Maybe it's ok to just have another
> > mainwindow.
>
> I don't think that's really needed. From what I see of your feature list,
> most things could be implemented as a MainWindow "personality",
> some need more thorough implementation in the dropin replacements, like a
> Line edit widget with history handling, the ssl dialog etc.

I think this makes sense.

>
> If you really want tabs you may have to touch the View and BrowserView
> classes...

Ok, from your mail I understand, that you suggest that we develop directly in 
kdenox and maybe even kdelibs. Is that ok for everybody?

Greetings,
eva


-- 
Eva Brucherseifer
General Manager

basysKom GmbH
Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany
Tel: +49 6151 3969-961 | Fax: -736 | Mobile: +49 170 5533642
eva.brucherseifer@basyskom.de | www.basyskom.de
_______________________________________________
konq-e mailing list
konq-e@kde.org
https://mail.kde.org/mailman/listinfo/konq-e
[prev in list] [next in list] [prev in thread] [next in thread]