[webkit-dev] webkit-dev Digest, Vol 73, Issue 28
523060808
523060808 at qq.com
Wed Jun 22 07:02:04 PDT 2011
thank you!
2011-06-22
523060808
发件人： webkit-dev-request
发送时间： 2011-06-22 22:00:33
收件人： webkit-dev
抄送：
主题： webkit-dev Digest, Vol 73, Issue 28
Send webkit-dev mailing list submissions to
webkit-dev at lists.webkit.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
or, via email, send a message with subject or body 'help' to
webkit-dev-request at lists.webkit.org
You can reach the person managing the list at
webkit-dev-owner at lists.webkit.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of webkit-dev digest..."
Today's Topics:
1. MathML Anonymous Block Conundrum (Alex Milowski)
2. Making Webkit - PluginViewGtk.cpp error (Tom Smith)
3. Re: Making Webkit - PluginViewGtk.cpp error (Ariya Hidayat)
4. Re: Making Webkit - PluginViewGtk.cpp error (Tom Smith)
5. Re: DumpRenderTree for the EFL port :) (Raphael Kubo da Costa)
6. Accessibility Object Searching (Samuel White)
7. Re: Accessibility Object Searching (Charles Pritchard)
8. Re: Accessibility Object Searching (Chris Fleizach)
9. Re: Accessibility Object Searching (Chris Fleizach)
10. Re: Spellcheck API for WebKit (Simon Fraser)
11. Re: Spellcheck API for WebKit (Hironori Bono (?? ??))
12. Re: Spellcheck API for WebKit (Ryosuke Niwa)
13. Setting up Eclipse IDE for Webkit.. (Tom Smith)
14. Re: Setting up Eclipse IDE for Webkit.. (Alexis Menard)
----------------------------------------------------------------------
Message: 1
Date: Tue, 21 Jun 2011 15:39:12 +0100
From: Alex Milowski <alex at milowski.org>
To: webkit-dev Development <webkit-dev at lists.webkit.org>
Subject: [webkit-dev] MathML Anonymous Block Conundrum
Message-ID: <BANLkTimJhZQBYdNsaMMt+L6ZTKMh2gfibA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I've run into a conundrum with "anonymous blocks" yet again. I was
helping track down a crash relating to DOM manipulation. While I
fixed that particular case by just marking all the instances as
anonymous blocks, this solution doesn't work in general.
In many places in the MathML rendering code we create
RenderMathMLBlock instances that are used to layout different
constructs. For example, for fractions we stack two RenderMathMLBlock
instances as wrappers for the numerator and denominator. In many
instances, that is all we need to do. In other instances, such as
fractions, we set style properties on each created instance.
Here's the problem:
If the created wrappers are marked as anonymous, the style created for
the wrapper is ignored due to this bit from the CSS 2.1
recommendation:
"The properties of anonymous boxes are inherited from the enclosing
non-anonymous box (e.g., in the example just below the subsection
heading "Anonymous block boxes", the one for DIV). Non-inherited
properties have their initial value. For example, the font of the
anonymous box is inherited from the DIV, but the margins will be 0."
[1]
If we don't mark them as anonymous, we can get a crash related to
Javascript DOM manipulation at RenderBlock.cpp:680:
ASSERT(anonymousChild->isAnonymous());
where it is searching for the anonymous wrapper that doesn't exist.
In fact, I believe the problem is that the beforeChild parameter is
the rendering object that has been wrapped and not the wrapper. As
such, beforeChild is "wrong" and by adding something like:
if (beforeChild && !beforeChild->isRenderMathMLBlock())
beforeChild = beforeChild->parent();
I can fix that before I use it to add the wrapper. I would have to do
this in all places where I know that I have wrappers with styles and
where I could actually guarantee what I'm doing. In the case of
fractions, over/under, and a few others, this may work fine.
This doesn't feel like a good general solution.
Also, if I wrap an added child and code elsewhere assumes that the
parent/child relationship is the same as in the DOM, then I've broken
their assumption. I see this same kind of behavior with table
sections in the RenderTable object and I wonder why beforeChild isn't
a problem there.
I fail to understand why I need to mark things as anonymous as they
aren't anonymous in the same sense of CSS. This is a layout construct
needed to display the Mathematics. I need to create these rendering
objects that do not correspond directly to a element in the way as
most others do.
I think I'm beginning to appreciate some of what Dave Hyatt was
hinting at to me that I may need my own line layout algorithm but I
still really don't want to go there. That is, layout of a fraction
doesn't feel like line layout to me.
--
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."
Bertrand Russell in a footnote of Principles of Mathematics
------------------------------
Message: 2
Date: Tue, 21 Jun 2011 12:16:52 -0400
From: Tom Smith <penguin.linux1 at gmail.com>
To: webkit-dev at lists.webkit.org
Subject: [webkit-dev] Making Webkit - PluginViewGtk.cpp error
Message-ID: <BANLkTi=Vyv1LoWiyJhOmzCfhuj8pOyXoHA at mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Hello,
I'm trying to install Webkit on Ubuntu, but I get the following error:
WebCore/plugins/gtk/PluginViewGtk.cpp: In member function ?void
WebCore::PluginView::init()?:
WebCore/plugins/gtk/PluginViewGtk.cpp:552: error:
?NPSetWindowCallbackStruct? was not declared in this scope
WebCore/plugins/gtk/PluginViewGtk.cpp:552: error: ?ws? was not declared in
this scope
WebCore/plugins/gtk/PluginViewGtk.cpp:552: error: expected type-specifier
before ?NPSetWindowCallbackStruct?
WebCore/plugins/gtk/PluginViewGtk.cpp:552: error: expected ?;? before
?NPSetWindowCallbackStruct?
WebCore/plugins/gtk/PluginViewGtk.cpp:572: error: ?struct NPWindow? has no
member named ?ws_info?
make[1]: *** [WebCore/plugins/gtk/libWebCore_la-PluginViewGtk.lo] Error 1
make[1]: Leaving directory `/home/screamer/Canmore/usr/src/WebKit-r36247'
make: *** [all] Error 2
I tried looking at the PluginViewGtk.cpp file, but I'm not sure how to fix
this. Can anyone help?
Best regards,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110621/a2fa2b94/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 21 Jun 2011 09:32:41 -0700
From: Ariya Hidayat <ariya.hidayat at gmail.com>
To: Tom Smith <penguin.linux1 at gmail.com>
Cc: webkit-dev at lists.webkit.org
Subject: Re: [webkit-dev] Making Webkit - PluginViewGtk.cpp error
Message-ID: <BANLkTimR7+aB0wRkcKyUhe6KXSNoDTY8=g at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
You post too many build errors lately. Care to tell us what exactly
did you run? How did you invoke the 'build-webkit' script?
--
Ariya Hidayat
http://www.linkedin.com/in/ariyahidayat
------------------------------
Message: 4
Date: Tue, 21 Jun 2011 13:51:01 -0400
From: Tom Smith <penguin.linux1 at gmail.com>
To: Ariya Hidayat <ariya.hidayat at gmail.com>
Cc: webkit-dev at lists.webkit.org
Subject: Re: [webkit-dev] Making Webkit - PluginViewGtk.cpp error
Message-ID: <BANLkTinq9xgiyvBW=Em6RJwZeYTT1NaQEg at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I used the command: ./autogen.sh --prefix=${BUILD_DEST} to setup and
configure webkit, which compiled fine. But I get errors when I try to make
it. I'm running Ubuntu 10.10 with
WebKit-r36247.
Best regards,
Tom
On Tue, Jun 21, 2011 at 12:32 PM, Ariya Hidayat <ariya.hidayat at gmail.com>wrote:
> You post too many build errors lately. Care to tell us what exactly
> did you run? How did you invoke the 'build-webkit' script?
>
>
>
> --
> Ariya Hidayat
> http://www.linkedin.com/in/ariyahidayat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110621/9aa2c209/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 21 Jun 2011 16:34:59 -0300
From: Raphael Kubo da Costa <kubo at profusion.mobi>
To: webkit-dev at lists.webkit.org
Subject: Re: [webkit-dev] DumpRenderTree for the EFL port :)
Message-ID: <87pqm7dllo.fsf at profusion.mobi>
Content-Type: text/plain
Leandro Pereira <leandro at profusion.mobi> writes:
> At last, the EFL port of WebKit got a DumpRenderTree implementation!
> We're still working on ironing out a lot of bugs found by some of the
> LayoutTests, but the DRT (and ImageDiff) code has been submitted to
> Bugzilla. It would be awesome if anyone could help reviewing these
> patches.
Thanks to eseidel, a few of our patchas have already made their way
upstream.
Unfortunately, he needs to take a break from too much exposure to
C-style code, so we need someone else to review our remaining
patches :-)
The remaining DRT patches are:
https://bugs.webkit.org/show_bug.cgi?id=61962
https://bugs.webkit.org/show_bug.cgi?id=61974
https://bugs.webkit.org/show_bug.cgi?id=63086
https://bugs.webkit.org/show_bug.cgi?id=61974
--
Raphael Kubo da Costa
ProFUSION embedded systems
http://profusion.mobi
------------------------------
Message: 6
Date: Tue, 21 Jun 2011 16:30:47 -0700
From: Samuel White <samuel_white at apple.com>
To: webkit-dev at lists.webkit.org
Subject: [webkit-dev] Accessibility Object Searching
Message-ID: <87C46CFC-F185-44D6-8986-F32DC1203C71 at apple.com>
Content-Type: text/plain; CHARSET=US-ASCII
Hey everybody,
I'm new to the list and thought it would be a good idea to get some feedback on an accessibility feature before filing a bug or submitting anything. Currently, no functionality exists in WebKit to search through AccessibilityObjects using basic search criteria like next link or next table internally. Screen readers and other access devices often must instead probe WebKit and build up their own internal representation of a page before they can begin searching for what they are after. This presents two big problems for the users of access technology. First, pages such as the HTML 5 working doc have a massive number of DOM elements and building up an external representation can be a very expensive and slow task. Secondly, maintaining an accurate external representation of a site can become difficult if that site has a large amount of dynamic content and users may not be accessing relevant information.
I would like to make a few small changes to the AccessibilityObject class that adds the functionality I've mentioned. I think these small but important additions will allow existing access technologies to rely much more on WebKits representation of a page and thus eliminate the problems I've described above. I appreciate any feedback and look forward to helping out.
Thanks
Sam
------------------------------
Message: 7
Date: Tue, 21 Jun 2011 17:45:36 -0700
From: Charles Pritchard <chuck at jumis.com>
To: Samuel White <samuel_white at apple.com>
Cc: "webkit-dev at lists.webkit.org" <webkit-dev at lists.webkit.org>
Subject: Re: [webkit-dev] Accessibility Object Searching
Message-ID: <DB51F91C-7EFA-44A3-A2F1-6614A25BF3C3 at jumis.com>
Content-Type: text/plain; charset=us-ascii
On Jun 21, 2011, at 4:30 PM, Samuel White <samuel_white at apple.com> wrote:
> Hey everybody,
>
> I'm new to the list and thought it would be a good idea to get some feedback on an accessibility feature before filing a bug or submitting anything. Currently, no functionality exists in WebKit to search through AccessibilityObjects using basic search criteria like next link or next table internally. Screen readers and other access devices often must instead probe WebKit and build up their own internal representation of a page before they can begin searching for what they are after. This presents two big problems for the users of access technology. First, pages such as the HTML 5 working doc have a massive number of DOM elements and building up an external representation can be a very expensive and slow task. Secondly, maintaining an accurate external representation of a site can become difficult if that site has a large amount of dynamic content and users may not be accessing relevant information.
>
> I would like to make a few small changes to the AccessibilityObject class that adds the functionality I've mentioned. I think these small but important additions will allow existing access technologies to rely much more on WebKits representation of a page and thus eliminate the problems I've described above. I appreciate any feedback and look forward to helping out.
>
> Thanks
> Sam
While you're rooting around in there, I'd love to see the tree exposed to WebKit inspector at some point. It might make ARIA a little easier to use.
I'm still months away from being a contributor-- I'm hoping to see the canvas shadow DOM made accessible, and subsequently, see paths supported by assistive technology, like Apple's gesture-based eyes-free mode in Mobile Safari/iOS.
-Charles
------------------------------
Message: 8
Date: Tue, 21 Jun 2011 18:56:44 -0700
From: Chris Fleizach <cfleizach at apple.com>
To: Samuel White <samuel_white at apple.com>
Cc: webkit-dev at lists.webkit.org
Subject: Re: [webkit-dev] Accessibility Object Searching
Message-ID: <342566E7-B50F-4192-B66A-BE57F23BBF01 at apple.com>
Content-Type: text/plain; CHARSET=US-ASCII
Searching for elements on a webpage is one of the important functions for a screen reader, so this has the potential for vastly improving screen reader access on the web.
What's nice about this approach is that it will allow other platforms to also take advantage. It should significantly reduce memory usage, number of IPC calls and overall runtime whenever searching is done.
On Jun 21, 2011, at 4:30 PM, Samuel White wrote:
> Hey everybody,
>
> I'm new to the list and thought it would be a good idea to get some feedback on an accessibility feature before filing a bug or submitting anything. Currently, no functionality exists in WebKit to search through AccessibilityObjects using basic search criteria like next link or next table internally. Screen readers and other access devices often must instead probe WebKit and build up their own internal representation of a page before they can begin searching for what they are after. This presents two big problems for the users of access technology. First, pages such as the HTML 5 working doc have a massive number of DOM elements and building up an external representation can be a very expensive and slow task. Secondly, maintaining an accurate external representation of a site can become difficult if that site has a large amount of dynamic content and users may not be accessing relevant information.
>
> I would like to make a few small changes to the AccessibilityObject class that adds the functionality I've mentioned. I think these small but important additions will allow existing access technologies to rely much more on WebKits representation of a page and thus eliminate the problems I've described above. I appreciate any feedback and look forward to helping out.
>
> Thanks
> Sam
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
------------------------------
Message: 9
Date: Tue, 21 Jun 2011 18:59:42 -0700
From: Chris Fleizach <cfleizach at apple.com>
To: Charles Pritchard <chuck at jumis.com>
Cc: "webkit-dev at lists.webkit.org" <webkit-dev at lists.webkit.org>
Subject: Re: [webkit-dev] Accessibility Object Searching
Message-ID: <DCEDCDAD-A113-454B-B883-71EE7FF6C267 at apple.com>
Content-Type: text/plain; CHARSET=US-ASCII
On Jun 21, 2011, at 5:45 PM, Charles Pritchard wrote:
> On Jun 21, 2011, at 4:30 PM, Samuel White <samuel_white at apple.com> wrote:
>
>> Hey everybody,
>>
>> I'm new to the list and thought it would be a good idea to get some feedback on an accessibility feature before filing a bug or submitting anything. Currently, no functionality exists in WebKit to search through AccessibilityObjects using basic search criteria like next link or next table internally. Screen readers and other access devices often must instead probe WebKit and build up their own internal representation of a page before they can begin searching for what they are after. This presents two big problems for the users of access technology. First, pages such as the HTML 5 working doc have a massive number of DOM elements and building up an external representation can be a very expensive and slow task. Secondly, maintaining an accurate external representation of a site can become difficult if that site has a large amount of dynamic content and users may not be accessing relevant information.
>>
>> I would like to make a few small changes to the AccessibilityObject class that adds the functionality I've mentioned. I think these small but important additions will allow existing access technologies to rely much more on WebKits representation of a page and thus eliminate the problems I've described above. I appreciate any feedback and look forward to helping out.
>>
>> Thanks
>> Sam
>
> While you're rooting around in there, I'd love to see the tree exposed to WebKit inspector at some point. It might make ARIA a little easier to use.
>
The accessibility hierarchy is usually coupled (tightly at times) to the platform's implementation. Often there are tools on the platform to help figure out the accessibility hierarchy.
On the Mac, there's "Accessibility Inspector", which conveniently can also be run on the iOS simulator. Just start the program and hover the mouse over an item on a webpage to learn how it's exposed to the platform.
> I'm still months away from being a contributor-- I'm hoping to see the canvas shadow DOM made accessible, and subsequently, see paths supported by assistive technology, like Apple's gesture-based eyes-free mode in Mobile Safari/iOS.
>
> -Charles
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
------------------------------
Message: 10
Date: Tue, 21 Jun 2011 21:17:22 -0700
From: Simon Fraser <simon.fraser at apple.com>
To: Hironori Bono (?? ??) <hbono at chromium.org>
Cc: webkit-dev Development <webkit-dev at lists.webkit.org>
Subject: Re: [webkit-dev] Spellcheck API for WebKit
Message-ID: <F2275B0C-3EE9-4E81-9C0E-B2E63E176664 at apple.com>
Content-Type: text/plain; charset=utf-8
On May 31, 2011, at 3:38 AM, Hironori Bono (?? ??) wrote:
> Greetings WebKit developers,
>
> These days, we have talked about adding Spellcheck API in the
> public-webapps ML:
> <http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0516>.
> This API currently consists of two functions (addSpellcheckRange and
> removeSpellcheckRange) and an attribute (spellcheckRanges) to editable
> elements of HTML so web-application developers (and extension
> developers) can implement custom spellcheckers. Also, I have uploaded
> a reference implementation of this API to <http://webkit.org/b/59693>.
> Even though this change enables this SpellcheckAPI only on Chromium,
> it would be definitely helpful to give me your feedback not only for
> this Spellcheck API and also for my WebKit change.
> Thank you for your help in advance.
This new API got turn on inadvertently on Mac just now, and a few of us spent
a wasted hour trying to get things to build. In this light, my comments on the API
may not be as favorable as they would otherwise be.
First, why is the API on HTMLDivElement?
Second, since this exposes to the web API in a non-final spec, the new methods
should be prefixed with 'webkit' to avoid potential conflict if the API changes later.
Simon
------------------------------
Message: 11
Date: Wed, 22 Jun 2011 15:04:09 +0900
From: Hironori Bono (?? ??) <hbono at chromium.org>
To: Simon Fraser <simon.fraser at apple.com>
Cc: webkit-dev Development <webkit-dev at lists.webkit.org>
Subject: Re: [webkit-dev] Spellcheck API for WebKit
Message-ID:
<BANLkTim9TzR2y70AJpWJSM1WJVY7qE+LQdjb5RP6bEkvxrXbCw at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Greetings Simon,
Apologies for my stupid change in advance.
My change just tried to straightforwardly implement a suggestion
<http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0545.html>
without deep consideration about WebKit manners noted by your e-mail.
On Wed, Jun 22, 2011 at 1:17 PM, Simon Fraser <simon.fraser at apple.com> wrote:
> This new API got turn on inadvertently on Mac just now, and a few of us spent
> a wasted hour trying to get things to build. In this light, my comments on the API
> may not be as favorable as they would otherwise be.
>
> First, why is the API on HTMLDivElement?
Unfortunately, I have just copied and pasted my code in
HTMLTextAreaElement to support contenteditable elements and designMode
ones because I did not have better ideas at that time. I should have
asked about it in this ML before landing this change.
> Second, since this exposes to the web API in a non-final spec, the new methods
> should be prefixed with 'webkit' to avoid potential conflict if the API changes later.
This is totally my fault. (The sin of ignorance.) Sorry again for that.
By the way, I wonder how I should treat my r88332 even though I
understand this change was wrong. Even though there are several
options: 1. re-design the API, 2. revert my r88332 and re-implement
it, 3. send changes that apply these comments, etc. Would it be
possible to give me your advice?
Regards,
Hironori Bono
E-mail: hbono at chromium.org
------------------------------
Message: 12
Date: Tue, 21 Jun 2011 23:27:12 -0700
From: Ryosuke Niwa <rniwa at webkit.org>
To: Hironori Bono (?? ??) <hbono at chromium.org>
Cc: webkit-dev Development <webkit-dev at lists.webkit.org>
Subject: Re: [webkit-dev] Spellcheck API for WebKit
Message-ID: <BANLkTini7srECj3Oj-wCa=BOK+FdZZEKsw at mail.gmail.com>
Content-Type: text/plain; charset="iso-2022-jp"
2011/6/21 Hironori Bono (?? ??) <hbono at chromium.org>
>
> On Wed, Jun 22, 2011 at 1:17 PM, Simon Fraser <simon.fraser at apple.com>
> wrote:
> > This new API got turn on inadvertently on Mac just now, and a few of us
> spent
> > a wasted hour trying to get things to build. In this light, my comments
> on the API
> > may not be as favorable as they would otherwise be.
> >
> > First, why is the API on HTMLDivElement?
>
> Unfortunately, I have just copied and pasted my code in
> HTMLTextAreaElement to support contenteditable elements and designMode
> ones because I did not have better ideas at that time. I should have
> asked about it in this ML before landing this change.
>
contenteditable attribute can appear in any element so I don't think we
should restrict it to div.
> Second, since this exposes to the web API in a non-final spec, the new
> methods
> > should be prefixed with 'webkit' to avoid potential conflict if the API
> changes later.
>
> This is totally my fault. (The sin of ignorance.) Sorry again for that.
>
> By the way, I wonder how I should treat my r88332 even though I
> understand this change was wrong. Even though there are several
> options: 1. re-design the API, 2. revert my r88332 and re-implement
> it, 3. send changes that apply these comments, etc. Would it be
> possible to give me your advice?
>
Given that the original patch seems to have various issues and we're going
to make a lot of changes (i.e. move it to HTMLElement and prefix it with
webkit or chrome), option 2 seems most suitable approach here.
- Ryosuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110621/aabce8e8/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 22 Jun 2011 09:19:05 -0400
From: Tom Smith <penguin.linux1 at gmail.com>
To: webkit-dev Development <webkit-dev at lists.webkit.org>
Subject: [webkit-dev] Setting up Eclipse IDE for Webkit..
Message-ID: <BANLkTi=vuYFpzdpWR5cfQ2iXAE9KNA5veg at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi everyone,
Has anyone used Eclipse IDE on Ubuntu? If so do you have
any recommendations?
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110622/0bf55c8a/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 22 Jun 2011 10:22:24 -0300
From: Alexis Menard <alexis.menard at openbossa.org>
To: Tom Smith <penguin.linux1 at gmail.com>
Cc: webkit-dev Development <webkit-dev at lists.webkit.org>
Subject: Re: [webkit-dev] Setting up Eclipse IDE for Webkit..
Message-ID: <BANLkTinD-vcmMC_g_GBgB65La89hgDK44A at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
Which port you want to build?
For Qt :
QtCreator for the Qt port works pretty well, just open the WebCore.pro
or QtWebKit.pro with it.
Though I've never tried Eclipse on the Qt port.
On Wed, Jun 22, 2011 at 10:19 AM, Tom Smith <penguin.linux1 at gmail.com> wrote:
> Hi everyone,
> ? Has anyone used Eclipse IDE on Ubuntu? ?If so do you have
> any?recommendations?
> Thanks.
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
--
Alexis Menard
Software Engineer
INdT Recife Brazil
------------------------------
_______________________________________________
webkit-dev mailing list
webkit-dev at lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
End of webkit-dev Digest, Vol 73, Issue 28
******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110622/8f94f81e/attachment.html>
More information about the webkit-dev
mailing list