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