3 KUrlRequester questions

David Faure faure at kde.org
Wed Aug 19 17:12:55 BST 2009

On Tuesday 21 July 2009, Konstantinos Smanis wrote:
> Now, question #1:
> Why does the [openFileDialog] signal emission occur before everything else in the "else"
> body? This can be quite frustrating if one wants to customise the
> KFileDialog selection:
> Let's say the KUrlRequester has a /home/user/foo.txt url(). And you want
> the dialog to initially select a different file (let's say
> /home/user/bar.txt). One would think "nice, just connect the signal
> openFileDialog() somewhere, and there use setSelection() on the dialog to
> have the other file initially selected". But no, this is impossible because
> the file dialog's selection changes a few lines of code afterwards. Is this
> done on purpose to avoid customising the file dialog's selection?

I guess not. Seems to me that you could move the signal emission
further down.

> Question #2:
> Just out of curiosity (and probably stupidity), why does the openFileDialog
> signal provide a KUrlRequester pointer? Extract from the documentation:
> Can't we simply call QObject::sender() to find out the caller?

sender() is ugly and hackish. KJob does the same, passing itself in signals,
it's much cleaner.

Why is sender() bad? Because in 2005 you write a slot that uses sender(),
and in 2009 you forget that you use sender() in the slot and you call it directly
from another place, and sender() is 0 or whatever the last signal emitter in
the current backtrace is.

(with threads sender() breaks too, but this particular bit of code is GUI related
so no threads possible anyway; just another reason against sender()).

> Question #3:
> Is there any need to have the "myCompletion" variable? Can't we just use
> KLineEdit's/KComboBox's accessors?

I guess you're right. In fact the code in KUrlRequesterPrivate::url() already
does this afaics... Patch welcome. Unit test more than welcome :)

David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

More information about the kde-core-devel mailing list