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

List:       kde-panel-devel
Subject:    Re: [Panel-devel] Multithreaded krunner
From:       "Ryan Bitanga" <ephebiphobic () gmail ! com>
Date:       2007-11-25 4:58:32
Message-ID: cf617050711242058s4057f140q90e9aa8a58490807 () mail ! gmail ! com
[Download RAW message or body]

On Nov 24, 2007 3:13 AM, Aaron J. Seigo <aseigo@kde.org> wrote:
>
> the reason SearchContext is a QObject was to manage the ownership of the
> QActions. so the options are two fold: either make SearchContext not a
> QObject and move to the data-only SearchMatch approach, or do as you note
> here and make some special constructors. i think it would be nice to keep
> SearchContext a QObject if only because that leaves the door open to
> signal/slot usage later. this might be useful if we move the default action
> selection into SearchContext as it could then signal when the default
> changes.
>
> so .. yeah, new constructor it is. =)
>
SearchContext lives in the GUI thread so leaving it as a QObject gives
us the additional bonus of using async calls :)

> why don't we just try one approach, picking the one that seems best. which
> would be the SearchContext copy passed in to the match, discarding
> mismatches.
>
got it. I'll post a patch for review in maybe an hour or so. :)

Cheers,
Ryan
_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel
[prev in list] [next in list] [prev in thread] [next in thread]