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

List:       kde-core-devel
Subject:    Re: KApplication::cut()....
From:       Richard Dale <Richard_Dale () tipitina ! demon ! co ! uk>
Date:       2005-09-23 16:46:32
Message-ID: 200509231846.32849.Richard_Dale () tipitina ! demon ! co ! uk
[Download RAW message or body]

On Friday 23 September 2005 18:15, Aaron J. Seigo wrote:
> On Friday 23 September 2005 09:32, Benjamin Meyer wrote:
> > Very cool.  Attached is the modified version
>
> and for apps that don't have a kmainwindow? besides, this is really just
> tacking these methods on to some class because it "kinda sorta maybe fits".
> in other words, exactly what was done with kapplication. this is not good
> design IMHO.
>
> david's suggestion of a KStandardSlots class in Frameworks makes a hell of
> a lot more sense. it has the added bonus of probably making the people
> currently using these methods a lot happier, and they count more than
> anyone else when it comes to this API, no?
Apple's Cocoa AppKit has the notion of a 'first responder' which is the 
thing/widget which currently has focus. So for KDE you might be able to 
connect to it as a SLOT of a standard widget in Qt Designer, as you can in 
Mac OS X Interface Builder as an IB outlet to a thing called the first 
responder. The actual target slot would need to vary dynamically. Maybe KDE 
already has some similar mechanism. How does KDE enable/disable the 'copy' 
menu action according to whether or not the equivalent of the first responder 
supports selecting text, and has something selected?

-- Richard
[prev in list] [next in list] [prev in thread] [next in thread]