From kde-core-devel Mon Aug 28 22:27:10 2000 From: Carsten Pfeiffer Date: Mon, 28 Aug 2000 22:27:10 +0000 To: kde-core-devel Subject: Re: konqueror <-> clipboard <-> klipper X-MARC-Message: https://marc.info/?l=kde-core-devel&m=96750158105551 On Mon, Aug 28, 2000 at 12:01:27AM +0100, Richard Moore wrote: Hi, > Will check. I did a little debugging and at least found the place where the CPU-time is spent. In qclipboard_x11.cpp, qt_xclb_wait_for_event(). There is a loop waiting for a specific event using XCheckTypedWindowEvent(). Usually the event is found prett soon so the method returns, but sometimes it takes up to 150.000 calls until the event is found. Any Xlib hacker around? > - I'd like to be able to install additional handlers (that invoke > commands, run scripts etc.) as plugins. One of the plugins would > be for festival via kspeechsynthd. Yeah, we should get this done for 2.1. BTW, is festvial already capable of using aRts as output device? > - I'd like the ability to send messages with structure, so I could > for example send a message from an AIM client which included info > about the person speaking as well as actual text. As SABLE allows > for multiple voices this has obvious benefits for speech > notification. Hmm, you can put anything into the message (a QString) and parse that however you like... that's the only generic way, I'm afraid. Not that it would look in a messagebox then, tho ;) Maybe one additional string with "extra" information? > Ideally this would also allow for some form of classification of > notifications. This would allow you to define a rule for errors > (eg. log them then display a warning) without having to > individually modify each one. Nice idea. But how configure that? The current way is the most flexible way, e.g. you can specify what to do for each event differently. Specifying groups would be easier, but also less flexible. Hmm. > - The ability to use the configuration dialog more flexibly. Kit > for example should be able to display the subsection of the dialog > that relates to itself in it's own config dialog. This is very > important for making the API easy to use. Yes, this is really necessary. I'm not sure this is possible with current kcmshell tho (can I get some parameter given to a kcmshell commandline? I'm afraid not). IMHO we need a "frontend class" for kcmshell anyway. Cheers, Carsten Pfeiffer -- http://www.geocities.com/SiliconValley/1632/