Bug 55925 - htmlview launches KDE application in non KDE desktop
Summary: htmlview launches KDE application in non KDE desktop
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: htmlview   
(Show other bugs)
Version: 7.2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jonathan Blandford
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2001-11-08 21:34 UTC by Josi Romildo Malaquias
Modified: 2013-04-02 04:15 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-18 21:02:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Make htmlview check if KDE is running (1.50 KB, patch)
2001-11-09 13:24 UTC, Josi Romildo Malaquias
no flags Details | Diff

Description Josi Romildo Malaquias 2001-11-08 21:34:05 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-13 i686)

Description of problem:
htmlview launches an HTML viewer based on the desktop being used. There are
3 sets of choices: one set of HTML viewers for KDE, one set for GNOME and
one set for a generic desktop (nor KDE, nor GNOME). At least this is what
can be understood reading the script /usr/bin/htmlview.

But the generic set is never given preference. The script tests only if the
user is running GNOME, in which case the gnome viewers are given
preference. Otherwise, the KDE viewers are given preference.

If KDE is installed, khelpcenter will be the chosen HTML viewer. One
complaint is that the KDE applications are slow to load into memory when
not running the KDE desktop.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run a graphical desktop different of GNOME and KDE. In my case I am
running the IceWM window manager.
2. Call htmlview to view an HTML page.

Actual Results:  Watch khelpcenter slowly load and then show you the HTML
page (supposing KDE is installed in your system).

Expected Results:  A non KDE or non GNOME HTML viewer be used to display
the HTML page.

Additional info:

Comment 1 Bernhard Rosenkraenzer 2001-11-09 12:10:06 UTC
This is true, because the "generic" ones simply aren't faster to start up 
(mozilla is huge).
In my experience, starting konqueror even without running KDE doesn't take 
longer. Is this different for you?

Comment 2 Josi Romildo Malaquias 2001-11-09 13:20:45 UTC
In fact, mozilla is not working when launched with htmlview when launched by my
mail client of choice (mutt). It seems to not accept a file name without the
file:// part as a URL, as is sent by mutt. So I have edited the htmlview script
and reordered the options. I have found that galeon is a good option (although
it is a GNOME application), even not running GNOME. It loads (and unloads) much
faster than the KDE browsers in my configuration. khelpcenter is really started
slower than galeon in my box (a Pentium II 400 MHz, 128 Mb computer).

I am attaching a patch of the changes I have made to htmlview. Maybe you could
consider testing explicitly the presence of KDE and add the KDE browsers (or
galeon) to the generic options.

Comment 3 Josi Romildo Malaquias 2001-11-09 13:24:04 UTC
Created attachment 37008 [details]
Make htmlview check if KDE is running

Comment 4 Pavel Roskin 2001-11-09 21:32:31 UTC
I also noticed the problem and made my patch.  My approach with KDE detection is
different.  kdeinit may be running just because konqueror was previously run,
but the desktop is not KDE (it's IceWM in my case).  The real sign of the KDE
desktop is "kdesktop".  However, it is seen as "kdeinit: kdedesktop" in the
process listing.

I believe that it's wrong to run konqueror just because I have already konqueror
ready or because I have run and closed it in that session.  This would be very

The right test for KDE is:

if [ "x`/sbin/pidof kdeinit:\ kdesktop`" != "x" ]; then

This has been tested with and without KDE.

Note You need to log in before you can comment on or make changes to this bug.