KDE 4 to Support Apple Dashboard Widgets

Ryan writes to tell us Applexnet is reporting that Zack Rusin, a lead developer of KDE, has confirmed that KDE 4 will be able to run and display Dashboard widgets similar to Mac OS X 10.4. From the article: "Basically, this means that a layer (similar in some ways to layers in Adobe Photoshop) in the KDE desktop could function the same way that Dashboard does in Mac OS X. Widgets themselves are not inherently difficult to write nor properly interpret, since they are usually just HTML and Javascript (although Cocoa code can be included, the developer's skills permitting). Furthermore, since Konqueror and Safari share very nearly the same rendering engine, KHTML and WebKit, this too will simplify the process."

Re:Too bad the K name is taken

[User 956]

Konfabulator?

Nah, didn't you hear the news? Konfabulator has been renamed to "Yahoo widget engine" [digg.com]. Which means "konfabulator" is up for grabs.

Memory Usage

[Arctic Fox]

Hopefully, they'll find some way to knock down the memory usage. A couple of widgets (weather, stocks, iCal) were killing my 1Gb Powerbook.

I switched to the ex-Konfabulator, Yahoo! Widgets and now my PB doesn't seem to thrash as much. That, and I've added a number of additional widgets.

Re:Lets slow down KDE Even more!

[chill]

You haven't used KDE lately, have you?

Each release has been faster than before with 3.5 being noticably faster than 3.4.1.

Finally, get off your whiney ass and compile it for yourself using Konstruct. Pick just exactly what you want and make it nice and slim for you.

That is what the source code is for, you know.

Re:Lets slow down KDE Even more!

[Anonymous Coward]

Kde4 should use less memory because it will be based on qt4. I've read somewhere that some apps use about 15%
less memory when compiled with qt4 instead of qt3 - so hopefully it wont be too bloated.And even if it is then you still have e17 ;)

Re:Exciting

[mblase]

I think this is a great idea. Right off the bat, there will be lots of Widgets available.

No, there won't. The headline is misleading. Read carefully:

...the upcoming KDE 4 will be able to run and display Dashboard widgets much in the same way that Mac OS X 10.4 can.... I'm planning to add full OSX Dashboard compatibility layer for Plasma....Basically, this means that a layer (similar in some ways to layers in Adobe Photoshop) in the KDE desktop could function the same way that Dashboard does in Mac OS X.

Furthermore, keep in mind that a not insignificant number of OS X widgets interact specifically with OS X apps like iTunes. Obviously, only internet-based widgets (like Google lookups) could be cross-platform.

Open Source Likes Apple?

[romiir]

If I recall correctly, the original code of the machintosh OS came from BSD 3... (Before they modifyed it extensively for commercial release) Now Opensource is taking the apple standard? This is interesting. Maby Microsoft will see this and include dashboard widgets for windows? It would be nice for once to be able to write something and run it on every os, not just Mac and Linux or Windows and Linux.

Re:Why a separate layer?

[Vaevictis666]

By layer, they're referring to a rendering layer.

I think the intention is to allow more dynamic desktop environments by putting multiple layers in your view. For example, Desktop Background -> water effect -> Widgets -> Desktop Icons -> App windows.

Not "most" widgets

[saddino]

KDE's runtime will be able to run most widgets designed for Dashboard. Also, KDE's runtime will be limited in that it will not be able to run widgets properly that use AppleScript or Cocoa in some way.

Those two statements are contradictory. Most widgets for Dashboard, especially for those that anyone considers useful, use Applescript and/or Cocoa. So in fact, KDE will be limited to only the simplest of widgets. Not much of a feature, IMHO.

Re:Lets slow down KDE Even more!

[10Ghz]

I still consider 395 megs of memory used when using the K web browser and file system to be too much.

I currently have following things running on my KDE-desktop:

- Konqueror with 4 tabs
- Kontact
- Konsole
- Basket
- Kopete
- Bunch of KDE-related services (Wallet-manager, Klipper etc.)
- The usual Linux-services

How much RAM is being consumed? 149 megs. Let me repeat that: KDE, with all those apps running plus host of other Linux-services, is consuming 149 megs of RAM. Not exactly the 395 megs you quoted, now is it? Let's make this interesting, shall we? I also often run K3b, Amarok (with 7gig music-library), Codeine and Kword. How much RAM is being consumed with those apps running as well (for a total of Konqueror, Kopete, Amarok, Kword, Codeine, Kontact, Basket and Konsole running at the same time)? 310 megs, it seems. So we are getting closer to your figure of 395 megs (which you claim KDE consumes with nothing but Konqueror running).

If I add System Settings (this is a Kubuntu-machine), KPDF and Kate to the mix, RAM-consumption jumps to 323 megs. Still not the same as your figure. Adding SuperKaramba, Info Center and Help in there, and the system consumes 338 megs of RAM. Kspread and Kedit make the RAM-consumption to jump to a whopping 347 megs, still not as high as your figure. And I don't even know what other apps I could be running here. My taskbar is full of running apps, and the RAM-consumption is more than reasonable.

I still am fond of when A GUI took up 20 megs, ran well with 12 megs of memory, and was almost instainious in response to commands. (Mac OS 7.1 and Windows 3.1 on a 68030 and 486 respectively)

Then keep on using those old GUI's. If modern GUI's are slow and bloated, why are you using them?

Re:Lets slow down KDE Even more!

[molnarcs]

395 megs of memory is too much. K web browser never uses that much. In fact, konqi's memory usage if far below firefox's. The least amount of ram you need for kde is 192. With 256, it should work smoothly (you can even have some konq. instances preloaded). Using purely KApps makes the experience smoother than with WinXP. Now if you start firefox (which is a memory hog) or openoffice, and $insert_app_here, and you find yourself running out of ram, don't blame kde!

This needs no special tuning whatsoever. Plain vanilla KDE will work fine without any tweaking on a puter with 256Megs. My main machine has 512, and even after extensive use, my swap partition isn't even touched. That with lots of apps loaded by default: skype, amarok, kmail, 4 preloaded instances of konqi, etc. My system begins swapping only if I start up firefox or ooo-build. (Or perhaps krita with an 50meg PNG :)

KDE's memory management is very efficient. In fact, considering what it does, I would say that I'd expect higher memory usage. Of course, we can throw numbers around here with little or no way to back up our claims, I realize that, but if you check the specs of people running kde (on forums) you'll see that configs like a 700Mhz duron with 256Mb RAM (I mentioned this in another post) is enough. I don't know where your K browser using 384Mb RAM comes from (well, except if you pull it out of your ass). Actually I made some screenies of kde 3.4.3 here. [unideb.hu] One of the screenshots displays memory usage. If you check the clock, you'll see that it shows the state of memory after opening a lot of apps, including scribus, with images loaded, etc (and you'll see what I have running in my systray). So I don't understand people who report excessive memory usage of KDE - it is either FUD, or they should switch distroes :)

re: Dashboard and usefulness

[King_TJ]

That's exactly the problem with Dashboard though ... it's too tempting to approach it as "let's load it up with all types of crazy widgets!". By doing that, you make it less functional. (Takes longer to switch to them when you've got a whole screen full of them, etc.)

Certain Dashboard widgets *can* change the way you work, but only when you select the right ones, and eliminate the rest!

For example, Ambrosia Software makes a free widget for easily printing addresses on envelopes (http://www.ambrosiasw.com/utilities/easyenvelopes / [ambrosiasw.com]). That's something I occasionally need to do, and it's something you don't really want to load up a whole word processing package for.

I find the weather widget handy too. It lets me get the forecast on a whim, while not constantly running and eating resources when I don't need it. Sure, you can visit a web site to get the same info - but a widget is faster and always saves your preferences. (Web sites usually rely on cookies that you might clear out of your browser cache.)

Re:who knew

[Decaff]

Who knew that the "write once, run anywhere" promised to us by Java, would be beaten to the punch by an Open Source project?

Wow! So this means that these Dashboard widgets can run on my mobile phone? On Windows? On IBM z-Series mainframes? Can you write databases using these widgets? Application servers? Distributed network applications? Numerical applications?

Excellent! Then I'll abandon the hundreds of thousands of lines of portable Java code I have written and translate it into HTML and JavaScript after reading your informative post.

Oops! Hold on! Let's take a look at the article:

"KDE's runtime will be limited in that it will not be able to run widgets properly that use AppleScript or Cocoa in some way. Likewise, it's possible that Mac OS X users may also have to face not being able to run some widgets that depend on KDE somehow."

Oh well, back to Java....

Re:Am I the only one

[NutscrapeSucks]

. Internet Explorer is problematic because it has multiple zones with different security settings,

That's also true of Apple Safari & WebKit. IE has a special "no sandbox" zone for ActiveDesktop widgets, and Apple has a special "no sandbox" zone for Dashboard widgets.

Now, it could be impossible to "trick" Safari into the wrong zone, so this won't be a problem. But the overall architecture is nearly identical.

Re:Lets slow down KDE Even more!

[10Ghz]

And you are hitting your HD how much with this config?

Hitting the HD would increase the amount of cached/buffered RAM. But that wasn't what I was measuring. I was measuring the amount of RAM the apps themselves consume. Cached/buffered RAM is basically free RAM. Of course, if I loaded some huge file to Kate for example, the RAM-consumption would go up. But that's hardly KDE's fault, now is it?

So are you saying that running KPDF should take up over 200 megs of memory if I need it running?

What makes you think that? KPDF itself takes few megs of RAM. KDE itself might consume some RAM, but I hardly consider the amount it consumes to be a lot. With the two apps I use the most (Konqueror and Kontact), it consumes under 150 megs of RAM (that's including whole KDE, the apps, and the related services). And considering that 512 megs is the minimium amount of RAM shipped these days, that's more than reasonable. 256 megs is really, really low end, with 128 megs being unheard of. 128 would be a bit too little for comfortable use, but 256MB would be perfectly doable, with 512MB being more than enough.

Also, asking why I am not runing 3.1 or 7.1 is asking why did you start using the 2.6 Kernal when 1.3 was running fine? Oh, you mean I can run final cut on a 68030?

So you wanted the advanced features of the newer GUI's? Guess what? Those advanced features need RAM and CPU-horsepower! TANSTAAFL.

Re:who knew

[Anonymous Coward]

Copying something from Apple? Apple got the code that makes it all work from KDE in the first place. Dashboard is based on WebCore, WebCore is based on KHTML, KHTML was developed by the KDE developers for use in Konqueror.

Existing Dashboard-ish-ings for Linux

[Shazow]

Just to set the record straight, there already exists something like this for Linux (and, more specifically, KDE). In fact, there are two major branches in development for such widgets:

1. The fancy branch (since sometime in 2003):
SuperKaramba [sourceforge.net], which spawned from the plain Karamba [efd.lth.se].

2. The non-fancy minimalistic branch (since god knows when - probably early 2004):
Conky [sourceforge.net], which spawned from the even less fancy Torsmo [sourceforge.net].

- shazow

Re:A possible merge in store, perhaps?

[Overly Critical Guy]

Perhaps KDE will convince Apple to make the GUI Free Software.

How could anyone possibly think this, and actually post it? Everyone knows this will never happen.

Re:Most misleading headline in slashdot ever?

[Anonymous Coward]

The summary is misleading, not the headline. Read the article. Quote:

I finally got most the implementation of the HTML Canvas element for KHTML finished. It's in the kdelibs-js branch in SVN. After George/Maks merge their other changes we'll merge it to HEAD. I'm planning to add full OSX Dashboard compatibility layer for Plasma (hence why I've spent most of the day yesterday on implementing the Canvas element).

Re:Am I the only one

[Matthias Wiesmann]

Widgets are not run by Safari. They are separate Unix processes. They just happen to share a library that handles HTML.

Re:KDE and GNOME trying to be OSX

[borgheron]

One of the things which is going to become the focus this year is precisely that. The look is badly in need of an update.

I'm one of the maintainers of GNUstep, so I'm hoping to beautify GNUstep in the months to come.