[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: konqueror <-> clipboard <-> klipper
From:       Carsten Pfeiffer <carpdjih () cetus ! zrz ! TU-Berlin ! DE>
Date:       2000-08-28 22:27:10
[Download RAW message or body]

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/

[prev in list] [next in list] [prev in thread] [next in thread]