Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

2018-11-16 Thread Timothy Hatcher
> On Nov 16, 2018, at 10:44 AM, Ryosuke Niwa  wrote:
> 
> If a stub implementation is ok for ports without an actual accessibility 
> implementation then I’d say remove both flags. Then downstream users would 
> never have to worry about breaking due to AX signatures changing.
> 
> 
> I don't think a stub implementation is okay.


Removing ENABLE(ACCESSIBILITY) would be fine. Either way, I do think we need a 
better way to maintain !HAVE(ACCESSIBILITY).

There have been at least ~38 build fixes for !HAVE(ACCESSIBILITY) over the 
years — one every 2-3 months on average. It was one of the pain points I 
remember in maintaining an outside port.

https://trac.webkit.org/search?q=%21HAVE%28ACCESSIBILITY%29

— Timothy Hatcher

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


Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

2018-11-14 Thread Timothy Hatcher
It wasn’t added for Tesla. But they did build with it disabled at the time I 
lasted worked on it. It was a frequent pain point to keep the build working 
when AX changes happened.

— Timothy Hatcher

> On Nov 14, 2018, at 5:29 PM, Ryosuke Niwa  wrote:
> 
> I think it was added for Telsa's private port. Probably not worth maintaining 
> the flag if the maintenance cost is high but is it?
> 
> - R. Niwa
> 
>> On Wed, Nov 14, 2018 at 5:19 PM Fujii Hironori  
>> wrote:
>> Hi webkit-dev,
>> 
>> It seems that all port defines HAVE_ACCESSIBILITY=1. Can I remove all code 
>> for !HAVE(ACCESSIBILITY)?
>> 
>> https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/Platform.h?rev=237992#L648
>> 
>>   #if PLATFORM(COCOA) || PLATFORM(WIN) || PLATFORM(GTK) || PLATFORM(WPE)
>>   #define HAVE_ACCESSIBILITY 1
>>   #endif
>> 
>> Bug 21802 – Rename HAVE_ACCESSIBILITY to ENABLE_ACCESSIBILITY
>> https://bugs.webkit.org/show_bug.cgi?id=21802
>> 
>> -- Fujii
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Matt Baker is now a WebKit Reviewer

2016-08-08 Thread Timothy Hatcher
I want to announce that Matt Baker <mattba...@apple.com> is now a WebKit 
Reviewer. His expertise is in the Web Inspector codebase.

Congratulations, Matt!

— Timothy Hatcher



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


Re: [webkit-dev] Proposal: Adopt Web Inspector coding style for all WebKit JS/CSS source code

2016-07-11 Thread Timothy Hatcher
> On Jul 9, 2016, at 3:22 PM, Sam Weinig <wei...@apple.com> wrote:
> 
> It should probably get a parallel page to 
> https://webkit.org/code-style-guidelines/ 
> <https://webkit.org/code-style-guidelines/> and be updated with the same type 
> of right / wrong examples.

Yes, I agree it should be a separate document. We can work on putting that 
together.

> Our of curiosity, other than for features that simply aren’t available in C++ 
> / Objective-C (or vice-versa), are there places where the inspector JS 
> guideline deviates from what we do in the rest of WebKit?


We pretty much follow the C++ WebKit style for things that overlap in the 
syntax.

— Timothy Hatcher



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


Re: [webkit-dev] WebKit project repo size

2016-03-31 Thread Timothy Hatcher
Also, removing files from the repo does not save anything with a Git checkout 
since they are still there in the history.

— Timothy Hatcher

> On Mar 31, 2016, at 12:50 PM, Brian Burg <bb...@apple.com> wrote:
> 
> Hi Marcus,
> 
> It’s unclear what your actual problem is.
>   
> If you have trouble downloading 7GB at once due to a slow or flaky 
> connection, you can fetch earlier git commits to finish the initial 
> repository checkout, and then fetch more commits in batches.
> If you just want a subset of the repository, I recommend you use SVN instead 
> of Git. (Maybe git supports sparse checkouts these days, i dunno).
> If you simply don’t like the repository layout or size, I don’t know how to 
> put it politely, but it’s unlikely to change due to the low payoff and huge 
> amount of work involved.
> 
>   -Brian
> 
>> On Mar 31, 2016, at 12:42 PM, Marcus Johnson <bumblebritche...@gmail.com 
>> <mailto:bumblebritche...@gmail.com>> wrote:
>> 
>> I use the git mirror, so I'm not sure how large the main SVN repo is, but 
>> the git one is huge at like 7 GB.
>> 
>> I think the best way to reduce that amount of space, is by splitting out the 
>> websites into their own repos, and possibly even the unit tests into their 
>> own repo as well.
>> 
>> Also, I've had pretty good luck reducing various repo's size running git gc 
>> --aggressive (it's re-compacts the .pack file) making it 5GB, so obviously 
>> some more work needs to be done.
>> 
>> I mean, it's just ridiculous trying to download a 7 GB project just to 
>> submit a few patches for memory related issues.
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev



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


Re: [webkit-dev] Suggestion: runtime disable Fetch API until it's complete enough for real web-apps

2016-03-31 Thread Timothy Hatcher

> On Mar 31, 2016, at 10:02 AM, Maciej Stachowiak <m...@apple.com> wrote:
> 
> The recently released Safari Technology Preview has gotten more people living 
> on builds close to trunk, which is cool. Some people pointing out that the 
> current state of Fetch API causes problems - it's not quite complete enough 
> for real web apps that want to use it, but its presence breaks the detection 
> that would substitute a polypill.
> 
> I'd like to suggest that it should be disabled until it's complete enough to 
> work. I would propose a runtime flag instead of compile-time so it can 
> continue to be tested by our regression tests while it's getting finished up.


It is is way better shape in trunk. It really just missed the Safari Technology 
Preview build by a couple days. A fetch example I have now works in a trunk 
Safari build for example.

I think we can keep it enabled and have it be in the next Safari Technology 
Preview release. We do need to be careful with things like this in the future 
though.

— Timothy Hatcher




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


Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

2016-03-13 Thread Timothy Hatcher

> On Mar 13, 2016, at 10:06 AM, Phil Bouchard <philipp...@gmail.com> wrote:
> 
> I just thought you might be interested in this benchmark.


Please stop email this list until you provide benchmark results replacing 
JavaScriptCore’s GC. The benchmarks you are providing are irrelevant to 
JavaScriptCore’s needs. We are not interested.

— Timothy Hatcher



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


Re: [webkit-dev] Web inspector images

2016-02-09 Thread Timothy Hatcher
Hi Michael,

I am looking into our options for the license of the images. Stay tuned.

— Timothy Hatcher

> On Feb 6, 2016, at 8:23 PM, Michael Catanzaro <mcatanz...@igalia.com> wrote:
> 
> Hi,
> 
> I'd like to address the problem with the license for the web inspector
> images. The background on this is that a WebKitGTK+ release was
> rejected by the legal department of one of our distributors after it
> discovered the file Source/WebInspectorUI/APPLE_IMAGES_LICENSE.rtf,
> which covers the images under
> Source/WebInspectorUI/UserInterface/Images. From a cursory glance at
> the license, it's clear that not only is this license not open source
> compatible (and therefore not compatible with the acceptable content
> policies of major WebKitGTK+ distributors), the images are also not
> distributable. I don't believe this is consistent with the values of
> the WebKit open source project.
> 
> In response to this issue, we created similar but freely-licensed
> replacement images under
> Source/WebInspectorUI/UserInterface/Images/gtk, took down our hosted
> tarballs for several previous WebKitGTK+ releases, reissued those
> tarballs with the images replaced, and posted a notice to alert some of
> our distributors to the issue. This was sufficient for our port, so we
> just... stopped at that. But it would be good if other ports did not
> have to address this problem individually, especially since there is no
> obvious warning when downloading WebKit as to the legal status of this
> content.
> 
> Since the images are not usable except by Apple, it would be nice to
> remove these images from the public repository to reduce the risk of
> other ports accidentally including these image files. Therefore, I
> propose to simply overwrite the images under Images with the images
> under Images/gtk. As part of this, we would need to create a few new
> images that do not currently exist under Images/gtk. Also, Apple's
> internal build process would need to be modified to include the Apple
> images from elsewhere.
> 
> If I am remembering correctly, I spoke to Joe Pecoraro about this at
> the WebKit Contributors Meeting, and he liked this idea. Would anyone
> object to this change?
> 
> A couple alternative solutions:
> 
>  * Apple could relicense its images. I suspect the set of similar but
> freely-licensed gtk images defeats the purpose of using a restrictive
> license for the Apple images. This would be the best solution.
> Possible?
> 
> * We could move the license file up from WebInspectorImages to the
> toplevel project directory. This would make it very difficult to
> accidentally distribute the Apple images without knowing the license.
> 
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] Some text about the B3 compiler

2016-01-29 Thread Timothy Hatcher
Markdown is pretty similar to the wiki formatting and very simple.

You can look at a cheatsheet if you login to the blog: 
https://webkit.org/wp/wp-admin/post.php?post=4300=edit

I have also used this HTML to Markdown converter before: 
http://domchristie.github.io/to-markdown/

The pages are created:

https://webkit.org/documentation/b3/ loads /docs/b3/bare-bones-backend.md
https://webkit.org/documentation/b3/intermediate-representation/ loads 
/docs/b3/intermediate-representation.md

Once those files are added to SVN, they will get picked up by the site. I can 
change those to point to other names if you want something different.

— Timothy Hatcher

> On Jan 29, 2016, at 9:34 AM, saam barati <saambara...@gmail.com> wrote:
> 
> I'm happy to convert the document to markdown. Can you send me your latest 
> revision or post it to the website?
> 
> I usually look at:
> http://daringfireball.net/projects/markdown/syntax 
> <http://daringfireball.net/projects/markdown/syntax>
> For a refresher on the syntax.
> 
> Tim, could you create a page that loads the markdown file?
> 
> Thanks,
> Saam
> 
> On Jan 29, 2016, at 12:06 AM, Filip Pizło <fpi...@apple.com 
> <mailto:fpi...@apple.com>> wrote:
> 
>> I'm all for this but I don't know anything about markdown. 
>> 
>> What's the best way to proceed?
>> 
>> -Filip
>> 
>> On Jan 28, 2016, at 9:24 PM, Timothy Hatcher <timo...@apple.com 
>> <mailto:timo...@apple.com>> wrote:
>> 
>>> They should be markdown files like we do for the code style and policy 
>>> documents.
>>> 
>>> https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md 
>>> <https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md>
>>> 
>>> We can then make Wordpress pages on the site that load the markdown.
>>> 
>>> Maybe put them in a /docs/b3/ directory?
>>> 
>>> — Timothy Hatcher
>>> 
>>> On Jan 28, 2016, at 4:48 PM, Filip Pizlo <fpi...@apple.com 
>>> <mailto:fpi...@apple.com>> wrote:
>>> 
>>>> I guess we could put it in Websites/webkit.org/b3 <http://webkit.org/b3>.  
>>>> Then patches could edit both B3 and the documentation in one go, and the 
>>>> documentation would go live when it’s committed.
>>>> 
>>>> Does anyone object to this?
>>>> 
>>>> -Filip
>>>> 
>>>> 
>>>>> On Jan 28, 2016, at 4:39 PM, Saam barati <sbar...@apple.com 
>>>>> <mailto:sbar...@apple.com>> wrote:
>>>>> 
>>>>> Yeah. That’d be the easiest way to keep it up IMO.
>>>>> 
>>>>> Saam
>>>>> 
>>>>>> On Jan 28, 2016, at 4:37 PM, Filip Pizło <fpi...@apple.com 
>>>>>> <mailto:fpi...@apple.com>> wrote:
>>>>>> 
>>>>>> +1
>>>>>> 
>>>>>> Do you think we should move the documentation to a file in svn so that 
>>>>>> it can be reviewed as part of patch review?
>>>>>> 
>>>>>> -Filip
>>>>>> 
>>>>>> On Jan 28, 2016, at 4:32 PM, Saam barati <sbar...@apple.com 
>>>>>> <mailto:sbar...@apple.com>> wrote:
>>>>>> 
>>>>>>> This is great. Thanks Fil.
>>>>>>> 
>>>>>>> I propose that we do all that we can to keep this updated.
>>>>>>> I suggest that all patches that change to the IR should also include 
>>>>>>> with it 
>>>>>>> a change to the documentation, and that reviewers should require this.
>>>>>>> 
>>>>>>> It’d also be great if other significant changes that seem like the 
>>>>>>> deserve
>>>>>>> a mention in the documentation also get added as part of patches.
>>>>>>> 
>>>>>>> Saam
>>>>>>> 
>>>>>>>> On Jan 28, 2016, at 4:23 PM, Filip Pizlo <fpi...@apple.com 
>>>>>>>> <mailto:fpi...@apple.com>> wrote:
>>>>>>>> 
>>>>>>>> Hi everyone,
>>>>>>>> 
>>>>>>>> We’ve been working on a new compiler backend for the FTL JIT, which we 
>>>>>>>> call B3.  It stands for “Bare Bones Backend”.  We recently enabled it 
>>>>>>>> on X86/Mac, and we’re working hard to enable it on other platforms.
&g

Re: [webkit-dev] Some text about the B3 compiler

2016-01-29 Thread Timothy Hatcher
I also added:

https://webkit.org/documentation/b3/air/ loads 
/docs/b3/assembly-intermediate-representation.md

> On Jan 29, 2016, at 10:05 AM, Filip Pizło <fpi...@apple.com> wrote:
> 
> Thank you!  I'll convert them today. 
> 
> -Filip
> 
> On Jan 29, 2016, at 10:02 AM, Timothy Hatcher <timo...@apple.com 
> <mailto:timo...@apple.com>> wrote:
> 
>> Markdown is pretty similar to the wiki formatting and very simple.
>> 
>> You can look at a cheatsheet if you login to the blog: 
>> https://webkit.org/wp/wp-admin/post.php?post=4300=edit 
>> <https://webkit.org/wp/wp-admin/post.php?post=4300=edit>
>> 
>> I have also used this HTML to Markdown converter before: 
>> http://domchristie.github.io/to-markdown/ 
>> <http://domchristie.github.io/to-markdown/>
>> 
>> The pages are created:
>> 
>> https://webkit.org/documentation/b3/ <https://webkit.org/documentation/b3/> 
>> loads /docs/b3/bare-bones-backend.md
>> https://webkit.org/documentation/b3/intermediate-representation/ 
>> <https://webkit.org/documentation/b3/intermediate-representation/> loads 
>> /docs/b3/intermediate-representation.md
>> 
>> Once those files are added to SVN, they will get picked up by the site. I 
>> can change those to point to other names if you want something different.
>> 
>> — Timothy Hatcher
>> 
>>> On Jan 29, 2016, at 9:34 AM, saam barati <saambara...@gmail.com 
>>> <mailto:saambara...@gmail.com>> wrote:
>>> 
>>> I'm happy to convert the document to markdown. Can you send me your latest 
>>> revision or post it to the website?
>>> 
>>> I usually look at:
>>> http://daringfireball.net/projects/markdown/syntax 
>>> <http://daringfireball.net/projects/markdown/syntax>
>>> For a refresher on the syntax.
>>> 
>>> Tim, could you create a page that loads the markdown file?
>>> 
>>> Thanks,
>>> Saam
>>> 
>>> On Jan 29, 2016, at 12:06 AM, Filip Pizło <fpi...@apple.com 
>>> <mailto:fpi...@apple.com>> wrote:
>>> 
>>>> I'm all for this but I don't know anything about markdown. 
>>>> 
>>>> What's the best way to proceed?
>>>> 
>>>> -Filip
>>>> 
>>>> On Jan 28, 2016, at 9:24 PM, Timothy Hatcher <timo...@apple.com 
>>>> <mailto:timo...@apple.com>> wrote:
>>>> 
>>>>> They should be markdown files like we do for the code style and policy 
>>>>> documents.
>>>>> 
>>>>> https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md 
>>>>> <https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md>
>>>>> 
>>>>> We can then make Wordpress pages on the site that load the markdown.
>>>>> 
>>>>> Maybe put them in a /docs/b3/ directory?
>>>>> 
>>>>> — Timothy Hatcher
>>>>> 
>>>>> On Jan 28, 2016, at 4:48 PM, Filip Pizlo <fpi...@apple.com 
>>>>> <mailto:fpi...@apple.com>> wrote:
>>>>> 
>>>>>> I guess we could put it in Websites/webkit.org/b3 
>>>>>> <http://webkit.org/b3>.  Then patches could edit both B3 and the 
>>>>>> documentation in one go, and the documentation would go live when it’s 
>>>>>> committed.
>>>>>> 
>>>>>> Does anyone object to this?
>>>>>> 
>>>>>> -Filip
>>>>>> 
>>>>>> 
>>>>>>> On Jan 28, 2016, at 4:39 PM, Saam barati <sbar...@apple.com 
>>>>>>> <mailto:sbar...@apple.com>> wrote:
>>>>>>> 
>>>>>>> Yeah. That’d be the easiest way to keep it up IMO.
>>>>>>> 
>>>>>>> Saam
>>>>>>> 
>>>>>>>> On Jan 28, 2016, at 4:37 PM, Filip Pizło <fpi...@apple.com 
>>>>>>>> <mailto:fpi...@apple.com>> wrote:
>>>>>>>> 
>>>>>>>> +1
>>>>>>>> 
>>>>>>>> Do you think we should move the documentation to a file in svn so that 
>>>>>>>> it can be reviewed as part of patch review?
>>>>>>>> 
>>>>>>>> -Filip
>>>>>>>> 
>>>>>>>> On Jan 28, 2016, at 4:32 PM, 

Re: [webkit-dev] Some text about the B3 compiler

2016-01-28 Thread Timothy Hatcher
They should be markdown files like we do for the code style and policy 
documents.

https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md

We can then make Wordpress pages on the site that load the markdown.

Maybe put them in a /docs/b3/ directory?

— Timothy Hatcher

> On Jan 28, 2016, at 4:48 PM, Filip Pizlo <fpi...@apple.com> wrote:
> 
> I guess we could put it in Websites/webkit.org/b3.  Then patches could edit 
> both B3 and the documentation in one go, and the documentation would go live 
> when it’s committed.
> 
> Does anyone object to this?
> 
> -Filip
> 
> 
>> On Jan 28, 2016, at 4:39 PM, Saam barati <sbar...@apple.com> wrote:
>> 
>> Yeah. That’d be the easiest way to keep it up IMO.
>> 
>> Saam
>> 
>>> On Jan 28, 2016, at 4:37 PM, Filip Pizło <fpi...@apple.com> wrote:
>>> 
>>> +1
>>> 
>>> Do you think we should move the documentation to a file in svn so that it 
>>> can be reviewed as part of patch review?
>>> 
>>> -Filip
>>> 
>>>> On Jan 28, 2016, at 4:32 PM, Saam barati <sbar...@apple.com> wrote:
>>>> 
>>>> This is great. Thanks Fil.
>>>> 
>>>> I propose that we do all that we can to keep this updated.
>>>> I suggest that all patches that change to the IR should also include with 
>>>> it 
>>>> a change to the documentation, and that reviewers should require this.
>>>> 
>>>> It’d also be great if other significant changes that seem like the deserve
>>>> a mention in the documentation also get added as part of patches.
>>>> 
>>>> Saam
>>>> 
>>>>> On Jan 28, 2016, at 4:23 PM, Filip Pizlo <fpi...@apple.com> wrote:
>>>>> 
>>>>> Hi everyone,
>>>>> 
>>>>> We’ve been working on a new compiler backend for the FTL JIT, which we 
>>>>> call B3.  It stands for “Bare Bones Backend”.  We recently enabled it on 
>>>>> X86/Mac, and we’re working hard to enable it on other platforms.
>>>>> 
>>>>> If you’re interested in how it works, I’ve started writing documentation. 
>>>>>  I’ll be adding more to it soon!
>>>>> https://trac.webkit.org/wiki/BareBonesBackend
>>>>> https://trac.webkit.org/wiki/B3IntermediateRepresentation
>>>>> 
>>>>> -Filip
>>>>> 
>>>>> ___
>>>>> webkit-dev mailing list
>>>>> webkit-dev@lists.webkit.org
>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Updated WebKit Project Logo

2015-08-05 Thread Timothy Hatcher

 On Aug 1, 2015, at 12:11 AM, Chris Aljoudi ch...@chrismatic.io wrote:
 
 Now that you mention the WebKit nightly builds on OS X, though, it seems like 
 that icon could use an update, too.

We were in the process of getting an updated nightly icon from Apple’s design 
team. I posted a patch to swap-in what they created.

https://bugs.webkit.org/show_bug.cgi?id=147684

 I put together an idea (see attached image) for one possible design.

Thanks for showing what you designed. The blueprint look is something Jon has 
been exploring for parts of the redesigned website.

— Timothy Hatcher

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


Re: [webkit-dev] Pattern for singleton classes instance getters

2015-01-28 Thread Timothy Hatcher
Yeah, that is exactly what I was thinking. Instance does not imply only one 
like singleton does. Call a singleton a singleton, we have a word for it.

— Timothy Hatcher

 On Jan 28, 2015, at 9:19 PM, Maciej Stachowiak m...@apple.com wrote:
 
 This may be a question of what jargon we’ve encountered, but to me, 
 “singleton clearly means the one unique instance of this class while 
 “instance means any instance of this class. If I hadn’t seen this thread, 
 I would interpret Class::instance() to mean “create a brand new instance of 
 this class” rather than “return the unique singleton instance of this class, 
 creating if necessary.
 
 Regards,
 Maciej
 
 On Jan 28, 2015, at 8:54 PM, Chris Dumez cdu...@apple.com wrote:
 
 Yes, instance() is what I’ve seen mostly outside WebKit as well. This would 
 be my preference.
 
 Kr,
 --
 Chris Dumez - Apple Inc.
 Cupertino, CA
 
 On Jan 28, 2015, at 8:44 PM, Michael Catanzaro mcatanz...@igalia.com 
 wrote:
 
 On Wed, Jan 28, 2015 at 8:11 PM, Maciej Stachowiak m...@apple.com wrote:
 Yet another possibility is finding a better name than ‘shared’ for the 
 singleton pattern function, but I don’t have any better ideas. 
 Class::getSingleton() is more explicit but the extra verbosity doesn’t 
 seem helpful to me.
 
 I recommend Class::instance(), which is what I've seen used almost 
 exclusively outside of WebKit. It's what Scott Meyers used, and it's very 
 similar to the Gang of Four's choice of Class::Instance() and the Java 
 pattern Class.INSTANCE.
 
 That said, Class::singleton() is very attractive too.
 
 I've never seen Class::shared() used anywhere except WebKit. The first time 
 I saw this I had no clue what it was until I looked up the implementation.
 
 All of these can get quite annoying to type, especially when the name of 
 the class is long. (Sometimes I will keep a reference to the instance in a 
 local variable with a shorter name.) But I think they're easier to read 
 than free functions, and we should optimize for reading code, not writing 
 it. Not a big deal either way.
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal: Removing ENABLE(INSPECTOR) guards

2015-01-19 Thread Timothy Hatcher
I agree. Lets remove it.

— Timothy Hatcher


 On Jan 19, 2015, at 9:44 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:
 
 Hi All,
 
 Inspector is enabled by default on all major WebKit port and
 the build without inspector isn't really maintained by anyone.
 
 Building without inspector can be useful on an embedded system where
 you don't need it, but it only reduces the binary code size with ~3%.
 It isn't so much, but the maintenance cost can be much more bigger.
 
 I propose removing ENABLE(INSPECTOR) guards to reduce maintenance cost.
 
 br,
 Ossy
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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


[webkit-dev] Brian Burg is now a WebKit reviewer

2014-09-12 Thread Timothy Hatcher
Howdy folks!

I’m happy to announce that Brian is now a WebKit reviewer. Brian has been 
working on Web Inspector for a while now — covering both the frontend and the 
backend. His primary focus is integrating his deterministic replay research 
into WebKit and Web Inspector. More on his work can be found at 
http://brrian.org/ http://brrian.org/. Lets hope he has enough time to review 
all of our patches now that he is a new father.

Congratulations on WebKit reviewer and fatherhood, Brian!

— Timothy Hatcher

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


Re: [webkit-dev] WebGL on by default?

2014-04-06 Thread Timothy Hatcher
On Apr 6, 2014, at 8:38 AM, Anatoly Ropotov anat...@innowate.com wrote:

 Is there a hope that either the next minor release will have WebGL turned on 
 by default or we'll have to wait for the next OS X to have WebGL enabled by 
 default (due to system-level security/sandboxing/energy consumption 
 concerns?). I've seen some recent commits on utilizing ANGLE here and there, 
 is there any ETA on rolling these things live and having WebGL turned on by 
 default?
 
 WWDC is still months away, so I hope we could get some ETA/roadmap hints to 
 make a promise to our users and properly convey information on Apple stance 
 for this tech.

These questions are not appropriate for webkit-dev — they are more about Safari 
than WebKit. Apple does not comment on future product releases.

— Timothy Hatcher

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


Re: [webkit-dev] Heap snapshot/profiling support in Web inspector

2014-03-05 Thread Timothy Hatcher
Yes, the feature was V8 specific. It is a feature we would like to eventually 
have in JSC.

— Timothy Hatcher


On Mar 5, 2014, at 8:59 AM, dipak kumar mail.di...@gmail.com wrote:

 Do we currently support heap profiling/snapshot with JSC engine? What I have 
 concluded is this feature is chrome/V8 specific. If yes, then any plan to 
 support this feature with JSC?

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


Re: [webkit-dev] Feature Announcement: URL API

2014-01-28 Thread Timothy Hatcher
On Jan 28, 2014, at 3:06 PM, Maciej Stachowiak m...@apple.com wrote:

 - The domainToASCII and domainToUnicode static methods (probably not to be 
 implemented for now based on comments in the spec discouraging it)

That is unfortunate, the Web Inspector could use these to show international 
domains better — instead of showing punycode.

Otherwise, the URL parsing parts will be useful and I look forward to using 
them and removing our JS URL parser!

— Timothy Hatcher

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


Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs

2014-01-16 Thread Timothy Hatcher
On Jan 16, 2014, at 2:28 AM, Alexey Proskuryakov a...@webkit.org wrote:

 
 15 янв. 2014 г., в 23:02, Ryosuke Niwa rn...@webkit.org написал(а):
 
 I think that it's good to try not dumping build failures into comments right 
 away, and to see what happens.
 
 As for not showing style bot failures, it seems almost certain that this 
 will make them substantially more annoying to work with. Can you describe 
 the workflow for patch author and reviewer to deal with style bot warnings 
 when they are not inline? Manually finding relevant lines by number can't 
 work.
 
 I agree with Tim that dumping all tested paths along with style warnings is 
 silly. How hard would it be it to get rid of that?
 
 The workflow is to click on the bubble to see the style errors. e.g.
 https://webkit-queues.appspot.com/results/6544662978363392
 
 
 Seems like that would require everyone to manually match errors to code lines 
 indeed, so I object against making this change for style checker warnings.
 
 - WBR, Alexey Proskuryakov

Yeah, seeing the style warnings as a comment (which also causes them to show up 
in the patch review) is helpful. I was just complaining about the python path 
spew it also includes.

— Timothy Hatcher
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs

2014-01-15 Thread Timothy Hatcher
It isn't just about seeing the comment on the page, it also gets emailed.

I agree, no bot comments would be better. The stye bot spew is particularly 
bad, mainly because it dumps all the file paths it tested not just what fails.

— Timothy Hatcher

On Jan 15, 2014, at 8:17 PM, Ryosuke Niwa rn...@webkit.org wrote:

 We could do that, or add some JS hack to Bugzilla so that it hides EWS 
 comments by default but makes them expandable.
 
 - R. Niwa
 
 
 On Wed, Jan 15, 2014 at 8:09 PM, Sam Weinig wei...@apple.com wrote:
 Could we compromise for now, and remove all the non-test failing EWS comments 
 (e.g. build failure, style failure)?
 
 - Sam
 
 On Jan 15, 2014, at 8:04 PM, Ryosuke Niwa rn...@webkit.org wrote:
 
 I find Mac EWS's listing the failing tests to be very useful especially 
 because it uploads the results to Bugzilla.
 
 I do agree that comments about build failures are much less useful.
 
 - R. Niwa
 
 
 On Wed, Jan 15, 2014 at 7:54 PM, Sam Weinig wei...@apple.com wrote:
 Hi Everyone,
 
 I am becoming increasingly annoyed by the comments made in bugs.webkit.org 
 bugs by our non-human helpers, the EWS bots.  I don’t find the addition of a 
 comment indicating that a patch has failed on a bot, over the existing 
 indication in the bubble, to be worth the noise it creates.
 
 I propose that we stop allowing the bots to comment, and leave that space 
 for the developers.
 
 - Sam
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] The SrcN responsive images proposal

2013-11-07 Thread Timothy Hatcher
On Nov 6, 2013, at 4:26 PM, John Mellor joh...@chromium.org wrote:

 I've suggested before that the attributes could be combined if that's 
 considered simpler. My only concern is that most developers aren't used to 
 putting line breaks in html attributes, so might feel obliged to put all the 
 alternatives on one line, harming readability. But as long as the developer 
 documentation encourages line breaks, that could be fine...

As I replied before, there should only be one attribute — srcset. Given that 
your micro format extends around parts of the existing micro format of srcset, 
it just makes sense to reuse the same attribute. Wishing srcset didn't exist 
doesn't make it go away. Tweaking it is more approachable and should get better 
support from the WebKit community and likely other venders who are now stalled 
because of this proposal. Especially since the current viewport syntax in 
srcset has little-to-no support or implementations. Also if srcset is the 
attribute, the CSS function srcset() should support the same micro format.

Designing this proposal around code formatting is a non-issue in my opinion and 
it surely didn't stop SVG from providing just one d attribute for path. 
Following the your logic, it should be d-N. Sure, path d=… is primarily 
meant to be written by software. Though, as responsive designs get more 
complex, people are going to rely on software to generate these src strings 
too. I surely don't want to be micromanaging the intrinsic widths in a 
viewport-urls set if I need to change the width and export again from 
Photoshop. Some workflow tool is likely going to generate these and having them 
in one attribute makes them infinitely easier for a script to manage. (And 
easier for humans too if things need reordered, as I mentioned earlier.)

— Timothy Hatcher

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


Re: [webkit-dev] The SrcN responsive images proposal

2013-11-07 Thread Timothy Hatcher
On Nov 7, 2013, at 2:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher timo...@apple.com wrote:
 On Nov 6, 2013, at 4:26 PM, John Mellor joh...@chromium.org wrote:
 I've suggested before that the attributes could be combined if that's
 considered simpler. My only concern is that most developers aren't used to
 putting line breaks in html attributes, so might feel obliged to put all the
 alternatives on one line, harming readability. But as long as the developer
 documentation encourages line breaks, that could be fine...
 
 As I replied before, there should only be one attribute — srcset. Given that
 your micro format extends around parts of the existing micro format of
 srcset, it just makes sense to reuse the same attribute. Wishing srcset
 didn't exist doesn't make it go away.
 
 srcset doesn't significantly exist yet. It's in one browser's
 nightly.  I'd like to resolve this soon, but it doesn't help anything
 to pretend that it's already a done deal that must be engineered
 around.

It is shipping in Safari 6.1, 7 and iOS 7. That ship has sailed.

 Tweaking it is more approachable and
 
 srcset's parsing algorithm *cannot* be extended in the future.  I gave
 an example of how it would fail over on blink-dev; I can reproduce it
 here if necessary.

I don't subscribe to blink-dev. The WebKit community are the ones you need to 
convince.

 Designing this proposal around code formatting is a non-issue in my opinion
 and it surely didn't stop SVG from providing just one d attribute for
 path. Following the your logic, it should be d-N. Sure, path d=… is
 primarily meant to be written by software.
 
 Please don't try to use reducto ad absurdum; it usually gives absurd
 results.  The reasoning for multiple attributes is not because it's a
 list, it's because it's a list of lists, and would require three
 different delimiters.


Three whole delimiters. What a crime against humanity!

— Timothy Hatcher
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] The SrcN responsive images proposal

2013-11-07 Thread Timothy Hatcher
On Nov 7, 2013, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher timo...@apple.com wrote:
 
 As I replied before, there should only be one attribute — srcset.
 
 I have a serious suggestion - could we rename srcset to src-n
 (literally, src-n), and then just ship it?  This puns in three
 interesting ways:
 
 1. If src-N is never accepted, it's still an attribute that holds N
 src values, so src-n works well.
 2. If src-N is accepted, but as a single attribute, src-n is just
 named perfectly to match the proposal name.
 3. If src-N is accepted fully, the obvious ordering is clearly src-1,
 src-2, src-3, ..., src-n, which matches the fallback we want.
 
 A guaranteed last fallback is legitimately useful for the full src-N
 proposal, so I'm totally okay with integrating that into my proposal.
 
 This'll let us ship now, and then continue to discuss src-N for a
 while, with whatever solution we land on still having a consistent
 name. Win for authors no matter what the result is.


No, you are just asking for support to muddy the waters and make the web your 
science project.

— Timothy Hatcher

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


Re: [webkit-dev] The SrcN responsive images proposal

2013-11-07 Thread Timothy Hatcher
On Nov 7, 2013, at 2:43 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 I'm pretty sure the argument is almost entirely around hand-authoring,
 where experience with style='' shows that lists-of-lists are bad.


Until you are dealing with dozens of images per tag. That is untenable one 
image heavy sites and tools will need to be written to auto generate these 
lists of lists from the original assets. Scripts can easily deal with a micro 
format in one attribute. They can't easily deal with a micro format spread 
across multiple src-n attributes in arbitrary HTML.

— Timothy Hatcher

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


Re: [webkit-dev] The SrcN responsive images proposal

2013-11-07 Thread Timothy Hatcher
On Nov 7, 2013, at 3:49 PM, Elliott Sprehn espr...@chromium.org wrote:

 It is shipping in Safari 6.1, 7 and iOS 7. That ship has sailed.
 
 Can you please clarify this, I just tested in Safari 6.1 and 7 and I don't 
 see srcset on HTMLImageElement. What do you mean it's shipped?
 
 document.createElement('img').srcset is undefined.


Sorry, I was confusing it with the CSS function. Tab is right, the HTML 
attribute is only in the WebKit nightly right now.

— Timothy Hatcher

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


Re: [webkit-dev] The SrcN responsive images proposal

2013-11-07 Thread Timothy Hatcher
On Nov 7, 2013, at 4:27 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 On Thu, Nov 7, 2013 at 3:39 PM, Timothy Hatcher timo...@apple.com wrote:
 On Nov 7, 2013, at 2:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 srcset's parsing algorithm *cannot* be extended in the future.  I gave
 an example of how it would fail over on blink-dev; I can reproduce it
 here if necessary.
 
 I don't subscribe to blink-dev. The WebKit community are the ones you need 
 to convince.
 
 A simple Yes would have sufficed.  I was just asking if I needed to
 demonstrate it.  Take this markup:
 
 img srcset=foo 1x, bar 2x || baz 1x, qux 2x
 
 You expect this to break into two lists, foo 1x, bar 2x and baz 1x,
 qux 2x, which are then each split as currently proposed.
 
 However, by the current parsing algorithm, || is read as an
 unsupported descriptor, so it just breaks them into foo 1x, bar 2x
 || baz 1x, and qux 2x.  The middle one is thrown away, because of
 the duplicate x descriptor, and so the whole thing is just parsed to
 the same value as foo 1x, qux 2x, which is completely wrong.

Good point. Thanks for the example. Luckily no one has shipped srcset, so it 
could be changed.

 Designing this proposal around code formatting is a non-issue in my opinion
 and it surely didn't stop SVG from providing just one d attribute for
 path. Following the your logic, it should be d-N. Sure, path d=… is
 primarily meant to be written by software.
 
 Please don't try to use reducto ad absurdum; it usually gives absurd
 results.  The reasoning for multiple attributes is not because it's a
 list, it's because it's a list of lists, and would require three
 different delimiters.
 
 Three whole delimiters. What a crime against humanity!
 
 I'm not sure why you're being sarcastic and hostile.  Three delimiters
 is a rather large mental tax for developers.  Being dismissive of
 mental complexity isn't very friendly to authors.  It's not the
 be-all-end-all, but it is important.


And that is more of a mental tax than managing multiple attributes? Developers 
already understand boolean logic. They don't already understand multiple 
stringed together attributes.

A proposal for a new paradigm of using multiple attributes deserves some 
resistance, careful consideration and exploration of alternatives. I feel my 
factual example of path d was flippantly tossed aside. So I responded in jest.

— Timothy Hatcher

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


Re: [webkit-dev] The SrcN responsive images proposal

2013-11-07 Thread Timothy Hatcher
On Nov 7, 2013, at 4:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 On Thu, Nov 7, 2013 at 3:43 PM, Timothy Hatcher timo...@apple.com wrote:
 On Nov 7, 2013, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 I have a serious suggestion - could we rename srcset to src-n
 (literally, src-n), and then just ship it?  This puns in three
 interesting ways:
 [...]
 This'll let us ship now, and then continue to discuss src-N for a
 while, with whatever solution we land on still having a consistent
 name. Win for authors no matter what the result is.
 
 No, you are just asking for support to muddy the waters and make the web 
 your science project.
 
 I have no idea what this means.  Could you restate your objection in
 some other way?  This is just a renaming request, mind, for an
 unreleased feature; it's not unusual.

Literally supporting src-n just to test the waters with the idea of 
introducing src-1..src-99 later is just an abuse of the HTML language and 
developers attention. Design something right and support it forever.

— Timothy Hatcher

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


Re: [webkit-dev] The SrcN responsive images proposal

2013-11-05 Thread Timothy Hatcher
On Nov 5, 2013, at 2:18 AM, John Mellor joh...@chromium.org wrote:

 img srcset=(min-width: 640px) 0.5x ph...@0.5x.jpg, 1x ph...@1x.jpg, 2x 
 ph...@2x.jpg || 0.5x photo-c...@0.5x.jpg, 1x photo-c...@1x.jpg, 2x 
 photo-c...@2x.jpg

I prefer this over multiple attributes. It is a syntax that needs little 
explanation before you can read it and use it. It also expands the existing 
srcset instead of confusing things with other attributes.

srcN is also too fiddly. If you want to add a higher precedent srcN, you need 
to reorder all the existing srcN attribute names. With srcset you just need to 
edit a single attribute's value, adding a logic operator between the rules.

— Timothy Hatcher

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


Re: [webkit-dev] canconfirm-bit for WebKit Bugzilla account

2013-10-31 Thread Timothy Hatcher
I went ahead and turned off unconfirmed. Only New and Assigned are now allowed 
when creating a bug.

— Timothy Hatcher

On Oct 31, 2013, at 4:33 PM, Darin Adler da...@apple.com wrote:

 The WebKit project doesn’t use the unconfirmed state in any significant way. 
 We probably should turn it off on bugs.webkit.org. There’s very little 
 distinction between an unconfirmed bug and a new bug. I don’t think you 
 really need that privilege on your account, although there’s also no harm on 
 giving it to you.
 
 — Darin
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d

2013-10-14 Thread Timothy Hatcher
On Oct 14, 2013, at 12:43 PM, Rik Cabanier caban...@gmail.com wrote:

 Also, how would your suggestion tell the UA about what areas are associated 
 with the elements? What happens if an element is no longer focused? The ring 
 is drawn into the canvas bitmap so those pixels have to be regenerated.


Focus rings are usually larger than the control they surround. How is the 
developer suppose to know the pixel padding needed for each platform's focus 
ring? Guess and hope for the best?

Would drawing the system focus ring taint the canvas pixels? (Drawing form 
controls into canvas via SVG images and foreignObject has been considered 
taint worthy because it could leak the user's UI theme.)

— Timothy Hatcher

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


Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d

2013-10-14 Thread Timothy Hatcher
On Oct 14, 2013, at 3:44 PM, Rik Cabanier caban...@gmail.com wrote:

 Isn't focus ring drawn on the canvas?  If so, it's important that the focus 
 ring fits within the canvas. e.g. consider focusing an element of 100px by 
 100px inside a canvas of the same size.  If the focus ring were to be drawn 
 around the element that currently has focus, then the entire focus ring would 
 be drawn outside of the visible region.
 
 True. That sounds like bad design though.
 
 Why? It doesn't seem particularly strange to have an element occupy the 
 entire canvas momentarily.
 
 No, but I wouldn't never make the focus ring as large as the canvas.

Even if you don't make it full size, if the focus ring is drawn into the canvas 
buffer, you don't know how much room you need to account for. (If the focused 
control is near the edge of the canvas.)

— Timothy Hatcher
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Announcement: CSS3_TEXT_DECORATION flag

2013-10-04 Thread Timothy Hatcher
Can we enable CSS3_TEXT_DECORATIONS on the Apple ports once you add it?

I have a legitimate use for -webkit-text-decoration-color that would allow me 
to eliminate a hack in the Inspector.

— Timothy Hatcher


On Oct 4, 2013, at 10:45 AM, Myles C. Maxfield mmaxfi...@apple.com wrote:

 Hello, all!
 
 Between the current and previous versions of the CSS3 Text spec, the text 
 decoration section was split out into its own spec [1] [2] [3]. Because of 
 this shift, I’m going to be creating a new compile-time flag: 
 CSS3_TEXT_DECORATIONS. Proposal for the features themselves was mentioned in 
 [4]. For those who wish to follow progress, the feature bug is at [5]. The 
 first thing I am working on is the text-decoration-skip: ink property [6]. I 
 will also be migrating existing text-decorations code from behind the 
 existing CSS3_TEXT flag to behind this new CSS3_TEXT_DECORATIONS flag.
 
 Thanks,
 Myles C. Maxfield
 
 [1] http://www.w3.org/TR/2012/WD-css3-text-20120814/
 [2] http://www.w3.org/TR/css3-text/
 [3] http://www.w3.org/TR/css-text-decor-3/
 [4] https://lists.webkit.org/pipermail/webkit-dev/2012-July/021715.html
 [5] https://bugs.webkit.org/show_bug.cgi?id=58491
 [6] https://bugs.webkit.org/show_bug.cgi?id=121806
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

2013-06-19 Thread Timothy Hatcher
What about?

StyleResolver* existingStyleResolver()
StyleResolver styleResolver()

— Timothy Hatcher


On Jun 19, 2013, at 11:49 AM, Balazs Kelemen kbal...@webkit.org wrote:

 For me optional seems very misleading and generally different prefixes 
 suggests that those objects are not the same.
 Maybe IfExists does not sound nicely but at least it's clear. I would choose 
 to have a pointer version with IfExists and a reference version which is a 
 noun, like:
 
 StyleResolver* styleResolverIfExists()
 StyleResolver styleResolver()
 
 Br,
 -Balazs

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


[webkit-dev] Web Inspector

2013-06-14 Thread Timothy Hatcher
On Tuesday the Safari team upstreamed the Safari Web Inspector to WebKit as a 
new top-level project — WebInspectorUI. This version of Web Inspector is nearly 
two years in the making. We now feel it is time to share our hard work with the 
WebKit project and further accelerate developer tool innovation with help from 
all of you.

The previous Web Inspector UI is still part of WebCore and is used by a number 
of ports currently. However, the previous version of Web Inspector is largely 
unmaintained at this point — since the departure of Chromium back in April. At 
this time, we would like to deprecate the previous Web Inspector and encourage 
ports to move over to using the new WebInspectorUI project.

We realize a transition like this can't happen overnight. For starters, the 
current UI assumes the Mac platform with keyboard shortcuts and other 
conventions. Another area would be making it work with the Inspector protocol 
vended over a WebSocket. To facilitate a smooth transition for ports, we are 
ready to help and review patches to get issues resolved as quickly as possible.

We hope you are as excited about this as we are, and are looking forward to 
working with all of you to make Web Inspector even better!

— Timothy Hatcher

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


Re: [webkit-dev] Web Inspector

2013-06-14 Thread Timothy Hatcher
Sorry for the duplicate message.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Web Inspector

2013-06-13 Thread Timothy Hatcher
On Tuesday the Safari team upstreamed the Safari Web Inspector to WebKit as a 
new top-level project — WebInspectorUI. This version of Web Inspector is nearly 
two years in the making. We now feel it is time to share our hard work with the 
WebKit project and further accelerate developer tool innovation with help from 
all of you.

The previous Web Inspector UI is still part of WebCore and is used by a number 
of ports currently. However, the previous version of Web Inspector is largely 
unmaintained at this point — since the departure of Chromium back in April. At 
this time, we would like to deprecate the previous Web Inspector and encourage 
ports to move over to using the new WebInspectorUI project.

We realize a transition like this can't happen overnight. For starters, the 
current UI assumes the Mac platform with keyboard shortcuts and other 
conventions. Another area would be making it work with the Inspector protocol 
vended over a WebSocket. To facilitate a smooth transition for ports, we are 
ready to help and review patches to get issues resolved as quickly as possible.

We hope you are as excited about this as we are, and are looking forward to 
working with all of you to make Web Inspector even better!

— Timothy Hatcher

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


Re: [webkit-dev] Enabling Experimental Features

2013-04-19 Thread Timothy Hatcher

On Apr 19, 2013, at 6:15 PM, Bear Travis betra...@adobe.com wrote:

 What do folks think about adding a mechanism for users to toggle features 
 like this on in WebKit nightlies? I don't have a definite approach yet, but 
 wanted to float the idea for feedback.

I like the idea. Having things off for everyone but the engineers is a bad 
approach and misses out on testing.

We could have WebKit modify Safari's Develop menu to provide additional items 
to toggle. Safari provides an Enable WebGL item, we could inject more items 
next to it.

— Timothy Hatcher

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


Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-10 Thread Timothy Hatcher

On Apr 10, 2013, at 6:32 PM, Ryosuke Niwa rn...@webkit.org wrote:

 Can we rewrite CodeGenerator*.pm in Ruby or Python?  I feel that the current 
 code is very hard to understand and hack on.  In particular we have 
 CodeGenerator.pm and CodeGeneratorJS.pm (CodeGeneratorV8.pm has been 
 removed), and we need to merge them anyway.

They can't be merged. We also have CodeGeneratorObjC.pm. (And internally we 
have CodeGeneratorSafari.pm.)

 I've seen many people expressing their inability to improve the binding code 
 because of its being written in Perl.


I've also seen people express their frustration for our tools currently written 
in Ruby and Python. I personally find Perl fine for this task and don't see a 
need to rewrite things just because.

— Timothy Hatcher


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


Re: [webkit-dev] Rewriting binding code generator, maybe?

2013-04-10 Thread Timothy Hatcher

On Apr 10, 2013, at 8:17 PM, Kentaro Hara hara...@chromium.org wrote:

 Now that JSC is the only engine in WebKit and V8 is the only engine in V8, we 
 both can remove a bunch of unnecessary abstractions and IDL attributes that 
 had existed to share code between JSC and V8. In short-term, this kind of 
 clean-up will improve our situation a lot. (I'm doing the work with the 
 highest priority in the V8 side.)

As I said in a previous email, JSC isn't the only binding we generate with 
these scripts. We also generate ObjC and internal Safari bindings. So those 
needs need to be considered for anyone rewriting these scripts.

— Timothy Hatcher

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


Re: [webkit-dev] Ever increasing binary size

2013-04-01 Thread Timothy Hatcher

On Mar 22, 2013, at 3:12 AM, Ryosuke Niwa rn...@webkit.org wrote:

 WebKit nightly build for r135421 dated November 21st, 2012 was 46.1MB.
 WebKit nightly build for r145786 dated March 13th, 2013 was 49.4MB.
 
 Our binary size increased by 7.2% in just 4 months.

Keep in mind that the Safari's Web Inspector is in the nightly. Also all of the 
frameworks and their resources are in the nightly twice (for 10.7 and 10.8).

Safari's Web Inspector framework is around 2.5 MB (uncompressed) in r135421 and 
4.2 MB in r145786. A 68% increase (that I will investigate further). Most of 
that size comes from image resources that can't be compressed further by the 
disk image. They are also duplicated for each OS, but the disk image 
compression should cancel that out.

Also the WebKit Web Inspector is in the nightly. It is 5.1 MB (uncompressed) in 
r135421 and 6.3 MB in r145786. A 24% increase. Again, mostly images.

So I don't think the majority of the download size increase correlates to 
in-memory size of the binaries. (See the link Eric sent later for that.)

— Timothy Hatcher

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


[webkit-dev] ChangeLogs

2012-03-21 Thread Timothy Hatcher
Lately I have observed more and more and more changes going into WebKit that 
lack any details about why a particular change was made. It is intended that 
the ChangeLog (and commit message) contain some details about your change, not 
just the bug title and URL.

The contributing information on subject is pretty sparse, which has likely 
caused this problem to manifest. However, the example ChangeLog linked from 
that page is prime example of what we all should strive for when describing our 
changes.

To help curb this lack of detail in ChangeLogs, I propose we add script (or 
augment an existing script) to check for this missing information and inform 
the contributor. It is clear not all reviewers are asking patch authors to 
provide this information when reviewing, and such a tool would help enforce it.

— Timothy Hatcher

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


Re: [webkit-dev] ChangeLogs

2012-03-21 Thread Timothy Hatcher

On Mar 21, 2012, at 2:46 PM, Adam Barth wrote:

 On Wed, Mar 21, 2012 at 2:29 PM, Timothy Hatcher timo...@apple.com wrote:
 Lately I have observed more and more and more changes going into WebKit that
 lack any details about why a particular change was made. It is intended that
 the ChangeLog (and commit message) contain some details about your change,
 not just the bug title and URL.
 
 Since I was the reviewer for http://trac.webkit.org/changeset/111577
 (although if you look in the bug thread, you'll see that I was just
 forwarding fishd's R+ after some trivial cleanups), I'm curious what
 additional information you think should have been included in that
 ChangeLog.
 
 There really isn't much to say about that change.  Tommy was just
 adding thin API wrappers around WebCore objects as part of the
 implementation of the MediaStream API.  The main point of discussion
 in the bug thread was whether to use the name ICE or Ice.
 
 Adam


Adding thin API wrappers around WebCore objects as part of the implementation 
of the MediaStream API. would be a good start. I shouldn't have to troll 
through a bug with 21 comments to figure out a change. Also the WebCore changes 
are just case changes, but you wouldn't know that by just perusing the 
ChangeLog/commit message.

— Timothy Hatcher


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


Re: [webkit-dev] ChangeLogs

2012-03-21 Thread Timothy Hatcher

On Mar 21, 2012, at 3:14 PM, Dirk Pranke wrote:

 I think this is a reasonable suggestion, but I don't agree with it :).
 I would prefer that we try to get good changelogs through culture and
 convention rather than through good tooling.
 
 This is of course based on my experience in my changes and the types
 of changes I review, but I personally find what value there is at all
 in ChangeLogs in the paragraphs at the top of the change, and I find
 the lists of changed files and to be distracting noise far more often
 than not. (Perhaps things are different in changes to the core
 rendering code than changes to tooling and test code).

I find the comments useful, even for scripts. ChangeLogs for tests are often 
more mundane.

My particular interest is the Web Inspector, which I follow by watching bugs 
and commits. Often I find myself asking why? or what does this do? when 
perusing the commits. It sometimes isn't very obvious and a nice concise 
description in the ChangeLog would help. This is even more important when folks 
are separated by timezones or are not easy to reach for explanation.

They also provide insight when looking back on changes from months or years ago 
when tracking down a regression.

 I think it is difficult to say what a good changelog is an any sort
 of algorithmic sense, and trying to implement something that would be
 done programmatically will be more annoying than useful (even if it
 means that I just have to delete a bunch of OOPS lines).


It would be difficult to make the tool smart. I merely looking for reminder to 
push folks to describe their changes in some fashion, not a analytical tool 
parsing for good vs bad.

— Timothy Hatcher

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


Re: [webkit-dev] WebKit unit test framework

2011-04-20 Thread Timothy Hatcher
I think having something the WebKit community owns and controls is preferred 
over importing and using a third-party library.

So that makes me prefer TestWebKitAPI (or something built from/on it) over 
gtest. And TestWebKitAPI already has a very simple test for WTF::Vector — just 
begging to be expanded.

On Apr 18, 2011, at 11:36 AM, David Levin wrote:

 Issue: There has been a long standing bug to add unit tests to WebKit 
 (https://bugs.webkit.org/show_bug.cgi?id=21010). It was also mentioned on 
 webkit-dev that it would be helpful in various cases.
 
 Landscape: Surveying WebKit, it is looks like there are at least three 
 testing frameworks being used: TestWebKitAPI/WebKitAPITest (in Tools), QTest, 
 gtest (in Source/WebKit/chromium/). However, only one TestWebKitAPI has been 
 used so far (as far as I can tell) for testing core WebKit items like WTF 
 (though I was unaware of TestWebKitAPI until Friday).
 
 It seems like a good way to think about the issue of which to use in general 
 in WebKit would be to decide on what would be desired in our framework and 
 then see how each matches up.
 
 Here's my take on this. (It may be biased toward what I am familiar with but 
 I welcome others to add their own criteria.) 
 
 Criteria
 
 Musts:
 Compatible license with WebKit
 Builds/Can be built on the many platforms and build systems supported by 
 WebKit (ideally without extra installs).
 Useful:
 Easy to write tests
 Hackable to suit our needs
 Well tested features (to support hackability/stability)
 Supports filtering of tests so you can run just the test you care about (and 
 easily listing the tests).
 Supports writing out values when there is test failure. (For example, if the 
 is verifying that A == B but that is not true, then the values of A and B 
 should be printed.)
 Well documented
 thanks,
 dave
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

— Timothy Hatcher


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


Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?

2010-08-09 Thread Timothy Hatcher
On Aug 9, 2010, at 7:52 PM, Dimitri Glazkov wrote:

 I am very, very tempted to just get rid of them. As Ojan indicated,
 the use cases for DOM Mutation events are extremely limited and to me,
 most of them feel like we should be solving them differently anyway.
 
 However, with the introduction of extensions into Chromium and Safari,
 DOM Mutation events experience a sort of renaissance, being used to
 sense the DOM changes to re-apply modifications (rewrite URLs, text,
 etc.).
 
 So I think we will upset a bunch of extensions developers if we just
 go cold turkey, which is probably not the right thing -- regardless of
 whether techniques they employ are sound or not.
 
 With this in mind, I think we should do #1 and #3, then #2 after some
 time and loud over-communication (like Inspector warnings, blog posts,
 billboards on Hwy 101 etc.).


Adding input/beforeinput events (#3) wont solve the need of most extension 
developers that use mutation events today (the examples you cite). So that 
makes it hard to remove them, especially over time, no matter how much warning 
you give.

— Timothy Hatcher

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


Re: [webkit-dev] Commit Queue Love

2010-07-09 Thread Timothy Hatcher
On Jul 9, 2010, at 3:38 AM, Alex Milowski wrote:

 Being able to go around the commit queue means you can cheat.  That
 seems like something that should be reserved for more severe problems
 where we know the process used by the commit queue will fail.

That is not how I see it at all. And calling it cheating is quite offensive 
to me. Just because I want control over when and how my patch is committed is 
suddenly considered cheating?

Some of the glaring reasons I don't use the commit queue have been resolved 
(svn blame mainly), but the fact that there is no control over when the path 
lands is my chief reason. Often I need to update Apple's internal bug database 
when I make a change to WebKit, so I just can't rely on the commit bot to close 
the bugzilla bug. That means holding a bug open and knowing go back days later 
when it finally lands to close the internal bug. Other times there are internal 
deadlines that need to be meet and hours matter. As well as keeping patches 
that span WebKit and Safari in-sync.

So until the commit queue solves these issues, I will keep exercising my right 
to svn commit and be responsive to problems my commits might bring. But please 
lets stop calling it cheating.

— Timothy Hatcher

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


Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)

2010-06-03 Thread Timothy Hatcher
Even if that wont prevent Sam's proposed information leak, I think this would 
be good to do. That way developers only see what they are affecting. Otherwise 
a developer might chase a red herring if they have Gmail  or something open in 
the background and keep seeing spikes of memory are not caused by their page.

On Jun 2, 2010, at 2:45 PM, Mikhail Naganov wrote:

 Used memory count can be restricted to include only objects reachable
 from the caller execution context. In this case, an app could only see
 the amount of memory consumed by itself, not by the whole engine.

— Timothy Hatcher

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


Re: [webkit-dev] webkit-patch requests

2010-05-19 Thread Timothy Hatcher
The xed --wait is much better, since it waits for the files to be closed, not 
for Xcode to quit. (And quitting Xcode is pretty disruptive if you have 
projects open.)

On May 19, 2010, at 1:08 PM, Maciej Stachowiak wrote:

 There’s also a tool called xed that I could probably use as an EDITOR. The 
 xed command has an option --wait that can make it behave more like modal 
 vi. The xed tool was created many years after I wrote those scripts.
 
 The Mac OS X open command also has a -W option which can wait for quit.
 
 I believe setting EDITOR=open -W -a Xcode would probably do it.

— Timothy Hatcher


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


Re: [webkit-dev] webkit-patch, check-webkit-style and git now support --squash and --git-commit

2010-04-26 Thread Timothy Hatcher
webkit-patch sounds useful now…

On Apr 26, 2010, at 10:55 AM, Ojan Vafai wrote:

 Eventually, I'd like to make --squash the default, but I want this to bake 
 and get some usage before flipping that switch.


But I don't think this makes sense as a default to me. But maybe I use git 
differently than everyone else… I don't do the whole branch-per-bug business.

I usually have one git commit per commit I plan to push to SVN (each with a 
separate ChangeLog entry).

— Timothy Hatcher

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


Re: [webkit-dev] #webkit and unregistered nicks

2010-04-14 Thread Timothy Hatcher
We could also appoint some channel operators that have the power to kick/ban 
spambots when they happen (or +r/+m the channel).

On Apr 14, 2010, at 4:44 AM, Maciej Stachowiak wrote:

 Done. We seem to have more trouble with people being mysteriously locked out 
 than with spambots, so we should probably only restrict the channel during 
 active spambot attacks (if we get any).

— Timothy Hatcher


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


Re: [webkit-dev] Git meeting notes

2010-04-12 Thread Timothy Hatcher
Only the first 5-7 characters are needed to identify a single commit (enough of 
the hash prefix to be unique). So REGRESSION(96c3b0) vs REGRESSION(r12345).

On Apr 12, 2010, at 6:28 PM, Alexey Proskuryakov wrote:

 One thing that wasn't mentioned at the meeting is that git doesn't seem to 
 have the same monotonously increasing revision numbers as svn does. It will 
 be a problem to replace REGRESSION(r12345) with 
 REGRESSION(96c3b0300ccf16b64efc260c21c85ba9030f2e3a).

— Timothy Hatcher


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


Re: [webkit-dev] Commit queue blocked because of failing tests

2010-02-25 Thread Timothy Hatcher
I agree with Jeremy and David. If you are a committer you should try to land 
patches on your own when you can. I mainly think this because it lets svn/git 
blame work as intended instead of always blaming who ran the bot. Maybe we 
should have a commit-...@webkit.org user?

On Feb 25, 2010, at 5:41 AM, Eric Seidel wrote:

 On Thu, Feb 25, 2010 at 5:26 AM, Jeremy Orlow jor...@chromium.org wrote:
 It also frees up the queue for those who need it.
 
 A common misconception, but looking at the logs the commit-queue looks
 to be no where near capacity.  I believe it could commit every change
 done to WebKit in a day and still not be near capacity. :)
 
 The only thing that prevents the commit-queue from cycling regularly
 is the bots breaking (this includes flakey tests). :(
 
 -eric
 
 
 On Thu, Feb 25, 2010 at 1:17 AM, Kenneth Russell k...@google.com wrote:
 
 On Wed, Feb 24, 2010 at 3:48 PM, David Levin le...@chromium.org wrote:
 1. It looks like you are a committer, so you don't need to wait for the
 commit queue to do this for you :)
 
 Understood -- but I prefer to use the bots where possible. I've seen
 multiple instances where the commit scripts failed to add new files
 for some reason, but the bots have always been 100% reliable.
 
 -Ken
 
 2. But it still would be good to have this fixed. If you'd like to help
 move
 this along, you can go to http://build.webkit.org/waterfall and find
 which
 patch caused the test to start failing. Then ping the relevant person.
 
 On Wed, Feb 24, 2010 at 3:41 PM, Kenneth Russell k...@google.com wrote:
 
 On Wed, Feb 24, 2010 at 12:02 PM, Alexey Proskuryakov a...@webkit.org
 wrote:
 
 On 24.02.2010, at 11:47, David Levin wrote:
 
 Actually, it doesn't appear to be do to recent changes in this
 area. They
 started failing after r55177
 (http://build.webkit.org/waterfall?last_time=1266975298), but that
 change is
 unrelated to these test as far as I can tell.
 
 It looks unrelated, but it somehow broke these editing tests
 nonetheless.
 I'm investigating now.
 
 Thanks. Our patch (from https://bugs.webkit.org/show_bug.cgi?id=34459)
 was about to be landed by the bot when the tree went red again. The
 test now failing is:
 
 fast/dom/prototype-inheritance-2.html - failed
 
 Could someone please look?
 
 Thanks,
 
 -Ken
 
 
 ___
 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] Buildbot Emails

2010-02-08 Thread Timothy Hatcher

On Feb 8, 2010, at 5:29 PM, Maciej Stachowiak wrote:

 That could be either webkit-dev or a new list. Maybe some won't want the spam 
 but I bet a lot of people would like to find out about every build break.

Please make it a new opt-in list.

— Timothy Hatcher


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


Re: [webkit-dev] Selection highlight painting (gaps?)

2009-10-19 Thread Timothy Hatcher

On Oct 19, 2009, at 1:43 PM, Peter Kasting wrote:

Note that within Chrome we put in ctrl-shift-v to paste as plain  
text precisely because of issues like this.  Most other programs  
don't have that option though (and even in Chrome it's hard to  
discover).


On Mac we call this Paste and Match Style and it is common is many  
Mac apps, including Safari.

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


Re: [webkit-dev] Selection highlight painting (gaps?)

2009-10-19 Thread Timothy Hatcher

On Oct 19, 2009, at 1:43 PM, Peter Kasting wrote:

Note that within Chrome we put in ctrl-shift-v to paste as plain  
text precisely because of issues like this.  Most other programs  
don't have that option though (and even in Chrome it's hard to  
discover).


I guess it isn't exactly what you describe, since images and other  
rich content are still pasted. Just not text styles.

___
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

2009-07-02 Thread Timothy Hatcher

I also agree and that is the style I use.

On Jul 2, 2009, at 7:05 AM, Adam Roben wrote:

- I generally move the Reviewed by line after the bug number/ 
description/URL.  When you're reading a ChangeLog entry/commit  
message (especially an older one), it's generally much more  
interesting which bug is being fixed rather than knowing who  
reviewed it.  (Also, putting the bug description first makes git's  
one-line description of each commit much more useful than either  
having a list of dates and the person who wrote the patch or having  
a list of patch reviewers.)


I agree with Dave on all three points. git users gotta stick together.


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


Re: [webkit-dev] how to destroy JSObjescts?

2008-11-25 Thread Timothy Hatcher
JavaScript objects and the JavaScriptCore API objects (except  
JSStringRef) are garbage collected. So sometime after the last  
reference goes away, they will release their memory.


In this case when the global object goes away. If you want to  
release them, you can call JSObjectDeleteProperty to remove the  
reference.


You also need to call JSStringRelease here when you are done with the  
jsstr variable.


On Nov 25, 2008, at 8:05 AM, Iulian wrote:



I create several JSObjects like this:

   js_object= JSObjectMakeConstructor(context, object_jsclass,
Object_Constructor);
   globalObject = JSContextGetGlobalObject(context);
   jsstr = JSStringCreateWithUTF8CString(MyObject);
   JSObjectSetProperty(context, globalObject, jsstr, js_object,
kJSPropertyAttributeNone, NULL);


From JavaScript i have: MyObject obj= new MyObject();


The problem is that the objects are never destroyed.
What can i do to release all these objects?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Debugging JavaScript Core Apps that are not Safari

2008-11-21 Thread Timothy Hatcher
The debugging functionally is part of WebKit, not Safari. So you can  
use the JavaScript debugger that is part of the Web Inspector in any  
WebKit client application. But this does not include JavaScriptCore  
client applications. I am surprised to hear that Drosera worked, since  
it was similarly tied to WebKit.


Please file a bug requesting this functionality.

On Nov 21, 2008, at 7:06 AM, Scott Thompson wrote:

It's been a while since I've looked at JavaScript Core and obviously  
a lot of changes have gone on.  In my previous examination, I was  
using Drosera to debug an application which used JavaScript Core as  
an internal scripting engine.  It would appear that all the  
JavaScript debugging facilities have been moved inside of Safari.   
Is it still possible to debug JavaScript code running through  
JavaScript Core in an application other than Safari?


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


Re: [webkit-dev] High Resolution Timer API proposal(s)

2008-10-02 Thread Timothy Hatcher

Why double delayInSeconds and not milliseconds to stay consistent?

On Oct 2, 2008, at 5:32 PM, Ojan Vafai wrote:


On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman [EMAIL PROTECTED] wrote:
On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak [EMAIL PROTECTED]  
wrote:

 I don't really like the overengineered version. I like the fairly
 minimalist version best, but is there anything from the
 overengineered version that should be added to it?

I like the fairly minimalist version best as well.

The stop() method does seem a little lonely on the Timer interface all
by itself.

If others think any other members from the overengineered version
are important I would welcome them to keep stop() company.

+1. My ideal would be the following:

Timer startTimer(double delayInSeconds, bool repeating, Function  
callback);


interface Timer {
void stop();
void resume();
void setDelay(double delayInSeconds);
}

That would cover the majority of cases I've seen in real-world  
javascript code. The argument for setDelay is wanting to be able to  
tweak the delay on the fly (e.g. Google Page Creator has autosave  
code that gets a response from the server  with a longer delay time  
when the server is overloaded).


Ojan
___
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] Web Inspector Can't Save Images or Open Images in New Window

2008-03-18 Thread Timothy Hatcher
If it worked before, this is is a regression. I confirmed they don't  
work in Safari 3.1, but I never tried this in Safari 3. Can you file a  
bug at bugs.webkit.org?


On Mar 18, 2008, at 3:07 PM, Ben Mills wrote:


After upgrading to Safari 3.1 why can I no longer open web inspector
and download images or open them in a new window. The contextual menu
has the options but they do nothing when selected and are not grayed
out. Everything worked perfectly in Safari 3.0.4 on OS X 10.4 -10.5.2
but the new version of webkit bundled with Safari 3.1 won't allow me
to do the fore-mentioned. I also tried the current nightly build and
it also has the same issue.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


— Timothy Hatcher


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


Re: [webkit-dev] How to catch JS exceptions/log messages from a WebView?

2007-12-23 Thread Timothy Hatcher

The Web Inspector also shows these for any WebView.

On Dec 22, 2007, at 8:14 AM, Todd Ditchendorf wrote:

For example, I want to implement something similar to the JavaScript  
Console in the Safari debug menu.


Also, how do you capture statements sent to console.log(),  
console.warn() and console.error() within a WebView?


— Timothy Hatcher


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


Re: [webkit-dev] Moving away from qmake

2007-11-12 Thread Timothy Hatcher
Apple needs to use native Xcode and VS projects to work with existing  
build systems. So generating an Xcode or VS project is not useful.


On Nov 12, 2007, at 12:20 PM, Jean-Charles VERDIE (Pleyo) wrote:

I might be wrong but I think it's useful to be able to generate,  
from the same sources and using a CMake facility, an Xcode project  
(to work under XCode on Mac), a VS project, a CMakeFile for linux- 
based solutions, 


— Timothy Hatcher


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


Re: [webkit-dev] Moving away from qmake

2007-11-12 Thread Timothy Hatcher
We could add a script that would add/remove/rename files in all the  
project files for the various build systems.


On Nov 12, 2007, at 1:19 PM, David D. Kilzer wrote:


Kevin Ollivier [EMAIL PROTECTED] wrote:


[...]  The tricky part AFAICT would be XCode, though, because
even if there is a scripted solution for this, it would probably need
to be run on a Mac where we have access to AppleScript or some other
scripting tool that can read and make changes to XCode projects...
[...]


Xcode project files are plain text as well.  It's possible to update  
them via
script (see WebKitTools/Scripts/sort-Xcode-project-file), but it  
requires a

little more insight than just staring at the source.


— Timothy Hatcher


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


Re: [webkit-dev] Should we consider switching to git over svn?

2007-10-08 Thread Timothy Hatcher

I think Git is rather slow on Windows I hear.

On Oct 8, 2007, at 9:29 PM, Oliver Hunt wrote:

 * Speed: Git is much faster than svn (which becomes very valuable  
on windows,


— Timothy Hatcher


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


Re: [webkit-dev] Threading issues regarding Netscape API plugins in WebKit

2007-09-28 Thread Timothy Hatcher
WebKit does not implement NPN_PluginThreadAsyncCall. A plugin could  
spawn another thread, but it can not call JavaScript (or any other API  
call) from that other thread.


On Sep 28, 2007, at 10:26 AM, Song Yuan wrote:
Are plugins implemented by using Netscape APIs in WebKit thread  
safe? Does Netscape APIs in WebKit have similar APIs like  
NPN_PluginThreadAsyncCall (refer to http://developer.mozilla.org/en/docs/NPN_PluginThreadAsyncCall) 
 in Gecko SDK in Mozilla? Will a new thread pawned from plugin main  
thread be able to invoke any JavaScript methods in browser?




— Timothy Hatcher


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


Re: [webkit-dev] identifying a unique iPhone?

2007-08-17 Thread Timothy Hatcher
Anything other than a cookie would be a privacy risk. So there is no  
other way.


This list is also not the best place to ask iPhone specific questions  
like this. (Though I don't have another list to recommend.)


On Aug 17, 2007, at 12:07 PM, Scott wrote:


Hopefully this is the proper list to post to:
I am writing an iPhone web application, and know how to tell that I  
am talking to an iPhone, but is there a way to uniquely identify a  
specific iPhone?   For example, some header or something I can get  
with either server side or browser side code and store on the server  
side so in the future I know which iPhone this is?


I know I can implement a cookie style log-in system, but I was  
hoping for some value I can just get and use.


— Timothy Hatcher


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


Re: [webkit-dev] lists and tables in contentEditable

2007-07-05 Thread Timothy Hatcher
We don't have plans to add support for these yet. But bug reports  
requesting the features and patches are always are always welcome.


— Timothy Hatcher


On Jul 5, 2007, at 6:54 PM, piet wrote:

NSTextView supports the edition of lists and tables through  
orderFrontListPanel: and orderFrontTablePanel:


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