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

List:       konq-e
Subject:    Re: Project: Konqueror/Embedded for Qtopia
From:       Luciano Montanaro <mikelima () cirulla ! net>
Date:       2006-01-16 18:06:17
Message-ID: 200601161906.17615.mikelima () cirulla ! net
[Download RAW message or body]

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?

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

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

Currently I am the one still working on Konqueror embedded. Lately more 
people have shown interest in it, but apart from bug fixing and updating 
the patches for new KDE versions, there is not much going on. 

I'll release a snapshot when kdelibs 3.5.1 is released. After that, I'd like 
to experiment with a Qt4 port. That could well be in a "work" branch, 
though.

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

Right. Moreover, Qt4 should be better suited with embedded environments 
anyway. 

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

Feel free to use count() in kdenox if it makes your life easier.
Qt4 classes seem to handle count() too, so I see no problem with that. 
As for more logical, that's arguable.   

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

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.

Ciao,
Luciano
 

> Greetings,
> eva

-- 
Luciano Montanaro //
              \\ //
               \x/ www.cirulla.net
_______________________________________________
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]