direct slot invocation (Re: kdelibs/kdecore)

[Antonio Larrosa Jiménez]

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.

Well, I'll think more about it after my exams, next weekend.

Greetings,

--
Antonio Larrosa Jimenez
KDE developer - larrosa at kde.org
http://developer.kde.org/~larrosa/
The only thing that interferes with my learning is my education.