|
Configuration and layout work in Plasma. A whole load of Plasma backports from trunk to the KDE 4.0 branch (for KDE 4.0.2). Plasma applets begin to be ported to use WebKit from Qt 4.4. Color blindness simulation for KMag. Work on support for button form fields, and support for encrypted ODF documents in Okular. More developments in the porting and maintanence of Kooka. Remote KABC resource and an Akonadi to KCal bridge in Akonadi. UPnp integration in Kopete. A rewritten upload plugin for KDevPlatform (used in Quanta and KDevelop). Continued work on a new projection framework in Marble. Undo/Redo work using a "piece table" in Okteta. Optimisations in Kalzium, Amarok, and KGet. A KControl module for configuring imaplib resources in Mailody, and a module for managing emoticon themes in KDE. Start of work on Puck, a tool to convert the Plasma XML user interface format into C++ code. Experiments with a KDE 4 version of Kommander. A branch of KDEPrint to experiment with refactoring and porting to Qt 4.4 (for KDE 4.1). Decibel and the Plasma "Luna" and "Trash" applets move to kdereview. KSystemLog moves into kdeadmin. Import of Smoke and Ruby Plasma bindings. KDE 3.5.9 and KOffice 1.9.95.3 (KOffice 2 Alpha 6) are tagged for release.
|
Norbert Frese introduces his work on KIO-GIObridge:
|
The aim of KIO-GIObridge is that all desktop applications and file-managers share the same network transparency layer for working with network file systems like FTP, SFTP, SMB, WEBDAV, etc. Therefore KDE4, Gtk, and 3rd party applications can access the same file-server resources without logging in twice or facing other inconsistencies. At the moment we have two incompatible network transparency systems, running in the same desktop session for different groups of applications. Also, with the existence of two frameworks, a lot of 3rd party applications were locked out, as they didn't want to decide on one of them.
KIO-GIObridge is an optional adapter for KIO to use the new GIO/GVFS (the successor of GNOME-VFS) to handle the protocols mentioned above. GIO/GVFS has been chosen, because it's independent from desktop specific libraries, daemons and toolkits and only depends on D-Bus and GLib. Another advantage of GIO/GVFS is its "stateful" mount daemons: All the communication to a certain share is handled by a single mount daemon process. The life-cycle of those mount daemons is user-controllable (mount/unmount), similar to kernel or FUSE mounts.
KIO-GIObridge is implemented as "multi-protocol" IO-slave which delegates calls to GIO/GVFS and provides it's own implementation of remote:// to list GVFS mounts and let users "unmount" them. To use KIO-GIObridge it's necessary to patch kdelibs to support "multi-protocol" IO-slaves. Additionally, it's required to compile Qt4 with GLib-Main-Loop support (which is default on many distributions already).
There is also some experimental code in the KIO-GIObridge package, which extends Solid to handle GVFS mounts. With this extension, network mounts will pop up in the "places pane" just like other drives. Whether this is desirable is still being discussed.
KIO-GIObridge is almost finished and usable, but the translation of error-codes, dir-entries and the implementation of certain KIO file operations might still need some fine-tuning.
Along with KIO-GIObridge it would be advantageous to implement the "Desktop Bookmarks Storage Specification", to fix another file-management interoperability bug.
The plan is to have KIO-GIObridge finished as an optional extension for KDE 4.1. GIO/GVFS should be pretty mature by then, as it will be shipped with the next GNOME release.
|
|
As development on Kommander, the visual scripted application environment, has been quiet for quite a while, I asked Eric Laffoon for a development update:
|
Kommander development has been largely static for some time. Originally it was worked on by Marc Britton and it was extended by Michal Rudolf, who also did the new parser. I've mostly played my usual role in interface specification and test, though I have fixed a few bugs. Recently, [3] was getting burned out working on Quanta4 and so for a break we decided to put some polish on Kommander for KDE3. As it happens I'm building my internal business management tools with Kommander.
Currently we are not planning to do any further development on the KDE3 Kommander, but we do have a nice plugin system in place, so if I start to go nuts and want something to do I could add a stackwidget or something. I'm playing with a few plugin ideas that would be useful to me and anything good will be released on the web site. We've had discussions with other KDE developers about bringing the Kommander executor into the main KDE packages, like kdebase, so that it can reliably be there for end users and for developers wanting to use it to extend applications. One key stumbling block has been the issue of security, which we addressed with the 3.5.9 release and using an executable bit. In the future I'm looking at using digital signatures and MD5 sums with an online database where people creating and sharing applications can enable validation automatically and any discovered exploits could revoke an application's certificate. This would get around nag screens if the embedded key signature looked up a valid MD5 for the window in the database. Otherwise it would be up to the user to set the executable bit.
The current development for Kommander is in maintenance mode and bug fixing for now, but the current offering is quite competent. Andras is planning within a month or so to build a KDE4 executor. There are advances in Qt4/KDE4 that would offer differences in widgets and functionality, but for now it is possible to alter the executor to use DBUS instead of DCOP and simply port. This would mean you could run any (or almost any) Kommander program now in KDE4 natively. It would mean that you could develop new Kommander programs in the current editor for KDE4. It would even be possible to create plugins for specific KDE4 functionality.
Early availability of a more capable Kommander in KDE4 and the possibility of the executor being included with KDE base packages offers a promising future for Kommander. It may be possible to attract more developers. Kommander offers distinct advantages for prototyping and extending applications with visual scripting, as well as small to medium applications and command-line front ends. KDE4 development of Kommander will focus also on language neutrality. Currently any DCOP/DBUS enabled language has full access to internal commands, signals and slots and everything.
I have been having discussions with [person4], the author of Kross, about how to go about multi-language implementation. His suggestion was to create a Qt plugin. Regardless, this will not be difficult. Currently Kommander maps all it's functions in a registration process so that they are available in the Function Browser. Our idea for KDE4 is to make internal functionality directly accessible to any scripting language, which DBUS bindings already does nicely and this is widely available. Our further idea is to get users of other scripting languages involved in creating registration files that make their language functions appear in the Function Browser. Some of this may be possible automatically, but I'd like to see the ability to enable the Function Browser to be usable for PHP or Python or whatever, providing assistance for build in functions!
The thinking here is potentially revolutionary. Applications are visually drawn. Much of the functionality is calling compiled functions, so you have speed advantages similar to a compiled application and interface design even easier than most scripting GUIs. By incorporating multiple language support, the core tools can benefit from and provide benefits for various languages. The final element of the puzzle is that once the core design tool is built the extentions and supplemental tools can be built with Kommander. A new widget or project tool would support all users and projects could be built by teams of people using different languages for their parts.
The one final issue for KDE4 is at least a few months out, and that is how to build the new editor. It looks like the new Qt4 Designer may support what we need for visual design, just as it appears we may also be able to use the KDevelop platform too. We're using it for Quanta because it is so flexible and brings so many tools to the table.
It will probably be third or fourth quarter of 2008 before we can introduce a new KDE4 editor with new functionality, unless we have new developers involved, volunteer or sponsored. The objective will be to offer a tool that is accessible for novice developers to create small programs, and useful for more experienced developers for small to medium size projects. It will encompass any and all aspects of KDE development and offer most of the functionality. The small trade off will be offset in ease and speed of development and the fact that you can create custom plugins for whatever you need.
My hope for Kommander is to produce a tool that develops the critical mass that no scripting GUI tool has ever had because it has "no religion" when it comes to the dogma of languages. All are welcome. Also, Kommander does not care how visual elements are created and is natively "typeless", reducing the workload for the developer and reducing potential errors when creating programs. Modern computers are faster and more powerful, so a small trade off for ease of use is an idea whose time has come. Anyone wishing to get involved in development or sponsor this project is welcome to contact me.
|
|
|
![[*]](/images/standard/features)
![[*]](/images/standard/bugfixes)
![[*]](/images/standard/other)
![[*]](/images/standard/optimise)