Re: [webkit-dev] Ports not building as C++11?

2013-07-29 Thread Hugo Parente Lima

On 07/29/2013 04:38 AM, Brianceau, Julien wrote:


Hi all,

I’m afraid that our sh4 bot won’t handle C++11 properly : 
http://build.webkit.org/builders/Qt%20Linux%20SH4%20Release


$ sh4-linux-g++ --version

sh4-linux-g++ (GCC) 4.6.3 20120613 (STMicroelectronics/Linux Base 
4.6.3-111)


Copyright (C) 2011 Free Software Foundation, Inc.



For most of the thing this wont be a problem.
http://gcc.gnu.org/gcc-4.6/cxx0x_status.html


Julien

*De :*webkit-dev-boun...@lists.webkit.org 
[mailto:webkit-dev-boun...@lists.webkit.org] *De la part de* Geoffrey 
Garen

*Envoyé :* lundi 29 juillet 2013 09:19
*À :* Brent Fulgham
*Cc :* WebKit Development
*Objet :* Re: [webkit-dev] Ports not building as C++11?

I’d really like to use atomic, which isn’t supported until VS2012.

When will we VS2012?

Geoff

On Jul 28, 2013, at 9:10 PM, Brent Fulgham bfulg...@gmail.com 
mailto:bfulg...@gmail.com wrote:




We can support auto and move semantics. We cannot support ranged 
iterators until VS2012.


But at least it's a step in the right direction...

Sent from my iPad

On Jul 28, 2013, at 2:36 PM, Oliver Hunt oli...@apple.com 
mailto:oli...@apple.com wrote:



So wait, is everyone using C++11 now?

I dream of using auto…

:-D

On Jul 28, 2013, at 12:47 PM, Gergely Kis gerg...@homejinni.com 
mailto:gerg...@homejinni.com wrote:



Hi,

On Sun, Jul 28, 2013 at 7:30 PM, Allan Sandfeld Jensen 
k...@carewolf.com mailto:k...@carewolf.com wrote:


became required in WebKit2. The only fallout will likely be the loss 
of the Qt

MIPS bot which is maintained by a third party and is too old.

The MIPS bot was updated to Debian Wheezy and GCC 4.7.2 a few weeks
ago, I just forgot to update the buildbot slave info file, did it now.

Best Regards,
Gergely
the 3rd party maintaining the MIPS bot :)
___
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 mailto:webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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




This message is confidential and intended only for the addressee. If 
you have received this message in error, please immediately notify the 
postmas...@nds.com and delete it from your system as well as any 
copies. The content of e-mails as well as traffic data may be 
monitored by NDS for employment and security purposes.
To protect the environment please do not print this e-mail unless 
necessary.


An NDS Group Limited company. www.nds.com


___
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] Cleaning House

2013-04-05 Thread Hugo Parente Lima
On Friday, April 05, 2013 09:24:59 AM Geoffrey Garen wrote:
 Hi Mario.
 
  First of all, let me say upfront that I see all the potential advantages
  of
  sticking to just one JS engine, and also perfectly understand the points
  that most of the people here have made on favour of not supporting
  multiple
  engines.
  
  Also, my mail was not really a formal request to keep the V8 bits around
  in
  
  the long term, but just a quick reply to the following comment from 
Maciej:
   
   Geoff posted the list in part because we'd like to know
   If any of the things above are used by other ports.
   We're not planning to remove things still in use.
   
  
  So, my position with regard to this is pretty much the same as Per's one,
  so I'll just quote him too: I'm not asking you to support an alternative
  JavaScript engine where it complicates the code.  Just please keep in
  mind there are people who use WebKit *without* JSC.
 
 Thanks for clarifying. It sounds like you're not asking us to maintain the
 v8 bindings.
  Who do you envision maintaining the v8 bindings going forward?
  
  In an ideal world, I would see the people interested in using those
  bindings doing it. And as per the feedback received so far, I understand
  it's just us for the V8 bindings, and maybe Oracle for the more generic
  bits about supporting multiple JS engines.
  
  However, that depends on whether those who were interested in WebKit +
  !JSC
  keep their interest on that for the long term, and I don't think this is a
  question that can be answered right now, as it probably depends on some
  other decisions.
 
 I apologize if this question was a little to Socratic. The point of the
 question was to identify real world challenges and solutions, not an ideal
 world. My understanding is that, in the real world, nobody is maintaining
 the v8 bindings. As of today, there are no v8 ports in WebKit trunk that
 build successfully.
  What do you see as their value to the WebKit project?
  
  I'm not an expert on JS engines at all, so I just see the obvious short
  term benefit of not breaking right now WebKit+V8 configurations that
  might be in use, and a more long-term benefit of having the needed bits
  in place to support other JS engines different than V8.
  
  Now, whether those are good enough benefits to keep this part of the code
  around in the future or not is something I can't answer either.
  
  Do you see any cost to the WebKit project in maintaining the v8
  bindings?
  
  Yes.
  
  I obviously see the cost and limitations imposed by having to maintain
  code
  to support more than one JS engine when, in most of the cases, only one
  (JSC) will be used. Also, considering that JSC will be the only one
  supported in WebKit2 suggests that whoever who try to use WebKit with
  other
  engine is going to have a hard time maintaining downstream patches that
  will probably be harder and harder to deal with over time.
  
  So yes, I'm not blind on this topic. I clearly see the drawbacks :)
  
  Does the benefit outweigh the cost?
  
  As I said, I'm not an expert on the matter, but after reading the comments
  here, I feel like benefit probably won't outweight the cost in the long
  run. 
  What would it take for WebKitGTK+ to adopt the JSC bindings?
  
  Martin already kindly answered this.
  
  
  To finish this mail, I'd just like to stress again that I was not
  requesting to keep this code forever in my previous mail. My point was
  more about keeping those bits for a while, or that just giving a smaller
  priority to the removal, since that would probably be appreciated in the
  short term by those that are currently using engines other than JSC.
 
 I'm not clear on what you're proposing here. How long should we wait to
 remove the v8 bindings?
 
 The uses of the v8 bindings I've heard of -- Oracle's Java project, a GTK
 project, and a Qt project -- are downstream adopters that don't work in
 WebKit trunk, and that can adjust to this change at their leisure.

Qt doesn't use it at all, Oracle use just the structure used to support 
multiple JS engines (that will probably vanish after v8 removal), not the v8 
bindings.
 
 Since I haven't heard of a specific disruption that will happen to a WebKit
 trunk contributor, I'm planning to remove the v8 bindings today.
 
 Geoff
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Compiling WebKit up to 25% faster in Windows?

2013-03-26 Thread Hugo Parente Lima
On Tuesday, March 26, 2013 01:40:56 PM Dirk Pranke wrote:
 On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain 
benja...@webkit.orgwrote:
  On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke dpra...@chromium.org wrote
  
  If we have consensus that we should just switch to paths relative to
  Source (or maybe a couple different options), that would be (IMO) a big
  win. It sounds like Daniel  co. have already done the big bang
  conversion.
  
  I think using full path would be a serious hit regarding hackability.
  
  I would rather spend some time tweaking my compiler to cache each
  directory content than waste time finding where is every single header I
  need to include.
 
 Interesting. I have the exact opposite experience, having to paw around to
 figure out where Font.h actually lives rather than just seeing
 WebCore/platform/graphics/Font.h.
 
 At any rate, to be clear, I would be in favor of that change but I'm not
 expecting it to happen :).

I would be in favor of that change but I'm not expecting it to happen :)

This summarizes my feel on any attempt to do a relative big change on WebKit 
project.

 -- Dirk

signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Compiling WebKit up to 25% faster in Windows?

2013-03-26 Thread Hugo Parente Lima
On Tuesday, March 26, 2013 01:47:26 PM James Robinson wrote:
 Also keep in mind that currently different build systems hack the include
 path up to have the same #include point to different headers depending on
 the build configuration, so the path expansion for a given #include will
 not be the same for all ports.  It's basically a very non-obvious way to do
 #if PLATFORM() guards at include sites without looking like it.  For
 instance there are 7 different versions of AuthenticationChallenge.h but
 only one #include statement in ResourceLoader.cpp.

I think this is another issue, but for sure a blocking issue for the one being 
discussed. 

 Consider:
 
 $ find Source/WebCore -name *.h -printf %f\n | wc -l
 3383
 
 $ find Source/WebCore -name *.h -printf %f\n | sort | uniq | wc -l
 3288
 
 
 - James
 
 On Tue, Mar 26, 2013 at 1:40 PM, Dirk Pranke dpra...@chromium.org wrote:
  On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain 
benja...@webkit.orgwrote:
  On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke dpra...@chromium.org wrote
  
  If we have consensus that we should just switch to paths relative to
  Source (or maybe a couple different options), that would be (IMO) a big
  win. It sounds like Daniel  co. have already done the big bang
  conversion.
  
  I think using full path would be a serious hit regarding hackability.
  
  I would rather spend some time tweaking my compiler to cache each
  directory content than waste time finding where is every single header I
  need to include.
  
  Interesting. I have the exact opposite experience, having to paw around to
  figure out where Font.h actually lives rather than just seeing
  WebCore/platform/graphics/Font.h.
  
  At any rate, to be clear, I would be in favor of that change but I'm not
  expecting it to happen :).
  
  -- Dirk
  
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev

signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Hugo Parente Lima
On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote:
 On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote:
  On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote:
  Thanks for sharing this.
  
  On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote:
  
  I wish we only had one build system (it were easy to add/remove/move
  files).
  
  I believe changes like http://trac.webkit.org/changeset/74849 are an
  unhealthy sign for the project.  Adam is not the only person who has
  chosen
  to empty files instead of removing them.  The pain of updating 8 build
  system is so great, we jump through hoops to avoid it.  Which means it
  took
  us months to move JavaScriptCore/wtf to WTF, and will take us years to
  kill
  WebCore/platform.
  
  
  +1
  
  This is a hard problem.  It is a problem worth solving.
  
  Do you have more thoughts on this, particularly since you know quite well
  how both Xcode and gyp work?
  
  I suspect this is one of those things that it would be hard to achieve
  consensus on since there are so many stakeholders.  But it may be
  fruitful
  to have a what if discussion about what this might look like.
  
  I think we can solve this problem if we agree that we want to. I think
  we haven't in the past mostly because we couldn't reach a consensus
  that it was worth solving enough to really try.
  
  I would love to see this fixed and would be glad to work on it. I
  think we should at least pursue this far enough to fully understand
  what our options are and what the costs and tradeoffs might be; does
  anyone disagree, and is anyone else willing to help pitch in?
  
  I think there are several possible ways we could solve this. One would
  be to switch to a common meta-build system. My understanding is that
  Apple's internal production build processes impose certain constraints
  here that I don't fully understand, but I know we've discussed the
  possibility of checking in generated project files as a workaround.
  Maybe there are other options as well to those constraints? I would
  love to discuss this further w/ someone from Apple ...
 
 It's far simplest for us if:
 (a) There is an Xcode project (or a Makefile) that builds the Mac port
 checked in to source control. (b) The generated project invokes only tools
 that are part of the default Mac OS X install.
 
 It may not be completely impossible to violate these requirements but it
 will require a lot of bureaucracy.
  (Also, just to get this out of the way, I don't think gyp needs to be
  the solution).
  
  Another alternative would be to write a script that did support at
  least the common use cases (add/move/delete files). There have been
  attempts in the past, but they have foundered on at least some
  perceived skepticism over how well this would work w/ XCode. That
  said, I don't think we've really pushed this to see. At some point
  this script might turn into a meta-meta-build system, which might be
  silly but also be the shortest path to the finish line.
  
  I suggest if there is interest in this we can start a new thread to
  discuss further ...
 
 My preference would be to use a common meta-build system with a comfortably
 human-readable and human-editable syntax, and checked in generated project
 files for those ports that need them.
 
 I think a key to making this work is to get Chromium and the Apple Mac port
 onto a common build system, which will probably require both Google and
 Apple ponying up at least one person to work on this project for a
 reasonable period of time.
 
 I think the plausible meta-build-systems to use would be CMake and Gyp, but
 in both cases it may be necessary to modify them to work well for everyone.
 
 I'd also like to add that I think a key related issue to common build system
 is common feature configuration. The many different ways ports control
 their feature flags is super confusing. I've long wanted to implement
 common configuration management, but have not had time.

I have a patch trying to solve this issue for CMake based ports[1], the patch 
still on going, but even a change affecting just 2-3 ports using the same build 
system is a bit hard to get a consensus, so you can imagine how hard will be 
to get a consensus over all WebKit ports.
 
[1] https://bugs.webkit.org/show_bug.cgi?id=103162

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

signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Hugo Parente Lima
On Thursday, January 31, 2013 06:14:20 PM Patrick Gansterer wrote:
 Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:
  On Jan 31, 2013, at 1:56 AM, Patrick Gansterer par...@paroga.com wrote:
  Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
  On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.org
  wrote: Another option is to add a webkit-patch command for modifying
  the build files. That way, the syntax doesn't need to be overly human
  friendly. There was also some attempt to write a tool to add files
  automatically: https://bugs.webkit.org/show_bug.cgi?ida772  I would
  expect that such a tool becomes easier if it would only modify one
  source of truth and generates all other artifacts such as Xcode
  projects from it.
 
  I don't want build file's syntax to be so human unfriendly that I need a
  tool
for it.
 
  Often times, these syntax problems can be improved dramatically by
  simple changes. e.g. we had a similar discussion about TestExpectation
  syntax, and I'm much happier with the new syntax even though the new
  syntax is functionally equivalent to the old one, and two syntaxes are
  very similar.
 
  On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote:
  I’ve experimented with this in the past and you’re right that it
  shouldn’t be particularly difficult to do. However, I suspect that the
  task would be similar in scope to defining an improved syntax for gyp.
  And if the syntax is the primary sticking point with gyp then it’d seem
  preferable to tackle initially.
 
  Yeah. In fact, we can just come up with whatever syntax we like and
  convert it to the existing gyp format if the syntax was the biggest
  issue.
  Do we want to define the whole build system (including inform
tion how to
  invoke the generators) with the new system, or is a simple list for
  the input files sufficient? IMHO adding a new generator build step
  happens very rarely. So maybe we can spit the input file list (mainly
  *.cpp and *.idl) into new files. Then GYP and CMake can read them and
  generate the build system out of them directly (like they to already
  today) instead of listing the files in the *.gpyi and *.cmake. This
  might work for other systems like qmake too. For XCode we can maybe have
  a template XCode project and generate the work XCode project with a
  script. This script then only need to fill in the files from the input
  file list into the template XCode project. Defining the feature flags
  can be done like Maciej suggested with Port.h files.
  I think it would be better to adapt an existing meta build system to our
  needs than to make one from scratch, unless we find that completely
  impractical.
 
  I
 particular, gyp and cmake both know how to handle generated sources,
  and while it may not be super common to make a new type of generated
  source, it's bad for hackability of the project of doing so is super
  hard. We get a lot of hackability benefits from using various kinds of
  generated sources, many first introduced in the days when we had a lot
  fewer build systems. So in my mind, they are already ahead of a
  hypothetical simple system.
 Do you want to kick the requirements of the smaller ports from trunk or do
 you think that e.g. a qmake generate for GYP makes sense? AFAIK e.g.
 QtWebKit is shipped with Qt, which uses qmake as build system, where
 CMake/GYP is not an option.

 I completely agree that creating a new meta meta build system isn't a good
 idea, but sharing the common parts (which reduce the daily productivity)
 might be a step in the right direction. Using simple text files which
 contain the list of files (like the gpyi files already do tod
y) isn't a
 new build system. It only offers the existing meta build systems (CMake,
 GYP, autotools, qmake) to use a common base.

I agree, common build system on WebKit is an utopia, create a new meta build
system isn't a good idea, so the only plausible option is to unify way we
add/remove/modify files from the build. Create a script to do this on all build
system is yet another utopia, so again, the only option is to have plain text
files.

Going a bit further on this idea, would be nice to also have conditionals on
these plain text files to cover the use case of e.g. add foo.cpp to the build
when ENABLE_FOO or WTF_USE_FOO is on would be even better, a script would be
called passing all ENABLE, USE, HAVE, etc.. flags and returning a list of files,
the only question is if all current build system would support such dynamic
source file list, CMake does :-)

 The remaining build systems can be ported to one of these systems or be
 adopted to use this file lists too.


 -- Patrick

pgpVpcWAo2RvL.pgp
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Please include function-level comments in change log entries

2012-07-06 Thread Hugo Parente Lima
On Friday, July 06, 2012 11:34:01 AM Per Bothner wrote:
 On 07/06/2012 10:05 AM, Dan Bernstein wrote:
  It appears that lately most WebCore change log entires don’t include any
  comments on individual functions. An overall description of the change at
  the top of the change log entry is valuable, but it is no substitute for
  describing the changes to each function. Good function-level comments are
  useful both while reviewing a patch and while revisiting existing code.
  Personally, I find that writing the function-level comments helps me a
  lot in reviewing my own patches before I post them.
 You forget there is a WebKit policy of not writing comments
 or otherwise documenting the code.

I think he meant function level comments on ChangeLogs, not on the code
itself.

 Or at least that's what it looks like. :-(-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEABECAAYFAk/3MI8ACgkQ+tuOMzntPWmSvwCfZX7mSpblM8xqtVYfMagmkS1V
6U4AoJOVtSW5QtfGk0C10boluUg+jzoe
vPjB
-END PGP SIGNATURE-
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] scrollInToView(true) have different behavior on WebKit and Firefox

2012-05-23 Thread Hugo Parente Lima
Hi,

While taking a look into bug 83419 (about fast/transforms/scrollIntoView-
transformed.html) I faced with the following render issue:

When using Element::scrollInToView(true) on blocking elements that have bigger 
child elements with margins webkit and Firefox show different results.

I attached the html file [1] and the render results on Firefox[2] and WebKit[3] 
into the bug, so what's the correct result?

IMO the Firefox behavior seems right, but before trying to fix anything better 
to know if a consensus on what is right exists.

The scrollInToView spec[4] says:

If the align to top flag is set align the top of the border box of the element 
to be scrolled into view with the top of the scrolling box.

[1] https://bug-83419-attachments.webkit.org/attachment.cgi?id=143619
[2] https://bug-83419-attachments.webkit.org/attachment.cgi?id=143620
[3] https://bug-83419-attachments.webkit.org/attachment.cgi?id=143621
[4] http://dev.w3.org/csswg/cssom-view/

Regards,
Hugo Parente Lima

signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Default viewport value on WAP DTDs

2012-05-08 Thread Hugo Parente Lima
 to turn on Tier 1
   content for us, and serves us the XHTML-MP (Tier 3?) content instead.
  
   As far as I understand, the decision comes from that team not wanting
   to dedicate resources to make sure the Tier 1 content keeps working on
   our device. I totally understand their reasoning and decision, but it
   is a saddens me given the promise of the open web and HTML5. It is
   even more sad that this is not a unique case and it will only be
   solved the day content providers stop looking at the user agent
   strings.
 

   Kenneth
  
   On Fri, May 4, 2012 at 11:32 PM, Ojan Vafai o...@chromium.org wrote:
Instead of UA faking, is it possible for you to pick an actual UA
 
  string
 
that is more compatible with the web at large? For Chromium we
experimented
with making the most minimal UA string possible without a big loss in
web
compatibility. To our disappointment, we found we had to match the
Safari UA
string almost exactly. Our current UA string is Mozilla/5.0 (X11;
 
  Linux
 
x86_64) AppleWebKit/536.6 (KHTML, like Gecko) Chrome/20.0.1096.1
Safari/536.6. The parts that we found to be safe to change are the
platform
names in the first sent of parenthesis. The version number after
AppleWebKit. And the Chrome/versionNumber section. Even getting rid
of
the
Safari/versionNumber caused us significant web compatibility
 
  problems.
   
That said, we did all this testing in 2008. The web may have changed
considerably since then. In either case, if your UA string diverges
 
  too
 
much, I expect this problem will just be the tip of the iceberg of
compatibility problems you'll encounter. So it might be worth
considering
changing your UA string before trying to add new DocType switching
behavior.
   
Ojan
   
On Fri, May 4, 2012 at 10:53 AM, Hugo Parente Lima
hugo.l...@openbossa.org
   
wrote:
On Friday, May 04, 2012 10:11:07 AM Ryosuke Niwa wrote:
 On Fri, May 4, 2012 at 9:39 AM, Kenneth Rohde Christiansen 

 kenneth.christian...@gmail.com wrote:
  This is not supporting XHTML-MP, as we are not implementing
  anything
  special to support it. We are basically showing the content as
 
it
  was
  HTML5 and that solves most real use-cases. Injecting a proper
  viewport
  configuration makes it also layout properly.

 Okay. Is this change observable by the page? Or more specifically,
 can a
 web page currently feature-detect whether a given browser support
 XHTML-MP
 by checking the size of the viewport?
   
The page knows nothing, just as it knows nothing about the ~980
 
  pixels
 
used
for the canvas width, it's a matter of change a magic value to the
device-
width to get websites better looking.
   
I attached screenshots of MiniBrowser runnin with and without the
 
  patch
 
using:
   
MiniBrowser --window-size 480x720 http://m.yahoo.com
   
Without patch (viewport of 980 pixels):
https://bug
85425-attachments.webkit.org/attachment.cgi?id0272
Patched (viewport of 880 pixels)
https://bug-85425-attachments.webkit.org/attachment.cgi?id0273
   
 If the answer is yes, then we'll be breaking the feature
 detection.

 Unfortunately most unknown mobile browsers tend to get lots of

  XHTML-MP. Heck, we even get that for google.com on the Nokia N9
  :
  :-(
  :
  as
  well as other high profile sites.

 Yeah, it's very unfortunate.

 This makes the sites render acceptable, until we can advocate the

  sites to accept our user agent, something which we haven't
  always
  had
  luck with. Google for one didn't want to provide us the Tier 1
 
  site
 
  of
  google.com on the N9, even though it works a lot better t
an the
  XHTML-MP version we are being served. I don't see this situation
  change any time soon.

 Can we work-around this issue by faking the user agent string?
   
If you are working on your own browser you wont be telling every
website
that
you are a iPhone forever, at least you will not be happy doing that.
   
Regards.
Hugo Parente Lima
   
___
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
  
   --
   Kenneth Rohde Christiansen
   Senior Engineer
   Nokia Mobile Phones, Browser / WebKit
eam
   Phone  +45 4093 0598 / E-mail kenneth at webkit.org
  
   http://codeposts.blogspot.com ﹆﹆﹆
 
  --
  Kenneth Rohde Christiansen
  Senior Engineer
  Nokia Mobile Phones, Browser / WebKit team
  Phone  +45 4093 0598 / E-mail kenneth at webkit.org
 
  http

Re: [webkit-dev] Default viewport value on WAP DTDs

2012-05-04 Thread Hugo Parente Lima
On Friday, May 04, 2012 10:11:07 AM Ryosuke Niwa wrote:
 On Fri, May 4, 2012 at 9:39 AM, Kenneth Rohde Christiansen 
 
 kenneth.christian...@gmail.com wrote:
  This is not supporting XHTML-MP, as we are not implementing anything
  special to support it. We are basically showing the content as it was
  HTML5 and that solves most real use-cases. Injecting a proper viewport
  configuration makes it also layout properly.
 
 Okay. Is this change observable by the page? Or more specifically, can a
 web page currently feature-detect whether a given browser support XHTML-MP
 by checking the size of the viewport?

The page knows nothing, just as it knows nothing about the ~980 pixels used 
for the canvas width, it's a matter of change a magic value to the device-
width to get websites better looking.

I attached screenshots of MiniBrowser runnin with and without the patch using:

MiniBrowser --window-size 480x720 http://m.yahoo.com

Without patch (viewport of 980 pixels):
https://bug-85425-attachments.webkit.org/attachment.cgi?id=140272
Patched (viewport of 880 pixels)
https://bug-85425-attachments.webkit.org/attachment.cgi?id=140273

 
 If the answer is yes, then we'll be breaking the feature detection.
 
 Unfortunately most unknown mobile browsers tend to get lots of
 
  XHTML-MP. Heck, we even get that for google.com on the Nokia N9 :-( as
  well as other high profile sites.
 
 Yeah, it's very unfortunate.
 
 This makes the sites render acceptable, until we can advocate the
 
  sites to accept our user agent, something which we haven't always had
  luck with. Google for one didn't want to provide us the Tier 1 site of
  google.com on the N9, even though it works a lot better than the
  XHTML-MP version we are being served. I don't see this situation
  change any time soon.
 
 Can we work-around this issue by faking the user agent string?

If you are working on your own browser you wont be telling every website that 
you are a iPhone forever, at least you will not be happy doing that.

Regards.
Hugo Parente Lima 


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Default viewport value on WAP DTDs

2012-05-03 Thread Hugo Parente Lima
Hi,

I was pointed to trigger a discussion here about the patch:

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

I'll try to resume to issue:

If no viewport is specified webkit uses the magic and well know value of 980 
pixels for the canvas width, this value is very good for most websites 
developed for desktop usage, on the other side there are the websites[1] 
developed for small screen mobile devices. Those websites will look pretty 
ugly on a 980 pixels canvas, many of those websites uses a different DTD like:

!DOCTYPE html PUBLIC -//WAPFORUM//DTD XHTML Mobile 1.0//EN 
http://www.wapforum.org/DTD/xhtml-mobile10.dtd;

The proposed patch changes the magic value of 980 pixels to device-width 
when this doctype is found causing the website to render nicely if the device 
screen is small, i.e. don't show the website in a 980 pixels canvas zoomed out 
to fit the 980 pixels screen.

Some webkit browsers already use this hack, like the N9 browser and if I 
understood correctly by the Zalan comments on the bug, the iOS Safari too.

Comments about why the viewport width should or shouldn't be changed by the 
doc type is appreciated. Thanks!

Regards
Hugo Parente Lima

[1] http://m.yahoo.com; http://www.google.com (using a user agent like: Nokia 
7110/1.0)


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Hugo Parente Lima
On Thursday 08 March 2012 17:12:47 Ryosuke Niwa wrote:
 On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat atr...@rim.com wrote:
  There is nothing about git that forces you to have multiple branches
  locally.  Good practice, yes, but nothing forcing it.  As for the
  difficulty of resolving conflicts between patches you've made locally and
  changes made on the shared repository since you started making your local
  patches... nothing about git makes this any harder.  Unless you have a
  lock based source control system you'll have to resolve conflicts.
 
 On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason jma...@rim.com wrote:
  It seems to me that there's no need to use multiple local branches in git
  if you find it confusing - it's an additional feature, but I don't see
  anything that requires it.
  
  What workflow do you have that requires you to have multiple branches
  locally in git, and how do you solve it in svn without using branches?
  
  What precisely do you find difficult about merging remote changes, and
  how is the svn equivalent easier?
 
 The simplicity. In git, I have to worry about things like committing local
 changes before rebasing to master, or stashing, etc... In svn, all I have
 to do is to run svn up.

git pull does the same (if no conflicts were found, but the same pain will 
happen on svn in case of conflicts)
 
or git fetch origin; git rebase origin/master

I remember the days were I switched from svn to git, blaming git for force me 
to type additional commands, today I'm just regrets for the blames and can't 
think in another VCS than git :-). 

 - Ryosuke

-- 
Hugo Parente Lima
INdT - Instituto Nokia de Tecnologia


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev