Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

KDE Traffic #23 For 26 Oct 2001

By Aaron J. Seigo

Table Of Contents

Introduction

Welcome to KC KDE! It has been another fast-paced week for KDE. CVS commits were flying in as were application announcements on apps.kde.com. The (relatively) new KDE eye-candy site got a make-over, and judging by how few KDE related items are to be found at themes.org it seems to have a firm grip on the KDE audience. And speaking of eye-candy, guess who is back again?

All of this activity around and outside of the core KDE team can only be good for the project. The vibrant KDE development and arts community is providing visible momentum which leaves the core developers to concentrate on making KDE3 a solid platform. This is in stark contrast to the very quiet times leading up to KDE2 when nearly all of the development was happening within the project on the new version.

1. Which RegExp Class To Use?

17 Oct 2001 - 18 Oct 2001 (4 posts) Archive Link: "Regular Expressions - PCRE wins, I think."

Topics: KDE Core Development

People: Michael BedyMichael HäckelMarc Mutz

KDE2 used Qt's regular expression facilities while providing the option of using the more capable PCRE (Perl Compatible Regular Expressions) library. Many a javascript woe was the result of not having PCRE installed. With Qt3 comes a much improved regular expression class but there were still doubts that it was featureful enough.

Michael Bedy wrote, " Well, I'm not exactly a Regular Expression Guru, so if someone thinks I got something wrong here, please let me know. It looks to me like QRegEx gets very close, but misses a few crucial features. The biggest of these is lack of /m support and all the various things that go along with it. Also, the "." atom always matches newlines in QRegEx. This is equivelant to the /s option in Perl, but Javascript unfortunatly requires that "." not match newlines. In addition, the /g option is not directly supported in QRegEx, however it could be emulated with a little bit of work. In short, I think PCRE is our best bet." Technical discussion and comparisons of the two libraries ensued which ended with the decision to use PCRE to get support for flags such as "g" and "m"

Elsewhere, Michael Häckel asked regarding the Qt and KDE regular expression classes used in KMail, "I think, these files are really obsolete now. KNode still depends on qregexp3 if the Qt version is <300. Can I remove them, or is there any good reason to still keep compatibility?" Marc Mutz pointed out that KRegExp3 provides support for things that Qt3's regular expression class doesn't. After some discussion of the merits of each it was decided to keep KRegExp3 around in an updated form.

2. Syncing WinCE Devices?

17 Oct 2001 - 22 Oct 2001 (7 posts) Archive Link: "[Kde-pim] activesync"

Topics: KDE PIM

People: Nick PapadonisLudovic Lange

Dave Dash asked if activesync, the mechanism used by Windows CE devices to synchronize their data with another system, was going to be supported by KDE PIM applications. David Eriksson pointed Dave to the synce project on SourceForge. Nick Papadonis looked at the project and said, " It would fit into the KPIM syncronization project nicely. Communication from the synce team on their API and usability of the library would help. From there we can determine if synce is in a state to integrate in a new project."

All Nick had to do was ask and shortly Ludovic Lange from the synce project replied with a lengthy and detailed description of the synce project and their current status. Regarding the readyness of the project to be used by KDE PIM, Ludovic said:

we are not ready yet to synchronise a PocketPC PDA. However, we're moving fast. The project started 3 months ago, and we now are able to get and put files, get databases, get registry keys.

I can't give a reasonable planning for the completion of different steps, but our aim is really to have our PDA synchronize with our desktops computer as soon as possible... (btw : the project's origin came from a selfish desire to synchronize my iPAQ with my home computer, running Linux.... And I still want to.)

As the next step is going to be the synchronisation layer, we will need to have advices on that part, so, do not hesitate to have a look on the mailing list, give advices, comment on the API, etc...

So while the library is not yet complete, the synce project has the hallmarks of a project that will succeed. Once synce is useful it probably won't be long before it is seen in end user applications on the desktop.

3. BiDi Widgets: Close But Not Yet

18 Oct 2001 - 19 Oct 2001 (7 posts) Archive Link: "KDE3 : How to use the widget mirroring feature of Qt3"

Topics: KDE 3

People: Amaoui HichamMeni LivneDirk MuellerMichael Häckel

Regarding the Qt3 capability to reverse the layout of widgets at runtime for right-to-left character sets, Amaoui Hicham inquired, " Just want to ask how to use the widgets mirroring feature of Qt3 with KDE3 ? I'm insterested in arabic support under kde." Meni Livne replied, " You can start any KDE 3.0 application with the command line option --reverse and its interface will show up mirrored. However, the obvious behavior we should expect is for applications to automatically come up reversed if KDE's language is set to an RTL one, but this isn't yet implemented."

After Michael Häckel reported that KMail's message list didn't look like it was rendered properly with --reverse, Dirk Mueller provided further bad news saying, " Try the Qt examples and you see how it should look like. there are really countless -reverse bugs in KDE, this is going to be a tough time fixing" So while Qt3 provides the basis for good BiDi support there is work left to do in KDE to make it work properly across all the widgets and applications.

4. Documenting KIOSlaves

18 Oct 2001 - 22 Oct 2001 (5 posts) Archive Link: "How to document protocols ( I/O Slaves )"

Topics: KIO, IOSlave, Documentation

People: Ben SchepensStephan Kulow

It has been said that when writing software documentation is next to godliness. For third-party KDE projects, the responsibility for documentation falls to the developers of those KDE applications. Ben Schepens asked, " I have written a Common Name Resolution Protocol I/O slave (search for Onyma on freshmeat.net) How do I properly create the documentation about the I/O slave that is shown when one uses the KDE menu to select Configuration/KDE/Network/Protocols to get info about the various I/O slaves installed on the machine?" Joerg Walter, author of kio_fish, also wanted to know the answer to this.

Stephan "Coolo" Kulow answered, " The .protocol file must exist. And the documentation must be in said doc/kioslave directory. And you have to add your file for inclusion to kioslave/index.docbook"

It is good to see those doing KDE development outside of the main KDE CVS are also concerned about (and actually providing) documentation.

5. New Javascript Engine

19 Oct 2001 - 23 Oct 2001 (5 posts) Archive Link: "KJS API changes"

Topics: JavaScript

People: Peter KellyHarri PortenRichard MooreDavid Faure

The rewrite of the Kate text editor part was covered in last week's KC KDE. This week the winner for "Best Rewrite" goes to Peter Kelly who has been busy rewriting the KJS library for KDE3. He announced his work saying:

I've recently been coding a reworking of the KJS API for KDE 3.0. This has involved a number of changes in structure, and as such the new API will be source incompatible with the 2.x series. The only code that uses KJS that I know of is khtml and kpac, so I do not anticipate this being a major inconvenience to other develoeprs out there (if it is, let me know!).

At present the changes are incomplete so are not ready for HEAD, but I have created a new branch for those interested in working on the new API. This will only be short lived (hopefully < 1 week) before it is merged back into HEAD and khtml and kpac are updated. Note that the branch was from KJS as it was ~3 weeks ago - I will merge in other changes since then as soon as the code is in a working state.

The changes basically involve cleaning up the API and removing a number of awkward aspects of the previous version, particularly relating to static class variables and the inheritance hierarchy, and exposing less of the internal code which made it hard to add new virtual functions etc.

Peter went on to describe in detail all the changes and benefits of those changes. The new KJS branch was merged back into HEAD after reaching a usable state with some help from David Faure.

On the issue of not affecting many other projects, it seems Peter underestimated how many people use the KDE code base. Harri Porten said, " I've been contacted by several people (I assume companies) that use the interpreter. That doesn't mean we can't change anything (the KDE 2.2 version works very well unless you have a browser) but let's keep "public" API changes to a minimum. Not "public" in the C++ sense of accessibility (public/private methods or classes) but for the cases of someone writing extensions." Richard Moore's XMElegance also uses the KJS engine and Peter offered to help port it to the new API. Overall, it was deemed that the changes had to be made, even if they were temporarily painful for those developers moving from the KDE2 to KDE3 since certain fixes could only be achieved with a restructuring.

6. Multiple Sent Mail Folders in KMail

21 Oct 2001 - 23 Oct 2001 (8 posts) Archive Link: "RFC: new Fcc field"

Topics: KMail, KDE 3

People: Roberto Teixeira

It is often the little things that make the difference between a program being OK and being Great. These bits of icing on the cake require that the core application is stable and has had time to mature. KMail is reaching this point in its life cycle as can be seen by the many small enhancements that have accompanied the larger and more sweeping improvements in CVS.

One such feature is multiple sent mail folders. Roberto Teixeira provided a patch along with an email in which he said, "one thing I was missing in Kmail was the possibility to select a different folder than sent-mail when I was writing a mail. I could use outgoing filters for a lot of cases, but sometimes we have to manually select the folder. This patch creates this option. First you can configure a special sent-mail folder for each identity you have (if there's none selected, we use kernel->sentFolder()). Secondly, this adds an option (a combobox) to the composer window to allow me to select a different one for that specific message."

Various technical issues in the patch were worked out between the KMail hackers and it was eventually committed. This is just one of many such smaller but very welcome features awaiting KMail users in KDE3.

7. Python and KDE3/Qt3

22 Oct 2001 (4 posts) Subject: "python bindings?"

Topics: KDE Bindings, Development Language

People: Boudewijn RemptShawn Gordon

The number of language bindings for KDE has slowly grown with time. Python is one of the more popular modern scripting languages and therefore support for that language is quite important. Marcos Dione inquired as to the status of Python bindings for KDE and Boudewijn Rempt replied:

Jim Bublitz has just finished binding Python to KDE - I'd think I'd best quote his mail to the PyKDE mailing list:

From: Jim Bublitz <jbublitz@nwinternet.com>

To: pykde@mats.gmd.de

PyKDE2 now builds without problems. There is one minor known bug remaining, but there is a simple workaround for it, so it won't delay the release, and it won't be visible to users. There are a few things left to cleanup (mostly "administrative"), but those should be done in a day or two.

I still need a home for the distribution tarball (probably theKompany, as before), and won't release PyKDE2 until sip/PyQt 3.0 are finalized (want to test the build with the released versions). The forthcoming sip and PyQt 3.0 releases will be required for PyKDE2. Again, keep in mind 'PyQt 3.0' does *not* necessarily mean Qt 3.0.

I still haven't done a CVS update, but will get to it soon. Once that's done, it will be possible to build from the sip/PyQt/PyKDE2 CVS - you can't do that right now.

Shawn Gordon also replied saying, " PyQt is totally up to date, it even has Qt3 support. not sure what the situation is for PyKDE at the moment, but PyQt should be very useful for you."

Incidentally, bindings for the C language were recently released so that creating new bindings should be easier.

8. Multimedia for KDE3.0

22 Oct 2001 - 26 Oct 2001 (17 posts) Subject: "KDE3.0 Multimedia Meeting Summary"

Topics: Multimedia, KDE 3, IRC

People: Stefan Westerfeld

Once again the KDE multimedia developers gathered on IRC for a meeting to coordinate their efforts. Stefan Westerfeld wrote up his usual summary of the meeting and posted it to the appropriate lists. In his email Stefan covered each of the topics discussed and who was responsible for implementing the end decision. The discussion included issues such as video embedding, multithreaded access to hardware devices, MCOP to DCOP bridging and extending the number of codecs supported. Perhaps one of the more interesting topics was that of the new GSL engine being used in aRts. Stefan detailed what GSL is and why it was being used in the summary, saying:

The GSL engine is a complete replacement of the algorithm with the following characteristics:

The GSL engine should first act as a drop-in replacement - however to take advantage of its capabilities, it will be necessary to make sure that the modules are implemented in a way that they can run in a seperate thread without interfering with anything else.

That means, that there will two types of modules: the old modules (which will still be running in the aRts main thread), and the hard-rt-modules (which will be able to run in the engine threaded).

You will get the very very low latency benefit only if you use only hard- rt-modules, but everything should work with any mix of modules.

Where is GSL from?

GSL is designed by Tim Janik and me, and contains a lot of know how about music apps (Tim Janik has been working for years on Beast - best.gtk.org, and I have been working for years on aRts).

GSL code is in the CVS and working (although yet somewhat slow) already.

9. Noatun2: The Sequel

24 Oct 2001 - 25 Oct 2001 (5 posts) Archive Link: "State of the Noatun"

Topics: Noatun, Multimedia, aRts

People: Charles Samuels

Noatun is a pretty ambitious project with its take-on-the-world, play-anything, everything-is-a-plugin approach. If the Noatun coders have their way, Noatun will return in KDE3 with more features and a better temperament. Charles Samuels posted an update on the new features that will be seen in Noatun2:

  1. Tag Reading

    Actually, this is a plugin, but I have a standard library handler for it. It's really quite nice. The best part is that I have a long regexp in noatun now too. You know how I feel about regexps.

  2. Rewritten Playlist Arch.

    Neil suggested that the playlist have reference counting. That sure turned out to be a good idea. This should make complicated playlists (like, say, SQL based lists) much easier. SPL is turning out to be about 25% faster, just as a cheap hack on the old version. Once Tron is rewritten properly, I'm expecting it to be about 50% faster. Neil, are you still having problems?

  3. Video Embedding

    I have a game plan for this. Stefan's main problem with noatun is the "multiple-interface" thing. My solution is that each plugin can inherit from a, say, VideoWidget (more or less) which will use the arts interface to reparent the video window.

    Since there are more than one plugins, there can be more than one of these widgets. The catch is that each has a "name" (E.g., "Excellent" as a name, or "Milk Chocolate"). The user can then select which widget gets control. If none of these widgets exist, then there is no reparenting. So it'l behave the same as it does now.

  4. Proper Playlist Handling

    I've been speaking with the author of AlsaPlayer (my player of choice after Noatun and mpeglibartsplay :) We settled on a standard XML format for playlists:

    http://noatun.kde.org/formats/xmlplaylist.phtml

    At the least, a playlist *should* be able to export and import this format. Tron will use this format natively (in fact, my "spec" is based on Tron's format). I'll do this for SPL, eventually. I loathe dealing with QDom.

    The other problem is with m3u playlists, the "pls" format used by shoutcast. How should this be dealt with? I think a --playlist option for noatun, with the argument being the playlist to open.

    How can this be dealt with in a powerful, but playlist-plugin friendly manner?

    Oh, and it looks like Liszt is going out of the release, because a) nobody knows how to use it b) it doesn't actually work anyway

  5. Winamp skins

    Apparently there are two efforts at this. The NickBetcherMartinVogtFrankNichols approach (winskin in CVS), which seems to be unmaintained. I heard rumors that Martin was going to maintain that.

    The second effort is by a person named "Phalanx" on IRC. He tells me that he's met the completeness of Winskin. He doesn't seem to get on IRC a lot, and I don't know much more about that. If he doesn't make any effort on getting it to cvs, and someone doesn't want to get winskin release-worthy (and it's close!), then no winskin for 3.0.

  6. Streaming

    I managed to get streaming to work. However, I uncovered a flaw in the KPlayObject design: The serious lack of buffering; it's downright awful. It skips like you wouldn't believe, with low or large amounts of simple load. I think this is the latency from the MCOP calls of the playobject asking noatun for the next download sample (the KIO request). Stefan knows about this: have you made any progress?

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.