Linked by Thom Holwerda on Sat 23rd Feb 2008 23:03 UTC, submitted by michuk
KDE "KDE 4.1 will be what everyone expected 4.0 to be - a fully functional revolutionary Linux desktop. I took a look at the revision 777000 of this desktop environment and what you get is a visual changelog describing the current progress in terms of look and feel and the features." It has Bejeweled KDiamond? I'm sold.
Thread beginning with comment 302136
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Desktop Widgets
by GeneralZod on Sun 24th Feb 2008 08:35 UTC in reply to "Desktop Widgets"
GeneralZod
Member since:
2007-08-03

Apple Dashboard widget support is being worked on by Aaron and Zack, literally as we speak. Well, maybe not literally - but when they wake up, in a few hours time ;) So it shouldn't be long now, especially now that one of the dependencies (Qt 4.4, with integrated Webkit) is now in KDE SVN trunk.

Reply Parent Score: 6

RE[2]: Desktop Widgets
by tyrione on Sun 24th Feb 2008 22:04 in reply to "RE: Desktop Widgets"
tyrione Member since:
2005-11-21

Apple Dashboard widget support is being worked on by Aaron and Zack, literally as we speak. Well, maybe not literally - but when they wake up, in a few hours time ;) So it shouldn't be long now, especially now that one of the dependencies (Qt 4.4, with integrated Webkit) is now in KDE SVN trunk.


Qt4.5 is when Qt gets Cocoa.

I've got KDE 4.1 Trunk. The Qt integration of WebKit is minimal, at best.

http://developer.apple.com/macosx/dashboard.html


Widget Plug-Ins

If you need to dig deeper into the system, or if you need to tap into your own application to create a Widget that closely interacts with it, you can create your own Cocoa-based plug-in. These plug-ins work by providing a JavaScript object that's made available to the Widget.

Widget plug-ins are created in Xcode using the "Cocoa Bundle" template. Once the project has been set up, the main class of the plug-in must implement the following methods:

- (id) initWithWebView:(WebView *) webView;
- (void) windowScriptObjectAvailable:(WebScriptObject *) windowScriptObject;

The first method is called when your Widget first loads the plug-in. The second method is then called and allows you to provide a JavaScript object that your Widget can use. This bridges the gap between JavaScript and Objective-C. For example, the following implementation creates a JavaScript object with the name MyScriptObject and allows methods on that object to be called from JavaScript:

- (void) windowScriptObjectAvailable:(WebScriptObject *) windowScriptObject
{
MyScriptObject *myObj = [[MyScriptObject alloc] init];
[windowScriptObject setValue:myObj forKey:@"MyScriptObject"];
}

The object can be accessed from JavaScript as follows:

<script>
if (window.MyScriptObject) {
MyScriptObject.someMethod(someArg);
}
</script>

Using this plug-in model, you can expose most any kind functionality from the system or from your application to a Widget.
Deploying a Widget

Once you have created a Widget, the next step is to get it into the hands of your users. For a Widget to be found by the Dashboard, it needs to be located in one of the following locations:

* /Library/Widgets
* ~/Library/Widgets

Conclusion

As you can see, Dashboard provides a great new development environment. Widgets are easy and fast to create, and yet very powerful. They have full access to the Internet, can use the advanced drawing capabilities of Quartz, and the rest of the functionality available in Mac OS X. The opportunities to be creative are enormous.


WebKit Widgets are not Dashboard Widgets that leverage Quartz and OpenGL directly. They rely on CSS/Javascript/XHTML and the Canvas and other elements implemented in Safari.

WebKit for Cocoa/OS X is much broader than WebKit for Qt and to think otherwise shows you aren't looking at the same WebKit source trunk from Apple as I am.

Reply Parent Score: 2

RE[3]: Desktop Widgets
by elsewhere on Mon 25th Feb 2008 06:49 in reply to "RE[2]: Desktop Widgets"
elsewhere Member since:
2005-07-13

WebKit for Cocoa/OS X is much broader than WebKit for Qt and to think otherwise shows you aren't looking at the same WebKit source trunk from Apple as I am.


What does any of that have to do with the price of tomatoes?

Support of OSX widgets was already coded into KDE4, it was waiting for the official integration of webkit into Qt, and now that KDE trunk moved to 4.4 last week, Aaron (and Zack, I believe) are working on making it happen.

Some of the OSX widgets that rely on embedded OSX binaries or OSX hooks for part of the functionality obviously won't work, and aren't targeted to, but the ones that are basically webkit-oriented HTML, CSS and javascript should be easily implementable.

At any rate, let's just wait and see what they come up with. It's speculation until they do.

Reply Parent Score: 4