direct slot invocation (Re: kdelibs/kdecore)

[Simon Hausmann]

On Mon, Feb 17, 2003 at 12:52:20AM +0100, Antonio Larrosa Jiménez wrote:
> El Domingo, 16 de Febrero de 2003 23:58, Scott Wheeler escribió:
> > Yes, this is something different.  See my explanation in:
> >
> > Subject: [patch] application wide edit (cut, copy, paste) actions
> >
> > Sent yesterday.  Rather than restating it here, I'll leave it up to you
> > to read that if you're interested and ask for clarification then.
> 
> Hi Scott, thanks a lot for the pointer to the explanation, I've read it and 
> it looks very interesting. In fact, I should have understood it from 
> looking at the source code. Btw, I'd love to see Oswald's changes in cvs 
> too.
> 
> After understanding (I hope :) ) what you were talking about, I have a 
> suggestion: what about changing the name from invokeEditSlot to something 
> like invokeFocusedWidgetSlot (if I understood it correctly, it can also be 
> used for any kind of slot, not just for "edit" ones) and then putting that 
> method in KAppDCOPInterface ? This would allow for making a simple DCOP 
> call in a text-to-speech application in order to get the text of the 
> currently focused widget in another application and read it through the 
> speakers. To be more precise: calling invokeFocusedWidgetSlot with a 
> "SLOT(text())" parameter. Hmmm, there would be a problem with the returned 
> value ... maybe calling copy() and then reading the clipboard ... hmmm, 
> that would insert a race-condition ... well, you get the idea :) (for this 
> particular problem, maybe the best would be to insert a dcop method 
> KApplication::focusedText() that returns the text of the focused widget). 
> I'm sure kttsd or kmouth could make use of something like that.

Much simpler idea: Why not use Qt properties for retrieving the
text? Once you know the 'address' of the focus widget in the Qt dcop
bridge of the process just query the text property (and fall back to
something like currentText if it doesn't exist, or the like) .

Simon