[webkit-dev] Webkit - Building Error

2007-11-29 Thread Piyush Sharma
Hi, All,

IWhile building WebKit Open Source with Qt on Flodra linux.
getting attached error ie. *can not find -lQtWebKit* in /../bin/QTLuncher.

Could you please help me out to resolve this error...

Please find attached error log.

Thanks  Regards
Piyush Sharma
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Comments on ProjectVision document

2007-11-29 Thread Maciej Stachowiak


On Nov 25, 2007, at 12:34 PM, Lars Knoll wrote:

I would prefer a discussion on the mailing list. I think it's  
important that
everyone contributing to the project can state it's opinion and hear  
all

arguments.


Sounds good to me.

Here's some parts I can comment on briefly:


Commit and review rights


I agree that we should have a fair and open policy on commit and  
review rights. Notwithstanding Alp's remarks that Apple has been  
reasonable in administering this, I think open source projects thrive  
on openness. I'm hoping we can improve the situation soon. One thing  
we are working on now is putting together a complete list of current  
committers anr reviewers to publish on the wiki.


Project planning should become more transparent. The mailing list  
should be used for larger discussions or decisions that affect all  
platforms, to give all involved parties a chance to comment.


I agree that large changes should be discussed on the mailing list.  
I'll try to post information about Apple's near to mid term feature,  
performance and architecture goals for the project to inform everyone  
and for discussion.


* Platforms need to have an idea of when to expect the next stable  
WebKit version.

* Releases should be time based.
* Release schedules and a (loosely defined) roadmap should be  
discussed and agreed upon inside the community.


These requests are pretty challenging to meet. We have a few  
conflicting constraints:


1) Currently more than half of development, and probably a bigger  
proportion of core cross-platform work, is done by Apple engineers.  
Also, most dogfood testing is currently done on the Mac platform via  
nightlies. That means it is strongly advantageous to be relatively in  
sync with Apple's release cycles; otherwise we'll be forced to do  
stabilization and feature development based on Apple product cycle in  
a vendor branch instead of on trunk. I think that would be a bad thing  
for the project as a whole, since Apple's Safari releases would end up  
out of sync with project releases.


2) Apple's general policy is to not comment on future product  
releases, either dates or features. For the WebKit open source  
project, it is obviously important to have shared discussion of the  
overall roadmap. So we finesse this by discussing plans and roadmap in  
general, and not details of the timetable.


3) As more organizations and companies ship WebKit-based products,  
there will be more different vendor release cycles to consider.


I can tell you that Apple's drive for stable WebKit releases is likely  
to become more frequent now that Safari 3 is out, and we are unlikely  
to see a gap as big as the Safari 2 -- Safari 3 gap for the  
foreseeable future.


We'll probably have to evolve our approach over time.

* The webkit.org/blog should aggregate the blogs of all contributors  
(Surfin' Safari and blogs of external contributors)


I think I'd like to keep Surfin' Safari as a blog for WebKit  
contributors where we also post occasionally Apple-focused info, and  
where any significant contributor is welcome to post. But I think we  
should add a planet.webkit.org type aggregator which includes Surfin'  
Safari and other WebKit contributor blogs.



* The main webpage and the navigation bar should be platform agnostic


I think the main page mostly is. Many of the pages linked from the  
sidebar have Mac or Safari specific info. However, that's not a matter  
of policy but just happens to be what the pages started with. The  
content is all in SVN and we welcome patches to add build info for  
other platforms. If we get enough different platforms maybe we can use  
a tab approach to split out instructions that are different per- 
platform.


* Safari specific things should go in a subpage (with a prominent  
link form the main page)


Is there anything on the main page that you consider Safari-specific?


* A free use WebKit logo would be great to have


I agree; I'm not a huge fan of the current one. We're thinking of  
having a design contest, I expect Adam will be starting some  
discussion about this.


Regards,
Maciej


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


[webkit-dev] Apple's feature and performance goals for WebKit

2007-11-29 Thread Maciej Stachowiak


In the spirit of greater openness, here are some of the general areas  
where Apple is interested in improvement in the near to mid term, in  
no particular order:


- Major JavaScript performance improvements. JavaScriptCore improved a  
lot since the Safari-3-stable branch; we think this is an important  
area for continuing improvement. We've already had a lot of non-Apple  
contribution here and welcome more.


- Support for offline web applications. We have local SQL storage now.  
We're also interested in many of the other evolving HTML 5 and Web API  
features for this.


- Better compliance to specifications including CSS 2.1,  
XMLHttpRequest, and so forth.


- Improvements to rich media integration (you can see this with the  
recent HTML5 video and audio support).


- Improvements to graphics, including more complete support for SVG  
and for new canvas features from HTML5 and other browsers.


- Continuing to push the envelope with CSS, with experimental support  
for advanced CSS features.


- HTML5 support generally, as the spec becomes more complete.

- Support for features of interest to web developers.

- Memory footprint improvements.

- Support for more advanced Web API specs of interest, such as  
possibly Selectors API or XMLHttpRequest v2.


- Continuing web compatibility improvements.

- Additional performance improvements to page load speed.

 We may post more details about some of these soon. I'm curious what  
is of interest to other WebKit contributors. I'm especially interested  
in areas where particular organizations or individuals might be  
interested in directly contributing.


It might be worth collecting this kind of data on a wiki page.

Regards,
Maciej

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


Re: [webkit-dev] Re: Comments on ProjectVision document

2007-11-29 Thread Adam Roben

Lars Knoll wrote:

On Thursday 29 November 2007, Maciej Stachowiak wrote:
  

On Nov 25, 2007, at 12:34 PM, Lars Knoll wrote:


* The webkit.org/blog should aggregate the blogs of all contributors
(Surfin' Safari and blogs of external contributors)
  

I think I'd like to keep Surfin' Safari as a blog for WebKit
contributors where we also post occasionally Apple-focused info, and
where any significant contributor is welcome to post. But I think we
should add a planet.webkit.org type aggregator which includes Surfin'
Safari and other WebKit contributor blogs.



Sounds good to me. The main thing is that it would be great to have a central 
place where all WebKit related blogs/news appears. Currently you have to 
search on lots of different places for blogs about WebKit (labs.trolltech.com 
and planetkde.org for the Qt port, planet.gnome.org for the Gtk port and 
other places for other people). This is IMO unfortunate as it doesn't give 
the public a good enough view on how large the community really is.
  


I can start working on setting up planet.webkit.org. I think it'll be a 
really nice resource.



* A free use WebKit logo would be great to have
  

I agree; I'm not a huge fan of the current one. We're thinking of
having a design contest, I expect Adam will be starting some
discussion about this.



Great to hear :)
  


Yes, I will be sending mail about this soon to this list.

-Adam

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


[webkit-dev] Calling all WebKit bloggers

2007-11-29 Thread Adam Roben

Hey everyone-
  I'm starting to work on setting up a blog aggregator at 
http://planet.webkit.org/ and am looking for a set of blogs to seed it 
with. If you have a blog that you'd like included, please send me an 
email at [EMAIL PROTECTED] with the URL of the feed you want 
aggregated. WebKit-specific category feeds are preferred over general 
ones. Thanks!


-Adam

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


Re: [webkit-dev] Calling all WebKit bloggers

2007-11-29 Thread Adam Roben

Robert Błaut wrote:

On 11/29/07, Adam Roben [EMAIL PROTECTED] wrote:
  

Hey everyone-
   I'm starting to work on setting up a blog aggregator at
http://planet.webkit.org/ and am looking for a set of blogs to seed it
with. If you have a blog that you'd like included, please send me an
email at [EMAIL PROTECTED] with the URL of the feed you want
aggregated. WebKit-specific category feeds are preferred over general
ones. Thanks!



It's great to hear that official Planet Webkit is creating now :) I've
prepared to set up a sort of unofficial Planet Webkit on webkit.pl
domain but it's currently pointless ;) So I want to share a part of
my Venus (http://www.intertwingly.net/code/venus/) config file with
blog URLs I've collected so far. I hope it will be helpful:
  


Thanks! I'll wait to get approval from the owners of these feeds before 
including them, but this is definitely a great starting point.


-Adam

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


Re: [webkit-dev] Calling all WebKit bloggers

2007-11-29 Thread Maciej Stachowiak


On Nov 29, 2007, at 12:17 PM, Robert Błaut wrote:


On 11/29/07, Adam Roben [EMAIL PROTECTED] wrote:

Hey everyone-
I'm starting to work on setting up a blog aggregator at
http://planet.webkit.org/ and am looking for a set of blogs to  
seed it

with. If you have a blog that you'd like included, please send me an
email at [EMAIL PROTECTED] with the URL of the feed you want
aggregated. WebKit-specific category feeds are preferred over general
ones. Thanks!


It's great to hear that official Planet Webkit is creating now :) I've
prepared to set up a sort of unofficial Planet Webkit on webkit.pl
domain but it's currently pointless ;) So I want to share a part of
my Venus (http://www.intertwingly.net/code/venus/) config file with
blog URLs I've collected so far. I hope it will be helpful:


We should probably limit it to blogs by people who consider themselves  
WebKit contributors. I would guess currently some KHTML developers do  
not think of themselves that way at all (for example Maks, although  
he's a great guy and maybe we will win him over someday).


Cheers,
Maciej




[http://webkit.org/blog/feed/atom/]
name = Surfin' Safari
blog = 1

[http://www.atoker.com/blog/feed/]
name = Alp Toker
blog = 1
filter = webkit|kthml

[http://labs.trolltech.com/blogs/feed/atom/]
name = Trolltech Labs
blog = 1
filter = webkit|khtml

[http://zrusin.blogspot.com/feeds/posts/default]
name = Zack Rusin
blog = 1
filter  = webkit|khtml

[http://bdash.net.nz/blog/feed.atom]
name = Mark Rowe
blog = 1
filter = webkit

[http://www.kdedevelopers.org/blog/278/feed]
name = Allan Sandfeld Jensen
blog = 1
filter = webkit|khtml

[http://www.kdedevelopers.org/blog/1088/feed]
name = Nikolas Zimmermann
blog = 1
filter = webkit|khtml

[http://www.kdedevelopers.org/blog/1089/feed]
name = Rob Buis
blog = 1
filter = webkit|khtml

[http://www.kdedevelopers.org/blog/105/feed]
name = Adam Treat
blog = 1
filter = webkit|khtml

[http://www.kdedevelopers.org/blog/11/feed]
name = Maksim Orlovich
blog = 1
filter = webkit|khtml

[http://blog.justinhaygood.com/feed/]
name = Justin Haygood
blog = 1
filter = webkit|khtml

[http://zecke.blogspot.com/feeds/posts/default]
name = Holger Freyther
blog = 1
filter = webkit|khtml

PS. Adam, sorry for duplicate :(
--
Regards
Robert Blaut
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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


Re: [webkit-dev] Calling all WebKit bloggers

2007-11-29 Thread Adam Roben

Maciej Stachowiak wrote:


On Nov 29, 2007, at 12:17 PM, Robert Błaut wrote:


On 11/29/07, Adam Roben [EMAIL PROTECTED] wrote:

Hey everyone-
I'm starting to work on setting up a blog aggregator at
http://planet.webkit.org/ and am looking for a set of blogs to 
seed it

with. If you have a blog that you'd like included, please send me an
email at [EMAIL PROTECTED] with the URL of the feed you want
aggregated. WebKit-specific category feeds are preferred over general
ones. Thanks!


It's great to hear that official Planet Webkit is creating now :) I've
prepared to set up a sort of unofficial Planet Webkit on webkit.pl
domain but it's currently pointless ;) So I want to share a part of
my Venus (http://www.intertwingly.net/code/venus/) config file with
blog URLs I've collected so far. I hope it will be helpful:


We should probably limit it to blogs by people who consider themselves 
WebKit contributors. I would guess currently some KHTML developers do 
not think of themselves that way at all (for example Maks, although 
he's a great guy and maybe we will win him over someday).


I agree with Maciej here, which is why I'm asking for people to nominate 
their own feeds. It would also be great if we could have most of the 
feeds be WebKit-specific ones, perhaps through the use of 
tag/category-specific feeds.


-Adam

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


Re: [webkit-dev] Apple's feature and performance goals for WebKit

2007-11-29 Thread Maciej Stachowiak


On Nov 29, 2007, at 3:16 PM, Nicholas Shanks wrote:


On 29 Nov 2007, at 10:56, Maciej Stachowiak wrote:

We may post more details about some of these soon. I'm curious what  
is of interest to other WebKit contributors. I'm especially  
interested in areas where particular organizations or individuals  
might be interested in directly contributing.



In reply to Maciej's goals email, I thought more about the features  
I would like to see in WebKit that are not there for one reason or  
another, and would like to know how best to add these on a  
conditional basis such that normal users can remain oblivious, and  
power users can customise them. For example, an API for Safari,  
NetNewsWire, Sandvox c. to hook into, or user defaults that apply  
to all WebKit clients without the app needing to support them  
explicitly. In the case of the latter, how should the defaults be  
named?


Things I would like to see (new features and high priority bugs)  
include…


• Fixed support for :last-child, :nth-child and related selectors.  
This is probably the biggest issue.


I agree with complete support for Selectors as a goal. I don't think  
this needs to be conditional in any way. One thing that is important  
is to make sure that support is added in a way that is performant and  
properly handles dynamic updates, so we don't set ourselves up


• Support for better typography, including kerning, automatic  
ligatures, true (AAT/OpenType) Small Caps, font-stretch, c.  (this  
can be a pref—off by default, if Apple prefers performance to  
presentation. As I have a fast computer i don't really care about a  
few milliseconds here or there during layout, i spend much longer  
reading the text than i spend waiting for it to be drawn. Maybe  
there should be browser engine tests that examine how easy the  
screen is to read.)


We're interested in investigating ways to get better typography  
without as much or possibly any perf hit. I'd agree with this as a  
goal. I guess I should have mentioned typography and text support, and  
I think our @font-face support shows our commitment there.


• Support for the link navigation elements in HTML headers and an  
API to be exposed with Safari implementation.


The DOM API is sufficient for WebKit clients to implement this if they  
choose to. Having this as a UI feature in Safari is not a WebKit  
request so I can't comment on that.


• Alternate stylesheets automatically offered with Safari interface  
for switching between them  (will require API for other WebKit  
clients)


The DOM API exposes alternate stylesheet switching. As for the Safari  
UI feature request, again, this is not the place.


• Allow user disabling of horrible/clueless author stylesheets   
(will require API)


Again, already possible at the API level, UI requests should go to the  
relevant browsers.


• A means by which to inject CSS and JavaScript into sites I visit,  
and have those modifications remembered across sessions.


Same thing - I think the needed API is there, can't comment on it as a  
UI request.


• A means by which to disable quirks mode for text/html (i would  
like this to be a persistent pref)


That does not make sense to me. What possible reason would there be to  
show a quirks mode page in standards mode? Standards mode pages  
already do not trigger quirks mode. But if you really want this at the  
API level, you can do it by preprocessing incoming HTML to force a  
standards mode doctype.


• A means by which to disable marquee, applet or other arbitrary  
things


Applet can be disabled by turning off Java. marquee can be  
(effectively) disabled with a user stylesheet.


• Ability to right-click on an element and remove it from flow  
(probably by adding a display: none attribute; so the DOM tree is  
intact)


The API capabilities needed for this are there. Can't comment on it as  
a UI feature request.


• Ability to customise one's HTTP headers manually, especially the  
Accept-* ones  (another persistent pref)
	• and further, the ability to specify what headers would be  
automatically sent in response to a 3xx code


This capability exists at the API level (ever request is sent to the  
ResourceLoadDelegate before hitting the net). Can't comment on it as a  
UI feature request.


• When rendering a web page aurally, the page should go through a  
series of xslt transformations: (HTML to) XHTML to SSML,  which  
would then either be sent to a third party TTS (e.g. swift from  
cepstral.com) or further transformed to PlainTalk + Applebet and  
sent to the Speech Manager.


I think the current VoiceOver architecture works fine for rendering  
web pages aurally, or at least, any specific issues could be addressed  
based on the existing architecture. I'm not sure what the basis for  
your request is.



And a developer-only feature:
• A means by which to manipulate the current media to something  
other than screen (e.g. for previewing tv, handheld, print,  

Re: [webkit-dev] Apple's feature and performance goals for WebKit

2007-11-29 Thread Nicholas Shanks

On 30 Nov 2007, at 00:27, Maciej Stachowiak wrote:

• Support for the link navigation elements in HTML headers and an  
API to be exposed with Safari implementation.


The DOM API is sufficient for WebKit clients to implement this if  
they choose to.


Well that could lead to incompatible or buggy implementations in some  
clients. I think it would be better if WebKit offered a simple  
dictionary or whatever that everyone can use equivalently. If a client  
wants to write their own and parse the relevant parts of the DOM  
themselves, they're free too, but don't force every implementation to  
reinvent this wheel.


• Alternate stylesheets automatically offered with Safari interface  
for switching between them  (will require API for other WebKit  
clients)


The DOM API exposes alternate stylesheet switching.


Didn't know that. Cool :-)

• Allow user disabling of horrible/clueless author stylesheets   
(will require API)


Again, already possible at the API level.

• A means by which to inject CSS and JavaScript into sites I visit,  
and have those modifications remembered across sessions.


Same thing - I think the needed API is there.


Okay, this is good. I'm not too sure where the lines are drawn between  
what should be done in the client and what should be done in the  
engine. I wanted the latter one to apply wherever WebKit was used  
though, not just in one client browser or another.


• A means by which to disable quirks mode for text/html (i would  
like this to be a persistent pref)


That does not make sense to me. What possible reason would there be  
to show a quirks mode page in standards mode?


Mostly to see how horrible it looks. I don't want to grace such sites  
with my patronage, and it would be nice if I could be told, rather  
than having the fact covered up. It's basically for developers and  
standardistas but would also be useful for gauging the competency of  
the author. Not a high priority.


• A means by which to disable marquee, applet or other  
arbitrary things


Applet can be disabled by turning off Java. marquee can be  
(effectively) disabled with a user stylesheet.


I meant make them be treated as unrecognised tags. But, other  
'arbitrary' things could include XMLHttpRequest or other areas of  
JavaScript, whilst leaving the rest functional. This isn't a high one  
on my list either :-)


• Ability to right-click on an element and remove it from flow  
(probably by adding a display: none attribute; so the DOM tree is  
intact)


The API capabilities needed for this are there. Can't comment on it  
as a UI feature request.


I thought contextual menus were handled by WebKit. Again, this isn't  
something that should only be in one client app, but ought to be  
everywhere HTML is rendered, so that the user experience is consistent  
and the feature doesn't get mis-implemented or simply left missing  
from some client.


• Ability to customise one's HTTP headers manually, especially the  
Accept-* ones  (another persistent pref)
	• and further, the ability to specify what headers would be  
automatically sent in response to a 3xx code


This capability exists at the API level (every request is sent to  
the ResourceLoadDelegate before hitting the net).


Okay, good to hear.

 When rendering a web page aurally, the page should go through a  
series of xslt transformations: (HTML to) XHTML to SSML,  which  
would then either be sent to a third party TTS (e.g. swift from  
cepstral.com) or further transformed to PlainTalk + Applebet and  
sent to the Speech Manager.


I think the current VoiceOver architecture works fine for rendering  
web pages aurally, or at least, any specific issues could be  
addressed based on the existing architecture. I'm not sure what the  
basis for your request is.


I want to include pronunciation data in my web pages. The only way to  
do that (that I can see) is with SSML embedded in an XHTML document.  
This would be used for isolate words, whose pronunciation cannot be  
discerned from context, and cases where pronunciation of a word or  
phrase differs from what a person would normally expect (perhaps a  
page discussing phonology or speech impediments). Even if computers  
were as smart as humans at language processing, they'd still get it  
wrong. That's why the pronunciation needs to be explicit.



And a developer-only feature:
• A means by which to manipulate the current media to something  
other than screen (e.g. for previewing tv, handheld, print,  
projection) and override various media properties manually (page  
dimensions, maximum volume) so media queries can be tested against  
them.


This is a case where I don't think we currently have the right API  
capabilities. I encourage you to file a bug.


another day perhaps, it's 2am now.

- Nicholas.



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

[webkit-dev] planet.webkit.org update

2007-11-29 Thread Adam Roben

Hey everyone-

I'm in the process of setting up planet.webkit.org, and thought I'd send 
along a quick update:


First, thanks to our kind (and speedy!) server administrator, we've got 
the domain all ready to go. Don't get too excited -- it's just a blank 
page for now.


Second, my plan is to get things configured and working on the server, 
then check in everything to Subversion. That way it'll be easy just as 
easy to modify planet.webkit.org as it is to modify webkit.org. I'm 
particularly hoping someone will come up with a nice stylesheet for it.


Third, I wanted to propose a few simple guidelines for planet.webkit.org:

1. No feed will be added without the owner's consent.
2. Only feeds belonging to WebKit contributors will be aggregated.
3. Feeds that are proposed to be added to planet.webkit.org should 
either be WebKit-specific, or contain a high proportion of 
WebKit-related content.
4. If a feed is found to contain a high proportion of non-WebKit-related 
content, the feed's owner will be asked to provide a WebKit-specific 
feed. If the owner fails to do so, the feed may be removed.


My hope is that these guidelines will help us to make planet.webkit.org 
friendly, informative, and relevant to WebKit development.


I'll send out another email when the site is up. Thanks!

-Adam

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