Your post should have just said, "This is NOT a sampler."
But I didn't know that. For all I know this is some new hip-hop term that I'm just not cool enough (or is that phat enough) to know. Apparently that isn't the case, but I didn't know it when I posted.
in the music world a sampler is often taken to mean something which plays samples, even if it doesn't record them
That's a new one on me, but this isn't a sampler by that definition either. As another person commented, this isn't really even a sequencer... it's just a controller.
The Dashboard server prompts the user with a warning when a Widget is run that uses local-access plugins, allowing the user to allow or deny any execution of the Widget.
Microsoft has a similar pop-up for many cross-site scenarios, where ActiveX plugins or scripts are involved. They've done it for years. This just led to a "crying wolf" problem.
There should not be any access from core webkit for local access. ALL local access should be added explicitly at the application level, using a mechanism like "I/O Slaves". It's the only safe approach, and it is actually *less* inconvenient to the user.
Weren't security zones a different concept designed to limit use of BROWSER plugins which used active-x and have system access, to ensure that they weren't used from untrusted sites on the internet? That doesn't really have anything to do with widgets - just because they use HTML etc doesn't mean they automatically use the internet or can be triggered from a web-site. You still have to download them.
That is precisely what security zones in Windows do, they say "if an HTML page is in THIS zone it has THESE rights, in THAT zone it has THOSE rights". In this case you have a "local disk" zone where the webkit extensions work, and an "internet zone" where they don't.
I can think of one pretty obvious way of using a fake Quicktime file and a local file:// link that has the possibility of breaking this model. I don't know if it could be made to work, but you can bet there will be lots of kids with more time on their hands working on this.
KHTML, the KDE component Safari was originally based on, has a much stronger security model. To add capabilities to a KHTML browser you create what's called an "I/O slave". The webkit extensions should be "I/O slaves" and wouldn't be loaded in Safari or any other application that's used to display untrusted content (Mail.app would be another one).
Some widgets (like the address book) contain actual plug-in code for local data access and will display (but but access records) within the browser. I just tested this.
Shit. We are going to be SO boned when people figure out how to fake out the Safari equivalent of security zones.
Dashboard is made for widgets that you need to look at and get rid of. People coding for Dashboard should know this.
Your faith in your theories about Dashboard is touching.
Sorry to respond like a dick,
I don't think you're sorry at all. I run into this problem a lot: whatever Apple says is right, so anyone who actually thinks different is wrong, and you're totally justified in being a dick about it. Lots of people have been saying that Apple should make a headless low-end Mac for years, and there's always been people ready to slam them for suggesting that people should put ugly monitors on nice Macs. Now Apple says "BYODKM" and it's absolutely OK. When Apple was badmouthing flash players, cheap dedicated display-less devices like the Magic Star MP3 player were obviously a bad idea. Now Apple makes the Shuffle, nobody can remember arguing that it was a bad idea.
It's OK, I understand, you don't mean to be a dick. It just happens. Well, it's OK, I'm not really a traitor to Apple, according to this post there's a backdoor, moving Dashboard widgets off the Dashboard sceren will be permitted, you don't have to defend Apple's precious bodily fluids any more.
There aren't desktop counterparts for all Dashboard widgets? Name one.
The weather and flight tracking applets don't ship with Panther. They have them standalone in Tiger? I didn't see that on Apple's website.
Do you really need to stare at the weather widget and watch the weather change?
No, but I do need to have that kind of thing in the corner of my eye when I'm working at a colo or other field location where there aren't any windows.
Yes, right now I don't know of any Dashboard widgets for which there is no third-party alternative... but just wait. Dashboard is going to be like Hypercard. People will do all kinds of things in Dashboard just because scripting is so easy. That cool potential makes the ghettoization of the widgets so unfortunate.
one wonders what the fate of the newer but still Firewire-less slot-load 350MHz iMacs will be.
That's one of the two anomolies on the requirements page... it simply says "slot-load iMac". Either Firewire isn't the actual cutoff, or the detailed list is wrong. I sent Apple feedback suggesting they clarify that point this morning... we will see.
Actually, I'd have put processing into each square, and make the floor play Conway's game of "Life".
Yeah, that would be cool. Tap a square to flip its state, and if the latency and clock can be tweaked right as you walk across it you'd leave a trail of decaying Life forms. New dance steps, the glider, the r-pentomino...
I've yet to see a Mac with a parallel port... what, they don't count as modern computers now? And if you're just talking about Wintel boxes, what about laptops? Even back in 1999 when I got a Toshiba Libretto, parallel ports were beginning to be optional or when-docked-only in laptops, and now they're fading even in mainstream models.
OK, if you want modern, use Ethernet.
That would be OK, there's some nice small ethernet-capable embedded microcontrollers you can use.
I just wrote the same thing, but I'm afraid that this will be a bad thing. With more and more dashboard applets being written, the fact that they're stuck in the stupid Dashboard ghetto-pane will drive me totally Librarian.
God, I hope someone comes up with a haxie to let me drag Dashboard widgets to the desktop or stick them to the menu bar or the dock...
One more time: dashboard apps are html, css and javascript. Not "applets." Not "ActiveX-like." Html, css and javascript have about as much access to your local disks as...well, any other webpage on the internet. Which is to say: nearly none.
That is unfortunately not true. They have access to your address book and other local data that it would be criminally negligent[1] if it were available from Safari-displayed web pages. Since I don't believe Apple is that stupid, I don't believe that they are just web pages.
[1] I'm not speaking figuratively here, I mean someone should go to jail if they've screwed it up this badly after all this time...
If you didn't want to get rid of them, thats when you use their counter parts (such as Calculator.app).
No, two big reasons no...
1. There aren't desktop counterparts for all the Dashboard applets, and because it's easier to write scripts that difference is just going to become more pronounced. Dashboard is going to be like Hypercard. If it was just a bunch of Cocoa or Java apps, I wouldn't care, but it isn't... what gives the *apps* so much potential is what makes the *presentation* suck.
2. What happens when you decide after you've brought something up in Dashboard you want keep it around while you work on something else?
Slashdot Mirror
Your post should have just said, "This is NOT a sampler."
But I didn't know that. For all I know this is some new hip-hop term that I'm just not cool enough (or is that phat enough) to know. Apparently that isn't the case, but I didn't know it when I posted.
in the music world a sampler is often taken to mean something which plays samples, even if it doesn't record them
That's a new one on me, but this isn't a sampler by that definition either. As another person commented, this isn't really even a sequencer... it's just a controller.
The Dashboard server prompts the user with a warning when a Widget is run that uses local-access plugins, allowing the user to allow or deny any execution of the Widget.
Microsoft has a similar pop-up for many cross-site scenarios, where ActiveX plugins or scripts are involved. They've done it for years. This just led to a "crying wolf" problem.
There should not be any access from core webkit for local access. ALL local access should be added explicitly at the application level, using a mechanism like "I/O Slaves". It's the only safe approach, and it is actually *less* inconvenient to the user.
I'd describe this as a sequencer, not a sampler.
I thought the whole of planet Earth had only one entry: Mostly harmless...
That's before the dolphins brought it back from the alternate universe. All of Ford's entries got re-inserted on the next update.
Weren't security zones a different concept designed to limit use of BROWSER plugins which used active-x and have system access, to ensure that they weren't used from untrusted sites on the internet? That doesn't really have anything to do with widgets - just because they use HTML etc doesn't mean they automatically use the internet or can be triggered from a web-site. You still have to download them.
That is precisely what security zones in Windows do, they say "if an HTML page is in THIS zone it has THESE rights, in THAT zone it has THOSE rights". In this case you have a "local disk" zone where the webkit extensions work, and an "internet zone" where they don't.
I can think of one pretty obvious way of using a fake Quicktime file and a local file:// link that has the possibility of breaking this model. I don't know if it could be made to work, but you can bet there will be lots of kids with more time on their hands working on this.
KHTML, the KDE component Safari was originally based on, has a much stronger security model. To add capabilities to a KHTML browser you create what's called an "I/O slave". The webkit extensions should be "I/O slaves" and wouldn't be loaded in Safari or any other application that's used to display untrusted content (Mail.app would be another one).
Backdoor?? ITS HTML!
So are all the cross-zone exploits in Internet Explorer.
Some widgets (like the address book) contain actual plug-in code for local data access and will display (but but access records) within the browser. I just tested this.
Shit. We are going to be SO boned when people figure out how to fake out the Safari equivalent of security zones.
TextEdit is a pretty thin wrapper around the Cocoa text system.
that's what I thought, hence my hopefully-not-too-naive assumption that other text apps would also get the new toys...
for a dedicated project like this, I'd get a small PC motherboard and bolts it right into the project.
I'd be more inclined to use a Soekris box. Why take on the overhead of rotating storage when you can boot from a cheap solid-state flash card?
Dashboard is made for widgets that you need to look at and get rid of. People coding for Dashboard should know this.
Your faith in your theories about Dashboard is touching.
Sorry to respond like a dick,
I don't think you're sorry at all. I run into this problem a lot: whatever Apple says is right, so anyone who actually thinks different is wrong, and you're totally justified in being a dick about it. Lots of people have been saying that Apple should make a headless low-end Mac for years, and there's always been people ready to slam them for suggesting that people should put ugly monitors on nice Macs. Now Apple says "BYODKM" and it's absolutely OK. When Apple was badmouthing flash players, cheap dedicated display-less devices like the Magic Star MP3 player were obviously a bad idea. Now Apple makes the Shuffle, nobody can remember arguing that it was a bad idea.
It's OK, I understand, you don't mean to be a dick. It just happens. Well, it's OK, I'm not really a traitor to Apple, according to this post there's a backdoor, moving Dashboard widgets off the Dashboard sceren will be permitted, you don't have to defend Apple's precious bodily fluids any more.
There aren't desktop counterparts for all Dashboard widgets? Name one.
The weather and flight tracking applets don't ship with Panther. They have them standalone in Tiger? I didn't see that on Apple's website.
Do you really need to stare at the weather widget and watch the weather change?
No, but I do need to have that kind of thing in the corner of my eye when I'm working at a colo or other field location where there aren't any windows.
Yes, right now I don't know of any Dashboard widgets for which there is no third-party alternative... but just wait. Dashboard is going to be like Hypercard. People will do all kinds of things in Dashboard just because scripting is so easy. That cool potential makes the ghettoization of the widgets so unfortunate.
Why does Tiger absolutely need firewire ports anyway?
Same reason Panther absolutely needs built-in USB ports. To give them an excuse to drop support for older machines.
I notice it's a DVD only too.
I don't believe that's the case. There was a note somewhere about CD versions being available on request.
one wonders what the fate of the newer but still Firewire-less slot-load 350MHz iMacs will be.
That's one of the two anomolies on the requirements page... it simply says "slot-load iMac". Either Firewire isn't the actual cutoff, or the detailed list is wrong. I sent Apple feedback suggesting they clarify that point this morning... we will see.
Do you have to be running 10.3.x to upgrade?
Exteremely unlikely, no previous version has had that kind of requirement.
PS:
Actually, I'd have put processing into each square, and make the floor play Conway's game of "Life".
Yeah, that would be cool. Tap a square to flip its state, and if the latency and clock can be tweaked right as you walk across it you'd leave a trail of decaying Life forms. New dance steps, the glider, the r-pentomino...
I've yet to see a parallel port-less PC.
I've yet to see a Mac with a parallel port... what, they don't count as modern computers now? And if you're just talking about Wintel boxes, what about laptops? Even back in 1999 when I got a Toshiba Libretto, parallel ports were beginning to be optional or when-docked-only in laptops, and now they're fading even in mainstream models.
OK, if you want modern, use Ethernet.
That would be OK, there's some nice small ethernet-capable embedded microcontrollers you can use.
But parallel? Not this century.
Dashboard will be the new HyperCard.
I just wrote the same thing, but I'm afraid that this will be a bad thing. With more and more dashboard applets being written, the fact that they're stuck in the stupid Dashboard ghetto-pane will drive me totally Librarian.
God, I hope someone comes up with a haxie to let me drag Dashboard widgets to the desktop or stick them to the menu bar or the dock...
Format newly composed email using HTML.
Stercus, stercus, stercus, moriturus sum.
This is cool, I really like TextEdit. Does this apply to other Cocoa rich text editing fields?
One more time: dashboard apps are html, css and javascript. Not "applets." Not "ActiveX-like." Html, css and javascript have about as much access to your local disks as...well, any other webpage on the internet. Which is to say: nearly none.
That is unfortunately not true. They have access to your address book and other local data that it would be criminally negligent[1] if it were available from Safari-displayed web pages. Since I don't believe Apple is that stupid, I don't believe that they are just web pages.
[1] I'm not speaking figuratively here, I mean someone should go to jail if they've screwed it up this badly after all this time...
If you didn't want to get rid of them, thats when you use their counter parts (such as Calculator.app).
No, two big reasons no...
1. There aren't desktop counterparts for all the Dashboard applets, and because it's easier to write scripts that difference is just going to become more pronounced. Dashboard is going to be like Hypercard. If it was just a bunch of Cocoa or Java apps, I wouldn't care, but it isn't... what gives the *apps* so much potential is what makes the *presentation* suck.
2. What happens when you decide after you've brought something up in Dashboard you want keep it around while you work on something else?
Just think of them as apps that all share the same hotkey to switch to them.
You mean like Sidekick under MS-DOS on the original IBM-PC? Full points for retro chic, but zilch for common sense.
And why bother with USB when a basic parallel port connection would give them all the control they need?
Parallel ports are so 2nd millennium.
No, really, modern computers increasingly don't have parallel ports. They DO have USB.