That's probably true, but no argument against making it smaller and more visually pleasing. :)
I expect people's eyes are drawn to it even if it's as small as Web+'s status bar, when there is actual movement in the progress bar. That's usually the case in an otherwise static GUI.

I find that one not very nice looking, hence created a new one. It's a matter of taste I guess.

I feel your pain.

I hate the zip-o-matic barberpole is why my friends find Haiku so old...
I think the system should be consistent a barberpole is a progressbar with time indeterminate.
The transition between progress bar and barber pole is seamless.
To my eyes the first look more modern and use the Haiku palette. My opinion...

The one from Zip-O-Matic looks quite "outdated" IMO. Not against a 3D'ish look, a more modern version of it would be nice. I like Janus' suggestion based on the progress bar look, although it might need a little more colour contrast.
So if someone implements a nice 3D look, I'd gladly accept the patch(es)... :-)

For now I'll look into making the bar smaller as requested and then focus on a few other, more pressing issues in HaikuDepot...

The BarberPole is in a LayoutCard with the fProgressBar you can change both size with

The one from Zip-O-Matic looks quite "outdated" IMO. Not against a 3D'ish look, a more modern version of it would be nice. I like Janus' suggestion based on the progress bar look, although it might need a little more colour contrast.
So if someone implements a nice 3D look, I'd gladly accept the patch(es)... :-)

For now I'll look into making the bar smaller as requested and then focus on a few other, more pressing issues in HaikuDepot...

My mockup is only a suggestion, but I really think the progressbar and polebar should look very similar... if used in all the os a statusbar can change in a polebar and the other way around based on the current action. We live in a flat world (UI speaking) using too much 3D make the os look outdated.

The BarberPole is in a LayoutCard with the fProgressBar you can change both size with

The one from Zip-O-Matic looks quite "outdated" IMO. Not against a 3D'ish look, a more modern version of it would be nice. I like Janus' suggestion based on the progress bar look, although it might need a little more colour contrast.
So if someone implements a nice 3D look, I'd gladly accept the patch(es)... :-)

Your barberpole is very configurable I hope someone with good design skill can achieve a very good result.

+1 on new barbar pole, the Zip-O-Matic one fits in a lot better on BeOS than it does on Haiku.

The status bar on WebPositive fits in the area between the bottom border and the top of the window resize notch, the Haiku Depot one should ideally also fit in this space, at least at the default font size.

in hrev51622 what is the significance of font size * 0.9? At default the 12pt font size that gives 10.8pt... you didn't even round to an integer value. In Tracker we have used font size * 0.75 in places (e.g. title view in list mode). At default 12pt font size at gives you a value of 9pt. All that said I think the text will fit even at 12pt font size so I'm not sure lowering the font size is needed.

I like the new barber pole, too. I'd prefer the nicer be_control_look->DrawTextControlBorder() over the plain be_control_look->DrawBorder(), though.
You all think moving the status bar up under the list view is a bad idea? It's more in the center of attention there and also near the "Install" button. Just saying...

You all think moving the status bar up under the list view is a bad idea? It's more in the center of attention there and also near the "Install" button. Just saying...

As far as UI structure is concerned, I think there is the general information of ongoing jobs, which is not specific to the selected package and thus should not be inside the package view. And then there is the case that the selected package happens to be the one being currently downloaded, which then justifies the progress bar within the package view. I can live with the bar where it is right now, since that doesn't conflict with the selected package even when it's the one being downloaded. Another solution is to have two progress bars, one for all jobs and one in the package when it's being downloaded.

You could also view it that you clicked Install in the package and dependencies being downloaded belong to that job as a whole. But when you look at another package, why would the progress bar then remain inside that unrelated package's view? The bottom location doesn't introduce such conflicts.

Oh... sorry, I just now took a look at the enlarged mockup you did further up. So it's just about moving the status group between the list view and the package view, not inside the package view. That is fine as well. Maybe even better since it doesn't mess with the resize handle how it fits with just the vertical scrollbar.

Oh... sorry, I just now took a look at the enlarged mockup you did further up. So it's just about moving the status group between the list view and the package view, not inside the package view. That is fine as well. Maybe even better since it doesn't mess with the resize handle how it fits with just the vertical scrollbar.

This would also solve a problem that installing a local package currently doesn't show an overall progress for its deps.