This is in jEmplode. I created a list named "Test" with the tag criteria, Artist and Source. The playlist was generated fine. I then deleted the playlist "test". It is removed from the list of playlists and everything looks fine. If I resync now or if I exit jEmplode and return the playlist "test" is back in it entirety. This is only in jEmplode as I never resynced when this playlist was visible.

I need to look more at your query ... I think the fact one of the "and" statement collapsed to an empty set means that it should have returned an empty set.

That having been said, you are also correct that refs is constantly changing and by being included in a playlist, it is possible you can setup a scenario where it actually then needs to be excluded from the playlist (and thus included again...). The saving grace here is that refs are real tags, and thus don't fire tagModified events when they are changed ... The more I think about this the more I think that soup membership needs to be idempotent .... I'll work on this. At the very least, jEmplode soups should be -- they should _appear_ to work exactly like they used to.

So to make sure -- "Test" is hanging off of the Empeg node of the tree, not off of the Playlist node of the tree? Is it the only soup you have? If you make another soup and delete the first, does it go away, or can you not delete any of them?

can you check your .jempegrc and tell me what the value of your jempeg.soup.count is? I wonder if you have the old soups in there and there's some problem ... I shouldn't have reused that variable...

Numeric fields like Position aren't right-justified any more (cosmetic)

"Set Playlist Order" doesn't put the tracks into exactly the order that's displayed. It seems to give a list that is in the correct order according to the current sort column, but shuffles items with equal sort key. This is annoying if I sort by several tags in turn to give a multi-level sort.

Interesting .. I'll take a look at that one ... I can't remember what sort algorithm that uses.

First problem I had -- I accidently added a soup list with no name, so only an icon shows up. I added it as a jempeg soup only, and it was simply a tag soup, by Artist.

Now I cannot delete that soup. It says it is deleting it when I right click and choose delete, but after a sync it reappears.

Cheers,
rjf&

I'll fix the no-name thing ... Can you tell me how many jEmplode-only soups you have and then look in .jempegrc in your home directory and tell me what the value of jempeg.soup.count is?

Sure. When I looked in there, the count was set to three. There were 4 soup's in the rc file, numbered 0 through 4.

However, in the UI, only the unnamed soup list showed up.

I deleted all the soups in my rc file, and restarted and all was fine.

rjf&

Not sure how to deal with this in a generic way ... On Windows, the default selector is very dark, so dark foregrounds make it hard to read there ... Anyone know of an easy way given an RGB value to determine if I should use a dark or a light foreground color?

Yes, convert the RGB to HSL (Hue, Saturation, and Luminance) and then look at the L value -- if it's above a certain threshold (i.e. bright), use a dark color, else use a light one.

I don't have the conversion handy, but a quick google search will find you what you need.

rjf&

The standard calculation of luminance is something like Y = (0.299*r + 0.587*g + 0.114*b). At least, that's what I've used in my own code in the past. You can do the calculation in integer arithmetic as Y = ((299*r + 587*g + 114*b) / 1000).

Perhaps for the selected node, we could simply invert foreground and background if it's a coloured or modified node? And use the normal highlight foreground and background (textHighlightText and textHighlight) otherwise?

Yeah, that looks familiar. Here is a link I dug up with a couple of alternative methods:

http://www.xbeat.net/vbspeed/c_RGBToHSL.htm

rjf&