Bug 75857 - hwbrowser does not display drives properly
hwbrowser does not display drives properly
Product: Red Hat Linux
Classification: Retired
Component: hwbrowser (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Brent Fox
: 73445 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2002-10-14 00:16 EDT by Need Real Name
Modified: 2008-05-01 11:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-02-28 15:06:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2002-10-14 00:16:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
I have three hard drives on this computer. hwbrowser displays the first two
splendidly, as a complete, light blue bar with partitions accounted for. The
third drive appears only as to it's top half, that is to say the upper half of
the blue bar shows along with its partitions but the bottom half doesn't seem to
have the room to appear so its not there. I've attempted to manipulate the
window size so as to make possible the full view of the third drive, but the
portion of the window in which the truncated blue bar appears can't be altered
in any way I can discover. Had this very fine program only taken into account
the possibilily that a computer would have two but no more drives? Please fix if
you will, I'm feeling shortchanged. :-)

John Lowell  

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

How reproducible:

Steps to Reproduce:
1.Requires computer with three hard drives
2.Open System Tools from Main Menu
3.Select Hardware Brower

Actual Results:  As described

Expected Results:  Three complete blue bars should show, not two and one half

Additional info:
Comment 1 matteo porta 2002-10-26 16:21:51 EDT
yes, it happens to me too.
please add a vertical scroll bar to the drives area, so that i can scroll and 
see the 3rd drive.
Comment 2 Need Real Name 2003-01-05 03:35:58 EST
My initial report now approaching its third month anniversary, I must confess to
a certain relief that some action, any action, even the recent reassignment, has
occured with respect to this bug. One begins to wonder if this long sleep
through which we've come has be drug induced. While I certainly can't speak for
Mr. Porta, for me, a point approaches where serious interest in and well wishing
for hwbrowser will be impossible to maintain without the courtesy of a more
energetic response. A search for less flawed alternative is always a
possibility, of course.

John Lowell
Comment 3 Brent Fox 2003-01-09 12:36:31 EST
I spent about three hours on this last night and made very little progress.  The
canvas is actually inside a ScrolledWindow, only the scroll doesn't function
even if the canvas is too big to fit.  Calling get_bounds() on the canvas
returns a smaller size than it actually is.  I'm leaning towards a gnome canvas
bug right now, but I need to investigate further.
Comment 4 Brent Fox 2003-01-09 23:15:02 EST
*** Bug 73445 has been marked as a duplicate of this bug. ***
Comment 5 Brent Fox 2003-02-28 15:06:48 EST
This turned out to be a really frustrating bug.  I've fixed it by calling
update_now() before the canvas is shown.  For some reason, the partitioning
screen in anaconda that is very similar does not have to make this call.  Maybe
glade has something to do with it.

Anyway, this should be fixed in CVS now.  The fix won't make the next version of
Red Hat Linux, but it will appear in the one after that.  It should also appear
in Rawhide sometime soon.  hwbrowser-0.8-11 should fix the problem.  

Thanks for your report.  Sorry this took so long, but it was really non-obvious
what the problem was.  I still think that there might be a subtle in
gnome-canvas.  For some reason, calling get_bounds() will not return the correct
bounds until the canvas has been repainted.

According to the gnome-canvas documentation at:

"void        gnome_canvas_update_now         (GnomeCanvas *canvas);

Forces an immediate update and redraw of a canvas. If the canvas does not have
any pending update or redraw requests, then no action is taken. This is
typically only used by applications that need explicit control of when the
display is updated, like games. It is not needed by normal applications."

I should not have to call update_now(), but it will not update correctly without it.

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