|
| This Week... |
|
KBoard, a game canvas, gets several new chess-based themes, whilst KSokoban gets many new levels. KPhotoAlbum imports the winning entry from its Splashscreen Contest. Krazy and apidox (parts of the EBN test suite) move from playground into the kdesdk module. KBlog, a library to interface with various blogs, is imported into the PIM playground in KDE SVN. Work begins on a GStreamer backend for Phonon. More work on Yahoo Chatroom support in Kopete. Kexi Query Designer supports data sorting in design and SQL view. Painting experiments with Chinese brushes in Krita.
|
Scripting applications using higher-level languages is currently a hot topic within KDE, with KDE 4 set to feature scripting functionality throughout. Scott Wheeler expresses the general sentiment:
|
- Having a "blessed" KDE scripting language for writing complete KDE applications is a good thing and allowing applications written in that language
- A tangent to the main thread is adding scriptability to KDE applications
- For the first sort of scripting, there's something of a concensus that Python or Ruby are the primary candidate languages
- There hasn't been much language flaming between Ruby and Python; it seems most folks agree that they're both acceptable OO scripting languages, though there have been plugs a bit for one language or the other
- There's some debate over what appropriate languages are for the latter; KJS (JavaScript) is currently advocated, but there's some debate over the merits of JavaScript
To qualify the first comment, even if your language of choice isn't the one taken, there's nothing lost. Currently all scripting languages are second class citizens in the KDE world. Promoting one to first-class status doesn't demote the others significantly. An "everybody wins, use what you want" solution really is just a way of rephrasing the current situation.
|
|
Boudewijn Rempt provides his KOffice-influenced viewpoint (emphasis added):
|
The thread is long, yes, but to say that matters have come to a conclusion, that it is possible to even arrive at an executive summary is premature. As far as I'm concerned, there have been no conclusive arguments in favor of Scott's summary. But since the discussion is now apparently to be held in blog form, here's my summary.- Blessing the use of scripting languages for writing complete applications is important. Equally important is not to bless a single language. Let's first see in which languages applications actually will be written. The really important thing is that among the set of tarballs that comprises a complete kde release can be applications completely written in a scripting language. Of course, apart from Python and Ruby there are no serious candidates.
- There are still people who think that the current bindings to Qt and KDE of, for instance Python, are not completely mature and stable and that the maintenance of those bindings will cost kde-core hackers time. Come on, guys! Living under a rock is not healthy. We've had stable scripting language bindings for more than half a decade. They just didn't take off because kde doesn't package scripted applications, relegating them to the whims of distribution packagers.
- Forcing users to script in Javascript is an act of unmitigated evil. Allowing them to do that is okay.
- Making applications extensible through scripting should be done with Kross. Using Kross exposes a single API for your applications to D-Bus, Javascript, Python and Ruby. That means, no longer designing a separate DCOP API and a separate KJSEmbed API. It also means that people actually using the applications can code their extensions in the language they already know.
- I'm fine with no, or just one, or two scripting languages allowed for extending or implementing kde-base and kde-core bits. I still think that Kross is better than just mandating kjsembed. Look at how cool Kross is: Kross 2.0 and DBus. Kross really is the definitive solution to scripting KDE, on a par with what BeOS had, maybe even better.
|
|
Richard Dale, KDE language bindings guru, provides a summary of the recent work on the QtRuby Ruby and Qyoto C# bindings:
|
Arno Rehn has added a uics tool which takes a Qt4 Designer file and generates C# code, and so you can now use Designer with Qyoto. Arno has also added Q_CLASSINFO class attribute and a Q_SCRIPTABLE method attributes. These attributes are used as part of the data to construct the QMetaObject for QObject based classes. He has also implemented the code for return values on slot invocations. The exciting thing about these changes is that we are quite close to getting the QtBus classes working with Qyoto, and you will soon be able to use DBus from C#.
I've been doing more work with QDBus in QtRuby. I've translated all the Qt4 dbus examples, and they all work except 'complexpingpong'. One nice thing I've added to Qt::DBusMessage is the ability to call methods on them as proxies, instead of having to invoke the call() method, with the target method name as a string. For example, you can call a method called 'query()' like this:
reply = iface.call("query", Qt::Variant.new(line))
Or call it more simply like this:
reply = iface.query(line)
In the first case 'reply' will be a Qt::DBusMessage, and you can check if it is ok with 'reply.valid?', and then extract the value with 'reply.value'. In the second case 'reply' is the return value of the method (a Ruby String in this example). So it works just as if it was a local method call.
|
|
In the upcoming week, KDE 3.5.5 will be released (11th October). On the 7th October, KOffice 1.6 was tagged in preparation for a release on the 16th October. Slightly-biased sources assure me that it is going to be an excellent release, one which will function comfortably until KOffice 2.0, currently the subject of intense development, is completed.
|
|
| Statistics |
|
| Contents |
|
|
Bug Fixes |
Features |
Optimise |
Security |
Other |
|
Accessibility |
 |
|
|
|
|
|
Development Tools |
|
![[*]](/images/standard/features) |
|
|
![[*]](/images/standard/other) |
|
Educational |
|
|
![[*]](/images/standard/optimise) |
|
|
|
Graphics |
|
|
|
|
|
|
KDE-Base |
|
|
|
|
|
|
KDE-PIM |
|
|
|
|
|
|
Office |
|
|
|
|
|
|
Konqueror |
|
|
|
|
|
|
Multimedia |
|
|
|
|
|
|
Networking Tools |
![[*]](/images/standard/bugfixes) |
|
|
|
|
|
User Interface |
|
|
|
|
|
|
Utilities |
|
|
|
|
|
|
Games |
|
|
|
|
|
|
Other |
|
|
|
|
|
|
|
Bug Fixes |
|
Networking Tools |
|
Joris Guisson committed changes in /trunk/extragear/network/ktorrent:
|
Changes :
- Fixed bug in advanced choke algorithm
- Deselecting files without deleting data is now possible
- Deselecting files without deleting data is now the default action when you uncheck a file in the infowdiget
- Deselecting existing files at torrent load time, will not delete the file |
|
|
|
|
|
|
Utilities |
|
Tom Albers committed changes in /trunk/extragear/utils/rsibreak/src:
|
- Allright, after two days I've finally tracked down this bug. The loadconfig did not get the correct value for the slider interval. By re-setting the config group it magically works again. If any guru can tell me why this is needed, you get a beer.
- Change default slider interval from 2 sec to 10 sec. Draining your system resources by default is not very friendly... |
|
|
|
|
|
|
Features |
|
Development Tools |
|
David Nolden committed changes in /branches/kdevelop/3.4:
|
Add initial support for namespace-aliases and namespace-imports. They are both stored into the code-repository and code-model now, and used through the namespace-aliasing system. Create facilities for efficient management and comparison of include-files for future header-parsing. Make the namespace-system aware of those facilities.
Together with some simple header-parsing (included headers need to be collected), and with a little work on making the resolution-system aware of those header-sets, that will allow near-perfect code-completion. A few other fixes. |
|
|
|
|
|
|
|
|
|
|
|
