Window sizing oddities in "Downloading Package Files" status window

Bug #9924 reported by David D Miller
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
synaptic (Ubuntu)
Fix Released
Medium
Michael Vogt

Bug Description

When you click the disclosure triangle to show progress of single files, the
window is too narrow to be able to see the filename that's being downloaded at
the same time as the progress meter showing its progress. The window is also
not resizable, so you can't make it wider to accommodate. Also, the window
width seems to "jiggle" a little if a package with a long filename gets added to
the list in the progress window. The content of the listbox is obviously
getting wider (the scrollbar adjusts) but it seems to kick the width of the
window itself by a few pixels as well.

Revision history for this message
David D Miller (justdave) wrote :

(this is in hoary, btw)

Revision history for this message
Michael Vogt (mvo) wrote :

Thanks for this bugreport. I'll have a closer look soon.

Revision history for this message
Martin Kretzschmar (martink) wrote :

I think it's not long list entries that make window width "jiggle," but the
width of the progress bar which itself depends on the length of the text inside.
And that text changes its width whenever the ETA changes.

Revision history for this message
Michael Vogt (mvo) wrote :

I fixed this problem in the current development version of synaptic. It will be
part of the next upload.

Revision history for this message
Michael Vogt (mvo) wrote :

I think this is fixed in 0.55+cvs20041113. can you please confirm this?

Revision history for this message
nandhp (nandhp) wrote :

I realize that I'm a bit late, but I've never been very happy with the resolution to this bug. The fix currently in use breaks when the details expander is opened and then closed again.

The original fix made the window resizable by default with a default_width of 450. But the expander modifies the resizable parameter when its visibility is toggled. Thus, the window reverts to the original, buggy, behavior when the expander is collapsed.

I've attached a patch which instead sets a minimum size request of 426 on the progress bar, which produces a window of the same size as with the existing fix. However, this size is enforced when the expander is visible and remains effective after it is collapsed again.

Perhaps there is some reason why this isn't a good solution, but I thought I'd suggest it, since it more fully resolves the problem.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.