[chromium-dev] A note to the Chromium Authors
Dear Chromium Authors, We, at RealWat Inc., are proud to announce the beta release of the Ti- Took™ platform. Ti-Took is a safe web browsing software solution that integrates innovative technologies to deliver a fast, safe, easy and personalized web experience. Named after the tuk-tuk vehicles that carry riders anywhere all day long in east Asian cities and towns, Ti-Took is a simple, trustworthy way of navigating the complex and often dangerous world of the internet. We are happy to announce that Ti-Took™ Nuage web browser is based on Google Chromium open-source code. Ti-Took™ Nuage was originally designed using other web toolkit. However, after Google released the Chrome browser and source code, we immediately fall in love with its technology and design, and has since adopted it as our web browser framework. We prefer Google Chrome over alternative solutions for many other reasons, but mostly because it fills our requirements and direction where we see the web browser model moving forward. We hope we will collaborate to enrich both Google Chromium and Ti-Took Nuage. Best Regards, Ti-Took Authors Press Release: http://www.titook.org/blog/?p=523 Our sites: www.titook.net www.realwat.com On Twitter: http://twitter.com/ http://twitter.com/realwat http://twitter.com/DavineDC --~--~-~--~~~---~--~~ 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: A note to the Chromium Authors
Cool! Would you mind summarizing the technical differences with Chromium? Looking through the features list I see some that are probably us (fast browser start), others that are you (social bookmarking), and others I'm not sure about (privacy browsing -- some sort of encrypted proxy for wifi users?). Do you plan to contribute any of your changes back to us? On Mon, Jul 27, 2009 at 8:27 AM, Titookvarma...@gmail.com wrote: Dear Chromium Authors, We, at RealWat Inc., are proud to announce the beta release of the Ti- Took™ platform. Ti-Took is a safe web browsing software solution that integrates innovative technologies to deliver a fast, safe, easy and personalized web experience. Named after the tuk-tuk vehicles that carry riders anywhere all day long in east Asian cities and towns, Ti-Took is a simple, trustworthy way of navigating the complex and often dangerous world of the internet. We are happy to announce that Ti-Took™ Nuage web browser is based on Google Chromium open-source code. Ti-Took™ Nuage was originally designed using other web toolkit. However, after Google released the Chrome browser and source code, we immediately fall in love with its technology and design, and has since adopted it as our web browser framework. We prefer Google Chrome over alternative solutions for many other reasons, but mostly because it fills our requirements and direction where we see the web browser model moving forward. We hope we will collaborate to enrich both Google Chromium and Ti-Took Nuage. Best Regards, Ti-Took Authors Press Release: http://www.titook.org/blog/?p=523 Our sites: www.titook.net www.realwat.com On Twitter: http://twitter.com/ http://twitter.com/realwat http://twitter.com/DavineDC --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] clobber-free gyp makefile generator
I just checked in a change to gyp to make the Makefile generator understand command-line dependencies. That means that a given target should now be rebuilt if its command line changes, which means that you shouldn't ever need to clobber anymore. (Previously, you would sometimes need to do some sort of find out -name *.a | xargs rm.) If you encounter a situation where clobbering seems necessary, please contact me if you wouldn't mind helping me debug it. If you run into trouble, grab a version of gyp before r559 or manually back out that change. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] auto-hide bookmarks bar
I hope it's ok to post this in this groupmy apologies if it's not. I really like the fact that the bookmark bar is seen only in the new tab page by default. Would it be possible to have the bookmark bar become visible when you move over to the navigation bar at the top of the screen. This would keep the screen decluttered by not showing the bookmarks bar when you don't need it but at the same time a person wouldn't have to go to the home page every time they wanted to access their bookmarks. The auto-hiding feature would also be helpful when toolbars are added to chrome as 3rd party toolbars would only be visible when a person really needed them. --~--~-~--~~~---~--~~ 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: Design Doc: Adaptive spell checking for multilingual users
if both dictionaries are not recognizing a word and only one of them suggests a correction (which will be a very common case for Hebrew users i am sure) - i rather not see a submenu in that case - it's one more click which isn't needed some sort of title item in the context menu can be added to indicate the language source in that case maybe... or a leading [Hebrew] string before the word? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] CMake for chromium
Why don't we use CMake for chromium's build system? It would ease the pain on for example xcode or kdevelop users. I think i'll work on studying the current build system to figure out how to implement a CMake one. --~--~-~--~~~---~--~~ 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: CMake for chromium
pjwaffle wrote: Why don't we use CMake for chromium's build system? It would ease the pain on for example xcode or kdevelop users. Because we have GYP, which eases the pain on Xcode, Visual Studio, SCons, and make users. We developed GYP specifically to meet Chromium's needs. We did consider CMake and even did some prototypes with it, but there were several areas where it wasn't able to meet our needs squarely. More on GYP: http://groups.google.com/group/chromium-dev/browse_thread/thread/7b881a18437fa320/ . Also, a recent thread on webkit-dev about GYP, WebKit, and Chromium touched on CMake: https://lists.webkit.org/pipermail/webkit-dev/2009-July/008881.html . I think i'll work on studying the current build system to figure out how to implement a CMake one. That's fine. Let us (including me) know what you come up with. Mark --~--~-~--~~~---~--~~ 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: CMake for chromium
On Mon, Jul 27, 2009 at 11:53 AM, Mark Mentovaim...@chromium.org wrote: I think i'll work on studying the current build system to figure out how to implement a CMake one. That's fine. Let us (including me) know what you come up with. In particular, a CMake backend for gyp might be cool. - Dan --~--~-~--~~~---~--~~ 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: CMake for chromium
On Mon, Jul 27, 2009 at 11:58 AM, Dan Kegeld...@kegel.com wrote: On Mon, Jul 27, 2009 at 11:53 AM, Mark Mentovaim...@chromium.org wrote: I think i'll work on studying the current build system to figure out how to implement a CMake one. That's fine. Let us (including me) know what you come up with. In particular, a CMake backend for gyp might be cool. hopefully dubbed mygyp for make your gyp files - Dan --~--~-~--~~~---~--~~ 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: auto-hide bookmarks bar
On Mon, Jul 27, 2009 at 11:51 AM, Peter Kastingpkast...@google.com wrote: On Fri, Jul 24, 2009 at 3:40 PM, David spam.free...@gmail.com wrote: I really like the fact that the bookmark bar is seen only in the new tab page by default. Would it be possible to have the bookmark bar become visible when you move over to the navigation bar at the top of the screen. From a UX perspective, I think this would make the UI very flickery. Because the auto-hide trigger region would be in the middle of the Chrome window (i.e. below the address bar), every time you needed to do anything with any of the browser chrome the bar would open and close. Plus, this would cause a page relayout. Therefore I think we should not do this. agreed. Just press ctrl+b whenever you want the bar. PK --~--~-~--~~~---~--~~ 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: CMake for chromium
On Mon, Jul 27, 2009 at 1:59 PM, Evan Stadeest...@chromium.org wrote: On Mon, Jul 27, 2009 at 11:58 AM, Dan Kegeld...@kegel.com wrote: On Mon, Jul 27, 2009 at 11:53 AM, Mark Mentovaim...@chromium.org wrote: I think i'll work on studying the current build system to figure out how to implement a CMake one. That's fine. Let us (including me) know what you come up with. In particular, a CMake backend for gyp might be cool. hopefully dubbed mygyp for make your gyp files (or would that be a gyp backend for cmake? I'm confused) - Dan --~--~-~--~~~---~--~~ 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: Getting Started with a New Project
That I am not too sure about. Perhaps someone from the UI team could assist
you with this one, or someone who is familiar with the Views framework?
-Original Message-
From: chromium-dev@googlegroups.com [mailto:chromium-...@googlegroups.com]
On Behalf Of Kruncher
Sent: Sunday, July 26, 2009 6:34 PM
To: Chromium-dev
Subject: [chromium-dev] Re: Getting Started with a New Project
Excellent, I am almost there now.
I have looked through several of the Chromium projects, but I cannot
see how they are specifying additional libs. Which libs are needed to
make this link?
Thanks again for your help!
On 26 July, 21:52, Juan Baez tux...@gmail.com wrote:
You are not missing any header files. Windows has its own definition of
min
and max, and so does the STL library. So to avoid conflict between the
two,
define the preprocessor directive NOMINMAX in your project.
-Original Message-
From: chromium-dev@googlegroups.com [mailto:chromium-...@googlegroups.com]
On Behalf Of Kruncher
Sent: Sunday, July 26, 2009 2:48 PM
To: Chromium-dev
Subject: [chromium-dev] Re: Getting Started with a New Project
What you have suggested seems to have solved the header file issue,
unfortunately I am now getting the following errors:
1c:\chromium\src\views\view.h(161) : error C2589: '(' : illegal token
on right side of '::'
1c:\chromium\src\views\view.h(161) : error C2059: syntax error : '::'
1c:\chromium\src\views\view.h(161) : error C2589: '(' : illegal token
on right side of '::'
There must be another header or definition that I am missing.
Here is a snapshot of the code where the errors are being encountered:
void SetBounds(int x, int y, int width, int height) {
SetBounds(gfx::Rect(x, y, std::max(0, width), std::max(0,
height))); // IT IS THIS LINE ***
}
Chromium seems to be undergoing some pretty major changes at the
moment.
Many thanks,
Lea Hayes
On 26 July, 04:48, Juan Baez tux...@gmail.com wrote:
After some research and SVN history browsing I found out that
ChromiumCanvas is no more. Instead, use the gfx::Canvas class. Your
header files should look somewhat like this (for the example to
compile):
#include app/gfx/canvas.h
#include views/view.h
#include views/controls/label.h
#include views/window/window.h
#include views/window/window_delegate.h
Hope that helps a little.
On Jul 25, 8:34 pm, Juan Baez tux...@gmail.com wrote:
Where you able to figure this out Kruncher? If so, could you provide
me with some feedback as to how you resolved the problem? I am sort of
trying to do something similar myself.
On Jul 20, 2:41 am, Kruncher leaha...@gmail.com wrote:
Yes, I tried adding thatprojectbut it didn't seem to help.
On 19 July, 20:49, Thiago Farina thiago.far...@gmail.com wrote:
Did you added the commonprojectto your solution?
On Jul 19, 12:40 pm, Kruncher leaha...@gmail.com wrote:
For the purposes of practice I am trying to create an empty
Win32
Exe
projectthat uses the demonstration code from:
http://dev.chromium.org/developers/design-documents/chromeviews
To do this I have created a new solution and an emptyproject. I
have
then added the demonstration code, and in theprojectsettings
added
the additional include/lib directories (which I copied from an
Exe
projectfrom the Chromium trunk).
However, when I try to build theproject, I get the following
compilation error:
1c:\chromium\src\quick_test\quick_test\views\main_window.cc(4)
:
fatal error C1083: Cannot open include file: 'chrome/common/gfx/
chrome_canvas.h': No such file or directory
What steps are required to create a new solution/projectof this
nature? I would really like to use the views API that Chromium
has
to
offer.
Many thanks,
Lea Hayes
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Layout test failures from WebKit merge 45873:45916
http://code.google.com/p/chromium/issues/detail?id=17015 was the layout failures from a merge, and I got assigned them because I'd checked in a small Mac-only change. Turns out that many of them are due to the failure to red-dotted-underline misspelled words and slight differences in the selection glow. Anyone hear about a change upstream that would cause something like that? Eyeballing the relevant changes in the WebKit SVN server doesn't yield anything that would look like it would do that. Avi --~--~-~--~~~---~--~~ 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: A note to the Chromium Authors
Please could you try again. We just bring it live today. :) Sorry for any inconvenient. Regards, Ti-Took Team On Jul 27, 11:52 am, PhistucK phist...@gmail.com wrote: I tried downloading it, but waited about ten seconds and the download will not start.Pass... ☆PhistucK On Mon, Jul 27, 2009 at 18:27, Titook varma...@gmail.com wrote: Dear Chromium Authors, We, at RealWat Inc., are proud to announce the beta release of the Ti- Took™ platform. Ti-Took is a safe web browsing software solution that integrates innovative technologies to deliver a fast, safe, easy and personalized web experience. Named after the tuk-tuk vehicles that carry riders anywhere all day long in east Asian cities and towns, Ti-Took is a simple, trustworthy way of navigating the complex and often dangerous world of the internet. We are happy to announce that Ti-Took™ Nuage web browser is based on Google Chromium open-source code. Ti-Took™ Nuage was originally designed using other web toolkit. However, after Google released the Chrome browser and source code, we immediately fall in love with its technology and design, and has since adopted it as our web browser framework. We prefer Google Chrome over alternative solutions for many other reasons, but mostly because it fills our requirements and direction where we see the web browser model moving forward. We hope we will collaborate to enrich both Google Chromium and Ti-Took Nuage. Best Regards, Ti-Took Authors Press Release: http://www.titook.org/blog/?p=523 Our sites: www.titook.net www.realwat.com On Twitter: http://twitter.com/ http://twitter.com/realwat http://twitter.com/DavineDC --~--~-~--~~~---~--~~ 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: A note to the Chromium Authors
Evan, There are not much difference with the Chromium source code, apart we added features which allow Nuage (based on Chromium) to talk with our Ti-Took Dashboard and to perform bookmarking online with the Ti-Took Web Services. We also added an automatic/periodic bookmarks import from Firefox/IE and Chrome, thus making Ti-Took a centralized bookmarks repository. We also made some fixes, the major one is to allow disabling JAVASCRIPT for different instance of Chromium. Our goal is provide end users a better browsing experience, hence end user could use Chrome, as well as Nuage, Firefox or IE. Therefore, we are not concentrating specifically on web browser functionalities, but rather on those that complements them. We are concentrating specifically on network protection(future release) and user privacy. In short, here's some functions we are working on: -Web traffic routed through a dedicated proxy server (SSL or VPN) -Internet Safety embedded inside the Dashboard -Themes manager -One Bookmarklet web app called Ti-Zapplet (http://www.titook.net/ tizapplet?view=classic) -Roaming profile for major web browsers (Chrome andFirefox) Concerning your questions: (fast browser start) Yes, it's the Chromium Authors who should take all the merit. What we meant here is that the Dashboard allows you to start Ti-Took Nuage in different mode very rapidly, within a specific user context. That's where our contribution come into the picture. privacy browsing What this means is that when a user login into Ti-Took, Ti-Took creates a profile for that specific user. There are no chance of conflict between two different users on the same system. If the Chromium team likes some of the features provided by Ti-Took, we will be pleased to help and contribute back to the Chromium Community. :) We could not thanks enough the great work you guys did with Chromium. Our team could not take any merits on what you did. Ti-Took is not a replacement to Chromium, it's rather a complementary tool. Regards, Ti-Took Team Twitter: @RealWat On Jul 27, 11:56 am, Evan Martin e...@chromium.org wrote: Cool! Would you mind summarizing the technical differences with Chromium? Looking through the features list I see some that are probably us (fast browser start), others that are you (social bookmarking), and others I'm not sure about (privacy browsing -- some sort of encrypted proxy for wifi users?). Do you plan to contribute any of your changes back to us? On Mon, Jul 27, 2009 at 8:27 AM, Titookvarma...@gmail.com wrote: Dear Chromium Authors, We, at RealWat Inc., are proud to announce the beta release of the Ti- Took™ platform. Ti-Took is a safe web browsing software solution that integrates innovative technologies to deliver a fast, safe, easy and personalized web experience. Named after the tuk-tuk vehicles that carry riders anywhere all day long in east Asian cities and towns, Ti-Took is a simple, trustworthy way of navigating the complex and often dangerous world of the internet. We are happy to announce that Ti-Took™ Nuage web browser is based on Google Chromium open-source code. Ti-Took™ Nuage was originally designed using other web toolkit. However, after Google released the Chrome browser and source code, we immediately fall in love with its technology and design, and has since adopted it as our web browser framework. We prefer Google Chrome over alternative solutions for many other reasons, but mostly because it fills our requirements and direction where we see the web browser model moving forward. We hope we will collaborate to enrich both Google Chromium and Ti-Took Nuage. Best Regards, Ti-Took Authors Press Release: http://www.titook.org/blog/?p=523 Our sites: www.titook.net www.realwat.com On Twitter: http://twitter.com/ http://twitter.com/realwat http://twitter.com/DavineDC --~--~-~--~~~---~--~~ 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: fighting the flakiness - resource bundle issues?
I'm going to try writing the hook, but I would first ask for advice. The hook syntax takes a filename pattern and a command. So I would have to create a new command (probably in src/tools), like clobber_generated_headers or something similar. And the tool itself does not get the list of changed files, so it has to clobber all of them, and have the list of files to be clobbered hardcoded. Do you see better solutions? --~--~-~--~~~---~--~~ 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: A note to the Chromium Authors
Whoops. You are using the Chrome ball when you should use the Chromium ball. The Chromium ball is shades of blue. The one you should use looks like this http://dev.chromium.org/_/rsrc/1220198801738/config/app/images/customLogo/customLogo.gif?revision=2 Jon On Mon, Jul 27, 2009 at 4:27 PM, RealWat varma...@gmail.com wrote: Please could you try again. We just bring it live today. :) Sorry for any inconvenient. Regards, Ti-Took Team On Jul 27, 11:52 am, PhistucK phist...@gmail.com wrote: I tried downloading it, but waited about ten seconds and the download will not start.Pass... ☆PhistucK On Mon, Jul 27, 2009 at 18:27, Titook varma...@gmail.com wrote: Dear Chromium Authors, We, at RealWat Inc., are proud to announce the beta release of the Ti- Took™ platform. Ti-Took is a safe web browsing software solution that integrates innovative technologies to deliver a fast, safe, easy and personalized web experience. Named after the tuk-tuk vehicles that carry riders anywhere all day long in east Asian cities and towns, Ti-Took is a simple, trustworthy way of navigating the complex and often dangerous world of the internet. We are happy to announce that Ti-Took™ Nuage web browser is based on Google Chromium open-source code. Ti-Took™ Nuage was originally designed using other web toolkit. However, after Google released the Chrome browser and source code, we immediately fall in love with its technology and design, and has since adopted it as our web browser framework. We prefer Google Chrome over alternative solutions for many other reasons, but mostly because it fills our requirements and direction where we see the web browser model moving forward. We hope we will collaborate to enrich both Google Chromium and Ti-Took Nuage. Best Regards, Ti-Took Authors Press Release: http://www.titook.org/blog/?p=523 Our sites: www.titook.net www.realwat.com On Twitter: http://twitter.com/ http://twitter.com/realwat http://twitter.com/DavineDC --~--~-~--~~~---~--~~ 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: A note to the Chromium Authors
Thanks Jon, We are going to update our page as soon as possible! :) Cheers, Dave On Jul 27, 8:28 pm, Jon j...@chromium.org wrote: Whoops. You are using the Chrome ball when you should use the Chromium ball. The Chromium ball is shades of blue. The one you should use looks like thishttp://dev.chromium.org/_/rsrc/1220198801738/config/app/images/custom... Jon On Mon, Jul 27, 2009 at 4:27 PM, RealWat varma...@gmail.com wrote: Please could you try again. We just bring it live today. :) Sorry for any inconvenient. Regards, Ti-Took Team On Jul 27, 11:52 am, PhistucK phist...@gmail.com wrote: I tried downloading it, but waited about ten seconds and the download will not start.Pass... ☆PhistucK On Mon, Jul 27, 2009 at 18:27, Titook varma...@gmail.com wrote: Dear Chromium Authors, We, at RealWat Inc., are proud to announce the beta release of the Ti- Took™ platform. Ti-Took is a safe web browsing software solution that integrates innovative technologies to deliver a fast, safe, easy and personalized web experience. Named after the tuk-tuk vehicles that carry riders anywhere all day long in east Asian cities and towns, Ti-Took is a simple, trustworthy way of navigating the complex and often dangerous world of the internet. We are happy to announce that Ti-Took™ Nuage web browser is based on Google Chromium open-source code. Ti-Took™ Nuage was originally designed using other web toolkit. However, after Google released the Chrome browser and source code, we immediately fall in love with its technology and design, and has since adopted it as our web browser framework. We prefer Google Chrome over alternative solutions for many other reasons, but mostly because it fills our requirements and direction where we see the web browser model moving forward. We hope we will collaborate to enrich both Google Chromium and Ti-Took Nuage. Best Regards, Ti-Took Authors Press Release: http://www.titook.org/blog/?p=523 Our sites: www.titook.net www.realwat.com On Twitter: http://twitter.com/ http://twitter.com/realwat http://twitter.com/DavineDC --~--~-~--~~~---~--~~ 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: CMake for chromium
Nesting. CMake claims to be able to generate build configs in all sorts of formats, and so does gyp. It would just be fun to see CMake dancing to gyp's tune, or vice versa. But you're right, I don't think it'd be particularly useful. It'd be more interesting to understand the originally reported problem, pain on for example xcode or kdevelop users. What is the problem, again? Does the OP want xcode or kdevelop to run gyp when the user starts a build? On Mon, Jul 27, 2009 at 5:24 PM, Steven Knights...@google.com wrote: What's the coolness here? On Mon, Jul 27, 2009 at 11:58 AM, Dan Kegel d...@kegel.com wrote: In particular, a CMake backend for gyp might be cool. --~--~-~--~~~---~--~~ 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: CMake for chromium
Much encouragement to anyone that wants to implement a KDevelop generator. -Ben On Mon, Jul 27, 2009 at 5:34 PM, Dan Kegeld...@kegel.com wrote: Nesting. CMake claims to be able to generate build configs in all sorts of formats, and so does gyp. It would just be fun to see CMake dancing to gyp's tune, or vice versa. But you're right, I don't think it'd be particularly useful. It'd be more interesting to understand the originally reported problem, pain on for example xcode or kdevelop users. What is the problem, again? Does the OP want xcode or kdevelop to run gyp when the user starts a build? On Mon, Jul 27, 2009 at 5:24 PM, Steven Knights...@google.com wrote: What's the coolness here? On Mon, Jul 27, 2009 at 11:58 AM, Dan Kegel d...@kegel.com wrote: In particular, a CMake backend for gyp might be cool. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Adding a Custom Scheme
Hi,
I am trying to add a custom scheme to the Chromium browser. I am
trying to write a scheme that will transparently redirect requests to
another URL.
For some reason, however, my custom scheme does not appear to get
recognized. Could somebody tell me what I am doing wrong?
For the time being I have added the following code to the
chrome_exe_main.cc source.
//
// Added above the main Windows function.
//
#include net/url_request/url_request.h
#include net/url_request/url_request_http_job.h
static const char kCustomURLScheme[] = my-scheme;
class URLRequestCustomJob : public URLRequestJob {
public:
static URLRequestJob* Factory(URLRequest* request, const
std::string scheme) {
DCHECK(scheme == my-scheme);
// Redirect response to a local network resource.
std::string requestPath = request-url().PathForRequest().replace
(0, 10, http://192.168.1.4:8080;);
// I tried using the following line, but it turns out that the
Redirect function is protected.
//request-Redirect(GURL(requestPath), request-status().status());
// So instead I am attempting to create a new request.
request = new URLRequest(GURL(requestPath), request-delegate());
// Proceed with regular HTTP scheme factory.
return URLRequestHttpJob::Factory(request, http);
}
};
//
// Added above #if defined(GOOGLE_CHROME_BUILD) inside Windows main
function.
//
// Register custom scheme:
url_util::AddStandardScheme(kCustomURLScheme);
URLRequest::RegisterProtocolFactory(kCustomURLScheme,
URLRequestCustomJob::Factory);
Many thanks,
Lea Hayes
--~--~-~--~~~---~--~~
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: CMake for chromium
yea I noticed that KDevelop does intellisense much better than MS does intellisense (all I had to do was set the header includes path to src/, and it was essentially instant to parse the symbols). I'm not sure what the point of a generator for it would be though. What advantage is there to building in KDevelop rather than from terminal? -- Evan Stade On Mon, Jul 27, 2009 at 5:41 PM, Ben Goodger (Google)b...@chromium.org wrote: Much encouragement to anyone that wants to implement a KDevelop generator. -Ben On Mon, Jul 27, 2009 at 5:34 PM, Dan Kegeld...@kegel.com wrote: Nesting. CMake claims to be able to generate build configs in all sorts of formats, and so does gyp. It would just be fun to see CMake dancing to gyp's tune, or vice versa. But you're right, I don't think it'd be particularly useful. It'd be more interesting to understand the originally reported problem, pain on for example xcode or kdevelop users. What is the problem, again? Does the OP want xcode or kdevelop to run gyp when the user starts a build? On Mon, Jul 27, 2009 at 5:24 PM, Steven Knights...@google.com wrote: What's the coolness here? On Mon, Jul 27, 2009 at 11:58 AM, Dan Kegel d...@kegel.com wrote: In particular, a CMake backend for gyp might be cool. --~--~-~--~~~---~--~~ 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: CMake for chromium
Does the debugger integration work without the project files? -Ben On Mon, Jul 27, 2009 at 6:20 PM, Evan Stadeest...@chromium.org wrote: yea I noticed that KDevelop does intellisense much better than MS does intellisense (all I had to do was set the header includes path to src/, and it was essentially instant to parse the symbols). I'm not sure what the point of a generator for it would be though. What advantage is there to building in KDevelop rather than from terminal? -- Evan Stade On Mon, Jul 27, 2009 at 5:41 PM, Ben Goodger (Google)b...@chromium.org wrote: Much encouragement to anyone that wants to implement a KDevelop generator. -Ben On Mon, Jul 27, 2009 at 5:34 PM, Dan Kegeld...@kegel.com wrote: Nesting. CMake claims to be able to generate build configs in all sorts of formats, and so does gyp. It would just be fun to see CMake dancing to gyp's tune, or vice versa. But you're right, I don't think it'd be particularly useful. It'd be more interesting to understand the originally reported problem, pain on for example xcode or kdevelop users. What is the problem, again? Does the OP want xcode or kdevelop to run gyp when the user starts a build? On Mon, Jul 27, 2009 at 5:24 PM, Steven Knights...@google.com wrote: What's the coolness here? On Mon, Jul 27, 2009 at 11:58 AM, Dan Kegel d...@kegel.com wrote: In particular, a CMake backend for gyp might be cool. --~--~-~--~~~---~--~~ 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: Print Settings Mockup
Hi all, I am looking into this again, and we implemented the print: http://www.google.com; hookup functionality into chromium (ToT). So far it just shows a webpage. I am trying to figure out how we could bring the image in there, so I worked on this CL (http://codereview.chromium.org/159387) which introduces the concept of chrome://image/http://www.google.com;, where it fetches the image from the current tab and places it on the domui. I got the idea from another CL for extensions (http://codereview.chromium.org/144019). The problem is that, we can't rely on that approach because of the following (Gathered from extension code review comments): Aaron Boodman said: That is an interesting idea. There would be a few challenges, though: - We need a way to specify the desired format, size, etc. I guess they could be querystring params? - For printing in particular, it seems important to print the exact thing the user sees, not re-request the URL Without a solution to the second issue, I don't think the chrome:// URL idea is workable. But I do think that the code we used to implement this extension API could easily be reused for for print preview. Erik Kay stated: The way this code is currently written, it just grabs the backing store from the current visible tab. This means that it's the same size as the viewport on the visible tab, no new layout happens. Given this, I don't think this could be made to work with printing. The two obvious problems are the my browser width might not match paper width, and that anything that's outside of the viewport (scrolled) won't be visible in the preview. I really don't know how to bring over the printed image, maybe because I am inexperienced in the language, and I am asking for advice on what approach should I take? I want to reuse the same functionality of printing but what is the best way to bring that image into the DOMUI. I tired with the chrome://image/url approach, but as Erik and Aaron stated above, it wont work. If you guys have the UI mockup of the settings, I could implement that now, but since our previous comments, it is directly hooked up to the Print Preview. Any guidance is appreciated :) -- Mohamed Mansour On Tue, Jun 9, 2009 at 9:50 PM, Nick Baum nickb...@chromium.org wrote: On Fri, Jun 5, 2009 at 9:03 PM, Mohamed Mansour m0.interact...@gmail.comwrote: I really like the mock-up, when can you do one for Settings? I'll put it on our list, but I don't expect to get to this in the next couple of weeks. In general, we try not to block engineers on UI, so if you make good progress on the preview, we'll prioritize this higher. If we are going to include settings to this page (such as margins, headers, footers, etc), does that mean it would be per page? I was thinking of global printer settings which will be persistent. I don't know how that will fit this mock-up, or we could have both. We could have a dialog which sole purpose is for printer settings and the inline page for per page settings/preview customization. The inline page can have a link to the global settings if needed. I think the settings should just be global and sticky (just like default printer on the mac: it just uses the last one you used). Most people probably don't want to change print settings when they're not printing. That will seem to be too crowded, and my vision would be incorporating all this (preview and settings) into the same page. I am just wondering how the UI's team vision is, wrt to settings. Would be nice to see. We already started with Headers/Footers data persistence in a previous CL. And would like to have a UI that will let the user interact with such data instead of editing the Preference file directly. Later on we could start the print preview implementation, which I think is challenging. I think Ben's opinion was that the preferences would be hard to understand without the preview, so we should do the preview first. I can't comment on the difficulty of it :) -- Mohamed Mansour On Thu, Jun 4, 2009 at 9:12 PM, Nick Baum nickb...@chromium.org wrote: Hi guys, I've attached an old print settings mock up from Glen. I think it'd make a lot of sense to add the print settings on this page as well. If someone wants to take a stab at the print preview as pictured here, I think that'd be a great first step. Once we have that working, I'd be happy to mock up some ideas for settings. Cheers, -Nick On Thu, Jun 4, 2009 at 7:21 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: Most of the print preview will be implement in RenderView and friends which is in chrome/ ... (previously it was all in browser/ in fact) On Jun 4, 2009 10:04 AM, Mohamed Mansour m0.interact...@gmail.com wrote: I don't think so, it would be using the same infrastructure of history / downloads / and new tab page. Someone can correct me if I am wrong. -- Mohamed Mansour On Thu, Jun 4, 2009 at 9:43 AM, Marshall
[chromium-dev] Re: Print Settings Mockup
Don't we have to re-render the page for printing anyway, since many sites have print-specific CSS? -Nick On Mon, Jul 27, 2009 at 6:52 PM, Mohamed Mansour m0.interact...@gmail.comwrote: Hi all, I am looking into this again, and we implemented the print: http://www.google.com; hookup functionality into chromium (ToT). So far it just shows a webpage. I am trying to figure out how we could bring the image in there, so I worked on this CL (http://codereview.chromium.org/159387) which introduces the concept of chrome://image/http://www.google.com;, where it fetches the image from the current tab and places it on the domui. I got the idea from another CL for extensions (http://codereview.chromium.org/144019). The problem is that, we can't rely on that approach because of the following (Gathered from extension code review comments): Aaron Boodman said: That is an interesting idea. There would be a few challenges, though: - We need a way to specify the desired format, size, etc. I guess they could be querystring params? - For printing in particular, it seems important to print the exact thing the user sees, not re-request the URL Without a solution to the second issue, I don't think the chrome:// URL idea is workable. But I do think that the code we used to implement this extension API could easily be reused for for print preview. Erik Kay stated: The way this code is currently written, it just grabs the backing store from the current visible tab. This means that it's the same size as the viewport on the visible tab, no new layout happens. Given this, I don't think this could be made to work with printing. The two obvious problems are the my browser width might not match paper width, and that anything that's outside of the viewport (scrolled) won't be visible in the preview. I really don't know how to bring over the printed image, maybe because I am inexperienced in the language, and I am asking for advice on what approach should I take? I want to reuse the same functionality of printing but what is the best way to bring that image into the DOMUI. I tired with the chrome://image/url approach, but as Erik and Aaron stated above, it wont work. If you guys have the UI mockup of the settings, I could implement that now, but since our previous comments, it is directly hooked up to the Print Preview. Any guidance is appreciated :) -- Mohamed Mansour On Tue, Jun 9, 2009 at 9:50 PM, Nick Baum nickb...@chromium.org wrote: On Fri, Jun 5, 2009 at 9:03 PM, Mohamed Mansour m0.interact...@gmail.com wrote: I really like the mock-up, when can you do one for Settings? I'll put it on our list, but I don't expect to get to this in the next couple of weeks. In general, we try not to block engineers on UI, so if you make good progress on the preview, we'll prioritize this higher. If we are going to include settings to this page (such as margins, headers, footers, etc), does that mean it would be per page? I was thinking of global printer settings which will be persistent. I don't know how that will fit this mock-up, or we could have both. We could have a dialog which sole purpose is for printer settings and the inline page for per page settings/preview customization. The inline page can have a link to the global settings if needed. I think the settings should just be global and sticky (just like default printer on the mac: it just uses the last one you used). Most people probably don't want to change print settings when they're not printing. That will seem to be too crowded, and my vision would be incorporating all this (preview and settings) into the same page. I am just wondering how the UI's team vision is, wrt to settings. Would be nice to see. We already started with Headers/Footers data persistence in a previous CL. And would like to have a UI that will let the user interact with such data instead of editing the Preference file directly. Later on we could start the print preview implementation, which I think is challenging. I think Ben's opinion was that the preferences would be hard to understand without the preview, so we should do the preview first. I can't comment on the difficulty of it :) -- Mohamed Mansour On Thu, Jun 4, 2009 at 9:12 PM, Nick Baum nickb...@chromium.org wrote: Hi guys, I've attached an old print settings mock up from Glen. I think it'd make a lot of sense to add the print settings on this page as well. If someone wants to take a stab at the print preview as pictured here, I think that'd be a great first step. Once we have that working, I'd be happy to mock up some ideas for settings. Cheers, -Nick On Thu, Jun 4, 2009 at 7:21 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: Most of the print preview will be implement in RenderView and friends which is in chrome/ ... (previously it was all in browser/ in fact) On Jun 4, 2009 10:04 AM, Mohamed Mansour
[chromium-dev] Re: CMake for chromium
On Mon, Jul 27, 2009 at 6:24 PM, Ben Goodger (Google)b...@chromium.org wrote: Does the debugger integration work without the project files? -Ben have not tried. On Mon, Jul 27, 2009 at 6:20 PM, Evan Stadeest...@chromium.org wrote: yea I noticed that KDevelop does intellisense much better than MS does intellisense (all I had to do was set the header includes path to src/, and it was essentially instant to parse the symbols). I'm not sure what the point of a generator for it would be though. What advantage is there to building in KDevelop rather than from terminal? -- Evan Stade On Mon, Jul 27, 2009 at 5:41 PM, Ben Goodger (Google)b...@chromium.org wrote: Much encouragement to anyone that wants to implement a KDevelop generator. -Ben On Mon, Jul 27, 2009 at 5:34 PM, Dan Kegeld...@kegel.com wrote: Nesting. CMake claims to be able to generate build configs in all sorts of formats, and so does gyp. It would just be fun to see CMake dancing to gyp's tune, or vice versa. But you're right, I don't think it'd be particularly useful. It'd be more interesting to understand the originally reported problem, pain on for example xcode or kdevelop users. What is the problem, again? Does the OP want xcode or kdevelop to run gyp when the user starts a build? On Mon, Jul 27, 2009 at 5:24 PM, Steven Knights...@google.com wrote: What's the coolness here? On Mon, Jul 27, 2009 at 11:58 AM, Dan Kegel d...@kegel.com wrote: In particular, a CMake backend for gyp might be cool. --~--~-~--~~~---~--~~ 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: auto-hide bookmarks bar
On the other hand, if it has the auto hide mode, in this mode, it should not relayout the page, but float over and hide the portion on which it hovers while activated. ☆PhistucK On Mon, Jul 27, 2009 at 21:51, Peter Kasting pkast...@google.com wrote: On Fri, Jul 24, 2009 at 3:40 PM, David spam.free...@gmail.com wrote: I really like the fact that the bookmark bar is seen only in the new tab page by default. Would it be possible to have the bookmark bar become visible when you move over to the navigation bar at the top of the screen. From a UX perspective, I think this would make the UI very flickery. Because the auto-hide trigger region would be in the middle of the Chrome window (i.e. below the address bar), every time you needed to do anything with any of the browser chrome the bar would open and close. Plus, this would cause a page relayout. Therefore I think we should not do this. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
