Colored Stars work, findings, comments, discussion, etc.

Gábor Lehel illissius at gmail.com
Wed Feb 21 18:53:05 CET 2007


On 2/21/07, Jeff Mitchell <kde-dev at emailgoeshere.com> wrote:
> Second:  while working on this I've fixed several bugs in the stable branch.
> Specifically, these relate to ratings not being updated everywhere when
> changed (they're now updated instantly in OSD, Context Browser, and Flat Mode
> collection view), as well as inconsistent usage of the values 1-10 and 1-5
> (as opposed to 0.5-5) for the ratings.  As a result of this last change, a
> song can now have a half-star rating, if it's *really* bad.  Some might think
> this doesn't make much sense, but the crucial thing is that we were mapping 9
> values onto a 10-value scale.  So if users manually modified the tag and set
> it to 1, it'd show up as a whole 1 star anyways -- exactly as if they had set
> it to 2.  But every other value from 3 to 10 resulted in its own star-value.
> This made even less sense, so I fixed this.  These bug fixes will be ported
> to trunk in time.

For the record, when I originally coded this it was 1 to 5 in steps of
0.5, with 0.5 itself intentionally omitted. I can't remember if there
was a reason for this other than personal taste... well, actually, I
can. When you click in the ratings area to set a rating, if you click
again (on the last star), it toggles it between a half and a full
star. If there's only one star, it toggles it between one star and no
stars instead, so you have a quick way to unset ratings without having
to resort to the tags dialog or the keyboard.


>
> Now to the meat.
>
> AFAIK, the major issue, more than the actual colors used, was the color
> consistency.  Stars in some parts of Amarok remained yellow, while in the
> Playlist they were colored.  This has been fixed, in a way that is fairly
> cheap, in the StarManager class.  In fact, whereas before some components
> would continually re-read the from the source files and convert them to
> pixmaps, this is now done once, allocated on the stack, and pointers to these
> single instances of the stars are passed around.  Even if the colors go it
> may be worth keeping some part of this paradigm to make things cheaper than
> they were before.

Good idea. I don't know where else stars have spread to since, but
when it was still restricted to the playlist, I remember I took the
same approach (though it didn't require a separate class -- just
pointers).


>
> The next major issues were both addressed the same way (this part is not
> complete yet in the source code).  Adding two sub-options to the Use Ratings
> checkbox allows users to either turn off the colors and use the defaults, or
> choose their own.  As I mentioned earlier on the mailing list I have what I
> feel is a fairly elegant way of doing this.  Although I'm having issues
> translating Qt Designer to actual running Amarok, this mockup from Designer
> shows what it would look like:
>
> http://img340.imageshack.us/img340/1282/qtdesignerdr3.png
>
> The "Use custom colors" as well as the pushbuttons are only enabled when "Use
> ratings" is checked (and the pushbuttons only enabled if "Use custom colors"
> is checked too).  Each of the groups of buttons will each have a pixmap of
> the star (where the Qt logo is now), colored with the currently chosen color
> for that rating (the second single button is for the half-star).  Clicking on
> any of the buttons in a group will bring up a color chooser for that rating.
> Chosen colors will be reflected immediately in the dialog.
>
> As you can see, a system like this would allow the flexibility that users and
> devs previously expressed wanting in a colored stars feature, so that it can
> be adjusted to work with any color scheme.  The drawback, which some devs
> always have an issue with, is that it requires more configuration options.  I
> think that should we wish to allow these options that this is a fairly
> elegant way of doing it.  The question then becomes whether we should allow
> these.

I don't have a problem with having these options -- I don't like the
colored stars myself, but if others do, I see no reason not to have it
both ways. I just don't really like the placement of it: these are all
fairly micromanaging options, not the sort of thing the front page of
the configuration dialog is meant for. One solution could be splitting
it out into a separate dialog, opened by a button next to [x] Use
ratings. (This could also be employed for Moods).

>
> In 1.4.5 Mark added a feature to make new playlist items colorized.  However,
> because of similar problems -- that is, issues with the colors clashing with
> some color schemes -- an option was added to allow the user to change the
> color.  I didn't hear (on the list) any complaining about this, but I
> wouldn't have expected it, because it makes a lot of sense.

All this colorising stuff isn't to my taste (neither in Kate), but
again, I'm not going to stop anyone else :-).

>
> I don't see why this is any different -- or rather, I think that any option
> that involves color will inevitably require a way to change what colors are
> used because of wildly varying color schemes by different users.

This I heavily agree with. I used to have a white-on-black color
scheme and getting everything to mesh with it was hell. (And there's
also a default white-on-black color scheme included with KDE for
accessibility purposes, so that shouldn't be ignored either).

>  I think
> that having the varied stars is a good idea; many of you expressed the same;
> many users did too (I don't actually remember hearing any opinions that the
> idea itself was bad, only that the previous implementation had issues).  So
> it makes sense to me that it would require a way to define the colors, the
> same as for new playlist items.  When you look at it this way, the only
> real "option" being added is the ability to turn the colored stars on and
> off.
>
> I look forward to comments, questions, suggestions, etc.
>
> --Jeff
>

One idea I've been having on and off, is with all these styling
options available in amarok now (context browser, icon set, colors,
potentially pixmaps for stars & volume slider, et al), we could
package all of these together in "amarok themes", via knewstuff. Maybe
split all of it out into a separate page in the config dialog.


-- 
Work is punishment for failing to procrastinate effectively.


More information about the Amarok-devel mailing list