I added a comment to the bug describing how we have solved problems like
this in the past.
-Darin
On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman a...@google.com wrote:
Working through crbug.com/8384 (copy/paste), I've had a chance to look at
Chromium's current copy/paste system.
For those
OK, so there's this nifty SendWithTimeout on SyncChannel. Awesome. And
RenderViewHost just has to call it, just like it calls Send() today for
other calls.
This is where things are falling apart for me.
For Send(), RenderViewHost calls (via RWH) its Send(), which calls
RenderProcessHost's
We just pushed the Omaha config changes for 2.0.169.1 to become the new dev
channel release.
Thank you to everyone for your hard work!
Jon
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options,
It is really complicated. I don't think we should work on this now. Let's
get the rest of the high priority work out of the way, and then return to
this.
-Darin
On Thu, Mar 12, 2009 at 11:04 AM, Avi Drissman a...@google.com wrote:
OK, so there's this nifty SendWithTimeout on SyncChannel.
The only place that calls it in the browser process is
BrowserAccessbilityManager, which I'm guessing isn't critical for the ports
(it's actually disabled by default on our shipping builds).
success = members-render_widget_host_-process()-channel()-
SendWithTimeout(msg,
http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/api-pattern
I'm thinking about what the general pattern for the APIs we expose to
extensions should be. I've been leaning toward something that is quite
a bit of a departure from the style of the DOM and more
One comment regarding synchronous IPC (I presume this is from the extension
process to the renderer\browser process): I agree that synchronous IPC is
slower, and better to be async when possible. However, if it's used for
APIs that aren't called frequently (100 calls/s, as opposed to thousands or
Basically, what I wrote was a quick hack just because I was tired of
not seeing where links go, and someone will need to think about harder
what exact kinds of behaviors we want.
I don't exactly understand how it works on windows, except that the
status bubble can slide out of the main window
this seems wrong. surely you can create a top-level window that has no
window decorations. then you can just position that however you like. is
the problem with managing the z-order?
-darin
On Thu, Mar 12, 2009 at 2:11 PM, Evan Martin e...@chromium.org wrote:
Basically, what I wrote was a
OK.
I'm going to do it on the Mac as a child window, so it'll be bound to the
parent but still independent in positioning. Sounds like that plan is fine.
Thanks,
Avi
On Thu, Mar 12, 2009 at 5:11 PM, Evan Martin e...@chromium.org wrote:
Basically, what I wrote was a quick hack just because I
I see... there has to be a way with window manager hints to make this work
:-)
Anyways, this isn't the most important thing to worry about now, but it sure
is sad to lose out on such a cool feature of Chrome (that the status bar
won't obscure what the mouse is over).
-Darin
On Thu, Mar 12,
On Thu, Mar 12, 2009 at 2:34 PM, Darin Fisher da...@chromium.org wrote:
I see... there has to be a way with window manager hints to make this work
:-)
I hope so, too. I played around with it for a while in a test app,
and then decided that doing it Right was going to be a lot of effort
and
John graciously explained all this to me so I thought I'd write what I
know before I forget. Amanda/John, please correct me where I'm wrong!
Windowless plugins are designed to run directly within the rendering
pipeline. When WebKit wants to draw a region of the screen involving
the plugin it
I think it'd be very helpful to just copy paste it here:
http://dev.chromium.org/developers/design-documents/plugin-architecture
On Thu, Mar 12, 2009 at 3:38 PM, Evan Martin e...@chromium.org wrote:
John graciously explained all this to me so I thought I'd write what I
know before I forget.
Congratulations on entering the zeitgeist! It's certainly an exciting time
for web browsers and the web.
cheers,
mike
- Original Message -
From: chromium-dev@googlegroups.com chromium-dev@googlegroups.com
To: Chromium-dev chromium-dev@googlegroups.com
Sent: Thu Mar 12 16:55:41 2009
On Thu, Mar 12, 2009 at 4:55 PM, Daniel A. White dwh...@thetrueaplus.comwrote:
Thought I let you guys know. Amazing!
What was the answer? (I'm assuming the question was What is Google
Chrome?)
PK
--~--~-~--~~~---~--~~
Chromium Developers mailing list:
16 matches
Mail list logo
