Quodlibet: Display a long size timescolling-bar on the window

[lazka]

Original issue 204 created by nanocmoi on 2009-05-22T09:02:53.000Z:

It's quite tying to have to click on the time button to display the time bar.
I think there is a lot of place to display such a bar all the time in the
window. If the bar could be bigger than now it would be easier to navigate
into long songs.

[lazka]

Comment #1 originally posted by steven.strobe.cc on 2009-06-18T17:10:31.000Z:

Not guaranteed to make it in to 2.1, but it will at least receive some discussion by
then.

[lazka]

Comment #2 originally posted by steven.strobe.cc on 2009-06-28T16:23:56.000Z:

<empty>

[lazka]

Comment #3 originally posted by steven.strobe.cc on 2009-08-22T15:37:27.000Z:

Issue #284 has been merged into this issue.

[lazka]

Comment #4 originally posted by steven.strobe.cc on 2009-08-23T17:34:12.000Z:

Here's an example implementation (it's not yet finished, the bookmark menu needs to
move to a traditional menu for this approach and there's something strange with the
timing, but the patch is for discussion, not for inclusion ATM).

As you can see in the attached screenshot, even with the extra spacing, the scrollbar
gets a little cramped in its current position. We could maybe come up with another
button or two to add which would balance things out, or move the current time info,
or just scale the buttons up to gargantuan size as shown in the second screenshot
(just change SIZE to gtk.ICON_SIZE_DND).

Feedback welcome.

[lazka]

Comment #5 originally posted by nanocmoi on 2009-08-23T20:31:32.000Z:

Nice,
I would find it better if the time scrollbar goes untill the cover image because it's
easyer to scroll with more precision in long songs.
I dont really like huge buttons, actually I find them huge in standard size but it's
my personal opinion.
I'll not start with code details because i didnt read it and i dont know python...

[lazka]

Comment #6 originally posted by nick.boultbee on 2010-02-20T09:15:42.000Z:

This seems like a long overdue UI enhancement (there are a few others perhaps). Too
many times I've clicked on the existing control and had it take over the cursor keys
(Though actually, I now use this feature quite a lot). That and for newbies, it's
unintuitive.

Just had a look at the patch. Screenshots look great! I can't get the patch to work
for me however (last 2 hunks rejected - I guess it's quite old now). Steven, are you
planning to continue this patch? If so what can be done to fix it for current hg HEAD?

Also, although logically distinct, it's close: when I showed a friend QL a while ago,
the first thing he said (he's a [web] UI / IA architect) was that the play button was
bad UI; it should change between a pause icon and a play icon depending on what it
will next do (like most players). I tend to agree. Thoughts? (or shall we open a new
issue?)

[lazka]

Comment #7 originally posted by marc.lieberenz on 2010-02-28T11:44:21.000Z:

I would appreciate it if the timescrollbar would be integrated like shown in this
patch. What is the advantage of the scrollbar hidden by a button?

[lazka]

Comment #8 originally posted by towolf on 2010-02-28T20:26:37.000Z:

I just want to say that I like the feng-shui of the current 3+2 button block and I find
the "fold-out" slider sufficient. It’s an odd approach, admittedly, but it doesn’t eat
space.

[lazka]

Comment #9 originally posted by marc.lieberenz on 2010-03-02T21:17:57.000Z:

But there is enough space beside the title and artist and with the scrollbar directly
on top it would save you one click and it would make it visual easier to see how far
the song is played.

[lazka]

Comment #10 originally posted by reiter.christoph on 2010-09-26T23:25:43.000Z:

Issue #574 has been merged into this issue.

[lazka]

Comment #11 originally posted by tom.wieland on 2010-10-06T12:14:10.000Z:

You could even use this area (red)

[lazka]

Comment #12 originally posted by towolf on 2010-10-07T00:02:33.000Z:

I use that area for my extended track info string.

[lazka]

Comment #13 originally posted by [email protected] on 2011-02-04T09:41:19.000Z:

Hello everybody, first lets thanks for that nice player, I searched a long time and tried a lot of others, but I was never satisfied like this before.

I (and a lot of my friends too) would really want to have a large, always visible and therefore quick accessible, seekbar! Like in the screenshot of comment 11. Because scrolling is essential to me. always have to click before I can scroll isn't the user friendly, intuitive way.

ok, if you don't want to change your design (for some reasons), I ask you to make it optional, so that I can change the setting in the preferences.

I tried to change it myself, but I realized it would take too long for me to get into your code / into GTK.

thanks a lot!!
paul

[lazka]

Comment #14 originally posted by spxxxk on 2011-05-18T10:55:21.000Z:

Has comment 11 solution been excluded ?

The usability of it is also to quickly see where we are in the track without having to look at the current time and track length.

[lazka]

Comment #15 originally posted by nick.boultbee on 2011-11-22T22:46:40.000Z:

Issue #851 has been merged into this issue.

[lazka]

Comment #16 originally posted by goldencut on 2011-11-23T21:46:16.000Z:

I don't know much about programming, but it seems to be doable. There's a patch(ed version) of QL 2.2 in http://0xab.com/code/quodlibet.git. I'm using it currently instead of official (I'd prefer the official, of course). I downloaded and it works. It's buggy (well, maybe it's "featured") since volume scroll is backwards, volume bar is too short and the bars are not aligned (none of them actually bugs, per se) but to me the gain in usability is worth the discomfort of the "features". Maybe some of the code could be used?
IMHO the seek bar "feature", lack of 'folder auto-advance' (Issue #852) and no official .DEBs are the only things holding QL back from being the best audio player on linux ATM. IMHO, that is...

Btw. Thanks to Andrei for that patched version.

[lazka]

Comment #17 originally posted by reiter.christoph on 2011-11-24T08:20:54.000Z:

Unstable PPA: https://launchpad.net/~lazka/+archive/dumpingplace
Stable PPA: https://launchpad.net/~lazka/+archive/ppa
Unstable Debian Repo: "deb http://www.student.tugraz.at/christoph.reiter/debian/ quodlibet-unstable/"

[lazka]

Comment #18 originally posted by goldencut on 2011-11-25T20:11:18.000Z:

Thank You for the repo and PPA's. Debs work fine.
Hoped that the unstable would have the seek bar... ;P

PS. I'm not sure if it's OK to bring this up here but I'll give it a shot. So I'm still on that unofficial 2.2 with full seek bar and would like to go on to latest. I know nothing about Python, so... Can I just mess around with the .py files in the sub-folders and it should work (if I don't break the code) right there or do I need to compile it (or do some other magic)?

[lazka]

Comment #19 originally posted by [email protected] on 2011-11-25T20:55:57.000Z:

Messing around with files is sufficient. No compiling is needed. Just don't forget to relaunch application with each change, or find another way to easily update interface.

[lazka]

Comment #20 originally posted by [email protected] on 2011-11-25T20:57:10.000Z:

Messing around with files is sufficient. No compiling is needed. Just don't forget to relaunch application with each change, or find another way to easily update interface.

[lazka]

Comment #21 originally posted by joe.wreschnig on 2011-11-25T23:21:35.000Z:

The reason Quod Libet did not include this is because it notably increases ambient CPU usage.

http://kitenet.net/~joey/blog/entry/music_stuff/

I seriously doubt Python / GTK / PyGTK has gotten more efficient at, well, anything in the intervening years.

[lazka]

Comment #22 originally posted by joe.wreschnig on 2011-11-25T23:24:48.000Z:

(I'll restate that using the space identified comment 11 is going to ruin a lot of custom song info patterns.)

[lazka]

Comment #23 originally posted by nick.boultbee on 2012-04-12T19:51:05.000Z:

At the risk of reawakening threads (my long-standing issue with occasional but fatal crashing on use of the existing seekbar is partially motivating me here), perhaps there's still room for implementing this in a way that isn't too slow, or intrusive, especially given the apparent popularity of this issue.

I've done a quick and unscientific poll of Rhythmbox, Audacious 2, Totem, Clementine, gnome-mplayer, Exaile (all of which use some kind of constantly visible seek bar). For me they seem surprisingly low on CPU usage - whilst updating the seek bar and playing a flac (hovering around 0-3% CPU on a quad-core x64), but some better tests would be nice.

Anyway, assuming this can be done in QL, a fairly unimaginative possibility attached. Doesn't really qualify as "long", but note it does not jeopardise current track info area. Comments welcome...

[lazka]

Comment #24 originally posted by hirveklubi on 2012-04-12T20:41:48.000Z:

Hey man , don't mess with the holy "custom song info patterns"!

[lazka]

Comment #25 originally posted by ed.galligan on 2012-06-26T02:34:40.000Z:

I'm new to QM (installed it ~1 hour ago), and this feature (the hidden, dropdown time-slider) is the first thing I noticed.

Perhaps I will get used to it after a while - I do like the player overall, but the main problem for me seems to be with missing information - I can choose to see how much time has elapsed or how much remains, whereas typical always-visible sliders allow me to see both simultaneously.

On that note - perhaps a good compromise that would suit those looking to maintain low CPU usage and their custom song info patterns would be to just show both elapsed and remaining times in the UI in some (hopefully intuitive) way. This would certainly do me.

[lazka]

Comment #26 originally posted by [email protected] on 2014-07-15T03:34:02.000Z:

With the current configuration if the time slider is displayed it will always eat the next mouse click, and hide. Having the time slider always displayed would be an important enhancement.

[lazka]

Comment #27 originally posted by aifjdaoifjsdoif on 2014-09-17T00:59:07.000Z:

The codebase has changed too much for the above patch to work properly. Is there any possibility of someone with more intricate knowledge of gtk to update it?

[declension]

+1

[Moilleadoir]

As a new user it’s really surprising to find that this basic element of playback control is missing in Quod Libet.

OK, not missing as such, but certainly well hidden and inadequate. The current slider is not wide enough for any practical use in seeking. Compare Rhythbox (about 25% of the window), Clementine (> 50% of the playlist pane) or Audacious (75% of the window).

Of course, QL doesn’t _have_ to be the same as those programs, but not implementing something so common does make the program distinctive in a _negative_ way. It also limits users to using the program in a particular way. For example if I want to find a particular phrase in a long piece of music I’m definitely not going to choose QL to do it.

So is this issue effectively dead or is there a chance it might be implemented one day?

[declension]

Personally I'm in favour of getting this done (but have limited time currently).

Six years of discussions and trial patches hasn't really helped the bigger picture much...

If users shout and cry, we can revert it (or provide a config option)

[Jimi-James]

I desperately want this feature, and also a "moodbar" (i.e. a waveform-type view like in Clementine) as an option. Currently, seeking in QL is, frankly, awful with the current implementation, and the lack of some sort of moodbar/waveform option makes it useless for something that was so easy in Clementine: skipping through a large silent portion of a track to get to the hidden track at the end.

[timpulver]

Just tried Quod Libet and I’m very happy so far. Not having an all-time visible (long) progress bar is the only thing I’m really missing right now.
As @Jimi-James suggested having some sort of waveform view for seeking would be the ultimate thing. Soundcloud currently has the best waveform-seeking I know.

[pierregermain]

That would be awesome @timpulver

[pierregermain]

for the time-being what I do for seeking is to use these shortcuts:

quodlibet --seek +0:10
quodlibet --seek -0:10  

[timpulver]

I will go with scrolling on the time label/button. Only downside is that I don’t know where I am in the track.

[felixsanz]

Missing this feature much!

[lazka]

This is now in master, as a plugin.

[felixsanz]

@lazka awesome! thanks so much!

[spxxxk]

Awesome indeed, thanks !

Notes:

• Seeking steps using mouse wheel are not consistent between old and new seekbar (and I prefer the old one, ie smaller steps)
• It's weird to have two updated current length times displayed, old seekbar button and left of new seekbar. Maybe the old seekbar button could display the fixed total length time..
• Doesn't seem to increase CPU on my side.

Also, If someone happens to know the gtk code that affect that seekbar/progressbar color, I'd appreciate it.

[lazka]

Notes: [...]

Thanks, I'll have a look

Also, If someone happens to know the gtk code that affect that seekbar/progressbar color, I'd appreciate it.

.scale.trough.highlight {
    background-image: none;
    background-color: #ffbb00;
    border-color: #000000;
}

[urielz]

Excellent! Much better now.

[CreamyCookie]

Nice. The new version looks even better!

I think the only minor things left to improve regarding the design is the empty space (highlighted in yellow) and the time being displayed twice.

In the mockup below, those issues have been fixed, but it leaves a new empty spot there.

[urielz]

The icons at the bottom left of the window could be placed there, following the previous mockup:

[declension]

Shall we close this ticket now? There are in fact two versions of this now available (as plugins)....

[urielz]

It seems that pretty much everything raised in this thread is covered by the plugins.

[declension]

Great. Closing for now.

[sylvainfaivre]

for anyone finding this bug with a google search, the plugins are "alternative seek bar" and "waveform seek bar".