Red Hat Bugzilla – Bug 75857
hwbrowser does not display drives properly
Last modified: 2008-05-01 11:38:04 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. :-)
Version-Release number of selected component (if applicable):
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
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.
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.
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.
*** Bug 73445 has been marked as a duplicate of this bug. ***
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.