implementing the logic via Javascript only will be hard.
Harder than what?
apparently you cannot use all features of Javascript to make a Chrome extension.
News to me. Which features can you not use?
There are no gestures API in Firefox, and FireGestures developers has to create their own gesture recognition engine.
Let me guess -- they wrote it in Javascript. Or, I'm sorry, XUL's XML + CSS + Javascript.
You cannot draw UI for Firefox extensions using HTML and have it be interactive with the guts of Firefox itself.
This seems a fairly arbitrary limitation of Firefox -- especially because the HTML can talk to the Javascript, and if the Javascript has access to the same APIs that XUL Javascript does, the only difference is XUL's XML vs HTML in Gecko.
XUL is used because it is easier to do cross-platform development with it.
Also true for HTML.
Ever wonder why Chrome is not available officially in Mac OS X/Linux yet, even after a year when Windows binaries comes out?
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.
If Google use XUL for Chrome, we may have official builds for Linux and OS X today
You're assuming that it was UI that was the issue, and that doesn't seem to be the case.
Imagine the riot that will happen if Mozilla released Firefox 4 only for Windows first
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.
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,
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.
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.
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.
Maybe HTML in Chrome extensions need to be attached to a Javascript script to access the Chrome API
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 certainly pull these in with Javascript, easily enough, as the Javascript can get a URL to anything else in your extension package.
Speaking of which, the extension package is just a signed zip, which I love. What's the XPI format like?
you are correct that C++ applications doesn't allow you to do that without source editing.
And Firefox is, at least in part, a C++ application.
Every 6 months to a year it seems there is yet another goof up that lets users access other users email (gmail) or data (google docs).
Unless I'm missing something, most of this revolves around users accessing their data through HTTP over insecure wireless, neither of which is required by Google.
It can be as simple as using https://mail.google.com/
I think my original point stands quite well that Linux is mostly associated with "difficult" and "stuff for geeks".
I guess we'll just have to disagree. I find Linux is mostly associated with "I don't know what this is", which is not automatically a bad thing.
Saying a Yugo and a BMW are the same thing because they both have tires and engines is a similar comparison to the cheap laptop vs MBP argument.
I never suggested a "cheap" laptop, only cheaper than a Macbook. You seem to have the bizarre assumption that only Apple makes quality hardware.
But then, your comparison may be more apt than you realize -- BMW has taken a lot of heat for their "iDrive" feature, which has been unintuitive, unreliable, and unnecessary.
So inevitably they drag out the high quality laptops to compare...well immediately the gap shrinks considerably and the MBPs are only slightly more expensive.
"Only slightly" ends up being around $200. It does look slight when you're looking at several thousand dollars of hardware, but it's still significant.
The MBP has a much more durable shell made of better materials, the new ones even more so.
What, aluminum? I guess it's nice, but plastic seems to work well, and isn't conductive.
The AC adapter is a magnetic thing,
Which is very nice. It also undermines any point you might make about open-ness -- it's patented, so no other laptop will have that for awhile.
The front loading CD/DVD is a big deal for me as a traveler too. I absolutely HATE those pop out drives while on a plane or other tight place, it is like they designed them to be easy to break and impossible to use.
By "front loading", you mean "slot loading"? I've got one of those, but it's on the side, a bit more convenient in my opinion -- especially "on a plane or other tight place."
Nothing on the back!
Just like my XPS.
The ambient light sensor that autodims the screen and backlights the keyboard is another good one.
It's sort of a "nice to have". Let me put it this way: If you were building a desktop, would you pay $10 for a cheap keyboard? Sure. Would you pay $50 for an Apple Aluminum keyboard? I would. Now, would you pay $100 for a keyboard that glows in the dark? I'm sorry, the glowiness isn't worth an extra $50 to me.
So sure, it's nice. It's just not worth the price difference, versus hitting fn+down to dim the screen, and knowing how to touch-type.
The people who try to reduce it to a discussion about memory/cpu/video/drive are rigging the argument.
In other words, it sounds like you're admitting that memory/cpu/video/drive are more expensive for what you get, and that the premium on price is worth it because of the bells and whistles.
Seriously...why in God's name would you still have all the F-Keys defaulting to their F-Key behavior on a laptop when the Fn-Fkey function is easily going to be used 10x as often.
Maybe you just have different usage patterns -- I use things like alt+f2 way more often than I use any of the FN keys up there. There's a completely separate set of physical keys for play/pause, volume, etc. About the only thing I use fn for is the brightness, which is fn+up/down.
So...I did get it cheap, I did have other reasons for switching,
Fair enough.
you are deluded or misinformed about prices.
You didn't bring up prices at all. You just tried to justify your purchase on everything in the world other than price and actual specs, and ultimately came up with exactly one feature I'd actually miss -- the magnetic detach. The glowy keys are cool, but not worth it, and pretty much everything else you mentioned I'd either d
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.
That's not a property of precision, that's a property of your logic for interpreting the gesture.
HTML+Javascript combo cannot be used to access XPCOM. Javascript, yes. HTML, no (this is by design).
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.
in Firefox, XUL is faster at compositing and displaying UI than HTML
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 can access XPCOM
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.
So a Chrome API in C++ may allows you to mess around Chrome parts that are not HTML+Javascript based.
If they expose it. They probably don't.
And of course, you will be able to dig deeply into the guts of Chrome just like you can do to Firefox.
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.
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 desire that need not be touched again by XUL or Javascript for modification.
In other words, you can modify the DOM before it's output, as opposed to after, right?
Why is this better?
This is why depending entirely on API will constrain you from adding new features.
Really? Because that's what you're doing with Firefox. I realize this is hard for you to understand, but unless I'm missing something, XPCOM is an API.
If it's more flexible an API than the Chrome API, that's another discussion. But it's still an API.
The average user doesn't understand that a TiVo is a Linux device.
Point is more that the word "TiVo" didn't scare them away, despite it being unknown and strange. So, calling it "Linux" shouldn't scare anyone away simply by being unknown and strange.
And every one of those products loudly announces to the average consumer that it is powered by Linux doesn't it...
The point is rather that they are well-known enough that, once you've got a passing familiarity with Linux, you'll probably have heard it's in at least one of these. Or, for that matter, Xbox Media Center...
Regardless, it doesn't match up with my experience -- people who are computer savvy and have heard of Linux generally at least have some understanding that it's used in services and embedded systems, and that finding it in a radio doesn't automatically make it "difficult".
"paying a premium on hardware" is an asinine comment, because there is a great deal of design and manufacturing in their laptops that is superior to your standard junk $400 plastic crap.
That pretty much fits the Mac stereotype, sorry. And why $400, and why crap? I know I've tried to make the "it's not that much more expensive" argument about Macs, and every time, when someone nails me down to actual specs, it proves that it's at least a few hundred dollars more.
If my budget for "not being annoyed by random people" is a few hundred dollars, I think I can do a lot better than having a Macbook. If it was something else about the Mac, sure, but that wasn't your argument.
Calling it mostly proprietary isn't quite true either. The core of it is open source
For some definition of "core". The GUI is proprietary, and the GUI is actually what drove me away, believe it or not. The kernel is occasionally open, but often not, and tends to be DRM'd.
So I can use almost all of the normal open source software that I use on the Mac.
Yes, I realize.
Why would I put a Windows theme on anything given that I hate how the interface works?
Forgive me, but this just doesn't sound sane. You won't run anything themed with Windows because you don't like the interface. You won't run Linux because people ask you questions.
So to sum up your argument, you run a Mac because it doesn't look like Windows and people don't ask you questions.
What irritates me is...
If I actually got those questions to the point where I was no longer willing to help, I'd start answering with "Here's the address of our LUG. If I'm there, I'll help. I'm just trying to get some coffee here."
I don't think the aggravation of having to do that, instead of "how do you like it", is worth the premium on hardware.
I think most people found it amusing rather than something to try and pick a part point by point as some kind of factual analysis
As a joke, it wasn't funny or obvious enough -- and you were modded "insightful", not "funny". Or in other words, you fail at humor.
And under serious scrutiny, I have to conclude, again, that you either got a really cheap MBP, or you have other reasons for switching, or you're deluded or misinformed about prices.
Can you use HTML or Javascript or CSS to paint a mouse trail?
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.
Is there anything in the current version of the Chrome API that will allow you to capture mouse movement in high precision (DPI)?
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.
Tab Mix Plus can save sessions
Yeah, I can do that. I can't necessarily save the state of each tab, but I can certainly save the URL, even the current values of the form fields.
paint the tab with user-specified color, format tab title texts
Probably can't do that yet.
can save tab opening order
What does that mean? The one reference I see to that is actually describing exactly how Chrome tabs work, by default. If that's what you mean -- that is, tab opening behavior -- that wouldn't be terribly difficult.
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.
These features are just some features that XUL allows you to do.
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.
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.
Probably somewhat true, though not entirely. Opening a new tab currently shows a page called "new tab", which contains a list of recently closed tabs, along with thumbnail links to your most frequently visited websites.
Just for fun, if you've got Chrome installed, visit that page and hit ctrl+U. See? HTML/javascript. Same with about:plugins. Same with chrome://extensions, with a recent build.
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).
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.
Many different Linux distributions use different libraries and even variants.
Which is why I said "most".
Such a statement pretty well validates you have no idea what you're talking about. X is not required to qualify as "Linux" or even "Linux-like".
However, if someone ships a Linux with a completely different GUI serving the same purpose X would have, especially for a platform where X was a credible option, it's not "orthodox".
I don't believe I ever said it wasn't Linux -- so your statement here pretty well validates that you don't read very well.
I'm technically and functionally correct.
Functionally, then, can I expect to take a Linux application and compile it for Android with no changes?
Most Linuxes are GNU/Linux, including such things as a standard libc. Android uses its own.
Moblin also uses X, I think. Android doesn't.
Thus, many apps you can run on a "desktop" Linux, or even a minimal or server Linux, you could simply recompile for Moblin, but you'd need to actually think about it and port to Android.
So, you're technically right (Linux is just a kernel), but functionally wrong.
Ok, this would be difficult -- at least, I don't know how to hook into something being downloaded. I also don't know how to hook into the local filesystem -- but then, I'd almost consider that a feature, as extensions can be limited in what they can access, meaning I don't have to trust an extension nearly as much to install it.
But then, downloads already happen in the status bar anyway.
it will be very difficult to replicate FireGesture functionality with only CSS+Javascript
...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?
AdBlock Plus extension functionality can be duplicated, but I have concerns about its performance.
The one I developed works pretty well. Remember, this is Chrome.
Flashblock should be easier.
It is indeed very easy.
Or any other XUL-heavy extensions like Screengrab or god- forbid, Tab Mix Plus.
I'm not sure how to replicate screengrab.
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.
XUL is not only feature Firefox extension API has, it also has 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.
Will Google allows developers to mess around with the the operation of the Webkit rendering engine or the JavaScript
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.
The API is still not final yet anyway.
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.
it would take much longer than the combined time for the changes on both ends to the existing system to rewrite the system so that that one need could be accomplished in a quick switch-flip style change whenever desired in the future
How many times longer, though? If it takes three years to replace it, that means four changes makes it worth it.
no matter the language
I argue that some languages tend towards modularity, flexibility, maintainability, and otherwise good code, while other languages (COBOL among them) tend towards shortcuts, brittleness, opaqueness, and otherwise bad code.
You can write good code in any Turing-complete language, but is it going with the grain of the language, or against it? In other words, how easy does the language make it to write good code, versus how seductively easy is it to write horrendously bad code?
This is why modern languages tend not to have goto -- you can write good code using goto, and indeed, the CPU is essentially using goto anyway (jump commands). But higher-level constructs make it easier to write good code, and using those constructs instead of goto makes it harder to write bad code. The same could be said of garbage collection and references vs manual memory management and integer pointers.
Non-Erlang code that's not part of the distributed VM can run inside Erlang processes as a "linked-in driver"... which may sometimes be desirable for performance reasons though it is generally discouraged because of the fact that errors in the driver can potentially crash the system.
Yes, that's my point. Granted, even if there wasn't native support for this availability, the Erlang source is open, so it's always possible. But doing that is, from a security/stability/sanity perspective, roughly like using eval.
While both the first and second halves are true, the "so" linking them isn't really. The fact that the VM handles scheduling doesn't make it scale to many cores (originally, the Erlang environment was optimized to run separate VMs per core communicating as separate Erlang nodes.)
You're right. However, Erlang does currently have SMP support:
Erlang processes aren't OS processes, they are more like green threads with very limited shared state with restricted means for accessing that state to avoid conflicts
And SMP Erlang doesn't use OS processes either -- it uses threads.
Still, if you can make it scale to multiple machines using the RPC support, you can certainly scale to multicore. By the time the number of cores is such a limiting factor that you need the SMP, I imagine it'll be a few years from now when the SMP is, well, older.
I'm probably going to sound clueless here, but what does XUL do that this doesn't? Because this is CSS+Javascript+HTML+DOM, so it's pretty much down to XUL vs HTML.
It's also got a large-ish positive effect for web pages -- for example, Chrome extensions use HTML5 local storage, rather than inventing its own dedicated storage API. This means that anything I need for an extension, if it's reasonable to do so, will likely be exposed to regular web pages.
And when I said "just", I mean that's only what's required -- though beyond that (so far), they seem to be talking about the plugin API. That is, if you need something HTML+Javascript won't give you, you could (for example) use Flash (ew) in your extension, just as you can in any webpage -- or roll your own plugin.
The Intel Atom Developer Program will make use of Wind River's VxWorks product, which the company believes will help it achieve that developer grail of the 'write once and run on all devices' experience.
I don't get it. VxWorks is an OS, right? How does that help with "write once, run anywhere"?
Seems to me that Android is doing more towards this, given that native Android apps target a VM, and thus aren't tied to ARM, x86, or anything else. I'm not saying Intel isn't doing this, I just don't see what that has to do with Moblin, VxWorks, or an App Store.
Yeah, well, so is the fact that if they upload personal stuff to the Internet, people might find it on the Internet. If this wasn't covered by whoever introduced you to the Internet, that's a bit like handing a toddler a knife without telling them to be careful.
Is there an ongoing "my Javascript is faster than yours ha-ha" competition in the browser market?
Uhm... Yes?
Javascript is the one client-side programming language that is always guaranteed to be there, on anything that can reasonably be called a browser. Anything that can be called a web application is probably at some point going to care about Javascript speed. And faster Javascript opens the door to somethings you might not have thought were possible in a browser.
When looking for a browser, it isn't just speed people are looking for; They want security
Chrome runs each tab in a separate process, meaning it can theoretically sandbox each tab using standard OS techniques -- for example, on Linux, my Chromium does seem to be running things as an unprivileged user, and chrooting them out of the way.
Other browsers are playing catch-up.
add-ons, customization
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.
If I want top speed, I'll use chrome. If I want an all-around great browser, I'll use Firefox.
We don't care, this isn't about you. (And for what it's worth, Firefox is working hard to improve javascript, security, and reliability to match Chrome.)
This is about the 80% who still use IE, and about the rest of us not having to care anymore. I can build a web app that works in Chrome, Firefox, Safari, Epiphany, Galeon, Konqueror, Opera, in every browser, ever, with minimal effort -- figure an extra 5-10% development time to make it work on browsers other than the one I develop for. IE will fuck it up and add easily 20-50% to my development time.
Doing it this way means that at some point in the future, hopefully, something like YouTube will force IE users to either switch browsers or install this plugin -- at which point, I can forget that IE exists, and let it all melt away like a bad dream.
Or you decide to just document a particular bug, or lack of a feature, in some "known bugs/limitations" document, because it's cheaper than actually trying to fix the bug.
That is: The speed at which you can fix a bug or implement a feature greatly influences what you consider to be a bug.
Well, you've just convinced me of the merits of balancing my checkbook and otherwise maintaining my own finances. At least I can use double-entry accounting with transactions, and correct the bank when they're wrong.
Because that really sounds like a "when", rather than "if"... *shudders*
TiVo is a very well known word for something and nearly everyone who watches TV often uses it or knows it by name.
This proves my point. Before the TiVo, that word was completely unknown. When it was released, it had to be at least as strange, if not stranger, than "Linux".
I've gotten a lot more interest when I call distributions by their short name (ie: Mint or Puppy).
That's why I say "Ubuntu". If people want to know more about it, I may eventually mention Linux, because it's useful to know. But saying "Ubuntu" up front avoids the paradox-of-choice of "Which distro should I use?" and "GNOME or KDE?"
I'd recommend not to say that to your customers unless you are absolutely sure they will understand it the way you mean it.
Programmable, and infinitely customizable, if I have to put some marketing terms on it.
Otherwise, I just let "hackable" be a rumor among people who will understand it. No customer is going to go out of their way to avoid what is known as "most hackable", but those of us who do understand it will gravitate towards such a device.
Fair enough -- but this can be a self-fulfilling prophecy. For example, California's problem of six months to lower wages, then nine months to restore them, probably means the change won't happen.
I'd argue that if you can afford to rewrite it such that it takes ten minutes (or a few days, maybe a month, counting all the administrative BS), it really doesn't take that many changes for it to pay off, and you'll probably find yourself making more changes -- that is, things that previously would've been "nice to have, but we can't afford to change it" now become reasonably possible.
Nobody can covertly copy/sell your paper records with a thumb drive, and they need physical access to destroy them. Also they're immune to EMP.
Two words: Encryption and backups.
Encrypted -- no one can covertly copy/sell your records without having your password. Paper records, someone can still covertly copy/sell them, it just takes a xerox machine.
Destroy -- multiple offsite backups, meaning they'd need multiple passwords. And nothing's stopping you from making a physical backup.
EMP -- multiple offsite backups.
Both of these make your data more private and more robust than paper, and they're much more difficult to do with paper.
Less deterministic performance is a problem for some people,
Very true. But it's not a problem for the vast majority of people, especially those who complain about garbage collection -- and with a generational collector, it's not going to be nondeterministic in any noticeable way for your typical end-user application.
I can see it mattering in embedded software, or in a device driver, but not many other places.
maybe some features aren't in the main UI of an app because they tell you to interactively hack the Lisp.
In other words, the fact that the feature is available might make programmers lazy?
Yeah, that is stretching. That's like an open source app suggesting you change a header file and recompile, rather than providing at least a config file -- in practice, most apps will use a config file for anything they expect a user to have to change, even if they are open source.
Slashdot Mirror
And one which can be applied domain-wide, if you've got apps for your domain.
implementing the logic via Javascript only will be hard.
Harder than what?
apparently you cannot use all features of Javascript to make a Chrome extension.
News to me. Which features can you not use?
There are no gestures API in Firefox, and FireGestures developers has to create their own gesture recognition engine.
Let me guess -- they wrote it in Javascript. Or, I'm sorry, XUL's XML + CSS + Javascript.
You cannot draw UI for Firefox extensions using HTML and have it be interactive with the guts of Firefox itself.
This seems a fairly arbitrary limitation of Firefox -- especially because the HTML can talk to the Javascript, and if the Javascript has access to the same APIs that XUL Javascript does, the only difference is XUL's XML vs HTML in Gecko.
XUL is used because it is easier to do cross-platform development with it.
Also true for HTML.
Ever wonder why Chrome is not available officially in Mac OS X/Linux yet, even after a year when Windows binaries comes out?
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.
If Google use XUL for Chrome, we may have official builds for Linux and OS X today
You're assuming that it was UI that was the issue, and that doesn't seem to be the case.
Imagine the riot that will happen if Mozilla released Firefox 4 only for Windows first
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.
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,
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.
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.
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.
Maybe HTML in Chrome extensions need to be attached to a Javascript script to access the Chrome API
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 certainly pull these in with Javascript, easily enough, as the Javascript can get a URL to anything else in your extension package.
Speaking of which, the extension package is just a signed zip, which I love. What's the XPI format like?
you are correct that C++ applications doesn't allow you to do that without source editing.
And Firefox is, at least in part, a C++ application.
That's why extensions in Firefox are powerful,
XPCOM is a framework, not str
Every 6 months to a year it seems there is yet another goof up that lets users access other users email (gmail) or data (google docs).
Unless I'm missing something, most of this revolves around users accessing their data through HTTP over insecure wireless, neither of which is required by Google.
It can be as simple as using https://mail.google.com/
I think my original point stands quite well that Linux is mostly associated with "difficult" and "stuff for geeks".
I guess we'll just have to disagree. I find Linux is mostly associated with "I don't know what this is", which is not automatically a bad thing.
Saying a Yugo and a BMW are the same thing because they both have tires and engines is a similar comparison to the cheap laptop vs MBP argument.
I never suggested a "cheap" laptop, only cheaper than a Macbook. You seem to have the bizarre assumption that only Apple makes quality hardware.
But then, your comparison may be more apt than you realize -- BMW has taken a lot of heat for their "iDrive" feature, which has been unintuitive, unreliable, and unnecessary.
So inevitably they drag out the high quality laptops to compare...well immediately the gap shrinks considerably and the MBPs are only slightly more expensive.
"Only slightly" ends up being around $200. It does look slight when you're looking at several thousand dollars of hardware, but it's still significant.
The MBP has a much more durable shell made of better materials, the new ones even more so.
What, aluminum? I guess it's nice, but plastic seems to work well, and isn't conductive.
The AC adapter is a magnetic thing,
Which is very nice. It also undermines any point you might make about open-ness -- it's patented, so no other laptop will have that for awhile.
The front loading CD/DVD is a big deal for me as a traveler too. I absolutely HATE those pop out drives while on a plane or other tight place, it is like they designed them to be easy to break and impossible to use.
By "front loading", you mean "slot loading"? I've got one of those, but it's on the side, a bit more convenient in my opinion -- especially "on a plane or other tight place."
Nothing on the back!
Just like my XPS.
The ambient light sensor that autodims the screen and backlights the keyboard is another good one.
It's sort of a "nice to have". Let me put it this way: If you were building a desktop, would you pay $10 for a cheap keyboard? Sure. Would you pay $50 for an Apple Aluminum keyboard? I would. Now, would you pay $100 for a keyboard that glows in the dark? I'm sorry, the glowiness isn't worth an extra $50 to me.
So sure, it's nice. It's just not worth the price difference, versus hitting fn+down to dim the screen, and knowing how to touch-type.
The people who try to reduce it to a discussion about memory/cpu/video/drive are rigging the argument.
In other words, it sounds like you're admitting that memory/cpu/video/drive are more expensive for what you get, and that the premium on price is worth it because of the bells and whistles.
Seriously...why in God's name would you still have all the F-Keys defaulting to their F-Key behavior on a laptop when the Fn-Fkey function is easily going to be used 10x as often.
Maybe you just have different usage patterns -- I use things like alt+f2 way more often than I use any of the FN keys up there. There's a completely separate set of physical keys for play/pause, volume, etc. About the only thing I use fn for is the brightness, which is fn+up/down.
So...I did get it cheap, I did have other reasons for switching,
Fair enough.
you are deluded or misinformed about prices.
You didn't bring up prices at all. You just tried to justify your purchase on everything in the world other than price and actual specs, and ultimately came up with exactly one feature I'd actually miss -- the magnetic detach. The glowy keys are cool, but not worth it, and pretty much everything else you mentioned I'd either d
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.
That's not a property of precision, that's a property of your logic for interpreting the gesture.
HTML+Javascript combo cannot be used to access XPCOM. Javascript, yes. HTML, no (this is by design).
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.
in Firefox, XUL is faster at compositing and displaying UI than HTML
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 can access XPCOM
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.
So a Chrome API in C++ may allows you to mess around Chrome parts that are not HTML+Javascript based.
If they expose it. They probably don't.
And of course, you will be able to dig deeply into the guts of Chrome just like you can do to Firefox.
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.
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 desire that need not be touched again by XUL or Javascript for modification.
In other words, you can modify the DOM before it's output, as opposed to after, right?
Why is this better?
This is why depending entirely on API will constrain you from adding new features.
Really? Because that's what you're doing with Firefox. I realize this is hard for you to understand, but unless I'm missing something, XPCOM is an API.
If it's more flexible an API than the Chrome API, that's another discussion. But it's still an API.
The average user doesn't understand that a TiVo is a Linux device.
Point is more that the word "TiVo" didn't scare them away, despite it being unknown and strange. So, calling it "Linux" shouldn't scare anyone away simply by being unknown and strange.
And every one of those products loudly announces to the average consumer that it is powered by Linux doesn't it...
The point is rather that they are well-known enough that, once you've got a passing familiarity with Linux, you'll probably have heard it's in at least one of these. Or, for that matter, Xbox Media Center...
Regardless, it doesn't match up with my experience -- people who are computer savvy and have heard of Linux generally at least have some understanding that it's used in services and embedded systems, and that finding it in a radio doesn't automatically make it "difficult".
"paying a premium on hardware" is an asinine comment, because there is a great deal of design and manufacturing in their laptops that is superior to your standard junk $400 plastic crap.
That pretty much fits the Mac stereotype, sorry. And why $400, and why crap? I know I've tried to make the "it's not that much more expensive" argument about Macs, and every time, when someone nails me down to actual specs, it proves that it's at least a few hundred dollars more.
If my budget for "not being annoyed by random people" is a few hundred dollars, I think I can do a lot better than having a Macbook. If it was something else about the Mac, sure, but that wasn't your argument.
Calling it mostly proprietary isn't quite true either. The core of it is open source
For some definition of "core". The GUI is proprietary, and the GUI is actually what drove me away, believe it or not. The kernel is occasionally open, but often not, and tends to be DRM'd.
So I can use almost all of the normal open source software that I use on the Mac.
Yes, I realize.
Why would I put a Windows theme on anything given that I hate how the interface works?
Forgive me, but this just doesn't sound sane. You won't run anything themed with Windows because you don't like the interface. You won't run Linux because people ask you questions.
So to sum up your argument, you run a Mac because it doesn't look like Windows and people don't ask you questions.
What irritates me is...
If I actually got those questions to the point where I was no longer willing to help, I'd start answering with "Here's the address of our LUG. If I'm there, I'll help. I'm just trying to get some coffee here."
I don't think the aggravation of having to do that, instead of "how do you like it", is worth the premium on hardware.
I think most people found it amusing rather than something to try and pick a part point by point as some kind of factual analysis
As a joke, it wasn't funny or obvious enough -- and you were modded "insightful", not "funny". Or in other words, you fail at humor.
And under serious scrutiny, I have to conclude, again, that you either got a really cheap MBP, or you have other reasons for switching, or you're deluded or misinformed about prices.
Can you use HTML or Javascript or CSS to paint a mouse trail?
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.
Is there anything in the current version of the Chrome API that will allow you to capture mouse movement in high precision (DPI)?
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.
Tab Mix Plus can save sessions
Yeah, I can do that. I can't necessarily save the state of each tab, but I can certainly save the URL, even the current values of the form fields.
paint the tab with user-specified color, format tab title texts
Probably can't do that yet.
can save tab opening order
What does that mean? The one reference I see to that is actually describing exactly how Chrome tabs work, by default. If that's what you mean -- that is, tab opening behavior -- that wouldn't be terribly difficult.
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.
These features are just some features that XUL allows you to do.
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.
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.
Probably somewhat true, though not entirely. Opening a new tab currently shows a page called "new tab", which contains a list of recently closed tabs, along with thumbnail links to your most frequently visited websites.
Just for fun, if you've got Chrome installed, visit that page and hit ctrl+U. See? HTML/javascript. Same with about:plugins. Same with chrome://extensions, with a recent build.
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).
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 c
Many different Linux distributions use different libraries and even variants.
Which is why I said "most".
Such a statement pretty well validates you have no idea what you're talking about. X is not required to qualify as "Linux" or even "Linux-like".
However, if someone ships a Linux with a completely different GUI serving the same purpose X would have, especially for a platform where X was a credible option, it's not "orthodox".
I don't believe I ever said it wasn't Linux -- so your statement here pretty well validates that you don't read very well.
I'm technically and functionally correct.
Functionally, then, can I expect to take a Linux application and compile it for Android with no changes?
If so, I'm misinformed, and I apologize.
The fact that Android uses a BSD-derived Bionic C library for core userspace, does not make the system any less "Linux".
However, it's probably what people mean by "less orthodox", and probably causes some compatibility issues.
As for eglibc, that's not so much a differently-designed libc as a fork to avoid the maintainer of glibc, IIRC.
Functionally, a lot of linux systems dont ship X,
Not a lot of them ship some GUI other than X, though -- so it's not as though a typical Android user would want to enable X.
So, in other words, the State of California has never altered wages? Wow.
By ensuring that all devices from the smallest phone to the largest supercomputer use x86 processors.
I'm sorry, I have to ask just about the same question again...
How does VxWorks ensure that everything runs x86?
Most Linuxes are GNU/Linux, including such things as a standard libc. Android uses its own.
Moblin also uses X, I think. Android doesn't.
Thus, many apps you can run on a "desktop" Linux, or even a minimal or server Linux, you could simply recompile for Moblin, but you'd need to actually think about it and port to Android.
So, you're technically right (Linux is just a kernel), but functionally wrong.
You can completely replace the download manager
Ok, this would be difficult -- at least, I don't know how to hook into something being downloaded. I also don't know how to hook into the local filesystem -- but then, I'd almost consider that a feature, as extensions can be limited in what they can access, meaning I don't have to trust an extension nearly as much to install it.
But then, downloads already happen in the status bar anyway.
it will be very difficult to replicate FireGesture functionality with only CSS+Javascript
...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?
AdBlock Plus extension functionality can be duplicated, but I have concerns about its performance.
The one I developed works pretty well. Remember, this is Chrome.
Flashblock should be easier.
It is indeed very easy.
Or any other XUL-heavy extensions like Screengrab or god- forbid, Tab Mix Plus.
I'm not sure how to replicate screengrab.
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.
XUL is not only feature Firefox extension API has, it also has 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.
Will Google allows developers to mess around with the the operation of the Webkit rendering engine or the JavaScript
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.
The API is still not final yet anyway.
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.
it would take much longer than the combined time for the changes on both ends to the existing system to rewrite the system so that that one need could be accomplished in a quick switch-flip style change whenever desired in the future
How many times longer, though? If it takes three years to replace it, that means four changes makes it worth it.
no matter the language
I argue that some languages tend towards modularity, flexibility, maintainability, and otherwise good code, while other languages (COBOL among them) tend towards shortcuts, brittleness, opaqueness, and otherwise bad code.
You can write good code in any Turing-complete language, but is it going with the grain of the language, or against it? In other words, how easy does the language make it to write good code, versus how seductively easy is it to write horrendously bad code?
This is why modern languages tend not to have goto -- you can write good code using goto, and indeed, the CPU is essentially using goto anyway (jump commands). But higher-level constructs make it easier to write good code, and using those constructs instead of goto makes it harder to write bad code. The same could be said of garbage collection and references vs manual memory management and integer pointers.
Non-Erlang code that's not part of the distributed VM can run inside Erlang processes as a "linked-in driver"... which may sometimes be desirable for performance reasons though it is generally discouraged because of the fact that errors in the driver can potentially crash the system.
Yes, that's my point. Granted, even if there wasn't native support for this availability, the Erlang source is open, so it's always possible. But doing that is, from a security/stability/sanity perspective, roughly like using eval.
While both the first and second halves are true, the "so" linking them isn't really. The fact that the VM handles scheduling doesn't make it scale to many cores (originally, the Erlang environment was optimized to run separate VMs per core communicating as separate Erlang nodes.)
You're right. However, Erlang does currently have SMP support:
Erlang processes aren't OS processes, they are more like green threads with very limited shared state with restricted means for accessing that state to avoid conflicts
And SMP Erlang doesn't use OS processes either -- it uses threads.
Still, if you can make it scale to multiple machines using the RPC support, you can certainly scale to multicore. By the time the number of cores is such a limiting factor that you need the SMP, I imagine it'll be a few years from now when the SMP is, well, older.
I'm probably going to sound clueless here, but what does XUL do that this doesn't? Because this is CSS+Javascript+HTML+DOM, so it's pretty much down to XUL vs HTML.
It's also got a large-ish positive effect for web pages -- for example, Chrome extensions use HTML5 local storage, rather than inventing its own dedicated storage API. This means that anything I need for an extension, if it's reasonable to do so, will likely be exposed to regular web pages.
And when I said "just", I mean that's only what's required -- though beyond that (so far), they seem to be talking about the plugin API. That is, if you need something HTML+Javascript won't give you, you could (for example) use Flash (ew) in your extension, just as you can in any webpage -- or roll your own plugin.
The Intel Atom Developer Program will make use of Wind River's VxWorks product, which the company believes will help it achieve that developer grail of the 'write once and run on all devices' experience.
I don't get it. VxWorks is an OS, right? How does that help with "write once, run anywhere"?
Seems to me that Android is doing more towards this, given that native Android apps target a VM, and thus aren't tied to ARM, x86, or anything else. I'm not saying Intel isn't doing this, I just don't see what that has to do with Moblin, VxWorks, or an App Store.
Those were my thoughts exactly.
it's likely to catch a lot of people by surprise.
Yeah, well, so is the fact that if they upload personal stuff to the Internet, people might find it on the Internet. If this wasn't covered by whoever introduced you to the Internet, that's a bit like handing a toddler a knife without telling them to be careful.
Is there an ongoing "my Javascript is faster than yours ha-ha" competition in the browser market?
Uhm... Yes?
Javascript is the one client-side programming language that is always guaranteed to be there, on anything that can reasonably be called a browser. Anything that can be called a web application is probably at some point going to care about Javascript speed. And faster Javascript opens the door to some things you might not have thought were possible in a browser.
When looking for a browser, it isn't just speed people are looking for; They want security
Chrome runs each tab in a separate process, meaning it can theoretically sandbox each tab using standard OS techniques -- for example, on Linux, my Chromium does seem to be running things as an unprivileged user, and chrooting them out of the way.
Other browsers are playing catch-up.
add-ons, customization
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.
If I want top speed, I'll use chrome. If I want an all-around great browser, I'll use Firefox.
We don't care, this isn't about you. (And for what it's worth, Firefox is working hard to improve javascript, security, and reliability to match Chrome.)
This is about the 80% who still use IE, and about the rest of us not having to care anymore. I can build a web app that works in Chrome, Firefox, Safari, Epiphany, Galeon, Konqueror, Opera, in every browser, ever, with minimal effort -- figure an extra 5-10% development time to make it work on browsers other than the one I develop for. IE will fuck it up and add easily 20-50% to my development time.
Doing it this way means that at some point in the future, hopefully, something like YouTube will force IE users to either switch browsers or install this plugin -- at which point, I can forget that IE exists, and let it all melt away like a bad dream.
It's not broke until you find a bug.
Or a missing feature.
Or you decide to just document a particular bug, or lack of a feature, in some "known bugs/limitations" document, because it's cheaper than actually trying to fix the bug.
That is: The speed at which you can fix a bug or implement a feature greatly influences what you consider to be a bug.
Yikes.
Well, you've just convinced me of the merits of balancing my checkbook and otherwise maintaining my own finances. At least I can use double-entry accounting with transactions, and correct the bank when they're wrong.
Because that really sounds like a "when", rather than "if"... *shudders*
What is a "COBOL interface"?
Fair point, but I was referring to MBGMorden's old COBOL app, with a "clunky interface", which was later rewritten as a Windows app.
Perhaps it'd be better if it had been straight ported? Then again, that's a WTF all its own.
Sorry, I misspoke...
TiVo is a very well known word for something and nearly everyone who watches TV often uses it or knows it by name.
This proves my point. Before the TiVo, that word was completely unknown. When it was released, it had to be at least as strange, if not stranger, than "Linux".
I've gotten a lot more interest when I call distributions by their short name (ie: Mint or Puppy).
That's why I say "Ubuntu". If people want to know more about it, I may eventually mention Linux, because it's useful to know. But saying "Ubuntu" up front avoids the paradox-of-choice of "Which distro should I use?" and "GNOME or KDE?"
I'd recommend not to say that to your customers unless you are absolutely sure they will understand it the way you mean it.
Programmable, and infinitely customizable, if I have to put some marketing terms on it.
Otherwise, I just let "hackable" be a rumor among people who will understand it. No customer is going to go out of their way to avoid what is known as "most hackable", but those of us who do understand it will gravitate towards such a device.
If changes are infrequent, it might be worth it.
Fair enough -- but this can be a self-fulfilling prophecy. For example, California's problem of six months to lower wages, then nine months to restore them, probably means the change won't happen.
I'd argue that if you can afford to rewrite it such that it takes ten minutes (or a few days, maybe a month, counting all the administrative BS), it really doesn't take that many changes for it to pay off, and you'll probably find yourself making more changes -- that is, things that previously would've been "nice to have, but we can't afford to change it" now become reasonably possible.
Nobody can covertly copy/sell your paper records with a thumb drive, and they need physical access to destroy them. Also they're immune to EMP.
Two words: Encryption and backups.
Encrypted -- no one can covertly copy/sell your records without having your password. Paper records, someone can still covertly copy/sell them, it just takes a xerox machine.
Destroy -- multiple offsite backups, meaning they'd need multiple passwords. And nothing's stopping you from making a physical backup.
EMP -- multiple offsite backups.
Both of these make your data more private and more robust than paper, and they're much more difficult to do with paper.
Less deterministic performance is a problem for some people,
Very true. But it's not a problem for the vast majority of people, especially those who complain about garbage collection -- and with a generational collector, it's not going to be nondeterministic in any noticeable way for your typical end-user application.
I can see it mattering in embedded software, or in a device driver, but not many other places.
maybe some features aren't in the main UI of an app because they tell you to interactively hack the Lisp.
In other words, the fact that the feature is available might make programmers lazy?
Yeah, that is stretching. That's like an open source app suggesting you change a header file and recompile, rather than providing at least a config file -- in practice, most apps will use a config file for anything they expect a user to have to change, even if they are open source.