Most platforms (meaning not Chrome) have the ability, when the user pulls down a menu, to adjust the states of the menu items within. For them, when the user selects the Edit menu, they're OK calling into WebCore and asking the Editor canCopy(), canPaste(), etc.
We're pretty much the only ones decoupling the UI from WebCore to the extent that we disallow blocking. With that design, we're forced to have WebCore (or at least glue/) bubble up state changes. Compared to just asking WebCore at the time of need, having state change notifications is more inefficient. I think it's worth paying the price. But it might be a harder sell to upstream. Avi On Wed, Mar 11, 2009 at 1:21 PM, Brett Wilson <[email protected]> wrote: > On Tue, Mar 10, 2009 at 7:44 AM, Avi Drissman <[email protected]> wrote: > > I actually don't know. It seems like just simple state gathering but it > > might be more. > > > > The big concern is that it fits our model but no one else's. Everyone > else > > is OK with the UI asking the renderer questions directly, and as that's > more > > efficient than doing status updates that are going to be ignored 99.44% > of > > the time, I'm not sure they have incentive. > > I'm not sure what you mean by this. What is everyone OK with? > > Brett > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
