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

List:       kde-freeqt
Subject:    Re: [freeqt] Things
From:       Jo Dillon <emily () thelonious ! new ! ox ! ac ! uk>
Date:       1998-11-05 13:59:22
[Download RAW message or body]

Christian Boos (boos@arthur.u-strasbg.fr) spake thusly:
> Jo Dillon writes:
>  > Ok..it's recently come to my attention that my messages yesterday were
>  > bounced (thanks Tero!). So here's what I said..
>  > 
> 
> Speaking of the mailing list, am I the only one for which it takes (at 
> least) half an hour before I can see my posting on the list? This is not very 
> important, but it can sometimes help to have more responsiveness.

  Hmm...it's not usually that bad for me.
> 
> A dove? Wasn't it a bunch of rabbits?  I haven't asked him yet (he is
> even more busy than I am :), but since you wait for it, I will urge
> him to do the nice picture.

  Well, a dove seems better fitted to 'Harmony'. But there's no enormous
hurry.
 
>  > Secondly, we need to think what to do when Qt 2.0 comes out - do we
>  > fork Harmony, try and maintain compatibility with both or just ignore
>  > it for now?
>  > 
> 
> Compatibility with both, I would say.
> That's another place where namespace will prove their usefulness.
> 
> Here's what I suggest:
> 
> namespace Harmony {
>   // Harmony specific extensions (like the themeing stuff)
> };
> 
> namespace Qt_1_40 {
>   // current Qt compatibility classes
> };
> 
> namespace Qt_2_00 {
>   // reuse from Qt_1_40 what remained compatible,
>   // define new 2.0 stuff, and redefine what has changed since 1.40
> };
> 
> namespace Relay {
>   // my stuff :)
> };
> 
> 
> On the (final) user side, it suffices to choose the appropriate
> aliasing:
> 
> namespace Qt = Qt_1_40;
> 
> or
> 
> namespace Qt = Qt_2_00;

  User side? As in each KDE application? That might be a Bad Thing. Remember
we don't want people to have to change their application source if possible.
Your suggestion does make sense tho (as long as it can be persuaded
to work with compilers that don't support namespaces, which would seem
difficult ;)
 
> 
> I'm also thinking of ways to have our own classes hierarchy with a
> versatile set of functionalities (H*** widgets), 
> and only aliasing them to Q*** classes, building the compatibility there.
> (nothing concrete in this direction for now...)
> 

  This would certainly make us less sue-able.

-- 
	Jo

Harmony - the project to create an LGPL Qt clone
http://harmony.ruhr.de

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