[chromium-dev] Strange key conflict on Windows versions of Chrome, F1 with P, F2 with Q, F3 with R, F4 with S

[est]

Hi guys, I filed an issue here:

http://code.google.com/p/chromium/issues/detail?id=31048

The key conflict is very strange because it looks like terminal
function key escape codes

F1  ^[OP
F2  ^[OQ
F3  ^[OR
F4  ^[OS

Are there any terminal related source code mistakenly went into
Windows build of chrome?

(Special thanks to ferret at #chromium)

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Extension for context menu?

[est]

Hi chomium-dev,

When could we add context menu items in an extension? I really which
at least there would be something like FlashGot or DownloadThemAll for
Chrome.

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Re: browser/sync is moving in

[est]

Thanks for the explaination, Nick Carter.

I understand now, Chrome is a Google product while Chromium is a open-
source project.

Any thing else differs between Google Chrome and Chromium? I found
dictionaries missing from Chromium.

On Aug 18, 2:13 pm, Nick Carter  wrote:
> Hi est,
>
> If you happen to be using a Chromium (blue logo) build, then this is the
> expected behavior.  The feature is currently available as a preview via the
> Google Chrome dev channel, but not in Chromium branded builds.  Sync won't
> be usable in Chromium until we can build the feature entirely from source.
> To recap from Tim's email that started this thread:
>
> We've been working in a proprietary environment until now because of the
> dependency of having to build the complementary Google production server
> environment for syncing.  As such, the code uses a small number of internal
> libraries that we need to open-source or replace, as well as libraries that
> would be redundant to what Chromium already includes. . . . We do *not* plan
> on ever checking in the windows-only syncapi dll to the main chromium
> repository.  So until the dll is no longer needed, the public repository
> won't have all the bits to actually build Chromium with sync enabled.
>
> The glue code is out in the open already, and several of us are working on
> getting the sync engine library to build as a fully open source part of
> Chromium.
>
>  - nick
>
>
>
> On Mon, Aug 17, 2009 at 10:12 PM, est  wrote:
>
> > not working on 4.0.202.0 (23600)?
>
> > chrome.exe --enable-sync
>
> > On Aug 1, 5:07 am, Tim Steele  wrote:
> > > Hi!
>
> > > A bunch of us have been working on a feature to sync user data in
> > Chromium
> > > with a Google account.  (Surprise! :))  The great news is that we'll be
> > > starting to work directly in the Chromium project this week, and let me
> > tell
> > > you, are we excited to do that!  This email discusses how we're planning
> > to
> > > get started, in detail (maybe too much detail... sorry).
>
> > > We have built a library that implements the client side of our sync
> > > protocol<
> >http://sites.google.com/a/chromium.org/dev/developers/design-document...>,
> > > as well as the Google server-side infrastructure to serve Google Chrome
> > > users and synchronize data to their Google Account.  Of course, all the
> > code
> > > going into Chromium is open source, and the messages between the client
> > and
> > > server use the open protobuf <http://code.google.com/p/protobuf/> format
> > and
> > > library.  Check out the sync developer
> > > page<
> >http://sites.google.com/a/chromium.org/dev/developers/design-document...>
> > > if
> > > you're interested in low-level goals and technical details.
>
> > > We will be landing this code in a few steps rather than one giant
> > changelist
> > > for a number of reasons.  First, this makes reviewing a *lot* easier; it
> > > isn't the most straightforward code by nature, so the more fine grained
> > > scrutiny the code gets, the better.  Second, we've been working in a
> > > proprietary environment until now because of the dependency of having to
> > > build the complementary Google production server environment for syncing.
> > >  As such, the code uses a small number of internal libraries that we need
> > to
> > > open-source or replace, as well as libraries that would be redundant to
> > what
> > > Chromium already includes.  Removing these, and open sourcing the entire
> > > sync engine, is our highest priority and we expect this to take about
> > three
> > > weeks.
>
> > > So how will we commit the code in pieces and not totally hose the build
> > in
> > > the process?  First, a little more background.  You may have come across
> > the
> > > CHROME_PERSONALIZATION #define when digging through Chromium source code.
> > >  Right now, this is used in conjunction with a relatively small number of
> > > private c++ source files to conditionally build Chromium with sync
> > enabled.
> > >  These files are in fact a glue layer between Chromium and what is called
> > > the "syncapi", which is the bulk of the client library I was talking
> > about
> > > above.  On windows, syncapi is built into a DLL, and when
> > > CHROME_PERSONALIZATION is defined this DLL gets placed alongside
> > chrome.dll
> > > for use at runtime.  Syncapi builds and runs on Linux, but not M

[chromium-dev] Re: browser/sync is moving in

[est]

not working on 4.0.202.0 (23600)?

chrome.exe --enable-sync

On Aug 1, 5:07 am, Tim Steele  wrote:
> Hi!
>
> A bunch of us have been working on a feature to sync user data in Chromium
> with a Google account.  (Surprise! :))  The great news is that we'll be
> starting to work directly in the Chromium project this week, and let me tell
> you, are we excited to do that!  This email discusses how we're planning to
> get started, in detail (maybe too much detail... sorry).
>
> We have built a library that implements the client side of our sync
> protocol,
> as well as the Google server-side infrastructure to serve Google Chrome
> users and synchronize data to their Google Account.  Of course, all the code
> going into Chromium is open source, and the messages between the client and
> server use the open protobuf  format and
> library.  Check out the sync developer
> page
> if
> you're interested in low-level goals and technical details.
>
> We will be landing this code in a few steps rather than one giant changelist
> for a number of reasons.  First, this makes reviewing a *lot* easier; it
> isn't the most straightforward code by nature, so the more fine grained
> scrutiny the code gets, the better.  Second, we've been working in a
> proprietary environment until now because of the dependency of having to
> build the complementary Google production server environment for syncing.
>  As such, the code uses a small number of internal libraries that we need to
> open-source or replace, as well as libraries that would be redundant to what
> Chromium already includes.  Removing these, and open sourcing the entire
> sync engine, is our highest priority and we expect this to take about three
> weeks.
>
> So how will we commit the code in pieces and not totally hose the build in
> the process?  First, a little more background.  You may have come across the
> CHROME_PERSONALIZATION #define when digging through Chromium source code.
>  Right now, this is used in conjunction with a relatively small number of
> private c++ source files to conditionally build Chromium with sync enabled.
>  These files are in fact a glue layer between Chromium and what is called
> the "syncapi", which is the bulk of the client library I was talking about
> above.  On windows, syncapi is built into a DLL, and when
> CHROME_PERSONALIZATION is defined this DLL gets placed alongside chrome.dll
> for use at runtime.  Syncapi builds and runs on Linux, but not Mac (yet).
>
> With the initial checkin, we will leave the CHROME_PERSONALIZATION #define
> as-is, so the sync code will not be built by default.  We'll be working hard
> over the coming weeks to make sure the code passes all existing test suites
> that are part of the regular buildbot cycle, and on removing the #define.
>  After that, our hope is that we will be free of the DLL altogether and have
> all the code checked in to the repository, fully functional or not, in a few
> weeks.  We do *not* plan on ever checking in the windows-only syncapi dll to
> the main chromium repository.  So until the dll is no longer needed, the
> public repository won't have all the bits to actually build Chromium with
> sync enabled.  That said, we want to keep the sync build running smoothly,
> so we will use a combination of command-line flag (to enable sync) and
> delay-loading syncapi.dll only when it is needed.  This will allow the
> "glue" code to compile as part of the normal Chromium build without
> introducing a dependency on this dll, yet still make it possible to run with
> the dll present.
>
> On that note, we're planning to use the syncapi DLL to produce a
> sync-enabled Google Chrome build for dev-channel users in a week or so, to
> get the feature into experimentally inclined hands.  We have a great deal of
> infrastructure, both in the browser and in the form of production Google
> services, that need to start seeing real user traffic and usage.  It takes a
> great deal of testing and confidence inspired by real usage statistics
> before any complex system like this can be deemed adequate for use by a
> large user base.  So if we want to let all Google Chrome users use sync (and
> we do! we do!), we've got to get started on this pronto.
>
> Our developer 
> page
> also
> covers the hierarchy of files we're landing that you can expect to start
> syncing (in the gclient sense) down in the next couple of days.  We can't
> wait (*really*) to work on this with the rest of the Chromium community and
> going even further in creating the best browzr ever!
>
> Thanks for reading, and happy syncing!
>
> - the cloudy bunch
> {idana, nick, nickbaum, chee, munjal, brg, chron, zork, laforge, tejasshah,
> tim} at chromium.org
--~--~-~--~~---

[chromium-dev] Re: Memory usage in chrome

[est]

use --single-process

On Jun 21, 3:37 pm, n179911  wrote:
> Hi,
>
> There is a test which compares memory usage among rendering 
> engineshttp://dotnetperls.com/chrome-memory
>
> From the site, it shows the maximum memory usage of Chrome is more
> than Safari is > 2 times.
> Since both of them are Webkit base, does that mean the V8 engine uses
> twice as much memory as squirrel fish?
>
> --- Maximum memory used ---
>     Peak memory usage measured during experiment.
>
> Chrome:  1216.16 MB      [Largest]
> Firefox:  327.65 MB      [Smallest]
> Opera:    554.11 MB
> Safari:   517.00 MB
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---