Your message dated Sun, 18 Apr 2010 18:57:34 +0200
with message-id <4bcb39fe.6040...@debian.org>
and subject line Re: Bug#578279: evince: Is relying on dbus & gconf really
necessary?
has caused the Debian Bug report #578279,
regarding evince: Is relying on dbus & gconf really necessary?
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
578279: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578279
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: evince
Version: 2.28.2-1
Severity: wishlist
As the subject says - is it really necessary to rely on dbus & gconf? While
it's all well and good that dbus gives apps numerous ways to communicate
with each other, and gconf gives apps a central place to store and retreive
configuration settings, one could argue that they add unnecessary complexity.
If dbus or gconf breaks, how does an end-user debug it? Should the end-user
be required to post on forums, kill random processes, and eventually reboot
in the hope that he can read a pdf? Documentation for these layers is sadly
sparse, and breakage is far too common, with a myriad number of reasons.
evince is a tool meant for end-users. Shouldn't it's functionality match?
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32.9 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages evince depends on:
ii evince-common 2.28.2-1 Document (postscript, pdf) viewer
ii gconf2 2.28.0-1 GNOME configuration database syste
ii gnome-icon-theme 2.28.0-1 GNOME Desktop icon theme
ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit
ii libc6 2.10.2-2 GNU C Library: Shared libraries
ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra
ii libdbus-1-3 1.2.16-2 simple interprocess messaging syst
ii libdbus-glib-1-2 0.84-1 simple interprocess messaging syst
ii libevince1 2.28.2-1 Document (postscript, pdf) renderi
ii libfontconfig1 2.8.0-2 generic font configuration library
ii libfreetype6 2.3.11-1 FreeType 2 font engine, shared lib
ii libgconf2-4 2.28.0-1 GNOME configuration database syste
ii libglib2.0-0 2.24.0-1 The GLib library of C routines
ii libgnome-keyring0 2.28.2-1 GNOME keyring services library
ii libgtk2.0-0 2.20.0-3 The GTK+ graphical user interface
ii libice6 2:1.0.6-1 X11 Inter-Client Exchange library
ii libnautilus-extension1 2.28.4-1 libraries for nautilus components
ii libpango1.0-0 1.26.2-1 Layout and rendering of internatio
ii libpoppler-glib4 0.12.2-2 PDF rendering library (GLib-based
ii libsm6 2:1.1.1-1 X11 Session Management library
ii libx11-6 2:1.3.3-1 X11 client-side library
ii libxml2 2.7.6.dfsg-2+b1 GNOME XML library
ii shared-mime-info 0.70-1 FreeDesktop.org shared MIME databa
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
Versions of packages evince recommends:
ii dbus-x11 1.2.16-2 simple interprocess messaging syst
ii gvfs 1.4.3-1 userspace virtual filesystem - ser
Versions of packages evince suggests:
ii nautilus 2.28.4-1 file manager and graphical shell f
pn poppler-data <none> (no description available)
ii unrar 1:3.8.2-1 Unarchiver for .rar files (non-fre
-- no debconf information
--- End Message ---
--- Begin Message ---
On 18/04/10 17:45, Mike Edwards wrote:
> As the subject says - is it really necessary to rely on dbus & gconf? While
> it's all well and good that dbus gives apps numerous ways to communicate
> with each other, and gconf gives apps a central place to store and retreive
> configuration settings, one could argue that they add unnecessary complexity.
>
> If dbus or gconf breaks, how does an end-user debug it? Should the end-user
> be required to post on forums, kill random processes, and eventually reboot
> in the hope that he can read a pdf? Documentation for these layers is sadly
> sparse, and breakage is far too common, with a myriad number of reasons.
>
> evince is a tool meant for end-users. Shouldn't it's functionality match?
Use evince-gtk.
Emilio
--- End Message ---