KDE Commit-Digest for 28th May 2006
Monday, 29 May 2006 | Dallen
In this week's KDE Commit-Digest: KViewShell gets support for PostScript files. Work begins on Akonadi (the new KDE PIM data storage backend) and amaroK 2.0, with further optimisations to the stable amaroK version. kttsd (the kde-accessibility text-to-speech system) is ported to Phonon. KDELibs is now fully ported to D-BUS. Aesthetic improvements to KSysGuard.
Comments:
Why ? - AC - 2006-05-28
> KDELibs is now fully ported to D-BUS. So - yet another GNOME dependency for KDE. Sorry to say this but this really sucks.
Re: Why ? - AC2 - 2006-05-28
> So - yet another GNOME dependency for KDE. Sorry to say this but this really sucks. WRONG WRONG WRONG. D-Bus is a very welcomed step. It is not related to Gnome, and will help making the Linux Desktop a better experience!
Re: Why ? - Eike Hein - 2006-05-28
D-BUS is desktop-agnostic.
Re: Why ? - Tom - 2006-05-28
...and the trolls get the first post. Come back when you have an argument. I for one am looking forward to more collaboration and unification where it makes sense!
Re: Why ? - Carsten Niehaus - 2006-05-28
There are many reasons for switching to DBUS, though of cause there are also reasons not to switch. But "it sucks because it is gnome" is a very bad reason. Reasons for the switch: - All apps using dbus will be able to communicate with KDE4-apps nativly (they use the same IPC) - The dbus-stuff is maintained outside KDE (on freedesktop), this means a workload is taken from KDE, the KDE-guys can concentrate on KDE - KDE-apps will integrate easier into a non-KDE environment. For example, many Gnome-users use amarok and k3b. - DBUS is very much like DCOP in some ways because the guys who created DCOP had a very close look how DCOP works. This means it is not like everything is changing. - Every line of code shared between two project means: More testing, better documentation, more features and so on (because more people are use the API, more applications use it and so on) The current situation with KDE and Gnome (and xfce, fluxbox...) is that some things are already shared but still there are many things for which similar solutions exist in both "worlds". It is good for OSS in general to cooperate instead of fighting each other just because "the other one sucks".
Re: Why ? - Carsten Niehaus - 2006-05-28
> the guys who created DCOP had a very close look how DCOP works that was of course supposed to be "the guys who created DBUS had a very close look how DCOP works"
Re: Why ? - ac - 2006-05-29
> "the guys who created DBUS had a very close look how DCOP works" But they still managed to write butt-ugly code. It's C, depends on glib and in general it looks messy and documentation is scarce (if not less). And I don't buy the workload argument. How much workload was DCOP really for KDE?
Re: Why ? - Ben - 2006-05-29
This is why there is QDBUS to wrap the C DBUS. To hide all of the "messy" code. I expect a rewrite will eventually be done to remove the dependency on glib since dbus is a protocol, not just a library. I do have a small problem with D-Bus though. Why is there 3 address types needed to find a client in dbus? Shouldn't one to the trick? Otherwise, it looks like a very solid interface. Cheers, Ben
Re: Why ? - Kevin Krammer - 2006-05-30
There is more than one type of bus, usually two: the session bus and the system bus. The session bus can be compared with what DCOP does, i.e. allowing communication of applications within the same user session. The system bus is, again compared with DCOP, a new possibility, a way to communicate with applications not running within the user's session, usually not even as the same user. I don't think the third type, activation bus, is used directly though.
Re: Why ? - Thiago Macieira - 2006-05-31
That shows you've never tried. First of all, beauty (or ugliness) is on the eye of the beholder. Obviously who wrote the code finds it beautiful. And as long as there are skillful people maintaining it, why would you care? Second, it does not depend on glib. Third, it does not look messy. Fourth, documentation is not scarce, though it may be outdated in some areas. There's a whole description of the protocol and specifications, something that DCOP never had. We just relied on everyone using Qt's QDataStream, so we never bothered with writing a description of the wire format.
Re: Why ? - André Somers - 2006-05-31
To me, refering to other documentation is also a form of documentation. The way Qt datatypes were written to a QDataStream is nicely documented (as we have grown accustomed with Qt), so it's not like the wire format was undocumented. Why anyone would care about "beautifull" code, is that there is no guarantee that the one who wrote is and/or is maintaining it now will still be doing so in the future. If KDE depends on it, it must be maintainable. To me, beautifull code is maintainable code. For the record: I don't oppose the move to DBUS at all. I am looking forward to a tighter integration of my system with my desktop environment, and I understand that DBUS will make this goal easier to reach.
Re: Why ? - Rob - 2006-05-31
Also, DBus does *not* depend on glib. Only the dbus glib bindings depend on glib. At the moment there is an issue that one of the headers installed as part of libdus should actually only be in the dbus glib bindings. This is on our (the DBus maintainers) plan to be fixed ASAP, and definitely before a dbus 1.0 release. All the language bindings will be split out from the main dbus tree - if anyone wants to help out doing this, we could do with the help ;)
Re: Why ? - Segedunum - 2006-06-01
"KDE-apps will integrate easier into a non-KDE environment. For example, many Gnome-users use amarok and k3b." I wouldn't hold out too much hope of that. One end still needs to understand what the other is sending, and DBUS specifies nothing in that way. Integration is far more than sharing an IPC mechanism.
Re: Why ? - Paul Eggleton - 2006-06-01
True. But sharing the same IPC mechanism is at least a good start.
Re: Why ? - AC - 2006-05-28
>>So - yet another GNOME dependency for KDE What other gnome dependencies does kde have? And if kde is already depending on gnome, why would another dependency hurt? As already stated, D-BUS is not a gnome technology, it comes from freedesktop.org and is derived from DCOP
Re: Why ? - Carsten Niehaus - 2006-05-28
I guess he means HAL or perhaps gstreamer as one of the "favorite" backends in phonon and amarok? No clue otherwise.
Re: Why ? - Carewolf - 2006-05-29
libxml2 for documentation and glib in arts
Re: Why ? - Erik - 2006-05-29
> libxml2 for documentation libxml2 depends on libc and zlib. So what's the real problem? The name "GNOME XML library" or any real objections? lg Erik
Re: Why ? - James Richard Tyrer - 2006-05-29
> What other gnome dependencies does kde have? There are dependencies on LibXML2, LibXSLT, LibArt_LGPL, GLib and (indirect) on GTK+. It also appears that AudioFile is now part of GNOME. This is a problem since GLib 2.10.x appears to break KDE stuff. OTOH, libraries which have moved from GNOME to FreeDesktop.org are not really GNOME dependencies. -- JRT
Re: Why ? - Thiago Macieira - 2006-05-31
libxml2, libxslt don't bring GNOME dependencies. Libart_lgpl is not being used anymore. Glib was used only by aRts and that is gone. Why does anyone care if any of the libraries that we use are used by GNOME as well? Next people are going to complain that we shouldn't use libc because GNOME uses it too.
Re: Why ? - ac - 2006-05-29
> So - yet another GNOME dependency for KDE. Sorry to say this but this really sucks. Haters really suck.
Re: Why ? - ac - 2006-05-29
Everybody sucks ;-)
Re: Why ? - Max - 2006-05-29
No, I don't! ;)
Re: Why ? - Michael Thaler - 2006-05-29
apt-cache show libdbus-1-2 Package: libdbus-1-2 Priority: optional Section: devel Installed-Size: 360 Maintainer: Utopia Maintenance Team <pkg-utopia-maintainers@lists.alioth.debian.org> Architecture: i386 Source: dbus Version: 0.61-5 Depends: libc6 (>= 2.3.5-1) Conflicts: dbus (<< 0.60) Filename: pool/main/d/dbus/libdbus-1-2_0.61-5_i386.deb Size: 233722 MD5sum: 3d9eed32ba7d7072f47b85d66bc36019 Description: simple interprocess messaging system D-BUS is a message bus, used for sending messages between applications. Conceptually, it fits somewhere in between raw sockets and CORBA in terms of complexity. . D-BUS supports broadcast messages, asynchronous messages (thus decreasing latency), authentication, and more. It is designed to be low-overhead; messages are sent using a binary protocol, not using XML. D-BUS also supports a method call mapping for its messages, but it is not required; this makes using the system quite simple. . D-BUS is still under heavy development, but is expected to be widely used. It comes with several interfaces, including GLib. See the description of libdbus-glib-1-2 for more information about those. . The daemon can be found in the dbus package. apt-cache show dbus Package: dbus Priority: optional Section: devel Installed-Size: 532 Maintainer: Utopia Maintenance Team <pkg-utopia-maintainers@lists.alioth.debian.org> Architecture: i386 Version: 0.61-5 Replaces: libdbus0, dbus-1 Depends: libc6 (>= 2.3.5-1), libdbus-1-2 (>= 0.61), libexpat1 (>= 1.95.8), libice6, libsm6, libx11-6, adduser, debianutils (>= 1.22.0), lsb-base (>= 3.0) Conflicts: libdbus0, dbus-1, dbus-1-utils (<< 0.50-2), libdbus-1-1 Filename: pool/main/d/dbus/dbus_0.61-5_i386.deb Size: 301352 MD5sum: 6243a07cdaab71c2ed77c1b5e500173d Description: simple interprocess messaging system D-BUS is a message bus, used for sending messages between applications. Conceptually, it fits somewhere in between raw sockets and CORBA in terms of complexity. . D-BUS supports broadcast messages, asynchronous messages (thus decreasing latency), authentication, and more. It is designed to be low-overhead; messages are sent using a binary protocol, not using XML. D-BUS also supports a method call mapping for its messages, but it is not required; this makes using the system quite simple. . D-BUS is still under heavy development, but is expected to be widely used. It comes with several interfaces, including GLib. See the description of dbus-glib-1 for more information about those. . This package contains the D-BUS daemon; the client-side library can be found in the libdbus-1-2 package, as it is no longer contained in this package. dbus does not depend on gblib. There are wrappers for glib and qt4, however.
Re: Why ? - Carewolf - 2006-05-30
Yes, it does, but they statically link to glib to please KDE.
Digest layout - Eike Hein - 2006-05-28
Sorry to be a pain, but what happened to the plans of moving to use the KDE.org stylesheets for the digest? The typography is very unfriendly to the eyes.
Re: Digest layout - Cerulean - 2006-05-30
Personal preference and all but I like the current layout very much. The font size is just large enough to be easily readable by a lazy mind, yet not overly large to waste space. The colour is slightly lighter than black but not too light - it retains contrast but still makes things feel smoother. The page generally has a nice, consistent feel. My only cripe would be that the links are a little tricky to distinguish (as they're black and the text is some form of dark grey).
Re: Digest layout - boemer - 2006-05-30
I think when you looking at this under windows with firefox, you can press Ctrl+[-] to make it one position smaller, afterwards it looks very good... Don't know about it when under linux....
why KViewShell is still developed in SVN??? - Sergey - 2006-05-28
I thought everything has moved to Okular, why KViewShell is still being developed?
Re: why KViewShell is still developed in SVN??? - m. - 2006-05-29
Because it fully supports DVI while oKular not and probably never will be? KDE/Linux is still geeky thing and formats like DVI are important.
Re: why KViewShell is still developed in SVN??? - Sergey - 2006-05-29
Hmm, my impression was that all of this stuff will be in Okular, including kCHM and kFAX? Otherwise what's the point to create "universal viewer app" that really not that universal?
Re: why KViewShell is still developed in SVN??? - Albert Astals Cid - 2006-05-29
> Because it fully supports DVI while oKular not and probably never will be? Thanks for that great showing of support ;-)
Re: why KViewShell is still developed in SVN??? - Wilfried Huss - 2006-05-29
> Thanks for that great showing of support ;-) Just think how encouraging this topic is for us ;-) Greetings, Wilfried Huss (Maintainer of KViewShell)
Re: why KViewShell is still developed in SVN??? - superstoned - 2006-05-29
well, i wouldn't want to downplay your work, on the contrary, but wouldn't it be nice if DVI support would get into oKular, instead of in kview? adding everything oKular does to Kview would cost more time than adding kview's capabilities to oKular, i guess. as KDE 4 is most likely gonna get a cleanup so it'll only ship one viewer (most likey oKular) - only those that install kview by hand will be able to use its features. and i guess you want everybody to be able to use what you write (and, after all, it IS cool to have DVI support), right? :D but sure, you've heard ppl asking to help a bit on oKular before, i guess, and you'll have you'r reasons for not doing it (or maybe you even DO)...
Re: why KViewShell is still developed in SVN??? - Wilfried Huss - 2006-05-29
> but wouldn't it be nice if DVI support would get into oKular. This is not as easy as it sounds, because oKular uses normalized coordinates to store things like the position letters or of hyperlinks. This does not work for DVI-files, because DVI-files don't need to specify a papersize. How do you know long 0.5 times the full page width is, when you don't know the size of the page? > adding everything oKular does to Kview would cost more time than adding > kview's capabilities to oKular, i guess. You guess incorrectly. It would need a rather big rewrite of oKular. And KViewShell already supports: DVI, DjVu, Fax/g3, PDF and now PostScript.
Re: why KViewShell is still developed in SVN??? - superstoned - 2006-05-30
so it looks more like the oKular ppl should join kviewshell, right? hmmm, come up with a better name and they might ;-)
Re: why KViewShell is still developed in SVN??? - Wilfried Huss - 2006-05-29
> KDE/Linux is still geeky thing and formats like DVI are important. DVI files are the format of choice when working on scientific publications with TeX/LaTeX. And it will still take some time until PDFs will be a better choice for this work. And the scientific desktop is a very important niche for desktop linux, and good DVI support is important for that. KViewShell is today probably the most featureful DVI-Viewer in existence on any platform.
Re: why KViewShell is still developed in SVN??? - mETz - 2006-05-29
> Because it fully supports DVI while oKular not and probably never will be? Then fix oKular instead!
Re: why KViewShell is still developed in SVN??? - AC - 2006-05-29
Well, go ahead :o)
Re: why KViewShell is still developed in SVN??? - Albert Astals Cid - 2006-05-29
Because we never came to agree if it was better to develop on kpdf's source code or in kdvi's (kviewshell) source code.
Re: why KViewShell is still developed in SVN??? - Wilfried Huss - 2006-05-29
> I thought everything has moved to Okular, why KViewShell is still being developed? The KViewShell developers never moved to Okular. When that project started, KViewShell already was a fully developed universal viewer. Also the SOC-Student that started Okular, clearly never was interested in a merge of our projects. And I get really tired of hearing that we should throw away our program, everytime it is mentioned somewere on a website.
Re: why KViewShell is still developed in SVN??? - Jakob Petsovits - 2006-05-29
> The KViewShell developers never moved to Okular. When that project started, > KViewShell already was a fully developed universal viewer. Also the > SOC-Student that started Okular, clearly never was interested in a merge > of our projects. Maybe he wasn't, but I think Albert should be? Perhaps you can find a common direction with him, no matter if oKular or KViewShell would be the outcome. (You could also trick the world and get all the oKular features into KViewShell, and afterwards nuke the original one and rename KViewShell to oKular. ...erm... just speculating.)
Re: why KViewShell is still developed in SVN??? - Wilfried Huss - 2006-05-29
> Maybe he wasn't, but I think Albert should be? We approached Albert about collaboration way before the oKular project started, obviously nothing came out of it. > Perhaps you can find a common direction with him, no matter if oKular or > KViewShell would be the outcome. > (You could also trick the world and get all the oKular features into > KViewShell, and afterwards nuke the original one and rename KViewShell to > oKular. ...erm... just speculating.) We already merged features from KPDF, where it made sense (for example the presentation mode, and the accessibility viewmodes). KViewShell already has most of the features that oKular has, and quite a few features that oKular doesn't have. Merging the two programs would have made sense one and a half year ago, but today KViewShell would gain nothing out of it.
Re: why KViewShell is still developed in SVN??? - Torsten Rahn - 2006-05-29
> Merging the two programs would have made sense > one and a half year ago, but today KViewShell > would gain nothing out of it. Oh yes, it would: It would gain a _NAME_ which doesn't sound like rocket science. Sorry, but while KViewShell might be descriptive to a developer it sounds simply awful to a common user and has exactly no potential when it comes to marketing. (Not that I really like oKular, but while it's still quite technical it gives at least something for the user to imagine). Torsten
Re: why KViewShell is still developed in SVN??? - Wilfried Huss - 2006-05-29
I know the name is not good. It was chosen by the original author, and probably never meant to be visible outside the API. Even on KDE 3.5 we still install kdvi as a binary for compability, although it is really the same program as kviewshell, and it supports more fileformats than only DVI. We do plan to rename KViewShell for KDE4. So, if there are suggestions for a better name, I would really be glad to here them.
Re: why KViewShell is still developed in SVN??? - AC - 2006-05-29
>>probably never meant to be visible outside the API. indeed, people don't mind application names, they just click on a file and use whatever programm is associated with it. If that is kviewshell, and it's sufficient for the user, he/she will continue using it. Renaming kviewshell may be a good idea, especcially if it comes with a good promotion strategie. Apparently kviewshell can do whatever okular wants to do (or even more), but nobody knows about it, while okular gets all the momentum and kviewshell not..
Re: why KViewShell is still developed in SVN??? - Cobarde anónimo - 2006-05-30
<I>We do plan to rename KViewShell for KDE4. So, if there are suggestions for a better name, I would really be glad to here them.</I> How do you like oKular? ;-)
Re: why KViewShell is still developed in SVN??? - Michal - 2006-05-31
Please don't use that insane capital K in the middle of the word. Looks just horrible and normal users have no clue what does it mean.
Re: why KViewShell is still developed in SVN??? - André Somers - 2006-05-31
Maybe krystal? The idea behind the name is of course that one can see (view) all in a crystal ball, including the future (new formats) and the past ("old" formats "nobody" uses anymore). Also, crystal clear displaying are of course the target for any viewer. Last, a natural crystal has may facets, wich could be seen as a reference to the many formats that come together in a single viewer. The K is just thrown in for KDE-ishness, which I happen to like :-)
Re: why KViewShell is still developed in SVN??? - André Somers - 2006-05-31
By the way: it fits nicely with the current "phyisics" naming theme in KDE too: Solid, Phonon, Plasma...
Re: why KViewShell is still developed in SVN??? - James Richard Tyrer - 2006-05-29
Why are we reinventing the wheel yet again? KViewShell is a mature application -- something that takes more than just a Summer to accomplish. I can see possible advantages to adding PS and PDF viewing to KViewShell, but why start over?
so, does it mean - Sergey - 2006-05-29
we will have TWO "not so universal" viewers in KDE4, or 4 if you count kfax and kchm? I'm not being negative, just trying to understand when "application cleanup" idea went down the toilet.
Re: so, does it mean - cl - 2006-05-29
No, it just means that nothing is decided yet....
Phonon - mime - 2006-05-29
Do the Phonon refactorings mean that it will be able to manipulate multiple backends at once?
Re: Phonon - AC - 2006-05-29
Why would you want that?
Re: Phonon - mime - 2006-05-29
To allow crossfading or other kinds of simultaneous playback of different media (which can be handled by different backends)
Re: Phonon - AC - 2006-05-29
I still don't see the point in using multiple backends? and simultaneous playback is already possible if you are using a decent sound card, or with alsa's dmix.
Re: Phonon - mime - 2006-05-30
I mean this: http://bugs.kde.org/show_bug.cgi?id=127308
Re: Phonon - AC - 2006-05-30
Ah that one :) But there are some problems with that: The outpunt from the backends won't be mixed, so if phonon directs different streams to different backends simultaniously, they will collide with each other (unless you have a sound card that does the mixing for you), and backends will complain that the audio device is not ready. And something else: lets say you have a playlist in amaroK containing mp3, ogg and wmv files, and for each file format you have configured phonon to use a different backend. Playing that list would mean that phonon should switch backends every time another audio format is loaded in amaroK. That would create a lot of overhead on the system, causing large gaps between the songs..
Re: Phonon - mime - 2006-05-30
> they will collide with each other (unless you have a sound card that does the mixing for you) Even if they all output to ALSA? Doesn't dmix solve that for everybody? (except the OSS apps) > That would create a lot of overhead on the system, causing large gaps between the songs.. This is why I was asking. If Phonon is now meant to allow apps to queue tracks for playback, then a specific engine can be preloaded when it's track is nearing, so that it's already available when needed, and no gap is caused. (I assume)
Re: Phonon - me - 2006-05-30
Right now I use aRts for general stuff in /dev/dsp, and I configured Xine to ouput /dev/dsp1 to get sound in my usb headphones (which I use to play music and movies without anoying my flatmates).
KDe not a D-BUS user - KDe User - 2006-05-29
Strange, but KDE is not on the D-BUS users list.
Re: KDe not a D-BUS user - James Richard Tyrer - 2006-05-29
So? That page is a Wiki, you can fix it.
Re: KDe not a D-BUS user - Thiago Macieira - 2006-05-31
Technically, we weren't a D-BUS user until a few hours ago.
Re: KDe not a D-BUS user - Morty - 2006-05-31
Are you sure that's technically correct? I thought KDE was a (optional) D-BUS user since KDE 3.4 (or was it 3.3?). Using D-BUS for it's HAL support, in handling mounting of media and such. More or less equaling Gnomes usage of D-BUS.