signal signatures vs. inheritance (Re: [PATCH] KProcess port of khelpcenter)

[Ralf Habacker]

Oswald Buddenhagen schrieb:
> On Thu, Dec 20, 2007 at 08:14:16PM +0100, Ralf Habacker wrote:
>   
>> i see, you mean this
>>
>>    meinproc->setOutputChannelMode(KProcess::SeparateChannels);
>>
>>     
> OnlyStdoutChannel, but anyway ...
>   
really ? in toc.cpp for example the stderr channel is printed with 
kDebug, stdout is ignored
>   
>> To be able to handle the finished signal i have to use QProcess related 
>> types in the signal definition like
>>
>>    connect( meinproc, SIGNAL( finished( int, QProcess::ExitStatus) ),
>>             this, SLOT( meinprocExited( int, QProcess::ExitStatus) ) );
>>
>> or
>>
>>    connect( meinproc, SIGNAL( finished( int, QProcess::ExitStatus) ),
>>             this, SLOT( meinprocExited( int, KProcess::ExitStatus) ) );
>>
>> both formats works.
>>
>> If  i use the following
>>
>>    connect( meinproc, SIGNAL( finished( int, KProcess::ExitStatus) ),
>>             this, SLOT( meinprocExited( int, KProcess::ExitStatus) ) );
>>
>> it compiles but raises a "could not connect" runtime error.
>>
>>     
> i'd call that a misbehavior/bug on qt's side, given that it does not
> reflect c++ namespacing rules. both of the first variants working and
> the last one failing seems outright weird ...
>   
is is compilable because KProcess inherits QProcess and  ExitStatus type 
is visible in KProcess :-(  could this not supressed to avoid that this 
is compilable like done with    

class KProcess
<snip>
// hide those
    using QProcess::setReadChannelMode;

>> Wouldn't it not better to add a  specific signal to KProcess to avoid
>> such problems ?
>>
>>     
> do you realize *how* many classes would have to be uglified that way?
>   
i see, then hiding this type in KProcess should probably be better :-)

Ralf