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

List:       kde-core-devel
Subject:    Re: What to do after 2.2?
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2001-07-13 20:35:02
[Download RAW message or body]

On Fri, Jul 13, 2001 at 04:07:15PM -0400, Andreas Pour wrote:
> Bernhard Rosenkraenzer wrote:
> > 
> > On Fri, 13 Jul 2001, George Staikos wrote:
> > 
> > >    Personally I'll be pretty pissed off if I have to recompile all my apps
> > > barely a year after 2.0 came out.  Yeah the new features are nice and all,
> > > but breaking applications is very unprofessional.
> > 
> > But it can't be avoided.
> > If we switch to 3.0 now, 3.x will at least have a very long lifetime.
> > 
> > I think the problem with existing applications gets bigger, not smaller -
> > if we break the ABI now, we'll break maybe 100 binary applications. If we
> > break the ABI 4 months from now, we'll break 300.
> > 
> > Besides, the imminent switch to 3.x on most Linux distributions and
> > probably most other OSes (*BSD) will break the ABI anyway for most of us -
> > there's no point in breaking it twice (2.2/gcc 2.x, 2.3/gcc 3.x, 3.x).
> > I'd rather go (2.2/gcc 2.x -> 3.0/gcc 3.x).
> 
> Hi,
> 
> Just to throw my $0.02 in, this is the single most persuasive point I've
> heard.
> 
> BTW, how hard is it to switch the style stuff?  What's involved?  Can
> some carefully-thought-out preg_replace's handle this (using some
> maybe-not-so-clever-but-workable defaults) or is it plainly impossible
> to automate the update?

It basically involves moving separated methods (current QStyle using
virtual methods) into a few dispatcher functions (new QStyle) 
which do a switch() . And it also involves adapting to new namings.
I don't think it can be automatized. It needs deep knowledge of
the new and the old API.

But styles can be ported step by step. KDE does not depend on the styles
source wise (except for a few calls in KToolBar and Kicker to KStyle, 
I think) .

Bye,
 Simon

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