Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family

[Adam Barth]

You have improved my quality of life by several months.

On Thu, Jul 9, 2009 at 9:34 PM, Jeremy Orlow wrote:
> This makes me very, very, very happy.  :-)
>
> On Thu, Jul 9, 2009 at 9:23 PM, Dimitri Glazkov 
> wrote:
>>
>> Dear WebKiteurs,
>>
>> In our persisting quest to be more like a common WebKit port, we have
>> added Chromium build files to the tree this afternoon. These files are
>> WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they
>> are the GYP include files. As you may know, we use GYP
>> (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and
>> even Make projects for Chromium.
>>
>> We are rather fond of GYP. Perhaps it is because it allows us to
>> maintain one set of project files for all three Chromium platforms;
>>
>> or maybe because it lets us to do things like WebCore.gypi, where we
>> can just mindlessly add all project files to the list and then use
>> various neat GYP filtering facilities to narrow them down to sets that
>> are relevant for specific builds;
>>
>> or maybe because it easifies creating cross-platform and
>> cross-build-system targets, actions, and rules;
>>
>> or maybe because we just love saying "Gyp!"
>>
>> I don't truthfully know.
>>
>> What I do know is that starting now, we'd love for you to remember
>> WebCore.gypi and JavaScriptCore.gypi when you are adding or removing
>> files from WebCore or JavaScriptCore. Thanks to the power of GYP, you
>> don't have worry whether this file will be used by Chromium: the rule
>> is that if there's a project file change, it applies to the *.gypi
>> files. The format is very simple and intuitive, a simple Python/JSONey
>> list+dict.
>>
>> Thank you for your attention, men and women of WebKit.
>>
>> :DG<
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Tools for test performance of webkit based gtk browser

[naveen pal]

Thank you jan for your suggestion. 

jmalonzo wrote:
> 
> On Fri, Jul 10, 2009 at 3:36 PM, naveen pal 
> wrote:
> 
>>
>> Hi
>>
>> I have developed webkit based gtk browser. now i want to test it's
>> performance and increase it's performance for this can any one suggest
>> any
>> free tools.
> 
> 
> Hi Naveen
> 
> This list is for developing WebKit. You're likely to get feedback if you
> post your question in webkit-help or webkit-gtk.
> 
> Regards,
> Jan
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Tools-for-test-performance-of-webkit-based-gtk-browser-tp24422068p24422196.html
Sent from the Webkit mailing list archive at Nabble.com.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Tools for test performance of webkit based gtk browser

[Jan Michael Alonzo]

On Fri, Jul 10, 2009 at 3:36 PM, naveen pal  wrote:

>
> Hi
>
> I have developed webkit based gtk browser. now i want to test it's
> performance and increase it's performance for this can any one suggest any
> free tools.


Hi Naveen

This list is for developing WebKit. You're likely to get feedback if you
post your question in webkit-help or webkit-gtk.

Regards,
Jan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Tools for test performance of webkit based gtk browser

[naveen pal]

Hi 

I have developed webkit based gtk browser. now i want to test it's
performance and increase it's performance for this can any one suggest any
free tools.

Thanks in advance.

Regards,
Naveen
   
-- 
View this message in context: 
http://www.nabble.com/Tools-for-test-performance-of-webkit-based-gtk-browser-tp24422068p24422068.html
Sent from the Webkit mailing list archive at Nabble.com.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] how to port webkit on mobile

[naveen pal]

Hi Nilesh,
Fast of all thank you for fast replay.
I have received following information from customer.

* Webkit-based browser and web application running on PXA270 reference board

  - Hardware spec.: PXA270, NOR Flash, NAND Flash, MDOC,
  3.5" LCD with touch screen,
  PCF50606 (Philips) PMIC,
  NEXUS CHIP 3D Acceleration chip,
  WM9714 audio,
  - Software spec.: Linux kernel 2.6.26 basis
  We implemented LCD, UART, Keypad, Audio device
drivers

  GTK-based GUI system

  - Objective: Open-source Webkit porting on the hardware.
Webkit-based browser.

Thanks & Regards,
Naveen Pal


Nilesh Patil-2 wrote:
> 
> Hi
> 
> Not sure what harware you are talking about ? Is it some board you are
> talking about like OMAP3430 or so? If yes then probably you have done
> all things
> that are needed.  if not then , I consider this as linux Kernel as you
> are talking about Gtk port.
> I think you will need to have a proper boot up environment for this to
> boot your kernel. Then obvious thing comes up to have all supporting
> packages that
> webkitgtk reqiures. You need to build them for your required platform.
> Not sure which window manager you will be using ? if X11 then you  als
> need corresponding libs and load them appropriately. (Probably you
> must have done
> this as you said you tested it on arm processor ).
> 
> Thanks & Regards
> Niilesh
> On Wed, Jul 8, 2009 at 4:40 PM, naveen pal wrote:
>>
>> hi all,
>>
>> I am  new in webkitgtk development. I have created webkitgtk browser and
>> successfully tested on arm processor. now i want to port this on actual
>> hardware . Please give me suggestion for this.
>>
>> Thanks in advance.
>>
>> Regards,
>> Naveen
>> --
>> View this message in context:
>> http://www.nabble.com/how-to-port-webkit-on-mobile-tp24388826p24388826.html
>> Sent from the Webkit mailing list archive at Nabble.com.
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 

-- 
View this message in context: 
http://www.nabble.com/how-to-port-webkit-on-mobile-tp24388826p24421851.html
Sent from the Webkit mailing list archive at Nabble.com.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family

[Jeremy Orlow]

This makes me very, very, very happy.  :-)

On Thu, Jul 9, 2009 at 9:23 PM, Dimitri Glazkov wrote:

> Dear WebKiteurs,
>
> In our persisting quest to be more like a common WebKit port, we have
> added Chromium build files to the tree this afternoon. These files are
> WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they
> are the GYP include files. As you may know, we use GYP
> (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and
> even Make projects for Chromium.
>
> We are rather fond of GYP. Perhaps it is because it allows us to
> maintain one set of project files for all three Chromium platforms;
>
> or maybe because it lets us to do things like WebCore.gypi, where we
> can just mindlessly add all project files to the list and then use
> various neat GYP filtering facilities to narrow them down to sets that
> are relevant for specific builds;
>
> or maybe because it easifies creating cross-platform and
> cross-build-system targets, actions, and rules;
>
> or maybe because we just love saying "Gyp!"
>
> I don't truthfully know.
>
> What I do know is that starting now, we'd love for you to remember
> WebCore.gypi and JavaScriptCore.gypi when you are adding or removing
> files from WebCore or JavaScriptCore. Thanks to the power of GYP, you
> don't have worry whether this file will be used by Chromium: the rule
> is that if there's a project file change, it applies to the *.gypi
> files. The format is very simple and intuitive, a simple Python/JSONey
> list+dict.
>
> Thank you for your attention, men and women of WebKit.
>
> :DG<
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Please welcome GYP to the our dysfunctional build family

[Dimitri Glazkov]

Dear WebKiteurs,

In our persisting quest to be more like a common WebKit port, we have
added Chromium build files to the tree this afternoon. These files are
WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they
are the GYP include files. As you may know, we use GYP
(http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and
even Make projects for Chromium.

We are rather fond of GYP. Perhaps it is because it allows us to
maintain one set of project files for all three Chromium platforms;

or maybe because it lets us to do things like WebCore.gypi, where we
can just mindlessly add all project files to the list and then use
various neat GYP filtering facilities to narrow them down to sets that
are relevant for specific builds;

or maybe because it easifies creating cross-platform and
cross-build-system targets, actions, and rules;

or maybe because we just love saying "Gyp!"

I don't truthfully know.

What I do know is that starting now, we'd love for you to remember
WebCore.gypi and JavaScriptCore.gypi when you are adding or removing
files from WebCore or JavaScriptCore. Thanks to the power of GYP, you
don't have worry whether this file will be used by Chromium: the rule
is that if there's a project file change, it applies to the *.gypi
files. The format is very simple and intuitive, a simple Python/JSONey
list+dict.

Thank you for your attention, men and women of WebKit.

:DG<
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Coding convention of constants

[Maciej Stachowiak]

On Jul 9, 2009, at 8:55 PM, Darin Fisher wrote:

Ditto.  The last time I wondered about this, I grepped through the  
code and found [1] to be the most prevalent.  So, in code reviews I  
have been recommending people do [1].


I think that's the nicest style (just like a variable, no special  
prefix). Let's go with that and update the coding style guidelines.


 - Maciej



-Darin

On Thu, Jul 9, 2009 at 8:16 PM, Dimitri Glazkov  
 wrote:

If we're voting, then +1 to [1]. If we're not voting, then oops.

:DG<

On Thu, Jul 9, 2009 at 12:50 PM, Darin Adler wrote:
> On Jul 8, 2009, at 9:08 PM, KwangYul Seo wrote:
>
> I found another style which starts with "k".
> [4] platform/chromium/PopupMenuChromium.cpp
> static const int kMaxVisibleRows = 20;
> static const int kMaxHeight = 500;
> static const int kBorderSize = 1;
> static const TimeStamp kTypeAheadTimeoutMs = 1000;
>
>
> 2009/7/9 KwangYul Seo 
>>
>> Hi,
>> It seems that there are three coding styles regarding "static  
const int"

>> constants.
>> [1] rendering/RenderImage.cpp
>> static const int maxAltTextWidth = 1024;
>> static const int maxAltTextHeight = 256;
>>
>> [2] rendering/RenderVideo.cpp  (prefixed with c)
>> static const int cDefaultWidth = 300;
>> static const int cDefaultHeight = 150;
>>
>> [3] storage/SQLTransaction.cpp (start with a capital letter)
>> static const int DefaultQuotaSizeIncrease = 1048576;
>>
>> http://webkit.org/coding/coding-style.html
>> WebKit Coding Style Guidelines does not mention this issue.
>> All 3 styles are acceptable?
>
> I don’t think we have consensus on this yet.
> I personally prefer (1).
> -- Darin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Coding convention of constants

[Darin Fisher]

Ditto.  The last time I wondered about this, I grepped through the code and
found [1] to be the most prevalent.  So, in code reviews I have been
recommending people do [1].
-Darin

On Thu, Jul 9, 2009 at 8:16 PM, Dimitri Glazkov wrote:

> If we're voting, then +1 to [1]. If we're not voting, then oops.
>
> :DG<
>
> On Thu, Jul 9, 2009 at 12:50 PM, Darin Adler wrote:
> > On Jul 8, 2009, at 9:08 PM, KwangYul Seo wrote:
> >
> > I found another style which starts with "k".
> > [4] platform/chromium/PopupMenuChromium.cpp
> > static const int kMaxVisibleRows = 20;
> > static const int kMaxHeight = 500;
> > static const int kBorderSize = 1;
> > static const TimeStamp kTypeAheadTimeoutMs = 1000;
> >
> >
> > 2009/7/9 KwangYul Seo 
> >>
> >> Hi,
> >> It seems that there are three coding styles regarding "static const int"
> >> constants.
> >> [1] rendering/RenderImage.cpp
> >> static const int maxAltTextWidth = 1024;
> >> static const int maxAltTextHeight = 256;
> >>
> >> [2] rendering/RenderVideo.cpp  (prefixed with c)
> >> static const int cDefaultWidth = 300;
> >> static const int cDefaultHeight = 150;
> >>
> >> [3] storage/SQLTransaction.cpp (start with a capital letter)
> >> static const int DefaultQuotaSizeIncrease = 1048576;
> >>
> >> http://webkit.org/coding/coding-style.html
> >> WebKit Coding Style Guidelines does not mention this issue.
> >> All 3 styles are acceptable?
> >
> > I don’t think we have consensus on this yet.
> > I personally prefer (1).
> > -- Darin
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Coding convention of constants

[Dimitri Glazkov]

If we're voting, then +1 to [1]. If we're not voting, then oops.

:DG<

On Thu, Jul 9, 2009 at 12:50 PM, Darin Adler wrote:
> On Jul 8, 2009, at 9:08 PM, KwangYul Seo wrote:
>
> I found another style which starts with "k".
> [4] platform/chromium/PopupMenuChromium.cpp
> static const int kMaxVisibleRows = 20;
> static const int kMaxHeight = 500;
> static const int kBorderSize = 1;
> static const TimeStamp kTypeAheadTimeoutMs = 1000;
>
>
> 2009/7/9 KwangYul Seo 
>>
>> Hi,
>> It seems that there are three coding styles regarding "static const int"
>> constants.
>> [1] rendering/RenderImage.cpp
>> static const int maxAltTextWidth = 1024;
>> static const int maxAltTextHeight = 256;
>>
>> [2] rendering/RenderVideo.cpp  (prefixed with c)
>> static const int cDefaultWidth = 300;
>> static const int cDefaultHeight = 150;
>>
>> [3] storage/SQLTransaction.cpp (start with a capital letter)
>> static const int DefaultQuotaSizeIncrease = 1048576;
>>
>> http://webkit.org/coding/coding-style.html
>> WebKit Coding Style Guidelines does not mention this issue.
>> All 3 styles are acceptable?
>
> I don’t think we have consensus on this yet.
> I personally prefer (1).
>     -- Darin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Coding convention of constants

[Scott Thompson]

On Jul 8, 2009, at 11:08 PM, KwangYul Seo wrote:


I found another style which starts with "k".

[4] platform/chromium/PopupMenuChromium.cpp

static const int kMaxVisibleRows = 20;
static const int kMaxHeight = 500;
static const int kBorderSize = 1;
static const TimeStamp kTypeAheadTimeoutMs = 1000;


For what it's worth, the convention of adding "k" to the beginning of  
constants was an artifact of the "Classic" Mac OS APIs (those that  
became Carbon).


Scott

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[Ojan Vafai]

While having consistency in changelog descriptions is nice, I'm not sure we
need to explicitly deal with the case of having multiple authors or multiple
bugs for a change. Those are rare enough situations that it's fine for
people to include that information however they want.
Or, if you don't agree with me, we can at least make those a separate
discussion. It would be nice if this discussion could focus on what goes in
the default text of a changelog description.

The original goal here was to reduce the number of patches that get r-'ed
for unnecessary changelog errors. Multiple authors rarely, if ever, results
in an r-. Similarly, multiple bugs is rarely an issue for new contributors.

Ojan

On Thu, Jul 9, 2009 at 1:30 PM, Mark Rowe  wrote:

>
> On 2009-07-09, at 08:02, Joe Mason wrote:
>
>  Maciej Stachowiak wrote:
>>
>>> Now that my attention has been called to it, it's starting to bug me that
>>> everyone formats their ChangeLog entries slightly differently. How about
>>> this as the canonical format (with prepare-ChangeLog encouraging it)?
>>>
>>
>> That reminds me: how do we format a patch with multiple authors?  I've
>> been doing this:
>>
>>  2009-07-08  Maciej Stachowiak  
>>>   Make prepare-ChangeLog less shouty
>>>   https://bugs.webkit.org/show_bug.cgi?id=27098
>>>
>> > Authors: Maciej Stachowiak , Joe Mason <
>> joe.ma...@torchmobile.com>
>>
>>>   Reviewed by Mark Rowe.
>>>   * Scripts/prepare-ChangeLog:
>>>
>>
>> So, the main author (or whichever one is submitting the patch if that's
>> unclear) in the header, then a separate "Authors" line above the Reviewer
>> line with everyone who deserves credit.
>>
>
> I've never seen this format used in WebKit patches.
>
> - Mark
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[Mark Rowe]

On 2009-07-09, at 08:02, Joe Mason wrote:


Maciej Stachowiak wrote:
Now that my attention has been called to it, it's starting to bug  
me that everyone formats their ChangeLog entries slightly  
differently. How about this as the canonical format (with prepare- 
ChangeLog encouraging it)?


That reminds me: how do we format a patch with multiple authors?   
I've been doing this:



2009-07-08  Maciej Stachowiak  
   Make prepare-ChangeLog less shouty
   https://bugs.webkit.org/show_bug.cgi?id=27098
> Authors: Maciej Stachowiak , Joe Mason >

   Reviewed by Mark Rowe.
   * Scripts/prepare-ChangeLog:


So, the main author (or whichever one is submitting the patch if  
that's unclear) in the header, then a separate "Authors" line above  
the Reviewer line with everyone who deserves credit.


I've never seen this format used in WebKit patches.

- Mark



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] possible wrong implementation visible_units....@logicalstartofline

[tonikitoo (Antonio Gomes)]

Hi,

trying to understand this part of the webcore code, I faced a possibly
wrong impl:

(...)
VisiblePosition logicalStartOfLine(const VisiblePosition& c)
{
VisiblePosition visPos = logicalStartPositionForLine(c);

if (visPos.isNull())
return c.honorEditableBoundaryAtOrAfter(visPos);

return c.honorEditableBoundaryAtOrAfter(visPos);
}
(...)

note that  "c.honorEditableBoundaryAtOrAfter(visPos);"  will be
executed regardless visPos being null or not. thoughts ?

commit : r43032

-- 
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Coding convention of constants

[Darin Adler]

On Jul 8, 2009, at 9:08 PM, KwangYul Seo wrote:


I found another style which starts with "k".

[4] platform/chromium/PopupMenuChromium.cpp

static const int kMaxVisibleRows = 20;
static const int kMaxHeight = 500;
static const int kBorderSize = 1;
static const TimeStamp kTypeAheadTimeoutMs = 1000;



2009/7/9 KwangYul Seo 
Hi,

It seems that there are three coding styles regarding "static const  
int" constants.


[1] rendering/RenderImage.cpp

static const int maxAltTextWidth = 1024;
static const int maxAltTextHeight = 256;


[2] rendering/RenderVideo.cpp  (prefixed with c)

static const int cDefaultWidth = 300;
static const int cDefaultHeight = 150;


[3] storage/SQLTransaction.cpp (start with a capital letter)

static const int DefaultQuotaSizeIncrease = 1048576;


http://webkit.org/coding/coding-style.html

WebKit Coding Style Guidelines does not mention this issue.

All 3 styles are acceptable?


I don’t think we have consensus on this yet.

I personally prefer (1).

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[David Kilzer]

On Thursday, July 9, 2009 11:11:05 AM, Maciej Stachowiak wrote:

> On Jul 9, 2009, at 8:52 AM, Darin Adler wrote:
> 
> > On Jul 9, 2009, at 1:47 AM, Maciej Stachowiak wrote:
> > 
> >> (the /b/ URL is a redirect):
> > 
> > I'm like most everything suggested in this thread.
> > 
> > But I'm a little sad that these new shorter URLs are redirects. I really 
> > like 
> to copy URLs out of the address field, so I’d want the legacy show_bug.cgi 
> one 
> to be the redirect, and the terse one to be the real URL. But that seems 
> impossible, possibly eternally so, if the /b/ one is at webkit.org and not on 
> the actual bugs.webkit.org server.
> 
> Mark and I discussed this and had two ideas:
> 
> 1) Something draggable/copyable in the bugzilla page that gives you the short 
> URL plus title in ChangeLog format.
> 2) A keyboard shortcut (perhaps Cmd+Shift+C?) to put the short URL plus title
> on the pasteboard for ease of pasting


Or the tool you use to attach patches to bugs.webkit.org could do the 
substitution of the bugs.webkit.org URL to the webkit.org URL for you so you 
don't have to think about it (much).

Or prepare-ChangeLog could preformat it for you so you only have to copy and 
paste the bug id:

 This is your bug title
Reviewed by NOBODY (OOPS!).

Dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[David Kilzer]

On Thursday, July 9, 2009 11:06:58 AM, Maciej Stachowiak wrote:

>On Jul 9, 2009, at 4:33 AM, David Kilzer wrote:
>
>>* What does the format look like for bugs with multiple URL
>>links, e.g., to  or to 
>>?  (The title should not have to be
>>repeated--you should be fixing the same issue for all of them.)
>
>I could think of two reasonable options?
>
>  Make prepare-ChangeLog 
> less shouty
> Reviewed by Mark Rowe.
>
>
>  Make prepare-ChangeLog less shouty
>  
> Reviewed by Mark Rowe.
>
>Preferences?


#2 please.

>>* Is the "Reviewed by" line going to have a blank line above it?
>>  (I think it should, but I could be persuaded otherwise.)

>
>I don't think it should, if it's one of two special lines at the
>top. Otherwise the whole ChangeLog entry looks double-spaced and
>gets harder to read.


Yeah, I've noticed that.

>>And from The-World-is-Not-Enough Department:
>>
>>* The commit-log-editor should be smart about condensing
>>duplicate content after the date-name-email lines for each
>>ChangeLog entry, and it should move those lines to the top of
>>the commit message.  (This also makes git users happy since the
>>first line would be the bug URL and description, making
>>"git log --oneline" more useful.)
>
>I'm not sure I understand this suggestion.


An illustrated example of pulling common lines out of each subsection (with 
double-spacing):

http://trac.webkit.org/changeset/44095
http://trac.webkit.org/changeset/44096

Dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[tonikitoo (Antonio Gomes)]

"I grew up listing and seeing people not writing their emails *as it*
and publishing on the internet"

so would replacing   by   be a
good practice ?

it reduces the spam count in your inbox for sure.

On Thu, Jul 9, 2009 at 2:11 PM, Maciej Stachowiak wrote:
>
> On Jul 9, 2009, at 8:52 AM, Darin Adler wrote:
>
>> On Jul 9, 2009, at 1:47 AM, Maciej Stachowiak wrote:
>>
>>> (the /b/ URL is a redirect):
>>
>> I'm like most everything suggested in this thread.
>>
>> But I'm a little sad that these new shorter URLs are redirects. I really
>> like to copy URLs out of the address field, so I’d want the legacy
>> show_bug.cgi one to be the redirect, and the terse one to be the real URL.
>> But that seems impossible, possibly eternally so, if the /b/ one is at
>> webkit.org and not on the actual bugs.webkit.org server.
>
> Mark and I discussed this and had two ideas:
>
> 1) Something draggable/copyable in the bugzilla page that gives you the
> short URL plus title in ChangeLog format.
> 2) A keyboard shortcut (perhaps Cmd+Shift+C?) to put the short URL plus
> title on the pasteboard for ease of pasting
>
>>
>> I also don’t love the Authors line as proposed. I normally prefer
>> something a bit less structured and formal for the case where there is some
>> sort of collaboration. See existing log entries with things like "Based on
>> idea by" etc.
>
> That's what I usually do too.
>
> Regards,
> Maciej
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



-- 
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[Maciej Stachowiak]

On Jul 9, 2009, at 8:52 AM, Darin Adler wrote:


On Jul 9, 2009, at 1:47 AM, Maciej Stachowiak wrote:


(the /b/ URL is a redirect):


I'm like most everything suggested in this thread.

But I'm a little sad that these new shorter URLs are redirects. I  
really like to copy URLs out of the address field, so I’d want the  
legacy show_bug.cgi one to be the redirect, and the terse one to be  
the real URL. But that seems impossible, possibly eternally so, if  
the /b/ one is at webkit.org and not on the actual bugs.webkit.org  
server.


Mark and I discussed this and had two ideas:

1) Something draggable/copyable in the bugzilla page that gives you  
the short URL plus title in ChangeLog format.
2) A keyboard shortcut (perhaps Cmd+Shift+C?) to put the short URL  
plus title on the pasteboard for ease of pasting




I also don’t love the Authors line as proposed. I normally prefer  
something a bit less structured and formal for the case where there  
is some sort of collaboration. See existing log entries with things  
like "Based on idea by" etc.


That's what I usually do too.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[Maciej Stachowiak]

On Jul 9, 2009, at 4:33 AM, David Kilzer wrote:




2009-07-08  Maciej Stachowiak  

 -  Make prepare-ChangeLog less shouty
 Reviewed by Mark Rowe.

 Hypothetical long description goes here. Yeah. Very long and  
detailed it is.


 * Scripts/prepare-ChangeLog:



Random nits (since you asked):

* Please do not put a "-" in front of the bug line.  What does that  
buy you besides (sometimes) a bullet in trac.webkit.org?


Mark Rowe said the same thing. Agreed.



* What does the format look like for bugs with multiple URL links,  
e.g., to  or to ?   
(The title should not have to be repeated--you should be fixing the  
same issue for all of them.)


I could think of two reasonable options?

  Make prepare- 
ChangeLog less shouty

 Reviewed by Mark Rowe.

  Make prepare-ChangeLog less shouty
 
 Reviewed by Mark Rowe.

Preferences?



* Is the "Reviewed by" line going to have a blank line above it?  (I  
think it should, but I could be persuaded otherwise.)


I don't think it should, if it's one of two special lines at the top.  
Otherwise the whole ChangeLog entry looks double-spaced and gets  
harder to read.




And from The-World-is-Not-Enough Department:

* The commit-log-editor should be smart about condensing duplicate  
content after the date-name-email lines for each ChangeLog entry,  
and it should move those lines to the top of the commit message.   
(This also makes git users happy since the first line would be the  
bug URL and description, making "git log --oneline" more useful.)


I'm not sure I understand this suggestion.

 - Maciej



Dave



- Original Message 

From: Maciej Stachowiak 
To: Maciej Stachowiak 
Cc: WebKit Development 
Sent: Thursday, July 9, 2009 1:47:16 AM
Subject: Re: [webkit-dev] Changes to prepare-ChangeLog


I discussed with Mark Rowe on IRC a bit and it seems like it would  
be nice if
the bug URL could be short enough to just go on one line with the  
summary. Which
turns out to be totally doable. Thus the latest format proposal  
(the /b/ URL is

a redirect):

2009-07-08  Maciej Stachowiak

  -  Make prepare-ChangeLog less  
shouty

 Reviewed by Mark Rowe.

 Hypothetical long description goes here. Yeah. Very long and  
detailed it is.


  * Scripts/prepare-ChangeLog:

On Jul 9, 2009, at 1:32 AM, Maciej Stachowiak wrote:



Now that my attention has been called to it, it's starting to bug  
me that
everyone formats their ChangeLog entries slightly differently. How  
about this as

the canonical format (with prepare-ChangeLog encouraging it)?


2009-07-08  Maciej Stachowiak

  Make prepare-ChangeLog less shouty
  https://bugs.webkit.org/show_bug.cgi?id=27098

  Reviewed by Mark Rowe.

  * Scripts/prepare-ChangeLog:



So specifically:

- Reviewed by line would go below, not above, to make git users  
happy (well,

happi*er*)
- Bug URL remains below one-line description, for git joy and  
scannability
- No angle brackets around URL, so that you can cut/paste or drag  
it from a

URL field without extra work

- No line between URL and summary

Is that a format everyone can live with for ChangeLogs and commit  
messages? If

so, I'll post a patch to update prepare-ChangeLog accordingly.


Regards,
Maciej



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[Darin Adler]

On Jul 9, 2009, at 1:47 AM, Maciej Stachowiak wrote:


(the /b/ URL is a redirect):


I'm like most everything suggested in this thread.

But I'm a little sad that these new shorter URLs are redirects. I  
really like to copy URLs out of the address field, so I’d want the  
legacy show_bug.cgi one to be the redirect, and the terse one to be  
the real URL. But that seems impossible, possibly eternally so, if  
the /b/ one is at webkit.org and not on the actual bugs.webkit.org  
server.


I also don’t love the Authors line as proposed. I normally prefer  
something a bit less structured and formal for the case where there is  
some sort of collaboration. See existing log entries with things like  
"Based on idea by" etc.


-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Executing stand alone Javascipt without HTML

[Darin Adler]

This mailing list is for discussing the development of WebKit. For  
help in using WebKit, please post to .


-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[Joe Mason]

Maciej Stachowiak wrote:


Now that my attention has been called to it, it's starting to bug me 
that everyone formats their ChangeLog entries slightly differently. How 
about this as the canonical format (with prepare-ChangeLog encouraging it)?


That reminds me: how do we format a patch with multiple authors?  I've 
been doing this:



2009-07-08  Maciej Stachowiak  

Make prepare-ChangeLog less shouty
https://bugs.webkit.org/show_bug.cgi?id=27098

> Authors: Maciej Stachowiak , Joe Mason 


Reviewed by Mark Rowe.

* Scripts/prepare-ChangeLog:


So, the main author (or whichever one is submitting the patch if that's 
unclear) in the header, then a separate "Authors" line above the 
Reviewer line with everyone who deserves credit.


Joe
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Executing stand alone Javascipt without HTML

[Guru Prasad H B]

Hi All,

[pleas ignore the previous mail its corrupted]
We are using webkit and developing web based application which uses
OPENAPI provided by various service provider. We have a javascript as given
below

test.js

---START---

function createEvent()
 {
 alert("start");
 var user = "username";
 var passwd = "passwd";
 var app_key = "apikey";

 var uiManager;
 var mainView;
 var callback = null;

 // Constants for menu item identifiers.
 var OPTION_CREATE_EVENT = 0;
 var OPTION_LIST_EVENT = 1;

callback = eventCreated;
var url = "https://www.eventbrite.com/xml/event_new?";;;
var title = "Test Event hey";
var desc = "This is the first event created using the test widget created by
Jacob Nelson";
var start_date = "2009-06-14 10:00:00";
var end_date = "2009-06-15 02:00:00";
var timezone = "GMT+05";
var status = "draft";

url = url + "app_key="+app_key;
url = url + "&user="+user;
url = url + "&password="+passwd;
url = url + "&title="+title;
url = url + "&description="+desc;
url = url + "&start_date="+start_date;
url = url + "&end_date="+end_date;
url = url + "&timezone="+timezone;
url = url + "&status="+status;

xmlhttp = new XMLHttpRequest();
 xmlhttp.open("GET", url, true);
xmlhttp.send(null);
alert("xmlhttp end");
 }

 function eventCreated()
 {
   alert("xmlhttp callback");
 }

 --END--

To establish a XHR from javascript we need a document.
can any one help us for creating document and handling the above script.
Any reference url or classes which i need to use in webkit.

Thanks in Advance,
Guru
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[David Kilzer]

> 2009-07-08  Maciej Stachowiak  
> 
>   -  Make prepare-ChangeLog less shouty
>   Reviewed by Mark Rowe.
> 
>   Hypothetical long description goes here. Yeah. Very long and detailed 
> it is.
> 
>   * Scripts/prepare-ChangeLog:


Random nits (since you asked):

* Please do not put a "-" in front of the bug line.  What does that buy you 
besides (sometimes) a bullet in trac.webkit.org?

* What does the format look like for bugs with multiple URL links, e.g., to 
 or to ?  (The title should not 
have to be repeated--you should be fixing the same issue for all of them.)

* Is the "Reviewed by" line going to have a blank line above it?  (I think it 
should, but I could be persuaded otherwise.)

And from The-World-is-Not-Enough Department:

* The commit-log-editor should be smart about condensing duplicate content 
after the date-name-email lines for each ChangeLog entry, and it should move 
those lines to the top of the commit message.  (This also makes git users happy 
since the first line would be the bug URL and description, making "git log 
--oneline" more useful.)

Dave



- Original Message 
> From: Maciej Stachowiak 
> To: Maciej Stachowiak 
> Cc: WebKit Development 
> Sent: Thursday, July 9, 2009 1:47:16 AM
> Subject: Re: [webkit-dev] Changes to prepare-ChangeLog
> 
> 
> I discussed with Mark Rowe on IRC a bit and it seems like it would be nice if 
> the bug URL could be short enough to just go on one line with the summary. 
> Which 
> turns out to be totally doable. Thus the latest format proposal (the /b/ URL 
> is 
> a redirect):
> 
> 2009-07-08  Maciej Stachowiak  
> 
>-  Make prepare-ChangeLog less shouty
>   Reviewed by Mark Rowe.
> 
>   Hypothetical long description goes here. Yeah. Very long and detailed 
> it is.
> 
>* Scripts/prepare-ChangeLog:
> 
> On Jul 9, 2009, at 1:32 AM, Maciej Stachowiak wrote:
> 
> > 
> > Now that my attention has been called to it, it's starting to bug me that 
> everyone formats their ChangeLog entries slightly differently. How about this 
> as 
> the canonical format (with prepare-ChangeLog encouraging it)?
> > 
> > 2009-07-08  Maciej Stachowiak  
> > 
> >Make prepare-ChangeLog less shouty
> >https://bugs.webkit.org/show_bug.cgi?id=27098
> > 
> >Reviewed by Mark Rowe.
> > 
> >* Scripts/prepare-ChangeLog:
> > 
> > 
> > 
> > So specifically:
> > 
> > - Reviewed by line would go below, not above, to make git users happy 
> > (well, 
> happi*er*)
> > - Bug URL remains below one-line description, for git joy and scannability
> > - No angle brackets around URL, so that you can cut/paste or drag it from a 
> URL field without extra work
> > - No line between URL and summary
> > 
> > Is that a format everyone can live with for ChangeLogs and commit messages? 
> > If 
> so, I'll post a patch to update prepare-ChangeLog accordingly.
> > 
> > Regards,
> > Maciej
> > 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Executing stand alone Javascipt without HT ML

[guru prasad]

Hi All, We are using webkit and developing web based application which uses 
OPENAPI provided by various service provider. We have a javascript as given 
below test.jsfunction createEvent() { xmlhttp = new 
XMLHttpRequest();xmlhttp.open("GET", url, 
true);xmlhttp.send(null);alert("xmlhttp end"); } function eventCreated() 
{alert("xmlhttp callback"); }As i went through the webkit code and i could 
execute simple javascript which dosn't have XHR, If XHR is there then result i 
am getting is "undefined". code.cppJSValueRef 
CTestScriptAppUi::JSEvaluateScripttestscipt(JSContextRef ctx, JSStringRef 
script, JSObjectRef thisObject, JSStringRef sourceURL, int startingLineNumber, 
JSValueRef* exception){ JSLock lock;ExecState* exec = toJS(ctx);JSObject* 
jsThisObject = toJS(thisObject);UString::Rep* scriptRep = 
toJS(script);UString::Rep* sourceURLRep = sourceURL ? toJS(sourceURL) : NULL;// 
Interpreter::evaluate sets "this" to the global object if it is 
NULL//evaluate(const UString& sourceURL, i
 nt startingLineNumber, const UString& code, JSValue* thisV)//JSValue *jsval = 
new JSValue;Completion completion = 
exec>dynamicInterpreter()>evaluate(UString(sourceURLRep), startingLineNumber, 
UString(scriptRep), (JSValue *)jsThisObject);if (completion.complType() == 
Throw) {if (exception)*exception = toRef(completion.value());return 0;}if 
(completion.value())return toRef(completion.value());// happens, for example, 
when the only statement is an empty (';') statementreturn 
toRef(jsUndefined());} To establish a XHR from javascript we need a document. 
can any one help us for creating document and handling the above script. Any 
reference url or classes which i need to use. Thanks in Advance, Guru Dear 
webkitdev! Get Yourself a cool, short @in.com Email ID now!
function createEvent()
 {
 alert("start");
 var user = "username";
 var passwd = "passwd";
 var app_key = "apikey";
 
 var uiManager;
 var mainView;
 var callback = null;
 
 // Constants for menu item identifiers.
 var OPTION_CREATE_EVENT = 0;
 var OPTION_LIST_EVENT = 1;

	callback = eventCreated;
	var url = "https://www.eventbrite.com/xml/event_new?";;
	var title = "Test Event hey";
	var desc = "This is the first event created using the test widget created by Jacob Nelson";
	var start_date = "2009-06-14 10:00:00";
	var end_date = "2009-06-15 02:00:00";
	var timezone = "GMT+05";
	var status = "draft";

	url = url + "app_key="+app_key;
	url = url + "&user="+user;
	url = url + "&password="+passwd;
	url = url + "&title="+title;
	url = url + "&description="+desc;
	url = url + "&start_date="+start_date;
	url = url + "&end_date="+end_date;
	url = url + "&timezone="+timezone;
	url = url + "&status="+status;

	xmlhttp = new XMLHttpRequest();
	
	xmlhttp.open("GET", url, true);
	xmlhttp.send(null);
	alert("xmlhttp end");
 } 
 
 function eventCreated()
 {
  	alert("xmlhttp callback");
 }___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] how to understand the grammar implemention of js script "var a=9; "?

[Maciej Stachowiak]

This mailing list is for discussing the development of WebKit. For  
help in using WebKit, please post to .


On Jul 9, 2009, at 2:55 AM, Suk Zhong wrote:


Hi All:
   I want to understand the javascript grammar from Grammar.y in  
JavascriptCore,for the script "var a=9;",we find the following code:

   VariableStatement:
VAR VariableDeclarationList ';' {...}

   VariableDeclarationList:
IDENT   {...}
| IDENT Initializer {...}
   Initializer:
'=' AssignmentExpr  { $$ = $2; }

   AssignmentExpr:
 ConditionalExpr
 | LeftHandSideExpr AssignmentOperator AssignmentExpr {...}

   in my understand, '9' maybe be as Literal/PrimaryExprNoBrace/ 
PrimaryExpr/MemberExpr/LeftHandSideExpr etc,but why can be converted  
as AssignmentExpr?


   in the script "a=b;", i also encounter the same case, why the 'b'  
can be converted as AssignmentExpr?


   the following update can be correct?
   AssignmentExpr:
 ConditionalExpr
 |LeftHandSideExpr
 | LeftHandSideExpr AssignmentOperator AssignmentExpr {...}

   someone can help me understand the grammar?

Thanks and Best Regards

Suk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Webkit based HTML to PDF converter

[Maciej Stachowiak]

This mailing list is for discussing the development of WebKit. For  
help in using WebKit, please post to .


On Jul 9, 2009, at 2:45 AM, Sharma, Ashish wrote:


Hello,

I have a requirement to create a MarkUp(HTML) to PDF generator. The  
mentioned component is to be deployed as a java class API for a  
cloud computing service on Linux platform.


I want to use WebKit for my HTML /MarkUp rendering and then use that  
rendered output to convert to PDF.


So I request suitable guidance in WebKit code, so that I could start  
my work.


Thanks in advance.

Ashish Sharma
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Webkit based HTML to PDF converter

[RDC]

Hi Ashish,

I have a requirement to create a MarkUp(HTML) to PDF generator. The 
mentioned component is to be deployed as a java class API for a cloud 
computing service on Linux platform.


I want to use WebKit for my HTML /MarkUp rendering and then use that 
rendered output to convert to PDF.


This was covered in this thread from a couple of months ago:

https://lists.webkit.org/pipermail/webkit-dev/2009-May/007676.html

-R

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] how to understand the grammar implemention of js script "var a=9; "?

[Suk Zhong]

Hi All:
   I want to understand the javascript grammar from Grammar.y in
JavascriptCore,for the script "var a=9;",we find the following code:
   VariableStatement:
VAR VariableDeclarationList ';' {...}

   VariableDeclarationList:
IDENT   {...}
| IDENT Initializer {...}
   Initializer:
'=' AssignmentExpr  { $$ = $2; }

   AssignmentExpr:
 ConditionalExpr
 | LeftHandSideExpr AssignmentOperator AssignmentExpr {...}

   in my understand, '9' maybe be as
Literal/PrimaryExprNoBrace/PrimaryExpr/MemberExpr/LeftHandSideExpr etc,but
why can be converted as AssignmentExpr?

   in the script "a=b;", i also encounter the same case, why the 'b' can be
converted as AssignmentExpr?

   the following update can be correct?
   AssignmentExpr:
 ConditionalExpr
 |LeftHandSideExpr
 | LeftHandSideExpr AssignmentOperator AssignmentExpr {...}

   someone can help me understand the grammar?

Thanks and Best Regards

Suk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Webkit based HTML to PDF converter

[Sharma, Ashish]

Hello,

I have a requirement to create a MarkUp(HTML) to PDF generator. The mentioned 
component is to be deployed as a java class API for a cloud computing service 
on Linux platform.

I want to use WebKit for my HTML /MarkUp rendering and then use that rendered 
output to convert to PDF.

So I request suitable guidance in WebKit code, so that I could start my work.

Thanks in advance.

Ashish Sharma
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Detecting a finished paint via JavaScript

[RDC]

While this is not a perfect solution, a common technique is to call 
(from onload) a DOM method like offsetHeight that forces layout to 
run.  That way the bulk of the work required to paint is forced to 
happen before the benchmark considers the page load complete.

>
> This still omits the cost of painting from a benchmark though.

Okay, this is interesting, thank you for all the comments. I agree that 
there is some degree of inaccuracy in the benchmark result, but I think 
this is something we accept and can live with at the moment; however 
anything we can do to improve the accuracy--even slightly--is useful.


-R

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[Maciej Stachowiak]

I discussed with Mark Rowe on IRC a bit and it seems like it would be  
nice if the bug URL could be short enough to just go on one line with  
the summary. Which turns out to be totally doable. Thus the latest  
format proposal (the /b/ URL is a redirect):


2009-07-08  Maciej Stachowiak  

   -  Make prepare-ChangeLog less shouty
  Reviewed by Mark Rowe.

	Hypothetical long description goes here. Yeah. Very long and detailed  
it is.


   * Scripts/prepare-ChangeLog:

On Jul 9, 2009, at 1:32 AM, Maciej Stachowiak wrote:



Now that my attention has been called to it, it's starting to bug me  
that everyone formats their ChangeLog entries slightly differently.  
How about this as the canonical format (with prepare-ChangeLog  
encouraging it)?


2009-07-08  Maciej Stachowiak  

   Make prepare-ChangeLog less shouty
   https://bugs.webkit.org/show_bug.cgi?id=27098

   Reviewed by Mark Rowe.

   * Scripts/prepare-ChangeLog:



So specifically:

- Reviewed by line would go below, not above, to make git users  
happy (well, happi*er*)
- Bug URL remains below one-line description, for git joy and  
scannability
- No angle brackets around URL, so that you can cut/paste or drag it  
from a URL field without extra work

- No line between URL and summary

Is that a format everyone can live with for ChangeLogs and commit  
messages? If so, I'll post a patch to update prepare-ChangeLog  
accordingly.


Regards,
Maciej



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[Adam Barth]

On Thu, Jul 9, 2009 at 1:32 AM, Maciej Stachowiak wrote:
> Is that a format everyone can live with for ChangeLogs and commit messages?
> If so, I'll post a patch to update prepare-ChangeLog accordingly.

LGTM
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[Maciej Stachowiak]

Now that my attention has been called to it, it's starting to bug me  
that everyone formats their ChangeLog entries slightly differently.  
How about this as the canonical format (with prepare-ChangeLog  
encouraging it)?


2009-07-08  Maciej Stachowiak  

Make prepare-ChangeLog less shouty
https://bugs.webkit.org/show_bug.cgi?id=27098

Reviewed by Mark Rowe.

* Scripts/prepare-ChangeLog:



So specifically:

- Reviewed by line would go below, not above, to make git users happy  
(well, happi*er*)
- Bug URL remains below one-line description, for git joy and  
scannability
- No angle brackets around URL, so that you can cut/paste or drag it  
from a URL field without extra work

- No line between URL and summary

Is that a format everyone can live with for ChangeLogs and commit  
messages? If so, I'll post a patch to update prepare-ChangeLog  
accordingly.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev