Re: [webkit-dev] Are Qt and GTK+ intentionally returning false in shouldShowPlaceholderWhenFocused?
El mar, 20-08-2013 a las 10:41 -0700, Martin Robinson escribió: On Mon, Aug 19, 2013 at 10:16 PM, Ryosuke Niwa rn...@webkit.org wrote: Are Qt and GTK+ (and other) ports intentionally returning false in shouldShowPlaceholderWhenFocused? Or is this just an oversight due to the fact the default implementation returned false? I just confirmed that the native GTK+ behavior is for placeholder text to disappear when a text entry is focused. I believe for GTK+ this method should return false. I think that removing the placeholder text when starting typing instead of when the entry is focused is indeed a good idea. I implemented the placeholder text in GTK+ following the WebKit approach, so maybe we can change it in both places. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Are Qt and GTK+ intentionally returning false in shouldShowPlaceholderWhenFocused?
+1 -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Carlos Garcia Campos Sent: Wednesday, August 21, 2013 3:08 PM To: Martin Robinson Cc: WebKit Development Subject: Re: [webkit-dev] Are Qt and GTK+ intentionally returning false in shouldShowPlaceholderWhenFocused? El mar, 20-08-2013 a las 10:41 -0700, Martin Robinson escribió: On Mon, Aug 19, 2013 at 10:16 PM, Ryosuke Niwa rn...@webkit.org wrote: Are Qt and GTK+ (and other) ports intentionally returning false in shouldShowPlaceholderWhenFocused? Or is this just an oversight due to the fact the default implementation returned false? I just confirmed that the native GTK+ behavior is for placeholder text to disappear when a text entry is focused. I believe for GTK+ this method should return false. I think that removing the placeholder text when starting typing instead of when the entry is focused is indeed a good idea. I implemented the placeholder text in GTK+ following the WebKit approach, so maybe we can change it in both places. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ 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] Fwd: Are Qt and GTK+ intentionally returning false in shouldShowPlaceholderWhenFocused?
Does that mean we want the new Mac behavior (i.e. shouldShowPlaceholderWhenFocused returning true) everywhere? - R. Niwa On Tue, Aug 20, 2013 at 11:35 PM, Kangil Han kangil@samsung.com wrote: +1 -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto: webkit-dev-boun...@lists.webkit.org] On Behalf Of Carlos Garcia Campos Sent: Wednesday, August 21, 2013 3:08 PM To: Martin Robinson Cc: WebKit Development Subject: Re: [webkit-dev] Are Qt and GTK+ intentionally returning false in shouldShowPlaceholderWhenFocused? El mar, 20-08-2013 a las 10:41 -0700, Martin Robinson escribió: On Mon, Aug 19, 2013 at 10:16 PM, Ryosuke Niwa rn...@webkit.org wrote: Are Qt and GTK+ (and other) ports intentionally returning false in shouldShowPlaceholderWhenFocused? Or is this just an oversight due to the fact the default implementation returned false? I just confirmed that the native GTK+ behavior is for placeholder text to disappear when a text entry is focused. I believe for GTK+ this method should return false. I think that removing the placeholder text when starting typing instead of when the entry is focused is indeed a good idea. I implemented the placeholder text in GTK+ following the WebKit approach, so maybe we can change it in both places. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ 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] Are Qt and GTK+ intentionally returning false in shouldShowPlaceholderWhenFocused?
El mar, 20-08-2013 a las 23:41 -0700, Ryosuke Niwa escribió: Does that mean we want the new Mac behavior (i.e. shouldShowPlaceholderWhenFocused returning true) everywhere? I think so unless any GTK+ port maintainer disagree, but consistency with the platform is important too, so I'll first check with GNOME designers if they are ok with changing that in GTK+. Ryosuke Niwa On Tue, Aug 20, 2013 at 11:35 PM, Kangil Han kangil@samsung.com wrote: +1 -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Carlos Garcia Campos Sent: Wednesday, August 21, 2013 3:08 PM To: Martin Robinson Cc: WebKit Development Subject: Re: [webkit-dev] Are Qt and GTK+ intentionally returning false in shouldShowPlaceholderWhenFocused? El mar, 20-08-2013 a las 10:41 -0700, Martin Robinson escribió: On Mon, Aug 19, 2013 at 10:16 PM, Ryosuke Niwa rn...@webkit.org wrote: Are Qt and GTK+ (and other) ports intentionally returning false in shouldShowPlaceholderWhenFocused? Or is this just an oversight due to the fact the default implementation returned false? I just confirmed that the native GTK+ behavior is for placeholder text to disappear when a text entry is focused. I believe for GTK + this method should return false. I think that removing the placeholder text when starting typing instead of when the entry is focused is indeed a good idea. I implemented the placeholder text in GTK+ following the WebKit approach, so maybe we can change it in both places. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ 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 -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] ChangeLog format
Hi, I have noticed that the change log format has recently been changed. Unfortunately, this didn't work well with all webkitpy tools we have, and has been rolled out in http://trac.webkit.org/changeset/154406. *I kindly ask you to manually edit your patch to use the old format before landing your patch for now.* Otherwise webkit-patch and other tools will get confused and all kinds of problem ensues. Separately, I'd like to know whether people liked the new format and it's worth my time making webkitpy adopt the new format. I personally didn't like the old format because it made the first line of each change log too long. I'm also not a big fun of wrapping URLs in angle brackets. It's also unclear to me what should happen when there are multiple Bugzilla URLs to list. But I hear the new format made git log --oneline much more readable so I can be convinced although I don't intend to use git for WebKit development in the foreseeable future myself. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ChangeLog format
On Wed, Aug 21, 2013 at 2:04 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, I have noticed that the change log format has recently been changed. Unfortunately, this didn't work well with all webkitpy tools we have, and has been rolled out in http://trac.webkit.org/changeset/154406. *I kindly ask you to manually edit your patch to use the old format before landing your patch for now.* To clarify, the old multi-line format looks like: 2013-08-13 Ryosuke Niwa rn...@webkit.org REGRESSION(r150187): Safari fails to render allrecipe.com comment popups https://bugs.webkit.org/show_bug.cgi?id=119780 Reviewed by Benjamin Poulain. while new single-line format looked like: 2013-08-18 Ryosuke Niwa rn...@webkit.org https://webkit.org/b/119917 Pasting multiple lines into a textarea can introduce extra new lines Reviewed by Darin Adler. Separately, I'd like to know whether people liked the new format and it's worth my time making webkitpy adopt the new format. I personally didn't like the *new single-line* format because it made the first line of each change log too long. I'm also not a big fun of wrapping URLs in angle brackets. It's also unclear to me what should happen when there are multiple Bugzilla URLs to list. But I hear the new format made git log --oneline much more readable so I can be convinced although I don't intend to use git for WebKit development in the foreseeable future myself. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ChangeLog format
On Aug 21, 2013, at 2:04 PM, Ryosuke Niwa rn...@webkit.org wrote: Separately, I'd like to know whether people liked the new format and it's worth my time making webkitpy adopt the new format. I personally didn't like the old format because it made the first line of each change log too long. I'm also not a big fun of wrapping URLs in angle brackets. It's also unclear to me what should happen when there are multiple Bugzilla URLs to list. I think you mean you personally don’t like the *new* format? :) I don’t like it either. The line was too long, and I frequently list multiple bug urls (a bugzilla and a radar). I’ve had prepare-ChangeLog give me the new format and I simply ignored it and used the old format instead. I didn’t feel remotely bad about this as there has never been 100% standardization on the format, anyways. But I hear the new format made git log --oneline much more readable so I can be convinced although I don't intend to use git for WebKit development in the foreseeable future myself. I use git, and the old format doesn’t bother me. I almost always care about the entire commit message, or at least the “TLDR;” included after the bug descriptions and urls. ~Brady - R. Niwa ___ 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] Does Qt ARM support NRWT?
Hi,
It seems like the only port that uses ORWT by default is Qt ARM (and iOS)
at this point.
Is it true that Qt ARM still doesn't support NRWT as this comment indicates?
sub useNewRunWebKitTests()
{
# NRWT does not support qt-arm:
https://bugs.webkit.org/show_bug.cgi?id=64086
return 0 if isQt() and isARM();
# All other platforms should use NRWT by default.
return 1;
}
If so, what are remaining issues?
https://bugs.webkit.org/show_bug.cgi?id=64086 has already been fixed so we
need a new bug to track it if we still have some issue on Qt ARM.
- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Does Qt ARM support NRWT?
Hi,
Thanks for the heads-up. I'm not working on Qt port nowadays, but
some of my colleagues (azbest_hu, kadam and abrhm). I cc-ed them to
this thread.
I can confirm that Qt ARM didn't support NRWT long long time ago,
but the Qt ARM bot on http://build.webkit.sed.hu was switched to
use NRWT directly instead of this RWT wrapper script at least half
a year before. So it's safe to remove this useNewRunWebKitTests()
function. It won't break anything.
As far as I remember that Qt ARM has only an easily fixable NRWT
issue: http://wkb.ug/6 . But it is unrelated to this bug.
I'm sure that the guys will fix these bugs quickly. ;)
Ossy
Ryosuke Niwa írta:
Hi,
It seems like the only port that uses ORWT by default is Qt ARM (and
iOS) at this point.
Is it true that Qt ARM still doesn't support NRWT as this comment indicates?
sub useNewRunWebKitTests()
{
# NRWT does not support qt-arm:
https://bugs.webkit.org/show_bug.cgi?id=64086
return 0 if isQt() and isARM();
# All other platforms should use NRWT by default.
return 1;
}
If so, what are remaining
issues? https://bugs.webkit.org/show_bug.cgi?id=64086 has already been
fixed so we need a new bug to track it if we still have some issue on Qt
ARM.
- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ChangeLog format
I’m a bit of a luddite and edit my change log entries by hand. The old format is more amenable to this, the new format is a regression. cheers, G. On Aug 21, 2013, at 2:25 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Aug 21, 2013 at 2:04 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, I have noticed that the change log format has recently been changed. Unfortunately, this didn't work well with all webkitpy tools we have, and has been rolled out in http://trac.webkit.org/changeset/154406. I kindly ask you to manually edit your patch to use the old format before landing your patch for now. To clarify, the old multi-line format looks like: 2013-08-13 Ryosuke Niwa rn...@webkit.org REGRESSION(r150187): Safari fails to render allrecipe.com comment popups https://bugs.webkit.org/show_bug.cgi?id=119780 Reviewed by Benjamin Poulain. while new single-line format looked like: 2013-08-18 Ryosuke Niwa rn...@webkit.org https://webkit.org/b/119917 Pasting multiple lines into a textarea can introduce extra new lines Reviewed by Darin Adler. Separately, I'd like to know whether people liked the new format and it's worth my time making webkitpy adopt the new format. I personally didn't like the new single-line format because it made the first line of each change log too long. I'm also not a big fun of wrapping URLs in angle brackets. It's also unclear to me what should happen when there are multiple Bugzilla URLs to list. But I hear the new format made git log --oneline much more readable so I can be convinced although I don't intend to use git for WebKit development in the foreseeable future myself. - R. Niwa ___ 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] ChangeLog format
El mié, 21-08-2013 a las 14:04 -0700, Ryosuke Niwa escribió: Hi, [...] Separately, I'd like to know whether people liked the new format and it's worth my time making webkitpy adopt the new format. I prefer the old format. I personally didn't like the old format because it made the first line of each change log too long. I'm also not a big fun of wrapping URLs in angle brackets. It's also unclear to me what should happen when there are multiple Bugzilla URLs to list. But I hear the new format made git log --oneline much more readable so I can be convinced although I don't intend to use git for WebKit development in the foreseeable future myself. Well, git log is not actually affected by the ChangeLog format, but by the commit message. I mean, we generate the commit message from the ChangeLog, so we can keep the old format in the ChangeLog and update the script to generate the commit message to make it better for oneline git log format. webkitpy parses the ChangeLog not the commit message, so everything should work. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ChangeLog format
On Wed, Aug 21, 2013 at 10:50 PM, Carlos Garcia Campos carlo...@webkit.orgwrote: El mié, 21-08-2013 a las 14:04 -0700, Ryosuke Niwa escribió: Hi, [...] Separately, I'd like to know whether people liked the new format and it's worth my time making webkitpy adopt the new format. I prefer the old format. I personally didn't like the old format because it made the first line of each change log too long. I'm also not a big fun of wrapping URLs in angle brackets. It's also unclear to me what should happen when there are multiple Bugzilla URLs to list. But I hear the new format made git log --oneline much more readable so I can be convinced although I don't intend to use git for WebKit development in the foreseeable future myself. Well, git log is not actually affected by the ChangeLog format, but by the commit message. I mean, we generate the commit message from the ChangeLog, so we can keep the old format in the ChangeLog and update the script to generate the commit message to make it better for oneline git log format. webkitpy parses the ChangeLog not the commit message, so everything should work. If I'm not mistaken, I think a bunch of tools DO analyze git logs to do the work; commit-queue, webkitbot, etc... - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
