Oh really? Why is then the poster child of software patents that is Microsoft FAT patent, was uphold in Germany?
This nonsense about software patents not valid in EPO members nations (which includes significant number of EU members) simply has to stop.
Because all members countries share the same patent application system. If Microsoft apply for a patent via European Patent Office and succeeded, Microsoft will automatically get 37 national patents, without a need to file 37 applications for each country. There is no such thing such as, if Microsoft files a successful software patent application, it will only takes effect in 20 of 37 member states. Therefore, if the patent is valid in Germany (a member state), it is valid in other EPO member countries.
Yeah, right. European Patent Office has 37 participating member states, which includes Germany. 37 out of 50 nations in Europe sure sound like a majority to me.
Haven't heard of Mozilla abandoning XP yet. But if the Direct2D and DirectWrite support become reality in future versions of Firefox (it will be because Opera and IE has hardware acceleration too), Firefox for XP will be second class to Firefox for Vista/7.
Switch codecs and suddenly YouTube doesn't work in Internet Explorer 9 and Safari. And yeah, on the likes of iPhone too (and Symbian or Blackberry etc).
Will Google do it? Making YouTube to not work on very many desktop/laptops/smartphones out there?
Plenty of companies make Blu-ray players. Nothing in DMCA prevents them to do so, legally.
ATSC can use MPEG2 in addition to H.264, but how many broadcasters uses that hugely inefficient codec? H.264 gives better quality at lower bandwidth, allowing more channels to be shoved into a given spectrum. This is a no-brainer economically.
There are plenty of royalty-free things from Microsoft, just take a look here. VC-1 a.k.a WMV9 at that time was supposed to be the same too, but alas it wasn't meant to be. The SMPTE standardization was done later after that.
Google can do the same, and the same companies that hit Microsoft will highly likely hit Google too.
ATSC supports H.264 (in addition to MPEG2), and most American broadcasters use H.264 to save spectrum bandwidth (and can pile on money making subchannels too). And most DVB-T/DVB-S2 broadcasters also used H.264 codec, for the same reason. For Blu-ray, vast majority of them uses H.264, with the exception of Warner that uses VC-1 (no idiot studios use MPEG2 nowadays). And some Blu-ray set-top boxes, from Samsung and Oppo already supports Netflix streaming (and Pandora) too. Netflix streaming I believe is H.264 only, and supported on PS3, Xbox 360 and Wii too (huge userbase there). Did Apple TV supports Netflix streaming now? News to me.
So do you think that the likes of Blu-ray videos and ATSC/DVB/ISDB standards (the latter which more than a billion people use - today) will switch to VP8 anytime soon? Google is not in a position to decide what video formats those standards will use. Last time I checked, Google is not a player in the broadcasting business.
What happened to Microsoft's VC-1 will happen to Google too. I'm sure of this.
Few years ago, Microsoft does the exact some thing with VC-1, telling the world and the dog that they will release VC-1 as a royalty-free video codec. Then the likes of Sony et. al. 'helpfully' tells Microsoft that VC-1 violates many of their patents. Knowing that they will lose heavily in court if sued, Microsoft back-tracks and now have to participate in MPEG-LA patent pool.
Considering that H.264 is used in Blu-rays, ATSC, DVB-T/DVB-S2, video streaming services like Netflix and of course, sites like YouTube, I don't think H.264 will go away anytime soon.
Harder than using XUL (which has Javascript in it) with XULConnect and XPCOM. It is kinda like writing software using Notepad/vim/emacs or Eclipse/Visual Studio. It is doable in both, but with the latter it is easier.
News to me. Which features can you not use?
Not all Javascript functions can be bound the Chrome API.
Also true for HTML.
And why is then Chrome did not use HTML to render its UI? Apparently, the UI is still C++.
Given that this is exactly what I'm doing right now, yes, I do wonder. Chromium has been on Linux for awhile, and official builds of Google Chrome exist.
Chromium != Google Chrome. It is like saying Google Chrome == Safari just because they use WebKit. Chromium is not Chrome just like SRWIron is not Chrome. Chromium is like Iceweasel (without the controversy) to Firefox as it is to Google Chrome.
You're assuming that it was UI that was the issue, and that doesn't seem to be the case.
Then please explain why after 1 year and three major version in Windows, why Google Chrome (not derivatives like Chromium) in Mac OS X is still developer preview? Is it really that hard to make a port?
Because Firefox 4 would be a new version of Firefox 3. Chrome was a brand-new browser.
To complete your analogy... Wasn't Netscape only for Windows, at first? Certainly, Mozilla took time to get a Linux port working, though they might've had it by public release. It certainly wasn't "free", as they had to develop their cross-platform XUL engine first -- just as Chrome leans on Google's cross-platform GUI libraries and the cross-platform Webkit.
When Firefox 1 was released, it is already available for Linux and OS X. And BTW, Netscape is not written by Mozilla, Netscape is written by Netscape Communication. Mozilla Foundation does not exist until this decade. Netscape doesn't even use XUL until version 6 (prior to that Netscape is completely C++), so where did you find evidence that Netscape is having to create the cross-platform XUL for Netscape 1?
And they already have the faster C++, thousands of lines of which are now cross-platform.
In short, I don't see why they'd use XUL for speed, but not C++ for speed. I don't think they chose XUL because of speed. I think they chose XUL because when it was developed, HTML wasn't anywhere near ready to do this kind of thing by itself.
Apple choose WebKit over Gecko for one reason only: cross-platform support. The current Gecko is still not crossplatform-friendly, but better than the early version of the rendering engine. XUL was chosen because using it will simplify Mozilla's heavy burden of making Firefox/Seamonkey cross-platform friendly. Considering the limitations of Gecko when it comes to cross-platform support, Mozilla can be commended for having released Firefox 1 on time for Linux/OSX users, instead of making them wait for 12 months as Google has done.
Mozilla use XUL for cross-platform compatibility, not speed. And HTML is never designed to be used as UI anyway, unlike XUL who are explicitly design to be used as UI compositing.
Ok, then.
Why not build a variant of XUL which uses HTML + CSS + Javascript, withaccess to XPCOM? It's just replacing the XML part of XUL with HTML.
That was my point.
Why would Mozilla replace the perfectly fine XUL with another variant that uses HTML? If you want some HTML action, why do you take a look at Mozilla Jet Pack, which is yet another way to create extensions for Firefox? Look at https://jetpack.mozillalabs.com/
Well, the parts that are done in HTML can just use normal script tags, if that's what you mean by "attached".
There are a few places where you can plug in Javascript, but not necessarily HTML/CSS -- but you can certain
That's not a property of precision, that's a property of your logic for interpreting the gesture.
And implementing the logic via Javascript only will be hard. After all, after more reading of the Chrome API, apparently you cannot use all features of Javascript to make a Chrome extension. You will need to hope that Chrome has an API for it (which it seem that they have), else doing it will be hard.
Now, can you make a mouse gesture extension that is as good as FireGestures but without using the gestures API in Chrome? Maybe doable, but it will be hard. There are no gestures API in Firefox, and FireGestures developers has to create their own gesture recognition engine. I imagine that doing the same will be hard in Chrome, unless you have an API for it. Well, if you have an API exposed, you are scot-free, but what if you don't?
If you mean, HTML can't access it without the help of Javascript, well of course. But I see no reason you couldn't draw the UI with HTML and add the behavior with Javascript, just like you do for a web app.
You cannot draw UI for Firefox extensions using HTML and have it be interactive with the guts of Firefox itself. At best, HTML UI is only good for display while for interactivity, XUL for UI is needed. What you have envisioned may be possible in the current beta of JetPack, but not the mainstream extension platform.
That suggests Firefox's HTML rendering should be improved -- but more importantly, I bet C++ is faster at displaying UI than XUL. Why did they use XUL?
I think you'll find that reason would also apply to HTML.
XUL is used because it is easier to do cross-platform development with it. Ever wonder why Chrome is not available officially in Mac OS X/Linux yet, even after a year when Windows binaries comes out? If Google use XUL for Chrome, we may have official builds for Linux and OS X today, not in some beta form. Imagine the riot that will happen if Mozilla released Firefox 4 only for Windows first while keeping users of OS X/Linux waiting for 12 months (and counting) to get it (meanwhile, they can only use betas for the time being).
Gecko is not that bad at spiting out HTML, this is not IE after all. But considering that they already use the faster XUL for UI, might as well use it for the extension platform,.
I keep trying to get you to be clear, and you seem to be unable. So please answer this question first:
Is XUL a Turing-complete lanugage?
If not, then let's be clear and say that Javascript, attached to a XUL view, can access XPCOM.
Apparently you did not know what XUL is. To make it simple, XUL is XML + CSS + Javascript. Why would XUL need to be attached to external Javascript scripts just to access XPCOM? XUL can access XPCOM by itself, it has Javascript within it. Maybe HTML in Chrome extensions need to be attached to a Javascript script to access the Chrome API, but XUL doesn't have to to access XPCOM. Yes you can attach Javascript to it, but it is not mandatory.
Have you actually done this with any program other than Firefox?
No, most C++ applications don't let you do that, without actually editing the source. Technically it's possible, but without a plugin/extension API, it's not easy, and will break with the next update.
So, I know Chrome exposes the Netscape Plugin API (the same one Firefox uses) via C/C++. I haven't seen it expose any other C/C++ API.
I have not done this outside Firefox, and yes you are correct that C++ applications doesn't allow you to do that without source editing. That's why extensions in Firefox are powerful, and also can be extremely dangerous (that's why Mozilla will only sanctioned people to get extensions from their SSL-enabled website). Chrome doesn't have this, and this is why Chrome extension platform is less powerful than Firefox's.
Really? Because that's what you're doing with Firefox. I realize this is hard for y
The short answer is, yes.
The long answer is, you might need the HTML5 Canvas element if you're wanting some sort of line behind the mouse, as opposed to a series of progressively-more-transparent mouse shadows. And of course, Chrome supports Canvas.
Higher than pixels? Not that I know of, but I also can't imagine when I'd want to, or what kind of Firefox extension would do so.
High precision mouse detection is needed so that. for example, you do not have to actually do a 90 degrees down-right mouse movements to close a tab. Else, a user has to perform the gesture several time just to get the command to execute. Kinda like Opera's early iterations of their built-in mouse gestures, which is harder to use than the version they have now.
can do tab mouse gestures (different one than FireGestures).
How are they different?
I could certainly do mouse gestures over the page. I'm not sure I can catch mouse events that wander off into the tabs or navigation bar.
That's exactly what I am talking about. Can you catch mouse gestures (in Tab Mix Plus example, they consists mostly of mouse-click combinations) that is executed over the tab bar? FireGestures captures mouse gestures executed over the web-page, but Tab Mix Plus captures the ones executed over the tab bar. Really convenient when you have several rows of them.
Of course, Firefox by its own do not have any stinking APIs that will allow developers to do that of course.
Sigh.
Again: Are these XUL or XPCOM?
And is there any reason XPCOM couldn't be exposed to privileged HTML and Javascript?
Show me some XUL to illustrate your point -- otherwise, I'm going to continue with my assumption that XUL provides none of these benefits on its own.
HTML+Javascript combo cannot be used to access XPCOM. Javascript, yes. HTML, no (this is by design). Extensions that uses HTML usually does so only for presentation/display. And with most developers preferring to use XUL in the first place for such purposes (in Firefox, XUL is faster at compositing and displaying UI than HTML), it is rare actually to see HTML being used, after all, XUL can access XPCOM and HTML can't (well, not directly).
You seem to be either misinformed or downright unimaginative about what an API could expose.
Let's pretend the Chrome UI is entirely C++, and let's pretend, for a moment, that there's no way (currently) to customize the settings dialog.
Now let's pretend we can write C++ extensions. What would the C++ API look like? I'll leave this as an exercise to the reader.
Go ahead, I'll wait. Build some sample applications. Use pseudocode, if you like.
Now, look at your API, and ask yourself why this couldn't be exposed to Javascript.
To take another, much simpler example: Webkit is probably written in C or C++, right? It's native code that parses HTML, and native code that generates the DOM, right? But I can manipulate the DOM with Javascript just fine.
And given that there just isn't that much UI -- that much chrome -- to Chrome, I wouldn't be surprised to see a more complete API in the future. As it is, the usual pattern for an extension that wants, say, a dialog box, is to pop up a new window pointing to some page inside the extension.
Oh, and yes, you can embed plugins inside your extension, which means you can use whatever language you like to make plugins -- probably C++ -- but you probably can't dig that deeply into the browser itself from that plugin.
A C++ API is probably kinda like gcc libraries that you can use instead of having to write your own functions. So a Chrome API in C++ may allows you to mess around Chrome parts that are not HTML+Javascript based. And of course, you will be able to dig deeply into the guts of Chrome just like you can do to Firefox.
About the DOM manipulation you describe above, in Firefox, you can actually have an extension that will make Gecko output the DOM (already modified) you
...really? I doubt it -- you've already got mouse move and click events, and you've got the possibility to intercept an event anywhere on the document. What's difficult?
Can you use HTML or Javascript or CSS to paint a mouse trail?
Is there anything in the current version of the Chrome API that will allow you to capture mouse movement in high precision (DPI)? etc.
However, at least some of the features of Tab Mix Plus should be possible -- there is a Tab API exposed to Javascript. Many of the features of Tab Mix Plus are built in -- like, undo close tab.
Tab Mix Plus can save sessions, paint the tab with user-specified color, format tab title texts, can save tab opening order and can do tab mouse gestures (different one than FireGestures). These features are just some features that XUL allows you to do. Is the Chrome tab API has any functions for tab mouse gestures? This is not part of Firefox but is possible because of XUL (and XPCOM).
There's my answer. Because XUL by itself is just UI markup, right? It's the API that's exposed to a firefox extension that is (so far) much better.
XUL is for user interface just like you say. But a pertinent point that you should not forget is that Firefox uses XUL as the layout for its user interface while a peek at Chrome source code shows that it uses C++ or maybe C for its interface. Firefox allows you to create an extension that will radically alter the Firefox user interface as you wish, but Chrome will not allow you to do the same thing (unless I missed the memo that I will be allowed to use C++ to write Chrome extensions that will hook straight to the user interface). If Google give me the same freedom the way Mozilla gives to me, I can make an extension that will put the tab bar at the bottom of the browser window, or maybe a tree-structure tab column at the left-side of the browser? Or even erase the Google logo at the top-right of the browser? This is without having to have mess around with the source code at all.
What kind of tweaks to Webkit?
And it can certainly mess with Javascript, to the extent that a content script is similar to a Greasemonkey script (but more isolated), so it can alter anything about that page, likely including other scripts on the page.
PrefBar is a Firefox extension that comes to mind when it comes to messing around with the behaviour of Gecko, that comes to my mind now.
True. But even in its current stage, it does prove one point which I don't think you've disputed:
It's much easier for me, as a web developer, to write an extension for Chrome than for Firefox. I've never really gotten off the ground with Firefox, but I wrote an ad blocker for Chrome in an afternoon, including learning to use the extension API.
Whoa, you have written an ad-blocker for Chrome? If you can use the AdBlock subscription list that would be swell. The lack of ad-blocker is apparently the excuse many Firefox users use to justify not trying Chrome.
With XUL, you can basically gut Firefox programming (whether the GUI or the back-end code etc) without actually having to dive into the source code itself (C/C++). You can completely replace the download manager (like Download Statusbar), add features like mouse gestures (it will be very difficult to replicate FireGesture functionality with only CSS+Javascript) and more.
AdBlock Plus extension functionality can be duplicated, but I have concerns about its performance. Flashblock should be easier. DownloadStatusbar should be doable, although with many features missing such as virus scanning etc. FireGestures mouse gesture extension will be very hard to duplicate. Or any other XUL-heavy extensions like Screengrab or god- forbid, Tab Mix Plus.
XUL is not only feature Firefox extension API has, it also has XPCOM. These two alone makes Firefox to become like a mini-operating system. XUL+XPCOM+HTML+CSS+Javascript+DOM combination is magnitudes more powerful than Chrome's HTML+CSS (limited from my observation)+Javascript combination.
Will Google allows developers to mess around with the the operation of the Webkit rendering engine or the JavaScript is something that I want to know. The API is still not final yet anyway.
The Chrome extension API isn't finished, but it's just Javascript and HTML. It's the kind of thing that a web developer could learn in an hour. It won't run Firefox extensions (yet), but it seems likely that it'll have plenty of extensions Firefox won't, just because of how much easier it is to get off the ground.
The fact that Chrome extensions will be based only with HTML + Javascript means that it will be less flexible and less powerful than Firefox extensions which is based on XUL + CSS + Javascript + DOM.
Maybe you did not find a reference because it didn't exist? That PC Magazine should have an online version right? Go to their website and find the article.
This is a nasty bug and the media will be all over it if it exists. Have tried it here with Word 2007 and XP SP3 Guest Account and it didn't work.
As a side note, the release of IE8 is going to be a big problem for MS: there's a potential that tons of pages developed incorrectly for IE (such as those using conditional comments that target all IE versions rather than just 7 and lower) will look incorrect in IE8. Also, most web stats (at non-tech sites) are showing 25+% of visits coming from IE6. People who use IE are either stuck with what their corp. IT does, or just don't care about new versions of IE.
These problems make the opportunity for Google Chrome to grab market share that much better.
If Chrome supports Group Policy and Active Directory intergration plus centralized updates, it will be able to penetrate the corporate environment. Else Internet Explorer 5/6 will continue to reign supreme.
That applies only for software patents filed to EU patent office. Software patents issued in US is still honored in EU because of WIPO and GATT commitments.
And that's the problem. Either encoding or decoding, you will need a patent license from MPEG-LA. I think that is not going anywhere soon. Anyway, as long as the standard is open, it is fine by me.
The patents in the MPEG-LA pool is not exactly 100% software patents, there are lots of hardware-based patents too. Streaming h.264 videos (online or Over The Air like DVB-T) for example will need dedicated ASIC/FPGA hardware for real-time rate-control mechanisms that was dependent on non-software patents in the MPEG-LA pool. No organization out there worth its salt will do software-based h.264 streaming when reliability and mission-critical goals are essential. Ever see any TV stations that do trial for DVB-T use only h.264 software encoders for broadcasting? And last time I checked, software patents is still valid in EU, and being WIPO members, EU will have to honor software patents issued to non-EU WIPO member countries like USA anyway.
Slashdot Mirror
Oh really? Why is then the poster child of software patents that is Microsoft FAT patent, was uphold in Germany?
This nonsense about software patents not valid in EPO members nations (which includes significant number of EU members) simply has to stop.
Because all members countries share the same patent application system. If Microsoft apply for a patent via European Patent Office and succeeded, Microsoft will automatically get 37 national patents, without a need to file 37 applications for each country. There is no such thing such as, if Microsoft files a successful software patent application, it will only takes effect in 20 of 37 member states. Therefore, if the patent is valid in Germany (a member state), it is valid in other EPO member countries.
Yeah, right. European Patent Office has 37 participating member states, which includes Germany. 37 out of 50 nations in Europe sure sound like a majority to me.
US software patents are not valid in Europe? Someone needs to tell Germany about that because Microsoft FAT patent has been declared valid in court.
Fact: Software patents are alive and well in European Union.
Haven't heard of Mozilla abandoning XP yet. But if the Direct2D and DirectWrite support become reality in future versions of Firefox (it will be because Opera and IE has hardware acceleration too), Firefox for XP will be second class to Firefox for Vista/7.
Switch codecs and suddenly YouTube doesn't work in Internet Explorer 9 and Safari. And yeah, on the likes of iPhone too (and Symbian or Blackberry etc).
Will Google do it? Making YouTube to not work on very many desktop/laptops/smartphones out there?
Plenty of companies make Blu-ray players. Nothing in DMCA prevents them to do so, legally.
ATSC can use MPEG2 in addition to H.264, but how many broadcasters uses that hugely inefficient codec? H.264 gives better quality at lower bandwidth, allowing more channels to be shoved into a given spectrum. This is a no-brainer economically.
There are plenty of royalty-free things from Microsoft, just take a look here. VC-1 a.k.a WMV9 at that time was supposed to be the same too, but alas it wasn't meant to be. The SMPTE standardization was done later after that.
Google can do the same, and the same companies that hit Microsoft will highly likely hit Google too.
Firefox nightly builds that has Direct2D support is not supported in Windows XP. Vista and 7 only.
ATSC supports H.264 (in addition to MPEG2), and most American broadcasters use H.264 to save spectrum bandwidth (and can pile on money making subchannels too). And most DVB-T/DVB-S2 broadcasters also used H.264 codec, for the same reason. For Blu-ray, vast majority of them uses H.264, with the exception of Warner that uses VC-1 (no idiot studios use MPEG2 nowadays). And some Blu-ray set-top boxes, from Samsung and Oppo already supports Netflix streaming (and Pandora) too. Netflix streaming I believe is H.264 only, and supported on PS3, Xbox 360 and Wii too (huge userbase there). Did Apple TV supports Netflix streaming now? News to me.
So do you think that the likes of Blu-ray videos and ATSC/DVB/ISDB standards (the latter which more than a billion people use - today) will switch to VP8 anytime soon? Google is not in a position to decide what video formats those standards will use. Last time I checked, Google is not a player in the broadcasting business.
What happened to Microsoft's VC-1 will happen to Google too. I'm sure of this.
Few years ago, Microsoft does the exact some thing with VC-1, telling the world and the dog that they will release VC-1 as a royalty-free video codec. Then the likes of Sony et. al. 'helpfully' tells Microsoft that VC-1 violates many of their patents. Knowing that they will lose heavily in court if sued, Microsoft back-tracks and now have to participate in MPEG-LA patent pool.
Considering that H.264 is used in Blu-rays, ATSC, DVB-T/DVB-S2, video streaming services like Netflix and of course, sites like YouTube, I don't think H.264 will go away anytime soon.
Harder than what?
Harder than using XUL (which has Javascript in it) with XULConnect and XPCOM. It is kinda like writing software using Notepad/vim/emacs or Eclipse/Visual Studio. It is doable in both, but with the latter it is easier.
News to me. Which features can you not use?
Not all Javascript functions can be bound the Chrome API.
Also true for HTML.
And why is then Chrome did not use HTML to render its UI? Apparently, the UI is still C++.
Given that this is exactly what I'm doing right now, yes, I do wonder. Chromium has been on Linux for awhile, and official builds of Google Chrome exist.
Chromium != Google Chrome. It is like saying Google Chrome == Safari just because they use WebKit. Chromium is not Chrome just like SRWIron is not Chrome. Chromium is like Iceweasel (without the controversy) to Firefox as it is to Google Chrome.
You're assuming that it was UI that was the issue, and that doesn't seem to be the case.
Then please explain why after 1 year and three major version in Windows, why Google Chrome (not derivatives like Chromium) in Mac OS X is still developer preview? Is it really that hard to make a port?
Because Firefox 4 would be a new version of Firefox 3. Chrome was a brand-new browser. To complete your analogy... Wasn't Netscape only for Windows, at first? Certainly, Mozilla took time to get a Linux port working, though they might've had it by public release. It certainly wasn't "free", as they had to develop their cross-platform XUL engine first -- just as Chrome leans on Google's cross-platform GUI libraries and the cross-platform Webkit.
When Firefox 1 was released, it is already available for Linux and OS X. And BTW, Netscape is not written by Mozilla, Netscape is written by Netscape Communication. Mozilla Foundation does not exist until this decade. Netscape doesn't even use XUL until version 6 (prior to that Netscape is completely C++), so where did you find evidence that Netscape is having to create the cross-platform XUL for Netscape 1?
And they already have the faster C++, thousands of lines of which are now cross-platform. In short, I don't see why they'd use XUL for speed, but not C++ for speed. I don't think they chose XUL because of speed. I think they chose XUL because when it was developed, HTML wasn't anywhere near ready to do this kind of thing by itself.
Apple choose WebKit over Gecko for one reason only: cross-platform support. The current Gecko is still not crossplatform-friendly, but better than the early version of the rendering engine. XUL was chosen because using it will simplify Mozilla's heavy burden of making Firefox/Seamonkey cross-platform friendly. Considering the limitations of Gecko when it comes to cross-platform support, Mozilla can be commended for having released Firefox 1 on time for Linux/OSX users, instead of making them wait for 12 months as Google has done. Mozilla use XUL for cross-platform compatibility, not speed. And HTML is never designed to be used as UI anyway, unlike XUL who are explicitly design to be used as UI compositing.
Ok, then. Why not build a variant of XUL which uses HTML + CSS + Javascript, withaccess to XPCOM? It's just replacing the XML part of XUL with HTML. That was my point.
Why would Mozilla replace the perfectly fine XUL with another variant that uses HTML? If you want some HTML action, why do you take a look at Mozilla Jet Pack, which is yet another way to create extensions for Firefox? Look at https://jetpack.mozillalabs.com/
Well, the parts that are done in HTML can just use normal script tags, if that's what you mean by "attached". There are a few places where you can plug in Javascript, but not necessarily HTML/CSS -- but you can certain
That's not a property of precision, that's a property of your logic for interpreting the gesture.
And implementing the logic via Javascript only will be hard. After all, after more reading of the Chrome API, apparently you cannot use all features of Javascript to make a Chrome extension. You will need to hope that Chrome has an API for it (which it seem that they have), else doing it will be hard. Now, can you make a mouse gesture extension that is as good as FireGestures but without using the gestures API in Chrome? Maybe doable, but it will be hard. There are no gestures API in Firefox, and FireGestures developers has to create their own gesture recognition engine. I imagine that doing the same will be hard in Chrome, unless you have an API for it. Well, if you have an API exposed, you are scot-free, but what if you don't?
If you mean, HTML can't access it without the help of Javascript, well of course. But I see no reason you couldn't draw the UI with HTML and add the behavior with Javascript, just like you do for a web app.
You cannot draw UI for Firefox extensions using HTML and have it be interactive with the guts of Firefox itself. At best, HTML UI is only good for display while for interactivity, XUL for UI is needed. What you have envisioned may be possible in the current beta of JetPack, but not the mainstream extension platform.
That suggests Firefox's HTML rendering should be improved -- but more importantly, I bet C++ is faster at displaying UI than XUL. Why did they use XUL? I think you'll find that reason would also apply to HTML.
XUL is used because it is easier to do cross-platform development with it. Ever wonder why Chrome is not available officially in Mac OS X/Linux yet, even after a year when Windows binaries comes out? If Google use XUL for Chrome, we may have official builds for Linux and OS X today, not in some beta form. Imagine the riot that will happen if Mozilla released Firefox 4 only for Windows first while keeping users of OS X/Linux waiting for 12 months (and counting) to get it (meanwhile, they can only use betas for the time being). Gecko is not that bad at spiting out HTML, this is not IE after all. But considering that they already use the faster XUL for UI, might as well use it for the extension platform,.
I keep trying to get you to be clear, and you seem to be unable. So please answer this question first: Is XUL a Turing-complete lanugage? If not, then let's be clear and say that Javascript, attached to a XUL view, can access XPCOM.
Apparently you did not know what XUL is. To make it simple, XUL is XML + CSS + Javascript. Why would XUL need to be attached to external Javascript scripts just to access XPCOM? XUL can access XPCOM by itself, it has Javascript within it. Maybe HTML in Chrome extensions need to be attached to a Javascript script to access the Chrome API, but XUL doesn't have to to access XPCOM. Yes you can attach Javascript to it, but it is not mandatory.
Have you actually done this with any program other than Firefox? No, most C++ applications don't let you do that, without actually editing the source. Technically it's possible, but without a plugin/extension API, it's not easy, and will break with the next update. So, I know Chrome exposes the Netscape Plugin API (the same one Firefox uses) via C/C++. I haven't seen it expose any other C/C++ API.
I have not done this outside Firefox, and yes you are correct that C++ applications doesn't allow you to do that without source editing. That's why extensions in Firefox are powerful, and also can be extremely dangerous (that's why Mozilla will only sanctioned people to get extensions from their SSL-enabled website). Chrome doesn't have this, and this is why Chrome extension platform is less powerful than Firefox's.
Really? Because that's what you're doing with Firefox. I realize this is hard for y
The short answer is, yes. The long answer is, you might need the HTML5 Canvas element if you're wanting some sort of line behind the mouse, as opposed to a series of progressively-more-transparent mouse shadows. And of course, Chrome supports Canvas. Higher than pixels? Not that I know of, but I also can't imagine when I'd want to, or what kind of Firefox extension would do so.
High precision mouse detection is needed so that. for example, you do not have to actually do a 90 degrees down-right mouse movements to close a tab. Else, a user has to perform the gesture several time just to get the command to execute. Kinda like Opera's early iterations of their built-in mouse gestures, which is harder to use than the version they have now.
can do tab mouse gestures (different one than FireGestures).
How are they different? I could certainly do mouse gestures over the page. I'm not sure I can catch mouse events that wander off into the tabs or navigation bar.
That's exactly what I am talking about. Can you catch mouse gestures (in Tab Mix Plus example, they consists mostly of mouse-click combinations) that is executed over the tab bar? FireGestures captures mouse gestures executed over the web-page, but Tab Mix Plus captures the ones executed over the tab bar. Really convenient when you have several rows of them. Of course, Firefox by its own do not have any stinking APIs that will allow developers to do that of course.
Sigh. Again: Are these XUL or XPCOM? And is there any reason XPCOM couldn't be exposed to privileged HTML and Javascript? Show me some XUL to illustrate your point -- otherwise, I'm going to continue with my assumption that XUL provides none of these benefits on its own.
HTML+Javascript combo cannot be used to access XPCOM. Javascript, yes. HTML, no (this is by design). Extensions that uses HTML usually does so only for presentation/display. And with most developers preferring to use XUL in the first place for such purposes (in Firefox, XUL is faster at compositing and displaying UI than HTML), it is rare actually to see HTML being used, after all, XUL can access XPCOM and HTML can't (well, not directly).
You seem to be either misinformed or downright unimaginative about what an API could expose. Let's pretend the Chrome UI is entirely C++, and let's pretend, for a moment, that there's no way (currently) to customize the settings dialog. Now let's pretend we can write C++ extensions. What would the C++ API look like? I'll leave this as an exercise to the reader. Go ahead, I'll wait. Build some sample applications. Use pseudocode, if you like. Now, look at your API, and ask yourself why this couldn't be exposed to Javascript. To take another, much simpler example: Webkit is probably written in C or C++, right? It's native code that parses HTML, and native code that generates the DOM, right? But I can manipulate the DOM with Javascript just fine. And given that there just isn't that much UI -- that much chrome -- to Chrome, I wouldn't be surprised to see a more complete API in the future. As it is, the usual pattern for an extension that wants, say, a dialog box, is to pop up a new window pointing to some page inside the extension. Oh, and yes, you can embed plugins inside your extension, which means you can use whatever language you like to make plugins -- probably C++ -- but you probably can't dig that deeply into the browser itself from that plugin.
A C++ API is probably kinda like gcc libraries that you can use instead of having to write your own functions. So a Chrome API in C++ may allows you to mess around Chrome parts that are not HTML+Javascript based. And of course, you will be able to dig deeply into the guts of Chrome just like you can do to Firefox. About the DOM manipulation you describe above, in Firefox, you can actually have an extension that will make Gecko output the DOM (already modified) you
...really? I doubt it -- you've already got mouse move and click events, and you've got the possibility to intercept an event anywhere on the document. What's difficult?
Can you use HTML or Javascript or CSS to paint a mouse trail? Is there anything in the current version of the Chrome API that will allow you to capture mouse movement in high precision (DPI)? etc.
However, at least some of the features of Tab Mix Plus should be possible -- there is a Tab API exposed to Javascript. Many of the features of Tab Mix Plus are built in -- like, undo close tab.
Tab Mix Plus can save sessions, paint the tab with user-specified color, format tab title texts, can save tab opening order and can do tab mouse gestures (different one than FireGestures). These features are just some features that XUL allows you to do. Is the Chrome tab API has any functions for tab mouse gestures? This is not part of Firefox but is possible because of XUL (and XPCOM).
There's my answer. Because XUL by itself is just UI markup, right? It's the API that's exposed to a firefox extension that is (so far) much better.
XUL is for user interface just like you say. But a pertinent point that you should not forget is that Firefox uses XUL as the layout for its user interface while a peek at Chrome source code shows that it uses C++ or maybe C for its interface. Firefox allows you to create an extension that will radically alter the Firefox user interface as you wish, but Chrome will not allow you to do the same thing (unless I missed the memo that I will be allowed to use C++ to write Chrome extensions that will hook straight to the user interface). If Google give me the same freedom the way Mozilla gives to me, I can make an extension that will put the tab bar at the bottom of the browser window, or maybe a tree-structure tab column at the left-side of the browser? Or even erase the Google logo at the top-right of the browser? This is without having to have mess around with the source code at all.
What kind of tweaks to Webkit? And it can certainly mess with Javascript, to the extent that a content script is similar to a Greasemonkey script (but more isolated), so it can alter anything about that page, likely including other scripts on the page.
PrefBar is a Firefox extension that comes to mind when it comes to messing around with the behaviour of Gecko, that comes to my mind now.
True. But even in its current stage, it does prove one point which I don't think you've disputed: It's much easier for me, as a web developer, to write an extension for Chrome than for Firefox. I've never really gotten off the ground with Firefox, but I wrote an ad blocker for Chrome in an afternoon, including learning to use the extension API.
Whoa, you have written an ad-blocker for Chrome? If you can use the AdBlock subscription list that would be swell. The lack of ad-blocker is apparently the excuse many Firefox users use to justify not trying Chrome.
With XUL, you can basically gut Firefox programming (whether the GUI or the back-end code etc) without actually having to dive into the source code itself (C/C++). You can completely replace the download manager (like Download Statusbar), add features like mouse gestures (it will be very difficult to replicate FireGesture functionality with only CSS+Javascript) and more.
AdBlock Plus extension functionality can be duplicated, but I have concerns about its performance.
Flashblock should be easier.
DownloadStatusbar should be doable, although with many features missing such as virus scanning etc.
FireGestures mouse gesture extension will be very hard to duplicate. Or any other XUL-heavy extensions like Screengrab or god- forbid, Tab Mix Plus.
XUL is not only feature Firefox extension API has, it also has XPCOM. These two alone makes Firefox to become like a mini-operating system. XUL+XPCOM+HTML+CSS+Javascript+DOM combination is magnitudes more powerful than Chrome's HTML+CSS (limited from my observation)+Javascript combination.
Will Google allows developers to mess around with the the operation of the Webkit rendering engine or the JavaScript is something that I want to know. The API is still not final yet anyway.
The Chrome extension API isn't finished, but it's just Javascript and HTML. It's the kind of thing that a web developer could learn in an hour. It won't run Firefox extensions (yet), but it seems likely that it'll have plenty of extensions Firefox won't, just because of how much easier it is to get off the ground.
The fact that Chrome extensions will be based only with HTML + Javascript means that it will be less flexible and less powerful than Firefox extensions which is based on XUL + CSS + Javascript + DOM.
Maybe you did not find a reference because it didn't exist? That PC Magazine should have an online version right? Go to their website and find the article.
This is a nasty bug and the media will be all over it if it exists. Have tried it here with Word 2007 and XP SP3 Guest Account and it didn't work.
No need to wait. Grab IE8 and you can get a multithreaded browser right now, a day earlier than Chrome. No more rogue Flash killing your browser.
As a side note, the release of IE8 is going to be a big problem for MS: there's a potential that tons of pages developed incorrectly for IE (such as those using conditional comments that target all IE versions rather than just 7 and lower) will look incorrect in IE8. Also, most web stats (at non-tech sites) are showing 25+% of visits coming from IE6. People who use IE are either stuck with what their corp. IT does, or just don't care about new versions of IE.
These problems make the opportunity for Google Chrome to grab market share that much better.
If Chrome supports Group Policy and Active Directory intergration plus centralized updates, it will be able to penetrate the corporate environment. Else Internet Explorer 5/6 will continue to reign supreme.
That applies only for software patents filed to EU patent office. Software patents issued in US is still honored in EU because of WIPO and GATT commitments.
And that's the problem. Either encoding or decoding, you will need a patent license from MPEG-LA. I think that is not going anywhere soon. Anyway, as long as the standard is open, it is fine by me.
The patents in the MPEG-LA pool is not exactly 100% software patents, there are lots of hardware-based patents too. Streaming h.264 videos (online or Over The Air like DVB-T) for example will need dedicated ASIC/FPGA hardware for real-time rate-control mechanisms that was dependent on non-software patents in the MPEG-LA pool. No organization out there worth its salt will do software-based h.264 streaming when reliability and mission-critical goals are essential. Ever see any TV stations that do trial for DVB-T use only h.264 software encoders for broadcasting? And last time I checked, software patents is still valid in EU, and being WIPO members, EU will have to honor software patents issued to non-EU WIPO member countries like USA anyway.