[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Trolltech <-> KDE contact point for critical issues
From: Simon Hausmann <hausmann () kde ! org>
Date: 2006-07-14 11:34:52
Message-ID: 200607141334.55881.hausmann () kde ! org
[Download RAW message or body]
On Friday 14 July 2006 13:32, Frans Englich wrote:
> On Friday 14 July 2006 11:00, Olivier Goffart wrote:
> > Le vendredi 14 juillet 2006 11:50, Simon Hausmann a écrit :
> > > I agree that this would be a useful feature to have in Qt (especially
> > > if you look at the numerous implementations in the Qt commandline tools
> > > ;-), but I'm not convinced that this is a critical feature for KDE 4.0.
> > > There's nothing fundamentally wrong with KCmdLineArgs and at this point
> > > it is too late to add an entire new class to Qt 4.2.
> > >
> > > It is definitely something to consider for Qt 4.3.
> >
> > Then we will have that exact scenario:
> > > On Thursday 13 July 2006 16:32, Frans Englich wrote:
> > > > For that reason, I wouldn't be surprised if such a basic class pops
> > > > into Qt later on, and then we'll have KCmdLineArgs and
> > > > Qt's(duplication, things that doesn't work together, confusion, etc).
>
> I obviously thinks that is problematic but I also understands
> Simon/Trolltech's reluctance to introduce features at this stage.
>
> My main concern with trying to get something like that into Qt 4.2 is to
> achieve a good result. Writing such a class for Qt provides an opportunity
> to write a really rocking, innovative thingy. Delegating handling of
> switches to slots(perhaps) and to allow expressing things like "this option
> can only be specified when 'this' and 'this' option is present". It's
> tricky to make something like that mature in such a small time frame.
>
> Handling translations needs thought too.
>
> However, one could /attempt/ to come up with something, and if it's
> sufficiently stable one could ship it with Qt 4.2 and mark it as being
> expected to change in the future(as have been done before, IIRC). Then one
> could stabilize it for Qt 4.2.1 and make KDE 4.0 depend on Qt 4.2.1. Or
> simply just introduce the class in Qt 4.2.1..
We do not have any intentions of doing that, for what I think are absolutely
obvious reasons.
Simon
[Attachment #3 (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic