direct slot invocation (Re: kdelibs/kdecore)
Antonio Larrosa Jiménez
larrosa at kde.org
Sun Feb 16 23:52:20 GMT 2003
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
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.
Antonio Larrosa Jimenez
KDE developer - larrosa at kde.org
The only thing that interferes with my learning is my education.
More information about the kde-core-devel