[Webkit-unassigned] [Bug 35072] [Mac] Move Icon::iconForFiles() code to WebChromeClient::iconForFiles().

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=35072





--- Comment #4 from Eric Seidel <eric at webkit.org>  2010-02-18 11:32:09 PST ---
My apologies.  I clearly didn't read the other patch closely enough to realize
that code was moving from WebCore to WebKit.  I should have commented on that
before.  It's obvious looking back.

Mark is right, historically the wisdom is that moving things out of WebKIt and
into WebCore is a good thing.  Makes the code cross-plaform and shared among
more ports.  Every WebKIt layer is a porting burden.

Although your patch added a good feature (asynchronous icon loading), I think
that we may need to re-visit how it was done.

Why do we need any special per-platform code for "icon" loading.  Don't we
already have plenty of async code for loading data files?  Can't we load these
icons the same way we would load any other CachedImage file?

Ideally the asynchronous loading code could all be shared by all WebCore ports,
and only the individual "read the bits off disk" and "turn these icon bits into
an Image" would be per-port.  None of that seems like it needs to be in WebKit.

I guess the problem is that the OS might not actually be loading files
directly.  In the case of Mac OS X, the library APIs hand you back NSImage
pointers instead of any URL to load?  Is that correct?

Perhaps other platforms function the same in which case the *entire* load is
platform specific, and it may make sense to do the load entirely in the
platform-speicifc bits we call WebKit as you have done.

I think I've talked myself in circles.  Lunch time.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.