[chromium-dev] Re: Rev 19669 and WebFrame::GetPrintPageShrink()
On Tue, Jul 7, 2009 at 7:25 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: On Mon, Jul 6, 2009 at 6:28 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Mon, Jul 6, 2009 at 6:09 PM, Darin Fisher da...@chromium.org wrote: I'm not sure what would be best. I was just describing the problem. It might help to setup a buildbot for chromiumembedded on the fyi page: http://build.chromium.org/buildbot/waterfall.fyi/waterfall That sounds like a good first step. Who should I talk to about getting this set up? Me or Nicolas. We could probably share it on a underused slave. Do you have an OS preference? We talked offline, and I'm planning to set it up on a unused windows slave. Nicolas --~--~-~--~~~---~--~~ 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: Rev 19669 and WebFrame::GetPrintPageShrink()
On Mon, Jul 6, 2009 at 6:28 PM, Marshall Greenblatt magreenbl...@gmail.comwrote: On Mon, Jul 6, 2009 at 6:09 PM, Darin Fisher da...@chromium.org wrote: I'm not sure what would be best. I was just describing the problem. It might help to setup a buildbot for chromiumembedded on the fyi page: http://build.chromium.org/buildbot/waterfall.fyi/waterfall That sounds like a good first step. Who should I talk to about getting this set up? Me or Nicolas. We could probably share it on a underused slave. Do you have an OS preference? --~--~-~--~~~---~--~~ 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: Rev 19669 and WebFrame::GetPrintPageShrink()
Sorry for deleting this function. I searched the Chromium code base and saw no consumer, so I assumed it was dead code. I do that from time to time, and so I'm concerned about how to avoid this problem in the future. -Darin On Sat, Jul 4, 2009 at 6:58 PM, Marshall Greenblatt magreenbl...@gmail.comwrote: On Sat, Jul 4, 2009 at 6:41 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: Hi Darin, Your rev 19669 removes the WebFrame::GetPrintPageShrink() method that was added in rev 14639: http://src.chromium.org/viewvc/chrome?view=revrevision=14639 --- begin paste --- Rev 12100 changed the way that we spool and render printed output, most notably introducing use of the PrintContext class. The existing PrintContext::spoolPage() method applies a webkit scaling factor before rendering output to the graphics context. ChromePrintContext::spoolPage() (in webframe_impl.cc), which is used by chromium instead of PrintContext::spoolPage(), does not apply this scaling factor, but instead eventually returns the scaling factor via WebFrame::PrintPage(). This is a problem for the Chromium Embedded Framework (CEF) because, unlike chromium, the CEF renders directly to the printer device context. It is therefore important for CEF that we retrieve and apply the webkit scaling factor before calling PrintPage(). In order to support this capability the following adds a WebFrame::GetPrintPageShrink() method. --- end paste --- Can you please restore the WebFrame::GetPrintPageShrink() method or provide an alternate approach for meeting the described need? A patch to restore this method is available here: http://codereview.chromium.org/149186 Thanks, Marshall --~--~-~--~~~---~--~~ 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: Rev 19669 and WebFrame::GetPrintPageShrink()
On Mon, Jul 6, 2009 at 2:02 PM, Darin Fisher da...@chromium.org wrote: Sorry for deleting this function. I searched the Chromium code base and saw no consumer, so I assumed it was dead code. I do that from time to time, and so I'm concerned about how to avoid this problem in the future. I've been thinking about that too. Maybe we should mention in the method comment that it's used by an external consumer? -Darin On Sat, Jul 4, 2009 at 6:58 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Sat, Jul 4, 2009 at 6:41 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: Hi Darin, Your rev 19669 removes the WebFrame::GetPrintPageShrink() method that was added in rev 14639: http://src.chromium.org/viewvc/chrome?view=revrevision=14639 --- begin paste --- Rev 12100 changed the way that we spool and render printed output, most notably introducing use of the PrintContext class. The existing PrintContext::spoolPage() method applies a webkit scaling factor before rendering output to the graphics context. ChromePrintContext::spoolPage() (in webframe_impl.cc), which is used by chromium instead of PrintContext::spoolPage(), does not apply this scaling factor, but instead eventually returns the scaling factor via WebFrame::PrintPage(). This is a problem for the Chromium Embedded Framework (CEF) because, unlike chromium, the CEF renders directly to the printer device context. It is therefore important for CEF that we retrieve and apply the webkit scaling factor before calling PrintPage(). In order to support this capability the following adds a WebFrame::GetPrintPageShrink() method. --- end paste --- Can you please restore the WebFrame::GetPrintPageShrink() method or provide an alternate approach for meeting the described need? A patch to restore this method is available here: http://codereview.chromium.org/149186 Thanks, Marshall --~--~-~--~~~---~--~~ 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: Rev 19669 and WebFrame::GetPrintPageShrink()
In this case, because the method will be part of the WebKit API, we'll have natural reluctance to remove the method. In general, however, I don't know that a comment like that is enough. It doesn't give me a way to eventually delete the method if it should become unnecessary to you. I think the only solution is for you to add a consumer to the Chromium code base, and then setup a buildbot that builds and preferably exercises that consumer. Then, if someone sees the function, they will be able to know who cares about it. Without something like that, you can be pretty much guaranteed to repeat this experience in the future. Regards, -Darin On Mon, Jul 6, 2009 at 11:09 AM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Mon, Jul 6, 2009 at 2:02 PM, Darin Fisher da...@chromium.org wrote: Sorry for deleting this function. I searched the Chromium code base and saw no consumer, so I assumed it was dead code. I do that from time to time, and so I'm concerned about how to avoid this problem in the future. I've been thinking about that too. Maybe we should mention in the method comment that it's used by an external consumer? -Darin On Sat, Jul 4, 2009 at 6:58 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Sat, Jul 4, 2009 at 6:41 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: Hi Darin, Your rev 19669 removes the WebFrame::GetPrintPageShrink() method that was added in rev 14639: http://src.chromium.org/viewvc/chrome?view=revrevision=14639 --- begin paste --- Rev 12100 changed the way that we spool and render printed output, most notably introducing use of the PrintContext class. The existing PrintContext::spoolPage() method applies a webkit scaling factor before rendering output to the graphics context. ChromePrintContext::spoolPage() (in webframe_impl.cc), which is used by chromium instead of PrintContext::spoolPage(), does not apply this scaling factor, but instead eventually returns the scaling factor via WebFrame::PrintPage(). This is a problem for the Chromium Embedded Framework (CEF) because, unlike chromium, the CEF renders directly to the printer device context. It is therefore important for CEF that we retrieve and apply the webkit scaling factor before calling PrintPage(). In order to support this capability the following adds a WebFrame::GetPrintPageShrink() method. --- end paste --- Can you please restore the WebFrame::GetPrintPageShrink() method or provide an alternate approach for meeting the described need? A patch to restore this method is available here: http://codereview.chromium.org/149186 Thanks, Marshall --~--~-~--~~~---~--~~ 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: Rev 19669 and WebFrame::GetPrintPageShrink()
On Mon, Jul 6, 2009 at 2:23 PM, Darin Fisher da...@chromium.org wrote: In this case, because the method will be part of the WebKit API, we'll have natural reluctance to remove the method. In general, however, I don't know that a comment like that is enough. It doesn't give me a way to eventually delete the method if it should become unnecessary to you. I think the only solution is for you to add a consumer to the Chromium code base, and then setup a buildbot that builds and preferably exercises that consumer. Then, if someone sees the function, they will be able to know who cares about it. Without something like that, you can be pretty much guaranteed to repeat this experience in the future. What kind of consumer do you have in mind? Are you thinking improvements and additional test cases for test_shell, or something completely different? Personally, I'd love to see the chromium embedded framework become part of the Chromium code base (with a full set of related test cases, builders, etc) but that might not be a popular option ;-). Regards, -Darin On Mon, Jul 6, 2009 at 11:09 AM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Mon, Jul 6, 2009 at 2:02 PM, Darin Fisher da...@chromium.org wrote: Sorry for deleting this function. I searched the Chromium code base and saw no consumer, so I assumed it was dead code. I do that from time to time, and so I'm concerned about how to avoid this problem in the future. I've been thinking about that too. Maybe we should mention in the method comment that it's used by an external consumer? -Darin On Sat, Jul 4, 2009 at 6:58 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Sat, Jul 4, 2009 at 6:41 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: Hi Darin, Your rev 19669 removes the WebFrame::GetPrintPageShrink() method that was added in rev 14639: http://src.chromium.org/viewvc/chrome?view=revrevision=14639 --- begin paste --- Rev 12100 changed the way that we spool and render printed output, most notably introducing use of the PrintContext class. The existing PrintContext::spoolPage() method applies a webkit scaling factor before rendering output to the graphics context. ChromePrintContext::spoolPage() (in webframe_impl.cc), which is used by chromium instead of PrintContext::spoolPage(), does not apply this scaling factor, but instead eventually returns the scaling factor via WebFrame::PrintPage(). This is a problem for the Chromium Embedded Framework (CEF) because, unlike chromium, the CEF renders directly to the printer device context. It is therefore important for CEF that we retrieve and apply the webkit scaling factor before calling PrintPage(). In order to support this capability the following adds a WebFrame::GetPrintPageShrink() method. --- end paste --- Can you please restore the WebFrame::GetPrintPageShrink() method or provide an alternate approach for meeting the described need? A patch to restore this method is available here: http://codereview.chromium.org/149186 Thanks, Marshall --~--~-~--~~~---~--~~ 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: Rev 19669 and WebFrame::GetPrintPageShrink()
On Mon, Jul 6, 2009 at 2:04 PM, Marshall Greenblatt magreenbl...@gmail.comwrote: On Mon, Jul 6, 2009 at 2:23 PM, Darin Fisher da...@chromium.org wrote: In this case, because the method will be part of the WebKit API, we'll have natural reluctance to remove the method. In general, however, I don't know that a comment like that is enough. It doesn't give me a way to eventually delete the method if it should become unnecessary to you. I think the only solution is for you to add a consumer to the Chromium code base, and then setup a buildbot that builds and preferably exercises that consumer. Then, if someone sees the function, they will be able to know who cares about it. Without something like that, you can be pretty much guaranteed to repeat this experience in the future. What kind of consumer do you have in mind? Are you thinking improvements and additional test cases for test_shell, or something completely different? Personally, I'd love to see the chromium embedded framework become part of the Chromium code base (with a full set of related test cases, builders, etc) but that might not be a popular option ;-). I'm not sure what would be best. I was just describing the problem. It might help to setup a buildbot for chromiumembedded on the fyi page: http://build.chromium.org/buildbot/waterfall.fyi/waterfall It looks like I can search at http://code.google.com/p/chromiumembedded/source/checkout to see how you are using various glue / webkit api interfaces. I will try to do that in the future, but I can't promise not to break you again. -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: Rev 19669 and WebFrame::GetPrintPageShrink()
On Mon, Jul 6, 2009 at 6:09 PM, Darin Fisher da...@chromium.org wrote: On Mon, Jul 6, 2009 at 2:04 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Mon, Jul 6, 2009 at 2:23 PM, Darin Fisher da...@chromium.org wrote: In this case, because the method will be part of the WebKit API, we'll have natural reluctance to remove the method. In general, however, I don't know that a comment like that is enough. It doesn't give me a way to eventually delete the method if it should become unnecessary to you. I think the only solution is for you to add a consumer to the Chromium code base, and then setup a buildbot that builds and preferably exercises that consumer. Then, if someone sees the function, they will be able to know who cares about it. Without something like that, you can be pretty much guaranteed to repeat this experience in the future. What kind of consumer do you have in mind? Are you thinking improvements and additional test cases for test_shell, or something completely different? Personally, I'd love to see the chromium embedded framework become part of the Chromium code base (with a full set of related test cases, builders, etc) but that might not be a popular option ;-). I'm not sure what would be best. I was just describing the problem. It might help to setup a buildbot for chromiumembedded on the fyi page: http://build.chromium.org/buildbot/waterfall.fyi/waterfall That sounds like a good first step. Who should I talk to about getting this set up? http://build.chromium.org/buildbot/waterfall.fyi/waterfall It looks like I can search at http://code.google.com/p/chromiumembedded/source/checkout to see how you are using various glue / webkit api interfaces. I will try to do that in the future, but I can't promise not to break you again. Thank you for keeping us in mind. I'll definitely let you know if/when things break again. :-) -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: Rev 19669 and WebFrame::GetPrintPageShrink()
On Sat, Jul 4, 2009 at 6:41 PM, Marshall Greenblatt magreenbl...@gmail.comwrote: Hi Darin, Your rev 19669 removes the WebFrame::GetPrintPageShrink() method that was added in rev 14639: http://src.chromium.org/viewvc/chrome?view=revrevision=14639 --- begin paste --- Rev 12100 changed the way that we spool and render printed output, most notably introducing use of the PrintContext class. The existing PrintContext::spoolPage() method applies a webkit scaling factor before rendering output to the graphics context. ChromePrintContext::spoolPage() (in webframe_impl.cc), which is used by chromium instead of PrintContext::spoolPage(), does not apply this scaling factor, but instead eventually returns the scaling factor via WebFrame::PrintPage(). This is a problem for the Chromium Embedded Framework (CEF) because, unlike chromium, the CEF renders directly to the printer device context. It is therefore important for CEF that we retrieve and apply the webkit scaling factor before calling PrintPage(). In order to support this capability the following adds a WebFrame::GetPrintPageShrink() method. --- end paste --- Can you please restore the WebFrame::GetPrintPageShrink() method or provide an alternate approach for meeting the described need? A patch to restore this method is available here: http://codereview.chromium.org/149186 Thanks, Marshall --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
