[chromium-dev] Re: Inline PDF Support
On Wed, Mar 4, 2009 at 8:16 AM, Tei wrote: > > > On Wed, Mar 4, 2009 at 5:47 AM, DanielC 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Inline PDF Support
On Wed, Mar 4, 2009 at 5:47 AM, DanielC 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 Tue, Mar 3, 2009 at 8:47 PM, DanielC 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
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 On Mar 3, 6:39 am, Amanda Walker wrote: > This is a lot easier to do on the Mac, where the OS includes PDF > display capabilities, though the Acrobat plugin is more full featured > even there, so it's a trade-off. > > What specific advantages are you looking for? > > --Amanda > > On Tue, Mar 3, 2009 at 3:01 AM, Daniel wrote: > > > 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: 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] [extensions] Ideas from chromium-discuss that should be implementable as extensions (Message #1 of an infinite series)
I'm just going to start forwarding these, since I know most of the relevant people are not on chromium-discuss :). These two ideas seem implementable if we had sidebar and toolstrip surfaces and an API that could drive/read the bookmark system. Interestingly, I just asserted today that there were few interesting uses cases for a bookmarks API. Ok, I guess one interesting case for all these sorts of automation type APIs is "I don't like the look/position/features/whatever of the built-in UI, and I want to replace it". - a -- Forwarded message -- From: emp Date: Tue, Mar 3, 2009 at 2:27 PM Subject: [chromium-discuss] quick and easy To: Chromium-discuss 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: Unit tests and anonymous namespaces.
On Tue, Mar 3, 2009 at 4:49 PM, William Chan (陈智昌) 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: 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 (陈智昌) 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.
>
> On Tue, Mar 3, 2009 at 4:30 PM, Darin Fisher wrote:
> > On Tue, Mar 3, 2009 at 3:55 PM, Scott Hess 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::’ whose type uses the anonymous
> >> namespace
> >> warning: ‘MyTest_ATest_Test’ has a base ‘::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 wrote:
> On Tue, Mar 3, 2009 at 3:55 PM, Scott Hess 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::’ whose type uses the anonymous
>> namespace
>> warning: ‘MyTest_ATest_Test’ has a base ‘::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 3:55 PM, Scott Hess 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::’ whose type uses the anonymous
> namespace
> warning: ‘MyTest_ATest_Test’ has a base ‘::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 3:55 PM, Scott Hess 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::’ whose type uses the anonymous
> namespace
> warning: ‘MyTest_ATest_Test’ has a base ‘::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] 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::’ whose type uses the anonymous
namespace
warning: ‘MyTest_ATest_Test’ has a base ‘::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: 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 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) > 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 wrote: >>> Yes that is the case. >>> >>> On Tue, Mar 3, 2009 at 1:57 PM, Ben Goodger (Google) >>> 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 wrote: > On Tue, Mar 3, 2009 at 11:36 AM, Ben Goodger (Google) > 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
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) 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 wrote: >> Yes that is the case. >> >> On Tue, Mar 3, 2009 at 1:57 PM, Ben Goodger (Google) >> 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 >>> wrote: >>> > On Tue, Mar 3, 2009 at 11:36 AM, Ben Goodger (Google) >>> > 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
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 wrote: > Yes that is the case. > > On Tue, Mar 3, 2009 at 1:57 PM, Ben Goodger (Google) > 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 wrote: >> > On Tue, Mar 3, 2009 at 11:36 AM, Ben Goodger (Google) >> > 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
Yes that is the case. On Tue, Mar 3, 2009 at 1:57 PM, Ben Goodger (Google) 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 wrote: > > On Tue, Mar 3, 2009 at 11:36 AM, Ben Goodger (Google) > > 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
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 wrote: > On Tue, Mar 3, 2009 at 11:36 AM, Ben Goodger (Google) > 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
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: 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 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: Linux TabStrip design doc 3-3-09
On Tue, Mar 3, 2009 at 11:36 AM, Ben Goodger (Google) 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
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 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] 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] 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] 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 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] 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: [Chrome-team] Re: --debug-children
[+chromium-dev] Ok this email reminded me that http://sites.google.com/a/chromium.org/dev/developers/how-tos/debugging really needed an overhaul. It cleaned it up and removed any reference to --debug-children. This flag should not be used (and should be removed). --wait-for-debugger-children should be favored instead, when needed. It's not an issue when not debugging a startup bug, read the reference to the .NET macro for more info. Yes, .NET. This is frightening but it won't hurt too much. I also added a reference to the symbols server. As Amit said, windbg -o always works. M-A On Tue, Mar 3, 2009 at 6:03 AM, Amit Joshi wrote: > try debugging with windbg -o > - Show quoted text - > > On Tue, Mar 3, 2009 at 2:12 AM, David Moore wrote: >> >> I discovered that --debug-children breaks handle sharing under Visual >> Studio, at least on Vista32. But --renderer-startup-dialog works, as long as >> you also specify --no-sandbox so that the MessageBox can be displayed. >> Dave >> >> On Mon, Mar 2, 2009 at 6:03 PM, David Moore wrote: >>> >>> I'm trying to track down something that only happens in multi-process. >>> When I run under the debugger with --debug-children I get a debug break. I >>> traced it down to a DuplicateHandle() failing with an access error. It's the >>> handle that's created in BrowserRenderProcessHost::InitVisitedLinks(), >>> sharing to the renderer. I'm running on Vista. Is this a config that's known >>> not to work? >>> Dave --~--~-~--~~~---~--~~ 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
This is a lot easier to do on the Mac, where the OS includes PDF display capabilities, though the Acrobat plugin is more full featured even there, so it's a trade-off. What specific advantages are you looking for? --Amanda On Tue, Mar 3, 2009 at 3:01 AM, Daniel wrote: > > 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 wrote: > > 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] 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 -~--~~~~--~~--~--~---
