[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 18:49:26
Message-ID: 200601161949.27154.eva.brucherseifer () basyskom ! de
[Download RAW message or body]

Am Montag, 16. Januar 2006 19:06 schrieben Sie:
> On Monday 16 January 2006 18:05, Eva Brucherseifer wrote:
> > > 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.
>
> Ok. But you are interested in a port to that eventually, right?

Not for this project, no. And after that - who knows. 

I guess sooner or later there will be gadgets based on Qtopia 4, so I guess 
other people will be happy to have a browser for Linux Embedded. It will 
surely be a gain to have it. 

>
> > > > 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.
>
> Sure. Well, again, for now I think that's the simpler way. For the future
> (at Qt4 porting time) I think we want most changes merged. Actually,
> with various other ports around, qt-embedded specific changes will not be
> too many. What I hope to be able to work on, is moving "advanced" things
> out of the KPart, into plugins or additional modules. For advanced stuff I
> am thinking on things that are normally disabled in Kde-embedded, like
> autocorrection in form widgets, printing and search GUIs.

Having a modular structure is definitly a plus. I only hope it doesn't make 
things too complicated.

> >
> > Ok, from your mail I understand, that you suggest that we develop
> > directly in kdenox and maybe even kdelibs. Is that ok for everybody?
>
> From next week on, it's fine with me if you want to work on the trunk.
> I'll prepare a snapshot during the weekend; after that, it's ok if the
> repository gets a bit unstable. Plus, many points of your todo will be
> generally useful.

Ok. If we work on the same code base the chance that stuff will be available 
later on is much bigger. You probably know how projects are - time is short 
and motivation for extra work like merging things back decreases.

So if it is doable for us to work on one code basis (kdenox), it probably 
gives the best results. Regarding kdelibs I'd stay with 3.5 for now and maybe 
not change too much stuff over there. But maybe we can discuss this later 
once we have concrete things.

BTW - I am already able to compile most code of konqueror with qt2. What's 
missing is mostly the difficult stuff: xml, fonts, paint/event options. 

Regards,
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]