Konfab doesn't have any "candy effects" Sure, it has composited windows, but every window is composited, and compositing is already GPU accelerated by Quartz Extreme.
There's more to it than that, Konfab has a pretty bad reputation for being a resource hog, depending on the widget you use.
I don't understand how the folks at Konfabulator can build something around Apples own style and ideas, and then accuse Apple of ripping them off. And the coolest thing about Dashboard isn't even in Konfab - the ability to use a hot key to fade in all the widgets.
There's more to it than that, Konfab has a pretty bad reputation for being a resource hog, depending on the widget you use.
Again, what makes you think Dashboard will be better in this regard? I'm not claiming anything one way or the other, I'm just asking why everyone seems so sure that similar widgets will have wildly different CPU and memory usage behaviors in Dashboard vs. Konfab.
Quote:
the coolest thing about Dashboard isn't even in Konfab - the ability to use a hot key to fade in all the widgets.
The "Konspose" of Kondabulator feature is similar in that it brings all the widgets to the front and fades the background. Put them all at desktop level and they won't interfere with anything until summoned (even though you may still be able to see some of them...which may be considered a feature for certain kinds of widgets).
If Dashboard gadget suck up RAM and CPU when they are not on screen then I won't use them. I already know Konfabulator is a pig because of its runtime environment. So Dashboard can be no worse the Konfablutor in my eyes.
The Konfab / Dashboard resources question seems simple enough to answer, or at least get a sense of an answer... if someone with access to the Tiger seed is willing to chime in with a report. Anyone out there?
If Dashboard gadget suck up RAM and CPU when they are not on screen then I won't use them.
Why do you think that "being on screen" makes such a big difference? If a widget is polling a web site periodically to get stock prices or the weather or whatever, it's going to do so whether or not it's visible, so that when it does become visible it has the correct stock prices or the weather.
Maybe a widget with constant animation will take less CPU if it isn't visible, but if you are running such an annoying widget, you deserve what you get, IMO
As for memory usage, it's pretty much the same for visible and invisible windows (+/- compression, but visible windows can be compressed too--check QuartzDebug)
Finally, as for the runtime, WebKit is not small. Of course, if you're using Safari, you're running it already anyway, which helps. But the Konfab runtime on my system has an an RPRVT of 1.68M. It's going to be hard for WebKit to beat that by much.
IMO, the only real hope for a big difference in CPU or memory usage is if Dashboard isn't running at all until the first time you call it up. But in that case, you can also simply bind Konfabulator to an F-key not run it until you need it to get the same effect.
The Konfab / Dashboard resources question seems simple enough to answer, or at least get a sense of an answer... if someone with access to the Tiger seed is willing to chime in with a report. Anyone out there?
Sure. The default widgets on the Tiger build I played with ate 6Mb each. They seemed to use virtually no CPU at all when displayed and none when they were hidden. I assume the more complicated widgets to come will eat more, but from what I've seen it's far less taxing than Konfabulator.
Again, what makes you think Dashboard will be better in this regard? I'm not claiming anything one way or the other, I'm just asking why everyone seems so sure that similar widgets will have wildly different CPU and memory usage behaviors in Dashboard vs. Konfab.
Here's a quote from developer John Gruber:
"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.)"
CoreImage is only used for the watersplash-effect when a new widget is activated. You can use Dashboard on any graphic-card shipped but will not get the above mentioned effect.
Care to elaborate on what was debunked? Or copy and paste the whole article?
I'd be very surprised if his argument was taken apart as he was merely popping the balloons of a bunch of (how can I put this?) whining, ignorant bitches.
I don't agree with everything that he writes but on this point his 'opponents' were barely rational, spouting knee-jerk reactions based on nothing more than screenshots and misplaced outrage. It would have been near miraculous if they had accidentally made a point that was actually correct.
Sorry, but that opinion piece by daring fireball was nothing but slight of hand in regards to Konfab/DB.
Who cares where certain, very basic, ideas may have originated, it;s how they are executed that counts. We could go back in time and say how this and that just copied from x, y, or z. But what Apple have done, is to wholesale copy and jump onto a bandwagon that the likes of Konfab. and Desktop X (Windows) made popular.
Look, if these new programs hadn't have become popular, do you thin Apple would be introducing something like them now? Nah, don't think so. The popularity of Konfab and the like is what drove Apple to do this.
I don't give a toss if way back in time Apple had some crazy idea of desktop accessories, they were nothing. Now we see Apple introducing something that hops onto this trend, introduces something that resembles konfab. The style, the idea, and the fact that konfab did it, in this manner, before Apple.
Quote:
Originally posted by stupider...likeafox
Care to elaborate on what was debunked? Or copy and paste the whole article?
I'd be very surprised if his argument was taken apart as he was merely popping the balloons of a bunch of (how can I put this?) whining, ignorant bitches.
I don't agree with everything that he writes but on this point his 'opponents' were barely rational, spouting knee-jerk reactions based on nothing more than screenshots and misplaced outrage. It would have been near miraculous if they had accidentally made a point that was actually correct.
Sorry, but that opinion piece by daring fireball was nothing but slight of hand in regards to Konfab/DB.
Who cares where certain, very basic, ideas may have originated, it;s how they are executed that counts. We could go back in time and say how this and that just copied from x, y, or z. But what Apple have done, is to wholesale copy and jump onto a bandwagon that the likes of Konfab. and Desktop X (Windows) made popular.
Konfabulator looks like Desktop X too. In fact anything using non-rectangular windows and trying to mimic other real life devices like clocks, etc will look like this. If a developer was given a modern operating system and told to port Desk Accessories to it with no prior knowledge of Desktop X and Konfab I suspect it would look surprisingly similar. Using a compositing layer is totally obvious if you have one available. Even if Apple should be paying "we ripped you off" money to Arlo and Perry for Konfabulator then surely Arlo and Perry in turn should be paying money to the Desktop X developers and they aren't doing that as far as I know.
All that aside though, you're right, it is how they are executed that counts and from all accounts in the areas that matter, i.e. the runtime, Dashboard appears to be very different to Konfabulator. I'm more than willing though to see what was debunked in MDJ.
"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.
I think Gruber was looking at VSIZE or something equally misleading. I have Konfabulator and can look for myself at the memory usage. I posted some numbers earlier. None of the widgets I have open right now (iTunes Bar, Weather, To Do) are using any CPU (0.0% in top).
As for running each widget in separate processes, someone with Tiger can comment on whether or not Dashboard widgets are separate processes, and what their memory footprints are like.
Observation of the developing programs. If program x exists for a certain amount of time and is popular; then program y comes along in which the implentation is virtually the same. Then it seems logical that program y's authors have based their idea n existing lines, but like most developers, they implement a slight twist to things.
I think as opposed to trying to "fight the big Apple", if I were him I would offer my services to Apple and see if they'd pull me on to help oversee the project. Or see if he could sell some of his widgets so they could "improve" on them or whatever..
It's all salmon in the fish game.. marinate bitches..
Observation of the developing programs. If program x exists for a certain amount of time and is popular; then program y comes along in which the implentation is virtually the same. Then it seems logical that program y's authors have based their idea n existing lines, but like most developers, they implement a slight twist to things.
Yes, but while Dashboard may be similar to Konfabulator in concept, their implementations (underlying codebase) are quite different. And while the two may look similar, Apple has provided a number of "twists" on the backend. Apple's inclusion of Webcore and Exposé are two extremely significant alterations to the widgets concept and should not be overlooked. (Konsposé or whatever the hell it's called was introduced well after Arlo Rose was aware of Dashboard). In the end, while it may initially seem like Apple is exercising its monolithic/monopolistic presence to stifle the "creativity" of smaller developers, looking a bit deeper reveals that Apple is doing nothing more than extending the concepts and "goals" of the decades-old desk accessories and providing several, dare I say it, innovations along the way. From my point of view, about the only things Dashboard rips off from Konfabulator are the crappy widget interfaces.
If program x exists for a certain amount of time and is popular; then program y comes along in which the implentation is virtually the same.
I'm beginning to think people posting in this thread haven't read the Gruber piece. You're offering opinions that were popular before people knew what the hell Dashboard actually was.
Now that people know better, no-one is claiming the implementation is virtually the same, and if you are then you'd better justify that comment.
Comments
Originally posted by John
Konfab doesn't have any "candy effects" Sure, it has composited windows, but every window is composited, and compositing is already GPU accelerated by Quartz Extreme.
There's more to it than that, Konfab has a pretty bad reputation for being a resource hog, depending on the widget you use.
I don't understand how the folks at Konfabulator can build something around Apples own style and ideas, and then accuse Apple of ripping them off. And the coolest thing about Dashboard isn't even in Konfab - the ability to use a hot key to fade in all the widgets.
There's more to it than that, Konfab has a pretty bad reputation for being a resource hog, depending on the widget you use.
Again, what makes you think Dashboard will be better in this regard? I'm not claiming anything one way or the other, I'm just asking why everyone seems so sure that similar widgets will have wildly different CPU and memory usage behaviors in Dashboard vs. Konfab.
the coolest thing about Dashboard isn't even in Konfab - the ability to use a hot key to fade in all the widgets.
The "Konspose" of Kondabulator feature is similar in that it brings all the widgets to the front and fades the background. Put them all at desktop level and they won't interfere with anything until summoned (even though you may still be able to see some of them...which may be considered a feature for certain kinds of widgets).
If Dashboard gadget suck up RAM and CPU when they are not on screen then I won't use them. I already know Konfabulator is a pig because of its runtime environment. So Dashboard can be no worse the Konfablutor in my eyes.
If Dashboard gadget suck up RAM and CPU when they are not on screen then I won't use them.
Why do you think that "being on screen" makes such a big difference? If a widget is polling a web site periodically to get stock prices or the weather or whatever, it's going to do so whether or not it's visible, so that when it does become visible it has the correct stock prices or the weather.
Maybe a widget with constant animation will take less CPU if it isn't visible, but if you are running such an annoying widget, you deserve what you get, IMO
As for memory usage, it's pretty much the same for visible and invisible windows (+/- compression, but visible windows can be compressed too--check QuartzDebug)
Finally, as for the runtime, WebKit is not small. Of course, if you're using Safari, you're running it already anyway, which helps. But the Konfab runtime on my system has an an RPRVT of 1.68M. It's going to be hard for WebKit to beat that by much.
IMO, the only real hope for a big difference in CPU or memory usage is if Dashboard isn't running at all until the first time you call it up. But in that case, you can also simply bind Konfabulator to an F-key not run it until you need it to get the same effect.
and if not how will Dashboard run?
Originally posted by Hobbes
The Konfab / Dashboard resources question seems simple enough to answer, or at least get a sense of an answer... if someone with access to the Tiger seed is willing to chime in with a report. Anyone out there?
Sure. The default widgets on the Tiger build I played with ate 6Mb each. They seemed to use virtually no CPU at all when displayed and none when they were hidden. I assume the more complicated widgets to come will eat more, but from what I've seen it's far less taxing than Konfabulator.
Originally posted by John
Again, what makes you think Dashboard will be better in this regard? I'm not claiming anything one way or the other, I'm just asking why everyone seems so sure that similar widgets will have wildly different CPU and memory usage behaviors in Dashboard vs. Konfab.
Here's a quote from developer John Gruber:
"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.)"
For more, see: http://daringfireball.net/2004/06/da...s_konfabulator
will the current G4 iBook support CoreImage?
and if not how will Dashboard run?
CoreImage is only used for the watersplash-effect when a new widget is activated. You can use Dashboard on any graphic-card shipped but will not get the above mentioned effect.
I'd be very surprised if his argument was taken apart as he was merely popping the balloons of a bunch of (how can I put this?) whining, ignorant bitches.
I don't agree with everything that he writes but on this point his 'opponents' were barely rational, spouting knee-jerk reactions based on nothing more than screenshots and misplaced outrage. It would have been near miraculous if they had accidentally made a point that was actually correct.
Who cares where certain, very basic, ideas may have originated, it;s how they are executed that counts. We could go back in time and say how this and that just copied from x, y, or z. But what Apple have done, is to wholesale copy and jump onto a bandwagon that the likes of Konfab. and Desktop X (Windows) made popular.
Look, if these new programs hadn't have become popular, do you thin Apple would be introducing something like them now? Nah, don't think so. The popularity of Konfab and the like is what drove Apple to do this.
I don't give a toss if way back in time Apple had some crazy idea of desktop accessories, they were nothing. Now we see Apple introducing something that hops onto this trend, introduces something that resembles konfab. The style, the idea, and the fact that konfab did it, in this manner, before Apple.
Originally posted by stupider...likeafox
Care to elaborate on what was debunked? Or copy and paste the whole article?
I'd be very surprised if his argument was taken apart as he was merely popping the balloons of a bunch of (how can I put this?) whining, ignorant bitches.
I don't agree with everything that he writes but on this point his 'opponents' were barely rational, spouting knee-jerk reactions based on nothing more than screenshots and misplaced outrage. It would have been near miraculous if they had accidentally made a point that was actually correct.
Originally posted by sanity assassin
Sorry, but that opinion piece by daring fireball was nothing but slight of hand in regards to Konfab/DB.
Who cares where certain, very basic, ideas may have originated, it;s how they are executed that counts. We could go back in time and say how this and that just copied from x, y, or z. But what Apple have done, is to wholesale copy and jump onto a bandwagon that the likes of Konfab. and Desktop X (Windows) made popular.
Konfabulator looks like Desktop X too. In fact anything using non-rectangular windows and trying to mimic other real life devices like clocks, etc will look like this. If a developer was given a modern operating system and told to port Desk Accessories to it with no prior knowledge of Desktop X and Konfab I suspect it would look surprisingly similar. Using a compositing layer is totally obvious if you have one available. Even if Apple should be paying "we ripped you off" money to Arlo and Perry for Konfabulator then surely Arlo and Perry in turn should be paying money to the Desktop X developers and they aren't doing that as far as I know.
All that aside though, you're right, it is how they are executed that counts and from all accounts in the areas that matter, i.e. the runtime, Dashboard appears to be very different to Konfabulator. I'm more than willing though to see what was debunked in MDJ.
Originally posted by sanity assassin
The popularity of Konfab and the like is what drove Apple to do this.
Evidence for that assertion?
Here's a quote from developer John Gruber:
"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.
I think Gruber was looking at VSIZE or something equally misleading. I have Konfabulator and can look for myself at the memory usage. I posted some numbers earlier. None of the widgets I have open right now (iTunes Bar, Weather, To Do) are using any CPU (0.0% in top).
As for running each widget in separate processes, someone with Tiger can comment on whether or not Dashboard widgets are separate processes, and what their memory footprints are like.
Originally posted by stupider...likeafox
Care to elaborate on what was debunked? Or copy and paste the whole article?
As it's a pay-for service, I don't think I can really post it here any more than I can post pirated songs here.
It's a very long and detailed piece - with the high quality analysis one expects from MDJ. It's in the 21st July edition.
You can get a free trial sub from macjournals.com
(I have no connection with MDJ other than as a subscriber - but I really really recommend it if you can afford it).
Originally posted by Tuttle
Evidence for that assertion?
Observation of the developing programs. If program x exists for a certain amount of time and is popular; then program y comes along in which the implentation is virtually the same. Then it seems logical that program y's authors have based their idea n existing lines, but like most developers, they implement a slight twist to things.
It's all salmon in the fish game.. marinate bitches..
Originally posted by sanity assassin
Observation of the developing programs. If program x exists for a certain amount of time and is popular; then program y comes along in which the implentation is virtually the same. Then it seems logical that program y's authors have based their idea n existing lines, but like most developers, they implement a slight twist to things.
Yes, but while Dashboard may be similar to Konfabulator in concept, their implementations (underlying codebase) are quite different. And while the two may look similar, Apple has provided a number of "twists" on the backend. Apple's inclusion of Webcore and Exposé are two extremely significant alterations to the widgets concept and should not be overlooked. (Konsposé or whatever the hell it's called was introduced well after Arlo Rose was aware of Dashboard). In the end, while it may initially seem like Apple is exercising its monolithic/monopolistic presence to stifle the "creativity" of smaller developers, looking a bit deeper reveals that Apple is doing nothing more than extending the concepts and "goals" of the decades-old desk accessories and providing several, dare I say it, innovations along the way. From my point of view, about the only things Dashboard rips off from Konfabulator are the crappy widget interfaces.
Originally posted by sanity assassin
If program x exists for a certain amount of time and is popular; then program y comes along in which the implentation is virtually the same.
I'm beginning to think people posting in this thread haven't read the Gruber piece. You're offering opinions that were popular before people knew what the hell Dashboard actually was.
Now that people know better, no-one is claiming the implementation is virtually the same, and if you are then you'd better justify that comment.