This week’s update is a bit later than planned as I had a few other things going on and then got carried away in trying to finishing off the replacement library playlists support and getting it as bug free as possible (which is much easier said than done). So let’s get on with this update…
Making the library playlists support better is one of the things that I’ve wanted personally for some time and so is something that I can now really do as part of my work on the WACUP project. So the main focus this week has been getting my replacement working correctly as well as being equal to or better than the existing native plug-in which has involved a lot of time spent on getting drag and drop handling implemented.
Drag and what and why spend time on it you might be thinking. Well one of the things in ensuring that drag and drop works as well as possible is that it makes it easier to work either between playlists already within the media library or to make it easier to support adding a smart view to a playlist or in accepting files and folders externally of Winamp.
So by making sure (I believe I’ve covered off all viable usage cases) that it works, it should ensure that the replacement works as good as or better than the native plug-in especially as the replacement will try to fill in the blanks on some of the information that playlists make use off (which the native plug-in doesn’t and which causes some inconsistent information).
The next thing with playlists has been do with trying to resolve a few of the complaints that the native plug-in has against what people want / expect.
The first has been adding clickable playlist view columns so it’s now possible to sort ascending / descending by either title or duration.
The second thing is how the columns are sized which has been complained about many times. The native plug-in by design tries to act like the main playlist editor window in having the duration fixed to the right-edge of the playlist window. With the library playlist views this behaviour isn’t always liked and so I’ve emulated the default behaviour but when a column is manually resized then the manually set size will be used. This should provide a good balance between acting like the native plug-in vs following how the rest of the library views work (in using the size they are set to).
The third thing is something that has annoyed me no end over the years and I should have done something about it when I worked natively on Winamp is that it wouldn’t correctly remember the selection when sorting items (via the sorting options). This led to the issue in that the position of the selection stayed the same but what was seen as selected was wrong.
The replacement doesn’t have this issue (as per the screenshot above) and I’m happier with how this replacement works compared to the native plug-in (which would have have the selection like on the left but show the items in the order on the right which is obviously wrong).
There’s a few other layout tweaks I’ve made versus the native plug-in (in addition to the obvious side-view support) which I think makes sense which is an exercise for anyone bored enough to work out from the image above.
Moving onto other things, something that came up on the Winamp Enthusiasts group related to Windows 10 Anniversary Edition and Project Centennial which I don’t know how I’d missed hearing about until now.
This is basically a means to make classic Windows programs (oh for example like Winamp) and re-package them into something which is able to act like a UWP package which then allows for Windows store distribution or just better fitting in with what Windows 10 prefers.
There are some limitations to this in that despite it making a UWP package, it doesn’t mean that it will run on anything other than an x86 based Windows install. I’ve still to try out how well it works as from initial research there are a few things that with how Winamp works means some tweaking might be required (skin and plug-in installs won’t work like before) and there’s also an apparent requirement for the package to be code signed.
Anyway, there’s more that needs to be done to look into whether this makes sense (are the limitations of a fixed package worth it) or even if it’s viable (see below and whether a derivative work could even make it into the store).
Which leads me on to the next thing and the mess that is to try to work out the best and appropriate code signing certificate to purchase. This is something I’ve known I need to look into at some point for the benefit of the installer and also to give a better experience with UAC and elevation).
Unfortunately it’s not clear cut and the prices seem to vary massively from expensive to mind-boggling expensive and you must be kidding levels. So if there’s any suggestions from others who’ve need to deal with this sort of thing on a budget then please let me know. I appreciate that I will need to pay out on this but I’m not going to waste money that I don’t have.
So that’s this update of what’s been going on over the last week which is not the most exciting of updates but not everything with software can be at times :) Here’s a general summary of what was talked about:
- Getting the replacement library playlists support finished off (a lot of stuff!)
- Could Winamp + Project Centennial work, we’re yet to find out
- Code signing certificates are a mess, can you provide some help?