[chromium-dev] Inline PDF Support
Hi guys, Are there any plans to support the viewing of PDF documents (inline/ natively) within chromium without the need for an external app/plugin like acrobat...i.e. kinda like how Safari does it on mac? alternatively, some manner of first converting them to PNG/HTML/etc? --~--~-~--~~~---~--~~ 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: Mac Dogfood Planning
I'll tackle breakpad support, if anyone else is already working on this, please ping me. Best regards, Jeremy On Mon, Mar 2, 2009 at 9:27 PM, Mike Pinkerton pinker...@chromium.orgwrote: As we're making rapid progress, I wanted to start to organize a little more around the 5 minute browser goal for the end of the quarter and see if we can better define what we want for our dogfood milestone. Here's a very quick list of things that I see us as needing in order to get to something that we can call dogfood: - bookmark bar - class/nib infrastructure for tab dragging, even if we don't drag tabs - history - cut/copy/paste - breakpad - HTML SELECT popups - page-cycler tests running on a bot and collecting stats - plug-ins in-process (out-of-process will probably be more difficult) Some other nice to have's, but I wouldn't consider these blocking for dogfood (probably a followup milestone, listed only to show I thought of them but didn't deem them important enough for inclusion in the primary dogfood milestone), include: - keychain integration - preferences - fancy omnibox functionality - improved UI from Cole - tab dragging - IME - out-of-process-plugins - ...the list goes on (printing, etc etc) First off, does the first list sound like the right list of things to be focusing on? Are there obvious things I'm missing? I'm sure there are. If these are the right things, we should probably reflect this work somewhere. The linux folks are using the bug system for their tasks. Some people don't mind this, others dislike the everything is a bug mentality. How do we want to capture the work so it's trackable externally? Personally I'm happy with bugs, I just know there are others that can't stand it. I went through the buglist of label:mac this morning and there's not too much on there that's top priority. I suggest we have a meeting tomorrow, similar to what the linux folks did, and triage the bugs (P1 = blocking dogfood, P2 = important for later, P3 = we'll get to it one day). Let's hold off picking what we're working on until we've agreed this is the right list. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] App Mode
Is there a design doc/notes/etc. for App Mode on Windows? I'm starting to look at it for the Mac because there could be some arch issues we'll have to deal w/, so I want to understand the Windows side first. TVL --~--~-~--~~~---~--~~ 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: App Mode
Short answer: no. But talk to me if you need to know more about the Chrome side. Some elements of it are implemented in Gears - specifically the shortcut creation step. -Ben On Tue, Mar 3, 2009 at 10:56 AM, Thomas Van Lenten thoma...@chromium.org wrote: Is there a design doc/notes/etc. for App Mode on Windows? I'm starting to look at it for the Mac because there could be some arch issues we'll have to deal w/, so I want to understand the Windows side first. TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Need an idiot's guide to GYP
I probably missed the email on the new Mac build system. (I was gypped!) So I went to http://dev.chromium.org/developers/quick-reference to try to learn how to add a file to the mac port. But alas, it just talks about xcodeproj. And of course, GMail search doesn't work, so I can't find any doc in email either. Probably more user-error on my part. Question: Can someone send consolidated instructions on how to use GYP to add files? Let me know if you want to update the wiki, or I will be happy to do so as well. Thanks! Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Linux TabStrip design doc 3-3-09
Hi,
We on the Linux team have settled on a TabStrip design that will allow
us to share as much code as possible without having to reimplement
Views, which would take a considerable amount of time and effort. The
TabStrip interfaces will be refactored to have cross-platform
super-classes and platform-specific subclasses. This split often
occurs where Views classes are pulled into the TabStrip interface.
This allows sharing of common code, such as tab animation. The
platform-specific code, for the most part, will be the implementation
of the UI for the tab strip. For example, the TabStrip class is
currently defined as:
class TabStrip : public views::View,
public TabStripModelObserver,
public Tab::TabDelegate,
public views::Button::ButtonListener,
public MessageLoopForUI::Observer {
The new super-class will be:
class TabStrip : public TabStripModelObserver,
public Tab::TabDelegate,
and the win subclass:
class TabStripWin : public views::View,
public views::Button::ButtonListener,
public MessageLoopForUI::Observer,
public TabStrip {
We are using the C interface for gtk, so the gtk variant TabStripGtk
will simply inherit from TabStrip. All of the UI needed by TabStrip
will be overridden and implemented using gtk.
On a higher level, the Linux tab strip will be implemented using a
gdkpixmap in a container, which allows fast blitting of the skbitmap
used by TabRenderer.
--
James Hawkins
--~--~-~--~~~---~--~~
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: Linux TabStrip design doc 3-3-09
Can you give a more detailed breakdown of the code/methods that'll be
moved to the shared base?
-Ben
On Tue, Mar 3, 2009 at 11:32 AM, James Hawkins jhawk...@chromium.org wrote:
Hi,
We on the Linux team have settled on a TabStrip design that will allow
us to share as much code as possible without having to reimplement
Views, which would take a considerable amount of time and effort. The
TabStrip interfaces will be refactored to have cross-platform
super-classes and platform-specific subclasses. This split often
occurs where Views classes are pulled into the TabStrip interface.
This allows sharing of common code, such as tab animation. The
platform-specific code, for the most part, will be the implementation
of the UI for the tab strip. For example, the TabStrip class is
currently defined as:
class TabStrip : public views::View,
public TabStripModelObserver,
public Tab::TabDelegate,
public views::Button::ButtonListener,
public MessageLoopForUI::Observer {
The new super-class will be:
class TabStrip : public TabStripModelObserver,
public Tab::TabDelegate,
and the win subclass:
class TabStripWin : public views::View,
public views::Button::ButtonListener,
public MessageLoopForUI::Observer,
public TabStrip {
We are using the C interface for gtk, so the gtk variant TabStripGtk
will simply inherit from TabStrip. All of the UI needed by TabStrip
will be overridden and implemented using gtk.
On a higher level, the Linux tab strip will be implemented using a
gdkpixmap in a container, which allows fast blitting of the skbitmap
used by TabRenderer.
--
James Hawkins
--~--~-~--~~~---~--~~
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: Linux TabStrip design doc 3-3-09
On Tue, Mar 3, 2009 at 11:36 AM, Ben Goodger (Google) b...@chromium.org wrote: Can you give a more detailed breakdown of the code/methods that'll be moved to the shared base? To be shared: * All of the TabAnimation classes. * The following methods: - GetPreferredHeight - CanProcessInputEvents - PointIsWithinWindowCaption, though we don't have a custom frame on linux yet - IsCompatibleWith - IsAnimating - model - IsDragSessionActive - AbortActiveDragSession - DestroyDragController - DestroyDraggedSourceTab - GetIdealBounds - UpdateLoadingAnimations - TabStripModelObserver implemenation - Tab::Delegate implemenation - GetTabAt - GetTabAtAdjustForAnimation - GetTabCount - GetCurrentTabWidths - GetDesiredTabWidths - ResizeLayoutTabs - all of the methods under the Animations section It's probably easier to look at it from the other side though, i.e. how much are we taking out of TabStrip? * The following inherited super-classes: - views::View - views::Button::ButtonListener - MessageLoopForUI::Observer * Any platform-specific code, usually Views overrides. -- James Hawkins --~--~-~--~~~---~--~~ 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: Need an idiot's guide to GYP
The answer to this question lies in the thread Let's make build system history. I've minimally updated the wiki page below. We should expand the gyp docs as it gets more mature. Mike On Tue, Mar 3, 2009 at 11:22 AM, Mike Belshe mbel...@google.com wrote: I probably missed the email on the new Mac build system. (I was gypped!) So I went to http://dev.chromium.org/developers/quick-reference to try to learn how to add a file to the mac port. But alas, it just talks about xcodeproj. And of course, GMail search doesn't work, so I can't find any doc in email either. Probably more user-error on my part. Question: Can someone send consolidated instructions on how to use GYP to add files? Let me know if you want to update the wiki, or I will be happy to do so as well. Thanks! Mike --~--~-~--~~~---~--~~ 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: Need an idiot's guide to GYP
I'm working on documenting everything this week. There's some stuff at http://code.google.com/p/gyp/w/list now. Mike Belshe wrote: I probably missed the email on the new Mac build system. (I was gypped!) So I went to http://dev.chromium.org/developers/quick-reference to try to learn how to add a file to the mac port. But alas, it just talks about xcodeproj. And of course, GMail search doesn't work, so I can't find any doc in email either. Probably more user-error on my part. Question: Can someone send consolidated instructions on how to use GYP to add files? Let me know if you want to update the wiki, or I will be happy to do so as well. --~--~-~--~~~---~--~~ 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: Linux TabStrip design doc 3-3-09
Because you're reusing display methods that retrieve metrics, I assume your tabstrip will have exactly the same bounds for itself and its contents as the windows one? -Ben On Tue, Mar 3, 2009 at 11:49 AM, James Hawkins jhawk...@chromium.org wrote: On Tue, Mar 3, 2009 at 11:36 AM, Ben Goodger (Google) b...@chromium.org wrote: Can you give a more detailed breakdown of the code/methods that'll be moved to the shared base? To be shared: * All of the TabAnimation classes. * The following methods: - GetPreferredHeight - CanProcessInputEvents - PointIsWithinWindowCaption, though we don't have a custom frame on linux yet - IsCompatibleWith - IsAnimating - model - IsDragSessionActive - AbortActiveDragSession - DestroyDragController - DestroyDraggedSourceTab - GetIdealBounds - UpdateLoadingAnimations - TabStripModelObserver implemenation - Tab::Delegate implemenation - GetTabAt - GetTabAtAdjustForAnimation - GetTabCount - GetCurrentTabWidths - GetDesiredTabWidths - ResizeLayoutTabs - all of the methods under the Animations section It's probably easier to look at it from the other side though, i.e. how much are we taking out of TabStrip? * The following inherited super-classes: - views::View - views::Button::ButtonListener - MessageLoopForUI::Observer * Any platform-specific code, usually Views overrides. -- James Hawkins --~--~-~--~~~---~--~~ 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: Linux TabStrip design doc 3-3-09
Yes that is the case. On Tue, Mar 3, 2009 at 1:57 PM, Ben Goodger (Google) b...@chromium.org wrote: Because you're reusing display methods that retrieve metrics, I assume your tabstrip will have exactly the same bounds for itself and its contents as the windows one? -Ben On Tue, Mar 3, 2009 at 11:49 AM, James Hawkins jhawk...@chromium.org wrote: On Tue, Mar 3, 2009 at 11:36 AM, Ben Goodger (Google) b...@chromium.org wrote: Can you give a more detailed breakdown of the code/methods that'll be moved to the shared base? To be shared: * All of the TabAnimation classes. * The following methods: - GetPreferredHeight - CanProcessInputEvents - PointIsWithinWindowCaption, though we don't have a custom frame on linux yet - IsCompatibleWith - IsAnimating - model - IsDragSessionActive - AbortActiveDragSession - DestroyDragController - DestroyDraggedSourceTab - GetIdealBounds - UpdateLoadingAnimations - TabStripModelObserver implemenation - Tab::Delegate implemenation - GetTabAt - GetTabAtAdjustForAnimation - GetTabCount - GetCurrentTabWidths - GetDesiredTabWidths - ResizeLayoutTabs - all of the methods under the Animations section It's probably easier to look at it from the other side though, i.e. how much are we taking out of TabStrip? * The following inherited super-classes: - views::View - views::Button::ButtonListener - MessageLoopForUI::Observer * Any platform-specific code, usually Views overrides. -- James Hawkins -- James Hawkins --~--~-~--~~~---~--~~ 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: Linux TabStrip design doc 3-3-09
OK. I understand what you're doing. I still don't understand then why given the identical rendering on Windows and Linux why is this approach easier than using Views/Canvas for that last 15% (rendering, hit testing)? Sorry to keep harping on this but the Mac display tree is totally different from the Windows one so I understand why it makes sense to have a lot of different code in that case. -Ben On Tue, Mar 3, 2009 at 2:02 PM, James Hawkins jhawk...@chromium.org wrote: Yes that is the case. On Tue, Mar 3, 2009 at 1:57 PM, Ben Goodger (Google) b...@chromium.org wrote: Because you're reusing display methods that retrieve metrics, I assume your tabstrip will have exactly the same bounds for itself and its contents as the windows one? -Ben On Tue, Mar 3, 2009 at 11:49 AM, James Hawkins jhawk...@chromium.org wrote: On Tue, Mar 3, 2009 at 11:36 AM, Ben Goodger (Google) b...@chromium.org wrote: Can you give a more detailed breakdown of the code/methods that'll be moved to the shared base? To be shared: * All of the TabAnimation classes. * The following methods: - GetPreferredHeight - CanProcessInputEvents - PointIsWithinWindowCaption, though we don't have a custom frame on linux yet - IsCompatibleWith - IsAnimating - model - IsDragSessionActive - AbortActiveDragSession - DestroyDragController - DestroyDraggedSourceTab - GetIdealBounds - UpdateLoadingAnimations - TabStripModelObserver implemenation - Tab::Delegate implemenation - GetTabAt - GetTabAtAdjustForAnimation - GetTabCount - GetCurrentTabWidths - GetDesiredTabWidths - ResizeLayoutTabs - all of the methods under the Animations section It's probably easier to look at it from the other side though, i.e. how much are we taking out of TabStrip? * The following inherited super-classes: - views::View - views::Button::ButtonListener - MessageLoopForUI::Observer * Any platform-specific code, usually Views overrides. -- James Hawkins -- James Hawkins --~--~-~--~~~---~--~~ 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: Linux TabStrip design doc 3-3-09
I chatted with Evan as well and he's said there's going to be linux-specific rendering in some components of the UI so that answers my question. -Ben On Tue, Mar 3, 2009 at 2:33 PM, James Hawkins jhawk...@chromium.org wrote: Our initial estimation is that it would take significantly longer to port what we need from Views than implementing what is needed by tabstrip with gtk directly. Most of our UI that's been brought up so far is directly implemented using gtk, so this design follows that pattern. On Tue, Mar 3, 2009 at 2:15 PM, Ben Goodger (Google) b...@chromium.org wrote: OK. I understand what you're doing. I still don't understand then why given the identical rendering on Windows and Linux why is this approach easier than using Views/Canvas for that last 15% (rendering, hit testing)? Sorry to keep harping on this but the Mac display tree is totally different from the Windows one so I understand why it makes sense to have a lot of different code in that case. -Ben On Tue, Mar 3, 2009 at 2:02 PM, James Hawkins jhawk...@chromium.org wrote: Yes that is the case. On Tue, Mar 3, 2009 at 1:57 PM, Ben Goodger (Google) b...@chromium.org wrote: Because you're reusing display methods that retrieve metrics, I assume your tabstrip will have exactly the same bounds for itself and its contents as the windows one? -Ben On Tue, Mar 3, 2009 at 11:49 AM, James Hawkins jhawk...@chromium.org wrote: On Tue, Mar 3, 2009 at 11:36 AM, Ben Goodger (Google) b...@chromium.org wrote: Can you give a more detailed breakdown of the code/methods that'll be moved to the shared base? To be shared: * All of the TabAnimation classes. * The following methods: - GetPreferredHeight - CanProcessInputEvents - PointIsWithinWindowCaption, though we don't have a custom frame on linux yet - IsCompatibleWith - IsAnimating - model - IsDragSessionActive - AbortActiveDragSession - DestroyDragController - DestroyDraggedSourceTab - GetIdealBounds - UpdateLoadingAnimations - TabStripModelObserver implemenation - Tab::Delegate implemenation - GetTabAt - GetTabAtAdjustForAnimation - GetTabCount - GetCurrentTabWidths - GetDesiredTabWidths - ResizeLayoutTabs - all of the methods under the Animations section It's probably easier to look at it from the other side though, i.e. how much are we taking out of TabStrip? * The following inherited super-classes: - views::View - views::Button::ButtonListener - MessageLoopForUI::Observer * Any platform-specific code, usually Views overrides. -- James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Unit tests and anonymous namespaces.
On the Mac, code like this:
namespace {
class MyTest : public testing::Test {
};
} // namespace
TEST_F(MyTest, ATest) {
}
generates errors like this:
warning: ‘MyTest_ATest_Test’ has a field
‘MyTest_ATest_Test::anonymous’ whose type uses the anonymous
namespace
warning: ‘MyTest_ATest_Test’ has a base ‘unnamed::MyTest’ whose type
uses the anonymous namespace
Removing the namespace fixes it, which is poor because we seem to want
to move towards more anonymous namespace use. Putting the test case
inside the namespace also fixes it, but is incompatible with
FRIEND_TEST(). This seems to be a gcc 4.2 addition, per:
http://gcc.gnu.org/gcc-4.2/changes.html
Members of the anonymous namespace are now local to a particular
translation unit, along with any other declarations which use them,
though they are still treated as having external linkage for language
semantics.
At this point, I'm sort of at the bleeding edge of my knowledge. For
FRIEND_TEST() cases, it seems like the anonymous namespace needs to
go, but elsewhere it can be changed to enclose the entire file. Does
that seem reasonable for now?
-scott
--~--~-~--~~~---~--~~
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: Unit tests and anonymous namespaces.
On Tue, Mar 3, 2009 at 3:55 PM, Scott Hess sh...@chromium.org wrote:
On the Mac, code like this:
namespace {
class MyTest : public testing::Test {
};
} // namespace
TEST_F(MyTest, ATest) {
}
generates errors like this:
warning: ‘MyTest_ATest_Test’ has a field
‘MyTest_ATest_Test::anonymous’ whose type uses the anonymous
namespace
warning: ‘MyTest_ATest_Test’ has a base ‘unnamed::MyTest’ whose type
uses the anonymous namespace
Removing the namespace fixes it, which is poor because we seem to want
to move towards more anonymous namespace use. Putting the test case
inside the namespace also fixes it, but is incompatible with
FRIEND_TEST(). This seems to be a gcc 4.2 addition, per:
http://gcc.gnu.org/gcc-4.2/changes.html
Members of the anonymous namespace are now local to a particular
translation unit, along with any other declarations which use them,
though they are still treated as having external linkage for language
semantics.
At this point, I'm sort of at the bleeding edge of my knowledge. For
FRIEND_TEST() cases, it seems like the anonymous namespace needs to
go, but elsewhere it can be changed to enclose the entire file. Does
that seem reasonable for now?
In this case the solution is easy. Erase the class MyTest definition
and use TEST instead of TEST_F.
Brett
--~--~-~--~~~---~--~~
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: Unit tests and anonymous namespaces.
On Tue, Mar 3, 2009 at 3:55 PM, Scott Hess sh...@chromium.org wrote:
On the Mac, code like this:
namespace {
class MyTest : public testing::Test {
};
} // namespace
TEST_F(MyTest, ATest) {
}
generates errors like this:
warning: ‘MyTest_ATest_Test’ has a field
‘MyTest_ATest_Test::anonymous’ whose type uses the anonymous
namespace
warning: ‘MyTest_ATest_Test’ has a base ‘unnamed::MyTest’ whose type
uses the anonymous namespace
Removing the namespace fixes it, which is poor because we seem to want
to move towards more anonymous namespace use. Putting the test case
inside the namespace also fixes it, but is incompatible with
FRIEND_TEST(). This seems to be a gcc 4.2 addition, per:
http://gcc.gnu.org/gcc-4.2/changes.html
Members of the anonymous namespace are now local to a particular
translation unit, along with any other declarations which use them,
though they are still treated as having external linkage for language
semantics.
At this point, I'm sort of at the bleeding edge of my knowledge. For
FRIEND_TEST() cases, it seems like the anonymous namespace needs to
go, but elsewhere it can be changed to enclose the entire file. Does
that seem reasonable for now?
-scott
Assuming that you really need to use TEST_F, then it would be unfortunate to
lose the anonymous namespace. The anonymous namespace has allowed us to
have short names for helper classes used by tests without fear of colliding
with other short names used by other tests. (We have had those kinds of
conflicts in the past.)
We don't use FRIEND_TEST that much. Maybe we can just use #ifdef UNIT_TEST
to expose class APIs to unit tests?
-Darin
--~--~-~--~~~---~--~~
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: Unit tests and anonymous namespaces.
My old team never really used FRIEND_TEST. We found it ugly that our
production code depended on test code. We typically used friended
Peer classes defined in the unittest file, but not in the anonymous
namespace. These are simple shims that provide access to the private
section. It also saves on having to FRIEND_TEST each individual test
as you add them. It looks like almost every time FRIEND_TEST is used,
it's used for multiple tests, not just a single one. I'm not sure how
much of a problem chrome has with build dependencies leading to
rebuilds, but it was very annoying in google projects to add a
FRIEND_TEST to a widely used .h file, thus forcing everyone to
rebuild, even though you're only adding a new test.
On Tue, Mar 3, 2009 at 4:30 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Mar 3, 2009 at 3:55 PM, Scott Hess sh...@chromium.org wrote:
On the Mac, code like this:
namespace {
class MyTest : public testing::Test {
};
} // namespace
TEST_F(MyTest, ATest) {
}
generates errors like this:
warning: ‘MyTest_ATest_Test’ has a field
‘MyTest_ATest_Test::anonymous’ whose type uses the anonymous
namespace
warning: ‘MyTest_ATest_Test’ has a base ‘unnamed::MyTest’ whose type
uses the anonymous namespace
Removing the namespace fixes it, which is poor because we seem to want
to move towards more anonymous namespace use. Putting the test case
inside the namespace also fixes it, but is incompatible with
FRIEND_TEST(). This seems to be a gcc 4.2 addition, per:
http://gcc.gnu.org/gcc-4.2/changes.html
Members of the anonymous namespace are now local to a particular
translation unit, along with any other declarations which use them,
though they are still treated as having external linkage for language
semantics.
At this point, I'm sort of at the bleeding edge of my knowledge. For
FRIEND_TEST() cases, it seems like the anonymous namespace needs to
go, but elsewhere it can be changed to enclose the entire file. Does
that seem reasonable for now?
-scott
Assuming that you really need to use TEST_F, then it would be unfortunate to
lose the anonymous namespace. The anonymous namespace has allowed us to
have short names for helper classes used by tests without fear of colliding
with other short names used by other tests. (We have had those kinds of
conflicts in the past.)
We don't use FRIEND_TEST that much. Maybe we can just use #ifdef UNIT_TEST
to expose class APIs to unit tests?
-Darin
--~--~-~--~~~---~--~~
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: Unit tests and anonymous namespaces.
That sounds like an even better solution, thanks!-Darin
On Tue, Mar 3, 2009 at 4:49 PM, William Chan (陈智昌) willc...@chromium.orgwrote:
My old team never really used FRIEND_TEST. We found it ugly that our
production code depended on test code. We typically used friended
Peer classes defined in the unittest file, but not in the anonymous
namespace. These are simple shims that provide access to the private
section. It also saves on having to FRIEND_TEST each individual test
as you add them. It looks like almost every time FRIEND_TEST is used,
it's used for multiple tests, not just a single one. I'm not sure how
much of a problem chrome has with build dependencies leading to
rebuilds, but it was very annoying in google projects to add a
FRIEND_TEST to a widely used .h file, thus forcing everyone to
rebuild, even though you're only adding a new test.
On Tue, Mar 3, 2009 at 4:30 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Mar 3, 2009 at 3:55 PM, Scott Hess sh...@chromium.org wrote:
On the Mac, code like this:
namespace {
class MyTest : public testing::Test {
};
} // namespace
TEST_F(MyTest, ATest) {
}
generates errors like this:
warning: ‘MyTest_ATest_Test’ has a field
‘MyTest_ATest_Test::anonymous’ whose type uses the anonymous
namespace
warning: ‘MyTest_ATest_Test’ has a base ‘unnamed::MyTest’ whose type
uses the anonymous namespace
Removing the namespace fixes it, which is poor because we seem to want
to move towards more anonymous namespace use. Putting the test case
inside the namespace also fixes it, but is incompatible with
FRIEND_TEST(). This seems to be a gcc 4.2 addition, per:
http://gcc.gnu.org/gcc-4.2/changes.html
Members of the anonymous namespace are now local to a particular
translation unit, along with any other declarations which use them,
though they are still treated as having external linkage for language
semantics.
At this point, I'm sort of at the bleeding edge of my knowledge. For
FRIEND_TEST() cases, it seems like the anonymous namespace needs to
go, but elsewhere it can be changed to enclose the entire file. Does
that seem reasonable for now?
-scott
Assuming that you really need to use TEST_F, then it would be unfortunate
to
lose the anonymous namespace. The anonymous namespace has allowed us to
have short names for helper classes used by tests without fear of
colliding
with other short names used by other tests. (We have had those kinds of
conflicts in the past.)
We don't use FRIEND_TEST that much. Maybe we can just use #ifdef
UNIT_TEST
to expose class APIs to unit tests?
-Darin
--~--~-~--~~~---~--~~
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: Unit tests and anonymous namespaces.
On Tue, Mar 3, 2009 at 4:49 PM, William Chan (陈智昌) willc...@chromium.org wrote: My old team never really used FRIEND_TEST. We found it ugly that our production code depended on test code. We typically used friended Peer classes defined in the unittest file, but not in the anonymous namespace. These are simple shims that provide access to the private section. It also saves on having to FRIEND_TEST each individual test as you add them. It looks like almost every time FRIEND_TEST is used, it's used for multiple tests, not just a single one. I'm not sure how much of a problem chrome has with build dependencies leading to rebuilds, but it was very annoying in google projects to add a FRIEND_TEST to a widely used .h file, thus forcing everyone to rebuild, even though you're only adding a new test. In some cases we make a class that derives from testing::Test a friend, and write pass-throughs there. I agree it's a good idea if we have many tests that need this for the same tested class. We don't have a whole lot of FRIEND_TESTs in the first place, so it probably isn't a big deal for us. Brett --~--~-~--~~~---~--~~ 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: Ideas from chromium-discuss that should be implementable as extensions (Message #1 of an infinite series)
And to make the first post more easily viewable, the hidden quoted text says: I've used google chrome as my main web browser for some time, because I like its simplicity and compact nature. nowadays everyone has, or is getting a widescreen computer monitor and google chrome is nice in that it saves alot of space vertically. When I'm browsing I notice that there is almost alway wasted space that is just used for filler on the left/right of webpages. I would like to see an option where i can move my bookmarks bar to the left hand side of the screen. Also, on my bookmarks bar i never use text, and only show icons, and it would be nice to have a little check mark option to just disable all text on bookmarks on the bar without having to delete all the text myself. --~--~-~--~~~---~--~~ 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: Inline PDF Support
On Tue, Mar 3, 2009 at 8:47 PM, DanielC dpc...@hotmail.com wrote: - Thanks for your reply. I was mainly just hoping we might get something for free with webkit, but it sounds like the PDF support in Safari is native OS support. Alas, I was hoping to find a simple PDF viewer or at least a royalty-free cross-platform PDF converter for a side- project I'm working on. Reader doesn't fit the bill as it's not customizable and full-blown Acrobat or the Acrobat SDK are too pricey. In the Linux world some people use Poppler: http://poppler.freedesktop.org/ Looks like it has build files for Windows too. --~--~-~--~~~---~--~~ 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: Inline PDF Support
On Wed, Mar 4, 2009 at 5:47 AM, DanielC dpc...@hotmail.com wrote: Hi Amanda, Thanks for your reply. I was mainly just hoping we might get something for free with webkit, but it sounds like the PDF support in Safari is native OS support. Alas, I was hoping to find a simple PDF viewer or at least a royalty-free cross-platform PDF converter for a side- project I'm working on. Reader doesn't fit the bill as it's not customizable and full-blown Acrobat or the Acrobat SDK are too pricey. Cheers, Daniel Not what you need, but Foxit is a lightweight PDF viewer. And the owners seems cool people and may let you redistribute it, If you ask nicelly. The next cool thing has to be to get KDE KPDF to compile for windows and runs standalone. I don't know if that feasible. (KDE can run on windows, but I don't know if KPDF can be made standalone). -- -- ℱin del ℳensaje. --~--~-~--~~~---~--~~ 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: Inline PDF Support
On Wed, Mar 4, 2009 at 8:16 AM, Tei oscar.vi...@gmail.com wrote: On Wed, Mar 4, 2009 at 5:47 AM, DanielC dpc...@hotmail.com wrote: Hi Amanda, Thanks for your reply. I was mainly just hoping we might get something for free with webkit, but it sounds like the PDF support in Safari is native OS support. Alas, I was hoping to find a simple PDF viewer or at least a royalty-free cross-platform PDF converter for a side- project I'm working on. Reader doesn't fit the bill as it's not customizable and full-blown Acrobat or the Acrobat SDK are too pricey. Cheers, Daniel Not what you need, but Foxit is a lightweight PDF viewer. And the owners seems cool people and may let you redistribute it, If you ask nicelly. The next cool thing has to be to get KDE KPDF to compile for windows and runs standalone. I don't know if that feasible. (KDE can run on windows, but I don't know if KPDF can be made standalone). postdata: A poor man solution can be to convert a PDF to images with ImageMagick, and use a html viewer for these images, much like a gallery viewer. This is a half a solution because you will be forced to write the interface part yourself. IM can work as a library, and is multiplatform. -- -- ℱin del ℳensaje. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
