In general, we've avoided cross platform UI toolkits because while
they may offer what superficially appears to be a quick path to native
looking UI on a variety of target platforms, once you go a bit deeper
it turns out to be a bit more problematic. As Amanda says, your app
ends up "speaking with
This thread sounds really scary. Although it was initially claimed
that Chrome was designed to be cross-platform from the ground up, it's
obviously full of windows-isms at almost every level. Now it seems you
will be forced to maintain a separate UI port for each platform.
I sincerely wonder, why
On Wed, Feb 4, 2009 at 6:07 PM, Charles Reis wrote:
> This seems good-- I like the fact that the "chrome" parts of each extension
> are isolated from page content and have to use message passing. That will
> make it easier to understand which extensions actually need to access page
> content.
I
On Wed, Feb 4, 2009 at 6:07 PM, Charles Reis wrote:
> This seems good-- I like the fact that the "chrome" parts of each extension
> are isolated from page content and have to use message passing. That will
> make it easier to understand which extensions actually need to access page
> content.
>
This seems good-- I like the fact that the "chrome" parts of each extension
are isolated from page content and have to use message passing. That will
make it easier to understand which extensions actually need to access page
content.
One small wording question, just be sure I'm clear:
"Process se
I wrote up a short design doc covering what our extension process model will
look like. Feedback welcome.
http://dev.chromium.org/developers/design-documents/extensions/process-model
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups
In r9193, I made a change that will require you to force rebuild your
test_shell.pak file. You can either clobber your whole tree or
just delete all .pak files in your Hammer dir (find Hammer -name "*.pak"
| xargs rm) and rebuild.
I will try to fix the SCons dependencies so this doesn't happen i
On Wed, Feb 4, 2009 at 3:56 PM, Evan Martin wrote:
> Probably this one is good:
> http://code.google.com/p/chromium/wiki/LinuxBuild64Bit
> Since it's where we put all of the hacks you need to do for 64-bit.
Done
AGL
--~--~-~--~~~---~--~~
Chromium Developers ma
On Wed, Feb 4, 2009 at 3:22 PM, Brett Wilson wrote:
> Can you add this to the build page or some Linux environment setup page?
Probably this one is good:
http://code.google.com/p/chromium/wiki/LinuxBuild64Bit
Since it's where we put all of the hacks you need to do for 64-bit.
--~--~-~
On Wed, Feb 4, 2009 at 2:58 PM, Adam Langley wrote:
>
> If you've ever tried running strace on our binaries, you've probably
> noticed the Ubuntu version messes up a lot because it cannot decode
> the 32-bit structures correctly. For example:
> [pid 21205] <... recvmsg resumed> {msg_name(-11664)
If you've ever tried running strace on our binaries, you've probably
noticed the Ubuntu version messes up a lot because it cannot decode
the 32-bit structures correctly. For example:
[pid 21205] <... recvmsg resumed> {msg_name(-11664)=NULL,
msg_iov(18446693667973365760)=0x8254b28,
msg_controllen
On Wed, Feb 4, 2009 at 5:12 PM, cpu wrote:
>
> We don't launch renderers using LaunchApp, we use broker_service-
> >SpawnTarget(). I guess in other platforms that don't have a sandbox
> you can replace that for whatever you want.
>
> You can see BrowserRenderProcessHost::Init() for all the cruft
+1 to string16
I can't make performance or memory saving claims with a straight face
for any. We just don't process enough strings for us to matter.
On Feb 4, 9:57 am, Mike Belshe wrote:
> The big string area is webkit, of course. If webkit were 100% UTF-8
> already, we might take a different
Hmm, OK, I'll dig further. If ProcessUtil is anyhow not appropriate,
then it probably doesn't make sense to rewire it before looking at how
real renderers would be spawned.
-scott
On Wed, Feb 4, 2009 at 2:12 PM, cpu wrote:
>
> We don't launch renderers using LaunchApp, we use broker_service-
We don't launch renderers using LaunchApp, we use broker_service-
>SpawnTarget(). I guess in other platforms that don't have a sandbox
you can replace that for whatever you want.
You can see BrowserRenderProcessHost::Init() for all the cruft that we
need to launch a renderer, I don't see a good w
I think what you're describing is a list of uses for the tar file. I think
they are valid uses, but I would say thata) what you describe as problems
with the build system are not "build system" problems, they're more "the
tarball doesn't satisfy my usecase" problems. The tarball was not intended
to
I had a similar problem. I used an svn checkout. The entrire
third_party/cygwin directory went missing in the tarball.
Also, I suggest aria2c to download the tarball in the future which is
better than the browser.
On Feb 4, 10:33 am, Evan Martin wrote:
> On Wed, Feb 4, 2009 at 10:31 AM, noemata
2009/2/4 Paweł Hajdan Jr. :
> I recently tried to port chrome/browser/safe_browsing/protocol_manager.cc to
> Linux, but there's one problem. ProtocolManager uses hash_map of
> URLFetcher*-s, and GCC needs a hash function for it.
>
> I see many ways we can deal with that, and I discussed some of th
I recently tried to port chrome/browser/safe_browsing/protocol_manager.cc to
Linux, but there's one problem. ProtocolManager uses hash_map of
URLFetcher*-s, and GCC needs a hash function for it.
I see many ways we can deal with that, and I discussed some of them on irc
and in review. The result so
+1 for Renderer/PluginLauncher()
+1 for moving IPC out of /chrome/common, in very own library.
Stoyan
On Wed, Feb 4, 2009 at 11:30 AM, Scott Hess wrote:
>
> On Wed, Feb 4, 2009 at 11:10 AM, Thomas Van Lenten
> wrote:
>> On Wed, Feb 4, 2009 at 2:02 PM, Darin Fisher wrote:
>>> On Wed, Feb 4, 20
We talked about moving IPC out of chrome/common, but we should really only
do that if we have a consumer. Right now, it is only needed by Chrome, so
it would seem to be a "premature optimization" to spend time moving it
elsewhere.
-Darin
On Wed, Feb 4, 2009 at 12:35 PM, stoyan wrote:
> +1 for
On Wed, Feb 4, 2009 at 11:10 AM, Thomas Van Lenten
wrote:
> On Wed, Feb 4, 2009 at 2:02 PM, Darin Fisher wrote:
>> On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess wrote:
>>> [Reposting from wrong mailing list, sorry for dupe.]
>>>
>>> On Mac/Linux, IPC::Channel uses socketpairs (or in some cases na
On Wed, Feb 4, 2009 at 11:02 AM, Darin Fisher wrote:
> On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess wrote:
>> On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named
>> pipes), with one end passed through the spawn to the child process.
>> Right now the interfaces don't expose this de
On Wed, Feb 4, 2009 at 2:02 PM, Darin Fisher wrote:
> On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess wrote:
>
>>
>> [Reposting from wrong mailing list, sorry for dupe.]
>>
>> On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named
>> pipes), with one end passed through the spawn to the
On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess wrote:
>
> [Reposting from wrong mailing list, sorry for dupe.]
>
> On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named
> pipes), with one end passed through the spawn to the child process.
> Right now the interfaces don't expose this de
On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess wrote:
> Adam mentioned on the wrong-mailing-list version of this thread that
> it's accepted to wire file descriptors into fixed places. Either way,
> my goal is to make sure that launching Chrome-internal helper tasks is
> distinct from launching arb
[Reposting from wrong mailing list, sorry for dupe.]
On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named
pipes), with one end passed through the spawn to the child process.
Right now the interfaces don't expose this dependency, so I'm thinking
of refactoring things a bit to do so.
On Wed, Feb 4, 2009 at 10:31 AM, noemata wrote:
> Surely, it's not that hard to have three sets of archives that provide
> a complete snapshot of a working build environment. Internal to
> Google, you must gen these anyways, so what's the issue? All such
> archives should deliver a built versio
I had also assumed that the tar ball and SVN repository were
complete. Though I appreciate the arguments associated with the
manner in which the build process is implemented, ultimately it ends
up being self limiting. At present, there is no easy way to have
historical snapshots of working relea
I didn't ask for plans before touching views/, so maybe I'll start doing it
now. So, I'd have just two questions (if the answer is "Paweł, don't touch
browser/views for now" that's an answer too):
- what does it mean for base/keyboard_codes.h (I checked this in shortly
before the discussion about
[A bunch of the team met up yesterday to hammer out some decisions.]
I think we decided to try to not port the views system, but instead
borrow as much code as possible from on top of it.
Some considerations that I think played into it (I had argued for this
one, so I apologize if I mischaracter
The big string area is webkit, of course. If webkit were 100% UTF-8
already, we might take a different stance on this issue as well.
If it is our goal to get to UTF-8 everywhere, then laying the plumbing for
utf8 strings rather than string16 strings seems like the right thing to do.
Mike
On We
On Wed, Feb 4, 2009 at 9:35 AM, Dean McNamee wrote:
>
> On Wed, Feb 4, 2009 at 6:11 PM, Darin Fisher wrote:
> > The proposal was to search-n-replace std::wstring to string16. We would
> > have to invent a macro to replace L"" usage. Most usages of string
> literals
> > are in unit tests, so it
Trying to remember what came up along the discussion.
UTF16 is what Mac/win use, so there we can avoid a batch of conversions on
those two platforms. (Mac can take UTF8, but the system would still be
doing conversions to get things into a form it prefers)
Didn't someone say ICU needs things in 1
On Wed, Feb 4, 2009 at 6:11 PM, Darin Fisher wrote:
> The proposal was to search-n-replace std::wstring to string16. We would
> have to invent a macro to replace L"" usage. Most usages of string literals
> are in unit tests, so it doesn't seem to matter if there is cost associated
> with the ma
The proposal was to search-n-replace std::wstring to string16. We would
have to invent a macro to replace L"" usage. Most usages of string literals
are in unit tests, so it doesn't seem to matter if there is cost associated
with the macro.
My belief is that there isn't much fruit to be had by con
On Wed, Feb 4, 2009 at 6:53 AM, Dean McNamee wrote:
> I apologize for missing this discussion, I'm sure that I'm not seeing
> the entire picture and the pros of this argument. I mentioned before
> that I'm in support of utf-8 everywhere we can get it.
I lost this argument, so I will defer this
Hey Evan,
I apologize for missing this discussion, I'm sure that I'm not seeing
the entire picture and the pros of this argument. I mentioned before
that I'm in support of utf-8 everywhere we can get it.
We are obviously going to have platform specific code for the UI
(win32 / cocoa/objective-c
The end result here sounds good to me. Just a few side comments:
* If we ever set up a directory for baselines common to all Chromium
platforms, it should be called 'chromium'. This matches the WebKit side,
where they have mac-tiger, mac-leopard, and mac. In fact, the layout-test
script is alread
We could make fully self-sufficient tarballs, but then we'd need three
separate ones, since the three platforms have different dependencies. (Or
we'd need to stick Mac and Linux developers with downloading a bigger
tarball than they need.) I think it's fair to require a sync after
downloading the
40 matches
Mail list logo
