Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
Not open for further replies.
dashboard and safari

Macrumors said:
David Hyatt updates his blog to provide some clarification on Apple's upcoming Dashboard Widgets.

indeed

actually all dashboard "things" are gadgets they have extensions .gadget
not widget

every gadget has inside html file which you can open with safari
and you'll see exactly the same image and functionality as from F12
 
nagromme said:
All we knew before was JavaScript and that's still true--but now we know there are OTHER methods too. No new limits have been introduced by this news.

(I wonder how you get the eye candy from JS? Like the flipping stickies? And I wonder where alpha control comes from? I hope Flash widgets can be rendered with no bounding box!)


He brings up a good point, actually. What "domain" does a Widget run in? What he is missing, I think, is that Cocoa is available to Widgets, so you have [full] access to the system through it. You don't need to run PHP scripts for command line execution. I can't wait for Tiger! Bring it on baby!

This is definitely the end of the browser and the beginning of tight desktop integration. Haha, I just realized that! Here Microsoft is going on about Web Services as one of the big features of Longhorn, and Apple is creating web integration into the OS "for the rest of us". Way to go Apple!
 
(Speaking of the end of the browser... let's keep Safari and lose Sherlock! Not because Sherlock isn't good--I love the movie and yellow/white pages channels for instance. But just put the Sherlock channels into Safari--including letting Sherlock search-plugins extend the Google bar to other sites.)
 
I'm curious as to what kind of file-system protection there will be from potentially malicious Dashboard gadgets. One of the major downsides of Konfabulator (arising because of its excellent versatility) is that a widget can potentially do very nasty things -- because it has access to all Applescript and command-line commands, a widget could easily do things like wipe your user directory. Because of this Rose and Perry vet the code of every single widget that gets posted in the Konfabulator Widget Gallery. That's an OK system for a small operation like Konfabulator, but just won't work when this functionality is actually baked into the OS.

So I wonder if Dashboard will have the same kind of system-level access that Konfabulator does (which lets K do a lot of really useful things), and if so, if there will be some sort of built-in protection against various forms of nastiness.
 
Tulse said:
I'm curious as to what kind of file-system protection there will be from potentially malicious Dashboard gadgets. One of the major downsides of Konfabulator (arising because of its excellent versatility) is that a widget can potentially do very nasty things -- because it has access to all Applescript and command-line commands, a widget could easily do things like wipe your user directory. Because of this Rose and Perry vet the code of every single widget that gets posted in the Konfabulator Widget Gallery. That's an OK system for a small operation like Konfabulator, but just won't work when this functionality is actually baked into the OS.

So I wonder if Dashboard will have the same kind of system-level access that Konfabulator does (which lets K do a lot of really useful things), and if so, if there will be some sort of built-in protection against various forms of nastiness.

I wouldn't think Apple would allow root access...given the nature of the beast.
 
fabsgwu said:
Besides, there's still the niche for people who want their widgets around all the time: there's over 600 already developed for Konfab as we speak, nothing to sneeze at.
'Tho many might qualify as crapware; see John Gruber's Broken Windows article (I'd like to believe his closing comment there (which would be censored if quoted here) is true most of the time :)).

nagromme, Re: ditching Sherlock. That topic has been kicked around a lot, maybe heaviest most recently (IIRC) around the time of the Sherlock 3 vs. Watson brouhaha. Some people are strongly opposed to the browser being a "universal UI". And for some people, at least for certain applications (e.g. webmail), it doesn't matter. Brings to mind another of John's recent Daring Fireball articles, The Location Field Is the New Command Line.
 
DGFan said:
If Konfabulator gets the HTML capabilities it is possible to add (apparently they're in internal testing on that part) then K will be much more flexible.

Uh, right...

Konfabulator: JavaScript with its own runtime and memory space, XML, and possibly HTML, with Quartz integration.

Dashboard: WebCore, JavaScript using the native OS X runtime, HTML and CSS, Cocoa (and thus regular application programming), Expose, and Core technologies. The interface can touch anything that WebCore can use - Flash, Director, Quicktime, and anything else Safari can render.

Who's more flexible?

Personally, I'd much rather deal with XML and provide JS action handlers than muck around setting up CSS and JS handlers. Konfabulator's layout is much more developer friendly. But there are advantages (Flash *shudder*) to HTML and I do hope Konfabulator adds them eventually.

This isn't about what you want, it's about making the platform more appealing to people of all kinds of skill levels. At least three of the techonologies demoed at WWDC this yeare were about making things easier on hobbyist programmers, just as much as the professionals. Which ones? Dashboard's environment, Core Image and Video, and Automator are all in this vein, for a start, and that's just what Steve was actively showing us.
 
Gadgets are web pages you say?

So, you want to try out the gadgets? Yup, they truly are web pages:

Address Book
Calculator
iTunes
Stickies
Tile Game
World Clock

To be fair, even when run locally in Safari, all the gadgets that interfere with the system info, most importantly Adress Book is non-functional. You can't even change the iTunes-track :) So there's clearly more to gadgets than just HTML+JavaScript. (I presume they use Cocoa-hooks only when run in a local Dashboard-enviroment).

But hey, have fun with the calculator and the tile game. Ripple-effect not included :D

(More info on my weblog)
 
Flash, eh? I wonder if someone can write a script that retrieves the latest Strong Bad e-mail from Homestar Runner. Now THAT would be a fantastically useful widget. Instant humor!

And iChan, can you please learn to multi-quote? Safari has tabs for a reason. Your double, triple, and sometimes quadruple posts are very annoying. Concatenate, man!

--Cless
 
Tulse said:
I'm curious as to what kind of file-system protection there will be from potentially malicious Dashboard gadgets.

Really, what does it need, other than the protection already built into the operating system? Applescript and the shell can already do these things. There really isn't any new functionality being added, just a new interface to things people can already get at and (mis)use today.

You may be worrying in particular about widget/gadget/whatevers written by people you don't know, but this is nothing new. All the programs written in C, Applescript, BASIC or whatever sitting out on macupdate and versiontracker could potentially be buggy or evil too, and indeed very many of them are terrible, written by people who haven't a clue what they're doing. We already have ways to deal with that stuff, it will apply as well to dashboard thingies.
 
thatwendigo said:
Uh, right...

Konfabulator: JavaScript with its own runtime and memory space, XML, and possibly HTML, with Quartz integration.

Dashboard: WebCore, JavaScript using the native OS X runtime, HTML and CSS, Cocoa (and thus regular application programming), Expose, and Core technologies. The interface can touch anything that WebCore can use - Flash, Director, Quicktime, and anything else Safari can render.

Who's more flexible?

I haven't seen any direct information about Cocoa. Did the headline of this thread say "In other words, each widget is just a web page?" I am not aware of a way to access Cocoa from something that is "just a web page."

Expose? Do you know something I don't? The widgets appear on their own screen. Ooooh. Konfabulator does this now (Konspose) and will soon have the ability for widgets to operate exactly like Dashboard - where they don't appear except when running Konspose. So what exactly was your point in bringing up Expose?

As far as HTML and Webkit, we don't really know if Konfabulator will be able to display any and all web pages. Given the fact that Webkit exists, I don't see why not. Sure, Konfabulator doesn't have it now. But then Dashboard hasn't been released yet, has it?

Core technologies? I haven't seen the details yet, but what makes you think that Konfabulator won't be able to use CoreImage? It's supposed to be usable anywhere, right?

That pretty much covers everything on your list. Yep, IF (big if) Konfabulator gets Webkit support (including CSS, Flash, Quicktime, and anything Webcore can render) it will be far more flexible than Dashboard, as it has been described currently.

thatwendigo said:
This isn't about what you want, it's about making the platform more appealing to people of all kinds of skill levels. At least three of the techonologies demoed at WWDC this yeare were about making things easier on hobbyist programmers, just as much as the professionals. Which ones? Dashboard's environment, Core Image and Video, and Automator are all in this vein, for a start, and that's just what Steve was actively showing us.

Core Image and Video is for hobbyists, huh? I guess we'll wait and see on that.

And if you had spent plenty of time on the Konfabulator bulletin boards you'd see that there are plenty of hobbyists making widgets. In fact, that's pretty much the complaint of many - a lot of widgets aren't made by "Pros."

edit: s/Webcore/Webkit/g
 
alright... this is becoming a comical paradox.

so, initially, camp K took the position that Apple were punks for 'ripping off' konfab and making dashboard. the grounds for this were that A) apple stole the idea and B) apple did it better and thereby destroyed arlo's hopes and dreams.

then david went and said that the widget/gadgets are web pages. this made people say "oooooh" and then camp Apple said "see, dashboard is simply better."

throughout this argument was the debate over whether Desktop assistants or konfab inspired dashboard.

now...perhaps the most amusing aspect of A vs K is the fact that camp K seems to be leaning harder on the notion that Konfab will be better.

now, if konfab will be better;
A) apple did not crush arlo's hopes and dreams.
B) Dashboard was different enough to force Konfab to change
C) competition might be worthwhile


how about everyone just stop and consider, how long does it take to write something like dashboard? i dont know when konfab came out.

i don't particularly care about any of this. i will not buy konfab, but i will buy tiger. i dont like too many small house apps.

some of what i have said may offend you
some of what i have said may not apply to you,
but no matter what, you must remember one thing that i have said
and that is that Jerk chicken is better.
 
DGFan said:
I haven't seen any direct information about Cocoa. Did the headline of this thread say "In other words, each widget is just a web page?" I am not aware of a way to access Cocoa from something that is "just a web page."

RTFA:
Plus, Dashboard gadgets are further extensible using Cocoa. You don’t need to use Cocoa — fully functional gadgets can be made using nothing more than HTML, CSS, and JavaScript — but the option to use Cocoa is there for doing things JavaScript alone can’t do.​

Expose? Do you know something I don't? The widgets appear on their own screen. Ooooh. Konfabulator does this now (Konspose) and will soon have the ability for widgets to operate exactly like Dashboard - where they don't appear except when running Konspose. So what exactly was your point in bringing up Expose?

My point is that Dashboard uses system hooks in Expose for its hide/show features, rather than adding a separate layer of runtime, memory usage, and outside APIs. It's cleaner, neater, and doesn't add untried and - as far as I've read - hideously buggy and memory-hole ridden code.

As far as HTML and Webkit, we don't really know if Konfabulator will be able to display any and all web pages. Given the fact that Webkit exists, I don't see why not. Sure, Konfabulator doesn't have it now. But then Dashboard hasn't been released yet, has it?

So... Konfabulator would be copying Dashboard, then, in a much more serious way than Apple sort-of-kind-of copied the look of a program that a former Apple Human Interface designer deliberately made to ape their style? Okay then.

Core technologies? I haven't seen the details yet, but what makes you think that Konfabulator won't be able to use CoreImage? It's supposed to be usable anywhere, right?

Dashboard has it as things stand. Konfabulator would be copying Dashboard, which is what Arlo accuses Apple of doing. Oops.

That pretty much covers everything on your list. Yep, IF (big if) Konfabulator gets Webkit support (including CSS, Flash, Quicktime, and anything Webcore can render) it will be far more flexible than Dashboard, as it has been described currently.

I'd like to see even a remote justification for this claim, rather than a repeated assertion that it's true. All that Konfabulator is, as far as "flexibility" goes, is an outside API that adds complexity, not anything all that groundbreaking.

Core Image and Video is for hobbyists, huh? I guess we'll wait and see on that.

It's a hell of a lot more friendly to hobbyists than having to write your own image handlers all the time, that's for certain. It's a core-level, high speed graphical code that interfaces with Apple's existing technology and which provides more options for anyone writing OS X aaplications. That means that hobbyists have more available to them than they did before. Konfabulator has a document that lists the syntaxes. Ooooh.... Yeah, that's an advantage. :rolleyes:

And if you had spent plenty of time on the Konfabulator bulletin boards you'd see that there are plenty of hobbyists making widgets. In fact, that's pretty much the complaint of many - a lot of widgets aren't made by "Pros."

I tried Konfabulator and I wasn't impressed enough to want to pay for it, so there's no reason to want to hang out on their boards. Contrary to my experience with K, it looks like Dashboard might very well be something I would use.
 
thatwendigo said:

I think it's pretty obnoxious and rude to suggest I RTFA when the article is
1) not linked in this discussion
2) not from Apple

Furthermore, I have seen other people reprimanded for "bypassing the profanity filter". Are acronyms allowed? So if I say FY (or is that FU) it's ok?

Now, to respond to your comments (in aggregate).

Yes, one could say that Konfabulator copied from Apple. Whoop-dee-do. I wasn't one of the "Apple stoles from ussss" crybabies.

I don't know anything about buggy or hole-ridden code in K. K runs on my system without using too much memory. Maybe I', just using the wrong widgets.

It doesn't really matter what Dashboard "has now" because Dashboard isn't a released product. Konfabulator may have features also in beta that they simply haven't released. Released products are all that count.

An API doesn't have to be groundbreaking to be adding flexibility. If A = a + b + c and B = a + b + c + d then B has more. It's simple, really.

I am very happy for you that you want to use Dashboard. And maybe when Dashboard and future versions of Konfabulator are actually released a more intelligent conversation can be had. But right now any pronouncements of "X is better" or "Y is more flebxible" are just pissing in the wind. I hope you enjoy being wet....
 
The article was posted in post #35 of this thread, but I can see how the confusion could start between Hyatt's article and the daring Fireball one.

As for acronyms, they have yet to be an issue on this forum, as far as I've seen, and in this case it is not a personal attack. Your examples, however, would be.

Play nice, folks. :)
 
crazy apple rumors has posted on how this will finally be settled

Jobs To Fight Rose After WWDC.

According to numerous paper notes being passed in sessions at Apple's Worldwide Developers Conference, CEO Steve Jobs will fight Konfabulator co-creator Arlo Rose near the swings outside the Moscone Center after the conference concludes.


Jobs and Rose's disagreement is the result of what many feel is the appropriation of Konfabulator's functionality in Tiger's Dashboard.

then added
Rose is also rumored to believe that Jobs smells and he looks funny and he dresses like a dork and is a stupid four-eyes. Jobs, on the other hand, thinks Rose is a loser and the only reason he is whining is that he is a loser who doesn't know how not to be a loser because he's such a loser.
 
DGFan said:
I think it's pretty obnoxious and rude to suggest I RTFA when the article is
1) not linked in this discussion
2) not from Apple

I think it's pretty obnoxious and rude to make allegations about software without having gone through the developer notes, or at least reading an article written by someone who has. The Daring Fireball writeup is excellent because it points out both the historical and technological aspects of this particular disagreement. In both senses, Apple is more than justified in its actions and Rose has basically no ground to stand on, especially in terms of mimicing previous efforts.

To summarize:
  1. Konfabulator is only innovative in its application of Quartz implentation.
  2. Rose worked for Apple's interface group, which explains why his programs look so much like something that would come out of Cupertino.
  3. Dashboard is based in Apple's system technology, while Konfabulator is based on external APIs that are designed for portability.
  4. Arlo Rose was competing on the basis of a single idea that was based on a perceived hole in the OS, and Apple has now done it better, thus plugging the hole. It's his own lack of foresight and diversification that did him in.

I don't know anything about buggy or hole-ridden code in K. K runs on my system without using too much memory. Maybe I', just using the wrong widgets.

Once again, RTFA:
Konfabulator is not a lightweight or small-footprint environment — every Konfabulator widget runs as a separate process, with its own runtime environment in memory. Most Konfabulator widgets use more memory than typical full-blown Mac OS X applications. Not just Konfabulator as a whole — but each widget. Install it, fire up Process Viewer, and see for yourself. (Ironically, the Konfabulator “CPU Portal” widget seems to leak memory.)​

An API doesn't have to be groundbreaking to be adding flexibility. If A = a + b + c and B = a + b + c + d then B has more. It's simple, really.

Konfabulator contains its own self-contained JavaScript runtime engine, based on SpiderMonkey, the open source JavaScript engine from the Mozilla Project. Konfabulator UI layouts are specified in a custom XML format. I.e.:

Konfabulator = (Custom XML format) + (Custom JavaScript engine)

...

Adding a new platform layer to the system is a serious decision and commitment. If you’re still willing to argue that Apple should have bought Konfabulator as the basis for Dashboard, you’re implicitly arguing that Apple should be more concerned about being nice to third-party developers than they are about the quality of the engineering undergirding their platform.​

I am very happy for you that you want to use Dashboard. And maybe when Dashboard and future versions of Konfabulator are actually released a more intelligent conversation can be had. But right now any pronouncements of "X is better" or "Y is more flebxible" are just pissing in the wind. I hope you enjoy being wet....

Who's trolling now? :rolleyes:

I'm having a perfectly intelligible conversation about the existing framework and APIs for Dashboard, which Apple apperently believes in enough that they gave out two prizes for the best Gadget programmed at WWDC: a PowerBook 15" and a 40GB iPod.
 
iChan said:
you are right, but i don't think anyone will argue that konposé is hideous.

with it's layer of parchment-y textured background and cog logo stamped in the middle.
It's not hideous. I just don't need to bring widgets to the forefront of my desktop as much as I need them to hide them off-screen and make them reappear as needed. If I could do that, I'd keep more widgets open and available for reference, but hidden.
 
thatwendigo said:
I think it's pretty obnoxious and rude to make allegations about software without having gone through the developer notes, or at least reading an article written by someone who has. The Daring Fireball writeup is excellent because it points out both the historical and technological aspects of this particular disagreement. In both senses, Apple is more than justified in its actions and Rose has basically no ground to stand on, especially in terms of mimicing previous efforts.

To summarize:
  1. Konfabulator is only innovative in its application of Quartz implentation.
  2. Rose worked for Apple's interface group, which explains why his programs look so much like something that would come out of Cupertino.
  3. Dashboard is based in Apple's system technology, while Konfabulator is based on external APIs that are designed for portability.
  4. Arlo Rose was competing on the basis of a single idea that was based on a perceived hole in the OS, and Apple has now done it better, thus plugging the hole. It's his own lack of foresight and diversification that did him in.

We are discussing which app is more flexible. You seem to have me confused with someone else with whom you may have been discussing which product is more innovative.

thatwendigo said:
Once again, RTFA:
Konfabulator is not a lightweight or small-footprint environment — every Konfabulator widget runs as a separate process, with its own runtime environment in memory. Most Konfabulator widgets use more memory than typical full-blown Mac OS X applications. Not just Konfabulator as a whole — but each widget. Install it, fire up Process Viewer, and see for yourself. (Ironically, the Konfabulator “CPU Portal” widget seems to leak memory.)​

First, only jerks say "RTFA".

And again, you seem to have me confused with someone else. Or perhaps you're trying to argue that Dashboard is more flexible because it has a smaller footprint? That's like arguing that "my car can carry more people because it has better fuel mileage."

Um. Okay

thatwendigo said:
Konfabulator contains its own self-contained JavaScript runtime engine, based on SpiderMonkey, the open source JavaScript engine from the Mozilla Project. Konfabulator UI layouts are specified in a custom XML format. I.e.:

Konfabulator = (Custom XML format) + (Custom JavaScript engine)

...

Adding a new platform layer to the system is a serious decision and commitment. If you’re still willing to argue that Apple should have bought Konfabulator as the basis for Dashboard, you’re implicitly arguing that Apple should be more concerned about being nice to third-party developers than they are about the quality of the engineering undergirding their platform.​

Where did I ever argue Apple should have bought Konfabulator? Are you for real?

thatwendigo said:
Who's trolling now? :rolleyes:

I'm having a perfectly intelligible conversation about the existing framework and APIs for Dashboard, which Apple apperently believes in enough that they gave out two prizes for the best Gadget programmed at WWDC: a PowerBook 15" and a 40GB iPod.

Who's trolling? Let's see, you made up a bunch of arguments that I never even vaguely mentioned and "tah-dah" you managed to refute them. What a pathetic straw man you created.

More proof that high post count != intelligence
 
DGFan said:
We are discussing which app is more flexible.

Then it would help to read up on at least one of the apps, hm? Or, at least the rest of the thread (where a very informative article was, indeed, referenced).

Sorry, but I can see how thatwendigo thought it was appropriate to say RTFA. Of course, I have a better right, since I was the one to reference the artlcle in question....and you replied to it.
 
Watch those pedals turn backwards!

DGFan said:
We are discussing which app is more flexible. You seem to have me confused with someone else with whom you may have been discussing which product is more innovative.

Actually, I was responding to your post that said it was rude and obnoxious to suggest that you ought to read an informative article that was linked to earlier in the thread, which just so happens to demolish every single one of your arguments. As such, it's entirely appropriate for me to have pointed you at it and summarized the basics of the situation.

I'm posting at you, but you're far from the limit of the audience.

And again, you seem to have me confused with someone else. Or perhaps you're trying to argue that Dashboard is more flexible because it has a smaller footprint? That's like arguing that "my car can carry more people because it has better fuel mileage."

For someone who likes to accuse others of straw men, you manage to - rather impressively - completely miss every point I made. The entire function of that section I quoted was to educate you on the topic of memory management within Konfabulator, since you said that you didn't know much about it. The article I told you to read explained how it handled memory, and how it's inferior to the way that Dashboard does, because it hogs far more resources.

This is entirely germane.

Where did I ever argue Apple should have bought Konfabulator? Are you for real?

An API doesn't have to be groundbreaking to be adding flexibility. If A = a + b + c and B = a + b + c + d then B has more. It's simple, really.

Konfabulator contains its own self-contained JavaScript runtime engine, based on SpiderMonkey, the open source JavaScript engine from the Mozilla Project. Konfabulator UI layouts are specified in a custom XML format. I.e.:

Konfabulator = (Custom XML format) + (Custom JavaScript engine)

...

Adding a new platform layer to the system is a serious decision and commitment. If you’re still willing to argue that Apple should have bought Konfabulator as the basis for Dashboard, you’re implicitly arguing that Apple should be more concerned about being nice to third-party developers than they are about the quality of the engineering undergirding their platform.​

So that your memory is refreshed, I took the whole section to give context.

My point was that Konfabulator does not add any functionality worth talking about, because it really doesn't add much, and Dashboard beats the hell out of it on the few things it did bring with it. On top of that, as I was pointing out, a huge part of not buying the rights to Konfabulator (which is a tangential point) is that the technology is poorly implemented and not at all beneficial to the OS. Dashboard, on the other hand, ties into the existing technologies and adds more, while giving a genuine flexibility that comes from a huge range of options that don't require outside APIs that run their own memory space for each applet.

Who's trolling? Let's see, you made up a bunch of arguments that I never even vaguely mentioned and "tah-dah" you managed to refute them. What a pathetic straw man you created.

Pot, meet ketttle.
 
thatwendigo said:
Actually, I was responding to your post that said it was rude and obnoxious to suggest that you ought to read an informative article that was linked to earlier in the thread, which just so happens to demolish every single one of your arguments. As such, it's entirely appropriate for me to have pointed you at it and summarized the basics of the situation.

I had already read the article. And it really doesn't touch on the *only* argument I have made which is that Konfabulator has what I consider to be a useful additional method of providing functionality to widgets which Dashboard does not appear to have. Furthermore, it is likely that Konfabulator will be adding functionality similar to that of Dashboards in the future rendering, IMO, K more flexible. Not better for most people to code for, not more efficient in system resources, just more flexible. The arguments that the article demolishes were arguments of your making, not mine.

It's not rude and obnoxious to suggest that I read an article which you believe may have ideas contrary to my opinion. It is rude and obnoxious to tell me to Read The F***ing Article.

thatwendigo said:
My point was that Konfabulator does not add any functionality worth talking about, because it really doesn't add much, and Dashboard beats the hell out of it on the few things it did bring with it. On top of that, as I was pointing out, a huge part of not buying the rights to Konfabulator (which is a tangential point) is that the technology is poorly implemented and not at all beneficial to the OS. Dashboard, on the other hand, ties into the existing technologies and adds more, while giving a genuine flexibility that comes from a huge range of options that don't require outside APIs that run their own memory space for each applet.

Whether Konfabulator adds much is open to opinion. Ok, so you don't value the current way K widgets are described. That doesn't mean it isn't there.

I think (after having read the article and used my own brain) that it is likely that Apple didn't try to buy Konfabulator because:
1. when Apple likely started work on Dashboard, Konfabulator was also in its infancy
2. Apple wanted to take a different direction technically making the widgets simply web pages (with support allowed for other technologies ie Core) - this is supported by the article you linked and makes it perfectly sensible that they didn't even bother to contact Arlo & Company
 
confused about core image

I don't have time to search through the countless forums here, so if this has been covered numerous times, I apologize. What I don't get is what this means exactly (core image) for computers with graphics cards below the requirements. I have an imac 800 and an ibook g4, both of which don't meet the requirements. Does this mean that the dashboard widgets for instance will not have the flip effect on my machines? Am I going to be missing out on a lot of the key features/future potential software releases for Tiger? (not trying to imply that flipping widgets is in itself a key feature).
 
Status
Not open for further replies.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.