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

List:       kde-core-devel
Subject:    Re: konqueror <-> clipboard <-> klipper
From:       Richard Moore <rich () ipso-facto ! freeserve ! co ! uk>
Date:       2000-08-27 23:01:27
[Download RAW message or body]

Carsten Pfeiffer wrote:
> 
> On Sun, Aug 27, 2000 at 12:52:21AM +0100, Richard Moore wrote:
> 
> Hi,
> 
> > My understanding was that since the clipboard was handled using
> > X properties that you could detect changes by asking for a
> > property changed event. There may be something I'm missing,
> > I've bought the O'Reilly XLib book so I'll see if it has
> > anything relevent.
> 
> would be great if you find something out.

Will check.

> 
> > Yes, my patch was bogus. The problem was that I had some old
> > autoconf info somewhere which was disabling the run time type
> > info - since the code used dynamic_cast it crashed. Doing a
> > complete cvs-clean sorted things out.
> 
> good.
> 
> > The KNotify stuff is a great idea, but at the moment it is
> > crippled by missing features. There are a bunch of things
> > that I'd like to see added in 2.1, do you know who is working
> > on this?
> 
> Christian Esken started knotify a while ago, Charles overtook development
> and is maintaining it right now.
> 
> What features do you have in mind? Starting user-defined programs per
> event would be nice (Charles just implemented that, although delayed for
> 2.1), or playing the message thru festival.
> 

Well, I think there are a bunch of things:

- 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.

- 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.

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.

- 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.

Cheers

Rich.

> Cheers,
> Carsten Pfeiffer
> --
> http://www.geocities.com/SiliconValley/1632/

-- 
     Richard Moore		rich@ipso-facto.freeserve.co.uk
http://www.robocast.com/	richard@robocast.com
http://developer.kde.org/	rich@kde.org

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