[patch] application wide edit (cut, copy, paste) actions

Scott Wheeler wheeler at kde.org
Tue Feb 18 05:30:53 GMT 2003

On Monday 17 February 2003 12:06, Waldo Bastian wrote:

> Looks very nice. Do you think it's also possible to disable/enable these 
> actions when applicable? Might be rather hard since you would need to track 
> the "has selection" state of the focus widget in order to properly 
> enable/disable cut & copy. Would be good to think a bit about that so that a 
> Qt 4 solution could accomodate that as well.
> Something along the lines of moving hasSelectedText() (Text only??) and 
> selectionChanged() into this new Qt base class. And isReadOnly() in order to 
> enable/disable paste.

I think just a "virtual bool QEditable::hasSelection() const = 0" would do the 
trick.  This could be done with a signal in [K/Q]Application that is tied to 
QClipboard::selectionChanged() and checks the above method.  There's probably 
a more efficient way of doing this, but it's not coming to mind at the 
moment.  ;-)

The more difficult one is pasting since you not only have to know if there's a 
current selection and you have to know if the widget can decode that type of 
clipboard data.  But even so, I think it would be possible to do this app 
wide by having something in [K/Q]Application that emits a signal not when the 
clipboard selection changes, but when the selection changes and 

bool QEditable::canDecode(const QMimeSource *s) const
- or -
bool QEditable::canDecodeClipboard() const

returns true.

Whatever -- I'm not so worried about the specific API, but I do think having 
this in Qt 4 would be a good thing.  IMHO having those things there is the 
right solution -- my patch is a hack, but one that can be easily be switched 
to the new mechanism in a source compatible way should it become available.

As for the current set up, well, it would require something like slot 
hasSelection(bool &v), which isn't implemented by the Qt widgets; it could be 
added to the KDE widgets, but then for this to work it would require using 
only subclasses of the Qt widgets, which isn't always practical. 

And when I was looking through a few apps I noted that most of them don't 
actually check to see if it's possible to do these things and disable 
appropriately, so I thought my stuff would be a decent interim solution 
that's not any worse that what's currently done.



Audience Member: "What was the hardest part of building TeX?"
Donald Knuth: "It was all pretty easy."

More information about the kde-core-devel mailing list