Handling any number of mounted volumes in tabs

[humdinger]

This is hrev39308.

DiskUsage's tab view doesn't handle the situation when there are many mounted volumes, which results in more tabs than there's space in the tab bar.
Maybe something like Web+'s solution could be implemented. Is this something that could be done automatically, i.e. the app wouldn't have to care about that?

[mmadia]

Any interest stpere?

[stpere]

Interest isn't the issue in that case, time is :) I doubt I will have time to start investigation on this one before next weekend. If anyone have any interest, feel free to take it! :)

[Disreali]

I prefer the old layout without the tabs for precisely this reason. The old drop-down box is a cleaner solution, especially when there are many disk mounted.

[humdinger]

It could be argued that most users only have a handful of volumes mounted at a time. In this case, tab views have advantages: You immediatly see all partitions and you save a click you'd need to pop up a pop-up menu. Also, DiskUsage remembers its window size, so people that usually have a bit more mounted volumes can compensate with a wider window.
It may be worth considering not to use navi-arrow-buttons like Web+ for invisible tabs, but a small pop-up menu button with e.g. a down-arrow symbol instead. This pop-up would list all tabs with a separator between the currently visible and invisible entries.

[stpere]

Hmm, I'll watch what I say because I'm bitter (not because of this) this afternoon.. but then why wasn't any such comments made in the original ticket (that was active for months). See, if it wasn't a welcome change, I would have saved my time.

[humdinger]

Hey, I love those tabs! :)
I just didn't think of situations with many mounted volumes when filing the original ticket...
There's still the question:

Is this something that could be done automatically, i.e. the app wouldn't have to care about that?

I guess the issue of having to navigate too many tabs for a window width can crop up for many apps. So, can it be solved with an API enhancement?

[luroh]

I too think the tabs in DiskUsage improve the functionality for the majority of users and the problem described in this ticket applies to other applications as well.

Humdinger's suggestion of solving the 'too many tabs' problem in a generic and unified way sounds useful and appealing [to a layman end-user like me]. Provided it also makes sense from a technological perspective, perhaps this ticket can be morphed into an enhancement ticket for the layout API instead?

[Disreali]

Replying to stpere:

Hmm, I'll watch what I say because I'm bitter (not because of this) this afternoon.. but then why wasn't any such comments made in the original ticket (that was active for months). See, if it wasn't a welcome change, I would have saved my time.

Sorry Stpere, but I missed ticket:3520 the first time around. All the other additions are very useful.

As, to this issue of tabs, I agree with luroh. Enhancing the layout API sounds like the best way to deal with the 'too many tabs' issue.

[stpere]

Sorry for my overly emotive answer (bad day.)

that being said, I also agree that this tab issue is likely to occur in other apps too and working on this issue upstream might be wiser.

[stippi]

In WebPositive, I've wrote a new tab view implementation. It's composed of lots of smaller inner classes to delegate the functionality. It may be possible to rewrite BTabView in a binary compatible way to offer the same functionality, but it could easily become a mess. Personally, I wouldn't mind putting the WebPositive implementation into a static library, like it's currently done with BColumnListView. I don't remember if the base class is completely reusable in any other context. I don't anticipate it would need more than a few minor changes to make it so. I don't have any time to work on this, but since the hard work is already done, it is low hanging fruit for anyone who is interested.

[pulkomandy]

Issue to be fixed in BTabView and there is already a ticket for that.