On Thursday 11 February 2010 09:31:21 Walter Dnes wrote:
On Wed, Feb 10, 2010 at 02:18:43PM +0000, Neil Bothwick wrote
> On Wed, 10 Feb 2010 07:57:57 -0500, Walter Dnes wrote:
> > > but D-Bus provides a standard way for applications to communicate
> > > with one another and removing it can stop your desktop working as
> > > it should.
> > >
> > Then how did things manage to work on my systems for the past 9
> > years,
> >
> > pray tell?
>
> Because nine years ago, Linux desktop software didn't use
interprocess
> communication. Of course things will still work, but not necessarily
> everything. For example, Network Manager uses D-Bus to tell programs
when
> your Internet connection is available and not, so your mail client
goes
> into offline mode rather than pointlessly trying to access your
mailbox.
> KDE4 uses it quite extensively, ust as KDE3 used DCOP.
There is too much solution-in-search-of-a-problem here. XMMS followed
the original Unix philosophy... it did one thing did it right, namely
playing audio. Unfortunately, XMMS was hard-coded to use a now obsolete
GTK library.
Unfortunately, that's analogous to a business employing 5 people, all of
whom
do their own thing all the time with no inter-person communication and
no co-
ordination. Perhaps they might scribble a note on a white board once a
day,
but that's about it.
The "successor" to XMMS is Audacious. It seems to subscribe to the
Microsoft philosophy, and tries to do everything under the sun, and
pretends it's a server, which requires dbus. Is it *REALLY* necessary?
I used XMMS to play mp3's and Live365.com. I ended up switching to
mpg123 for both functions when XMMS was dropped, and then to the Flash
player for Live365. I emerged Audacious, but unmerged it when I saw the
post-install warning that said not to submit any Audacious bug reports
if I don't have dbus installed.
Modern desktops are integrated, because that's what users want. Any two
apps
should be able to inter-communicate wherever that communication makes
sense.
Example: You have any old arbitrary email client. A mail contains a URL.
Click
it. The URL should open in your preferred browser, whatever that should
be.
Please note that any email client should support launching any browser,
whether the dev built in support for it or not. Yes, I know there are
the xdg*
scripts, but tally up the number of things a user would want to work like
this, tally up the number of scripts in the infinite number of locations
this
will take, and then ask the user to "pick one".
Example: Notifications. I have 3 (yes, three!!) kinds of popups that
show up
here daily. There's KDE's system which is the majority of them, some GTK
apps
throw popups in the top right corner where I don't want them and them
then
there's Skype which does it's own thing. God, you gotta love proprietary
sekrit apps </sarcasm>. The solution is a notification service, apps send
their notifications to it and the service does whatever the user
configured it
to do with the notification. Note that the user is in control here, the
user
says what happens with popups and does it in one central place and the
apps
does one thing and one thing only with it's notifications: sends them.
It's
like syslogger, letting the app concentrate on it's real purpose (which
is not
logging, and definitely is not making sure it doesn't clobber log files
from
any other apps that might be running).
See where this is going? Do you need a hundred more examples?
When you have arbitrary, unknown (at install time) sources of data that
may
interoperate with other arbitrary, unknown (at install time) sinks of
data,
good data modelling says that a known broker of data should sit in the
middle,
which is generic enough for anything to be able to use it.
And the transport for that is dbus.
Just to bring this back to your original statement of Unix philosophy.
IPC on
modern desktops conforms exactly to the Unix philosophy. Apps were
moving away
from that and were becoming IM clients cum custom loggers cum notifiers
cum
<insert any other crap here>.
Standardized IPC is moving back TOWARDS the Unix philosophy, not away
from it.
Apps can now concentrate on their core function, and hand over the
integration
aspects to something else dedicated to IPC and nothing else. The apps now
merely does the minimum required to hand over data to the service via a
messaging bus.
Which if you look at it in that light, is EXACTLY the same rationale as a
syslogger. Do you use a syslogger? Why?
If you don;t like all this integration stuff, and you have every right
to not
like it, then you should uninstall KDE and use Openbox (or similar
lightweight
WM). These WMs exist for users that do not want desktop integration. One
thing
you cannot have is the latest KDE without it's integration features.
