KDE Commit-Digest for 28th May 2006

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.

Dot Categories: 

Comments

by AC (not verified)

> KDELibs is now fully ported to D-BUS.

So - yet another GNOME dependency for KDE. Sorry to say this but this really sucks.

by AC2 (not verified)

> 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!

by Eike Hein (not verified)

D-BUS is desktop-agnostic.

by Tom (not verified)

...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!

by Carsten Niehaus (not verified)

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".

by Carsten Niehaus (not verified)

> 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"

by ac (not verified)

> "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?

by Ben (not verified)

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

by Kevin Krammer (not verified)

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.

by Thiago Macieira (not verified)

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.

by André Somers (not verified)

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.

by Rob (not verified)

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 ;)

by Segedunum (not verified)

"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.

by Paul Eggleton (not verified)

True. But sharing the same IPC mechanism is at least a good start.

by AC (not verified)

>>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

by Carsten Niehaus (not verified)

I guess he means HAL or perhaps gstreamer as one of the "favorite" backends in phonon and amarok?

No clue otherwise.

by Carewolf (not verified)

libxml2 for documentation and glib in arts

by Erik (not verified)

> 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

by James Richard Tyrer (not verified)

> 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

by Thiago Macieira (not verified)

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.

by ac (not verified)

> So - yet another GNOME dependency for KDE. Sorry to say this but this really sucks.

Haters really suck.

by ac (not verified)

Everybody sucks ;-)

by Max (not verified)

No, I don't! ;)

by Michael Thaler (not verified)

apt-cache show libdbus-1-2
Package: libdbus-1-2
Priority: optional
Section: devel
Installed-Size: 360
Maintainer: Utopia Maintenance Team
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
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.

by Carewolf (not verified)

Yes, it does, but they statically link to glib to please KDE.

by Eike Hein (not verified)

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.

by Cerulean (not verified)

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).

by boemer (not verified)

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....

I thought everything has moved to Okular, why KViewShell is still being developed?

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.

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?

by Albert Astals Cid (not verified)

> Because it fully supports DVI while oKular not and probably never will be?

Thanks for that great showing of support ;-)

by Wilfried Huss (not verified)

> Thanks for that great showing of support ;-)

Just think how encouraging this topic is for us ;-)

Greetings,
Wilfried Huss (Maintainer of KViewShell)

by superstoned (not verified)

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)...

by Wilfried Huss (not verified)

> 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.

by superstoned (not verified)

so it looks more like the oKular ppl should join kviewshell, right? hmmm, come up with a better name and they might ;-)

by Wilfried Huss (not verified)

> 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.

> Because it fully supports DVI while oKular not and probably never will be?
Then fix oKular instead!

Well, go ahead :o)

by Albert Astals Cid (not verified)

Because we never came to agree if it was better to develop on kpdf's source code or in kdvi's (kviewshell) source code.

by Wilfried Huss (not verified)

> 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.

by Jakob Petsovits (not verified)

> 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.)

by Wilfried Huss (not verified)

> 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.

by Torsten Rahn (not verified)

> 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

by Wilfried Huss (not verified)

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.

>>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..

by Cobarde anónimo (not verified)

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.

How do you like oKular? ;-)

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.

by André Somers (not verified)

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 :-)

by André Somers (not verified)

By the way: it fits nicely with the current "phyisics" naming theme in KDE too: Solid, Phonon, Plasma...