Wrong (?) usage of deprecated and usage of setActiveWindow vs. activateWindow (was: Re: kdelibs/kdecore)
Ingo Klöcker
kloecker at kde.org
Mon Oct 27 19:49:23 GMT 2003
On Monday 27 October 2003 14:55, Lubos Lunak wrote:
> On Saturday 25 of October 2003 15:56, Ingo Klöcker wrote:
> The point is that you usually don't have to call setActiveWindow()
> at all. That's why the comment next to @deprecated says what it says.
> The intention of marking the call as deprecated was that people will
> see the warning, will read the comment, and will update the app as
> necessary (I guess I'm naive). And the comment about the KDE4 merging
> should have ?? at the end.
>
> Using KDE_DEPRECATED that way probably is not exactly the way it's
> supposed to be, but I have no idea how to do it differently.
You could add a comment which tells the reader of the comment what you
wrote above.
> > Apart from that it's absolutely unclear to me whether I should use
> > activateWindow or setActiveWindow in the following use cases in
> > KMail:
>
> Hmm, is the description of KWin::activateWindow() not clear enough?
Not really. The "which represent direct user actions" part of "The usage
of setActiveWindow() is meant only for pagers and similar tools, which
represent direct user actions." confused me because if the user presses
's' to open the search dialog (see 2. below) then that's obviously a
direct user action.
> Not that it really explains the matter in detail, because it can get
> a bit complicated and it wouldn't quite fit there - an attempt to
> explain that in detail is a section in kdebase/kwin/README.
The explanation should be part of the API, e.g. in the Detailed
Description of the KWin class, and not "hidden" in some README. Is it
really in kdebase/kwin? I would have never looked there because the
KWin class is in kdelibs/kdecore.
> > 1. The user clicks on KMail's system tray icon -> KMail's main
> > window should be activated.
>
> Use KSystemTray.
We use KSystemTray, but we can't use it for activation because KMail
needs a more sophisticated behavior. Anyway, I'll have a look at how
KSystemTray does it.
> > 2. The user wants to search for messages and presses 's'. In case
> > the search window is already open it should be activated.
>
> "applications should use activateWindow()"
Okay, but does it even matter? AFAIU the stuff about "focus stealing" in
the REAME it's pretty much irrelevant whether we use setActiveWindow()
or activateWindow() because there's no other application involved so
that KWin's "focus stealing prevention" doesn't come into play.
> > 3. The user starts KMail a second time
>
> Hmm, the a bit complicated case. Use KUniqueApplication. If you
> insist on doing it yourself for some strange reason, consult
> KStartupInfo::setNewStartupId().
Yeah. We are of course using KUniqueApplication.
> > or the dcop call openReader is
> > used -> KMail's main window should be activated.
>
> Even more complicated, probably worth reading the relevant part of
> kwin's README. I don't know what openReader() is exactly supposed to
> be. You'll have to explain what it is, or you'll have to consult the
> README. Maybe both ... I invented this stuff few months back, and I'm
> still unsure about few details myself.
Okay, I read kwin's README. openReader() is supposed to open KMail's
main window. Currently I can't think of a reason why it should be ever
called by anyone. I guess I'll just use activateWindow() until someone
shows up with a valid complaint.
Thanks for your help!
Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20031027/2e71d297/attachment.sig>
More information about the kde-core-devel
mailing list