Bug 20299 - hard to keep track of QSharedPointer's with AccountManager
Summary: hard to keep track of QSharedPointer's with AccountManager
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-qt (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-24 13:21 UTC by Ian Monroe
Modified: 2009-04-23 06:49 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Ian Monroe 2009-02-24 13:21:51 UTC
For instance in the following code, where m_manager is a Telepathy::Client::AccountManager:

    m_accounts = m_manager->allAccounts();
    foreach( int i = 0; i < m_accounts.size(); i++ )
    {
        connect( m_account.at( i )->becomeReady(),
            SIGNAL(finished(Telepathy::Client::PendingOperation *)),
            SLOT(accountReady(Telepathy::Client::PendingOperation *)));
    }

Standard stuff. allAccounts returns QSharedPointer's which are stored in a QList (m_accounts). In the accountReady slot there is however no way to access the QSharedPointer, so if accountReady wants to share the account with another class it can't (at least not without additional hacks). 

The reason PendingAccountReady return a QSharedPointer is because some accounts are created independently of AccountManager, so the strong pointer wouldn't be available to PendingAccountReady. 

Something like KSharedPtr could solve it, since KSharedPtr keeps the refcounter in the object instead of the pointer. QExplictlySharedDataPointer might work as well.
Comment 1 Simon McVittie 2009-04-23 06:49:33 UTC
I believe 0.1.3 fixes this.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.