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