New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show ~#rating as number in songlist #1381

Closed
lazka opened this Issue Mar 15, 2015 · 16 comments

Comments

Projects
None yet
1 participant
@lazka
Member

lazka commented Mar 15, 2015

Original issue 1381 created by J.Path95 on 2014-04-26T15:04:59.000Z:

In most places ~#rating is rendered as a number and ~rating as stars. Now it alsways bugged me, that that's not the case in the songlist. Therefore I made a patch, that fixes this misbehaviour.
However up to now the default rating column, which you can en- and disable through the menu is ~#rating, so people who update to a version with the patch will see there old columns with rating as stars now rendered as numbers, what might be quite surprising for some.
Is there an easy way to change all ~#rating columns to ~rating ones on the first launch after the update?

Also another effect of the patch is that all numeric values in the songlist will only display two decimal points. AFAIK that's done in other places likewise and in the search only two decimal points are significant.

This would also address http://code.google.com/p/quodlibet/issues/detail?id=972

Jan

@lazka

This comment has been minimized.

Member

lazka commented Mar 15, 2015

Comment #1 originally posted by reiter.christoph on 2014-04-26T19:32:11.000Z:

ML thread: https://groups.google.com/forum/#!topic/quod-libet-development/raUjfk6pvm0

@lazka

This comment has been minimized.

Member

lazka commented Mar 15, 2015

Comment #2 originally posted by reiter.christoph on 2014-04-26T19:52:04.000Z:

Solutions I can think of:

  • Change the config key and migrate
  • Add a global config version, increment on format changes and use that to decide if to migrate.
@lazka

This comment has been minimized.

Member

lazka commented Mar 15, 2015

Comment #3 originally posted by J.Path95 on 2014-04-26T20:03:13.000Z:

I'd prefer the second solution, because my config file seems to be already good populated with legacy options. I'll try to prepare a patch for it.

@lazka

This comment has been minimized.

Member

lazka commented Mar 15, 2015

Comment #4 originally posted by reiter.christoph on 2014-04-26T20:29:32.000Z:

Sounds good.

@lazka

This comment has been minimized.

Member

lazka commented Mar 15, 2015

Comment #5 originally posted by J.Path95 on 2014-04-26T20:42:55.000Z:

Couldn't you just test the quodlibet_last_active_version config for that?

@lazka

This comment has been minimized.

Member

lazka commented Mar 15, 2015

Comment #6 originally posted by J.Path95 on 2014-04-26T20:43:48.000Z:

Couldn't we just use the quodlibet_last_active_version config for that?

@lazka

This comment has been minimized.

Member

lazka commented Mar 15, 2015

Comment #7 originally posted by reiter.christoph on 2014-04-26T22:01:11.000Z:

That would break the setup of people using the unstable PPA / hg checkout I think

@lazka

This comment has been minimized.

Member

lazka commented Mar 15, 2015

Comment #8 originally posted by J.Path95 on 2014-04-30T13:33:28.000Z:

Here we go. The newly introduced infrastructure for config migrations should make it easy in the future to migrate things. Tests are also included.

@lazka

This comment has been minimized.

Member

lazka commented Mar 15, 2015

Comment #9 originally posted by J.Path95 on 2014-04-30T13:58:13.000Z:

Replaced my single quotes with double quotes to be consistent.

@lazka

This comment has been minimized.

Member

lazka commented Mar 15, 2015

Comment #10 originally posted by J.Path95 on 2014-05-02T15:04:25.000Z:

The attachment has both patches as an hg bundle, because the first patch got unapplyable.

@lazka

This comment has been minimized.

Member

lazka commented Mar 15, 2015

Comment #11 originally posted by J.Path95 on 2014-07-25T10:38:24.000Z:

Are you going to merge this? I am using this now for about two months and didn't noticed any problems.

@lazka

This comment has been minimized.

Member

lazka commented Mar 15, 2015

Comment #12 originally posted by reiter.christoph on 2014-07-25T12:36:55.000Z:

Sorry, missed this. I'll try before 3.2

@lazka

This comment has been minimized.

Member

lazka commented Mar 15, 2015

Comment #13 originally posted by J.Path95 on 2014-07-25T12:38:22.000Z:

Ok, thank you.

@lazka

This comment has been minimized.

Member

lazka commented Mar 15, 2015

Comment #14 originally posted by reiter.christoph on 2014-07-30T19:09:50.000Z:

I went for the version increment approach in revision 88854f2. Mainly for the reason that I don't want a dependency between the migration code and that migrations can happen at some later point in any order (plugins, browsers etc.)

For the tag change see revision 1735157 (+ some cleanup afterwards)

Thanks for the report and patches.

@lazka

This comment has been minimized.

Member

lazka commented Mar 15, 2015

Comment #15 originally posted by J.Path95 on 2014-08-01T10:01:39.000Z:

Awesome, thank you.
However if you don't define the order in which migrations should appear, that could lead to problems if one migration depends on another migration already being made. Probably without the author knowing that.

@lazka

This comment has been minimized.

Member

lazka commented Mar 15, 2015

Comment #16 originally posted by reiter.christoph on 2014-08-01T10:52:52.000Z:

Yeah, right, but in practice most keys are only used/managed in one place. So you can put everything related in one upgrade callback and define the order yourself there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment