Bug 183193

Summary: Status window of rhgb adjust size for power management
Product: [Fedora] Fedora Reporter: Philip Wyett <philip.wyett>
Component: rhgbAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: jrb, martin.sourada, mattdm
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-09-05 17:08:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 235704    

Description Philip Wyett 2006-02-27 12:09:10 UTC
Description of problem:

When FC is booting and rhgb is running, the status section below the logo will
adjust size moderately to accomodate the poer management element and looks a bit
nasty.

How reproducible:

Just boot with rhgb enable - All resolutions.
  
Actual results:

Status section will adjust size.

Expected results:

Status section to be slightly larger to accomodate the power management element
without the need to resize itself.

Additional info:

If the expected was the case the rhgb would look totally slick!!! :-)

Comment 1 Matthew Miller 2007-04-06 18:53:21 UTC
Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer
test releases. We're cleaning up the bug database and making sure important bug
reports filed against these test releases don't get lost. It would be helpful if
you could test this issue with a released version of Fedora or with the latest
development / test release. Thanks for your help and for your patience.

[This is a bulk message for all open FC5/FC6 test release bugs. I'm adding
myself to the CC list for each bug, so I'll see any comments you make after this
and do my best to make sure every issue gets proper attention.]


Comment 2 Ray Strode [halfline] 2007-08-14 15:48:02 UTC
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there haven't been any
updates to the report in quite a long time now after we've
requested additional information, we're assuming the problem
is either no longer present in our current OS release, or
that there is no longer any interest in tracking the problem.

Setting status to CANTFIX, however if you still
experience this problem after updating to our latest Fedora
Core release and are still interested in Red Hat tracking
the issue, and assisting in troubleshooting the problem,
please feel free to provide the information requested above,
and reopen the report.

Thank you in advance.

(this message is mass message)

Comment 3 Steven Garrity 2007-08-23 23:50:38 UTC
If you have services starting up that have titles that cause the text in the
status box to be wider than the box itself, the box grows in width to
accommodate the additional text.

This has a jumping/jarring effect. It would be better if the width of the box
was fixed, and there was some vertical space for long text lines to wrap on the
a second line while the overall height/width of the status box remained stable.

I'd suggest this be re-opened.

Comment 4 Steven Garrity 2007-08-23 23:51:45 UTC
See fedora-art thread suggesting re-open:
https://www.redhat.com/archives/fedora-art-list/2007-August/msg00236.html

Comment 5 Martin Sourada 2007-08-24 10:09:44 UTC
Since it seems I am not the only one understanding that this bug is the issue we
noted in the art list, I therefore reopen this bug. As far as I remember it is a
issue with all fedora releases since fedora core 3 (which was the first fedora I
user) and it is still present in rawhide. Possible fix would be to make the
width fixed (probably to the same width the window with details have).

Comment 6 Ray Strode [halfline] 2007-09-05 17:08:56 UTC
We "solved" this by taking the descriptions out entirely. 

It turns out there were only ~15 or so possible messages anyway and they weren't
that good

"Initializing random number generator" ?
"Starting console mouse services" ?

Another technique that was discussed was to preload every message into a
separate label, and add each label to a different page of a notebook (without
visibile notebook tabs) and then just switch pages when new messages came in.