RESOLVED FIXED 173145
Add API::IconDatabaseClient
https://bugs.webkit.org/show_bug.cgi?id=173145
Summary Add API::IconDatabaseClient
Carlos Garcia Campos
Reported 2017-06-09 03:30:34 PDT
We will use this instead of the C API in GTK+.
Attachments
Patch (14.27 KB, patch)
2017-06-09 03:32 PDT, Carlos Garcia Campos
achristensen: review+
Carlos Garcia Campos
Comment 1 2017-06-09 03:32:54 PDT
Alex Christensen
Comment 2 2017-06-09 10:24:40 PDT
Comment on attachment 312418 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=312418&action=review > Source/WebKit2/UIProcess/WebIconDatabase.h:118 > + std::unique_ptr<API::IconDatabaseClient> m_client; I think this is wrong. Usually we have the API object own the WebKit namespace object.
Carlos Garcia Campos
Comment 3 2017-06-10 01:37:56 PDT
Comment on attachment 312418 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=312418&action=review >> Source/WebKit2/UIProcess/WebIconDatabase.h:118 >> + std::unique_ptr<API::IconDatabaseClient> m_client; > > I think this is wrong. Usually we have the API object own the WebKit namespace object. Could you point to an example? I think I've followed what all other objects do. - WebPageProxy in WebKit namespace owns API::LoaderClient, API::PolicyClient, API::NavigationClient, and a lot more clients - WebProcessPool in WebKit namespace owns API::AutomationClient, API::DownloadClient, API::LegacyContextHistoryClient and API::CustomProtocolManagerClient or did I misunderstand what you mean?
Alex Christensen
Comment 4 2017-06-12 09:59:28 PDT
Comment on attachment 312418 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=312418&action=review > Source/WebKit2/UIProcess/API/APIIconDatabaseClient.h:2 > + * Copyright (C) 2014 Apple Inc. All rights reserved. 2017 >>> Source/WebKit2/UIProcess/WebIconDatabase.h:118 >>> + std::unique_ptr<API::IconDatabaseClient> m_client; >> >> I think this is wrong. Usually we have the API object own the WebKit namespace object. > > Could you point to an example? I think I've followed what all other objects do. > > - WebPageProxy in WebKit namespace owns API::LoaderClient, API::PolicyClient, API::NavigationClient, and a lot more clients > - WebProcessPool in WebKit namespace owns API::AutomationClient, API::DownloadClient, API::LegacyContextHistoryClient and API::CustomProtocolManagerClient > > or did I misunderstand what you mean? After talking to some people, I now think this is correct. Sorry about the misunderstanding. API namespace objects own WebKit namespace objects, but clients pass calls in the opposite direction. This is correct. We should us a UniqueRef here because it's never null.
Carlos Garcia Campos
Comment 5 2017-06-12 10:04:47 PDT
(In reply to Alex Christensen from comment #4) > Comment on attachment 312418 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=312418&action=review > > > Source/WebKit2/UIProcess/API/APIIconDatabaseClient.h:2 > > + * Copyright (C) 2014 Apple Inc. All rights reserved. > > 2017 > > >>> Source/WebKit2/UIProcess/WebIconDatabase.h:118 > >>> + std::unique_ptr<API::IconDatabaseClient> m_client; > >> > >> I think this is wrong. Usually we have the API object own the WebKit namespace object. > > > > Could you point to an example? I think I've followed what all other objects do. > > > > - WebPageProxy in WebKit namespace owns API::LoaderClient, API::PolicyClient, API::NavigationClient, and a lot more clients > > - WebProcessPool in WebKit namespace owns API::AutomationClient, API::DownloadClient, API::LegacyContextHistoryClient and API::CustomProtocolManagerClient > > > > or did I misunderstand what you mean? > > After talking to some people, I now think this is correct. Sorry about the > misunderstanding. np, the whole thing is indeed confusing at first. > API namespace objects own WebKit namespace objects, but > clients pass calls in the opposite direction. This is correct. > We should us a UniqueRef here because it's never null. Didn't know UniqueRef, do you want me to change this patch before landing to use UniqueRef, or better do that in a follow up and switch all clients to UniqueRef?
Alex Christensen
Comment 6 2017-06-12 10:11:50 PDT
Switching all clients to UniqueRef would be nice.
Carlos Garcia Campos
Comment 7 2017-06-12 10:13:40 PDT
(In reply to Alex Christensen from comment #6) > Switching all clients to UniqueRef would be nice. Then I'll keep this simple and switch all clients in a follow up.
Carlos Garcia Campos
Comment 8 2017-06-12 10:19:35 PDT
Note You need to log in before you can comment on or make changes to this bug.