Week 35 + 36

It’s been a while since I’ve had to double up on one of these updates and those following along closely enough will have noticed that I missed the end of September for providing the first WACUP beta. The last 2 weeks have been a bit up in the air due to family IT support duties and more importantly health issues that my better half has been having and so understandably that all has had an impact on my focus and normal routine to get things done (waiting around for doctors and hospital appointments isn’t fun).

So I hope it’s understood why I’ve missed the end of September date I’d mentioned previously and instead just posted a link to the development changelog as something for last week’s update on social media. Now onto what was done which if you’ve been able to work out the development changelog differences will not be all that new to you …


The first thing came about from work done in the last update with playlists and the fixes for keeping the correctly selection when sorting within the library playlist views. This led me to have a look at the rest of the library views as now I’ve got my eye on this issue I’m seeing it all over the library views (and am wondering why no one, myself included) ever did anything to fix it assuming it was reported (part of me thinks that ujay from the forums would have done that).

The end result of this is that I’ve fixed the issue within my replacement podcasts plug-in (as I’d missed it during testing) and have created a replacement library downloads plug-in (which is only really used by the podcasts plug-in and so may end up being merged into the podcasts plug-in to reduce code duplication and providing what’s needed as a single plug-in instead of two and their overheads).


The above sorting and selection handling issue has also led to my completion of a replacement library history plug-in which I’d started on a while back but hadn’t done much on it to get it feature compatible to the native plug-in along with it not having some of the niggles I’ve had with the native plug-in (mainly trying to minimise persistent memory usage along with the sorting and selection fix).

The reason for doing this and why I’ve included my tweets from the time is that the generally better way to provide lists of data that are fast with large data sets is to use ‘virtual’ listview controls. Unfortunately this mode causes the selection (if present) to stay where it was when sorting happens as the UI and the data behind it aren’t linked.

So to get around this, the existing selection and some unique identifier is used which then helps post-sorting to be able to select the new positions of the items. I’m still not sure this is the correct way to get the desired end result but it’s working and sometimes that’s all you can ask for.

Due to how the existing plug-ins work, it’s not been obvious how to attribute a unique identifier to the displayed items in the list and so it’s led to the creation / fixing of more replacement library plug-ins so that internally there is a unique identifier associated with the displayed items to allow for the sorting with a selection to work correctly.


This now just leaves the following library views with the sorting with selection issue:

  • local library views (as provided by ml_local.dll)
  • portable device views (as provided by ml_pmp.dll)
  • CD/DVD views (as provided by ml_disc.dll - I don’t have it installed due to not having a CD/DVD drive anymore but I would assume it would have the same issue)

Of the three, the local library views are the ones that I think should be fixed sooner rather than later which would involve looking into making another replacement plug-in (unless I can somehow just override the whole view and query the local library database directly but then it might be simpler to just write a complete replacement as I’ve briefly talked about before).


Moving on to other things, there were a range of minor bug fixes and shared library updates. The most notable small bug related to the library window and the F6 and F8 actions weren’t working. Pressing F6 in a compatible view will focus and select the current search field whilst pressing F8 will cause the current library view to be refreshed without having to manually select another view and move back.

These keyboard actions were unfortunately broken by some of my library window overrides but thankfully turned out to be simple fix by re-ordering some logic in my override code for the window.

I’ve also done some work on the podcasts plug-in to work out some of the usability issues I’ve seen with my replacement as well as making it re-update things a lot less often than it was doing from the initial implementation (which was to just get something running and then optimise a bit later once I’ve worked out what the issues with it were).

With going back and forth between the replacement and the native plug-in, I’d not realised until now that the native plug-in will reset the selection in the episodes list when you click back on the podcast list. This just seems like a weird thing to be doing and I guess there must have been some reason behind it but it’s definitely not a behaviour I’m replicating in my replacement podcast plug-in.


The next thing to cover is some additional work done relating to library playlists which has been an on-going thing for the last few weeks.

The first thing has been changing the delete behaviour so that now any removed playlist (our managed copy or an external file) will always go to the recycle bin. Before this was only being done with external playlists but doing it for all cases makes sense as despite a confirmation prompt, it’s better to be safe than sorry and not physically remove the playlist.

The second thing is related to deletion and whilst testing the above change, I added an option for external playlists (i.e. the original playlist) so that deleting from the library playlists just removes the reference and will leave the actual playlist where it is. I’ve made that a default behaviour partly to better cover myself against data loss (which the first change also helps) and it’s probably a saner behaviour to go with overall.

external_playlists_column.png

The third thing has been the addition of an extra column to the library playlists root view (as above) which indicates if the playlist is an external playlist or if it’s a managed copy. This can be hidden by sizing the column to a zero width for those not liking it but I thought it could be useful when using a mix of external and managed playlists to see what is what.


The next thing with the playlists support and worthy of it’s own sub-section has been recording when importing a playlist where it originally came from. This is intended to make it possible later on to check for changes between the managed playlist copy and the original source of the playlist (assuming that it still exists) which has been a long standing complaint against the library playlist support so that it could be possible to re-sync between the two.

I’m also hoping that this will eventually allow for some more playlist specific handling when loaded into the main playlist editor (e.g. some form of remembering what was last being played from the playlist as long as it’s not been modified). This still needs a lot more research / thinking about the problem but having the origin of the playlist is better to have than not.


Moving onto the next thing, back in week 29 I covered how I’d creating a new plug-in which is a combination of the existing global hotkey plug-ins I’ve previously provided which I’d decided to call ‘Global Hotkeys Extra’.

At the time I was already thinking about it being better if there wasn’t even the need for this new plug-in and instead having it all done via a single hotkeys plug-in. Additionally one of the things that I’ve wanted with the playlist file remover (PLFR) plug-in was for it’s configurable hotkeys to work as fully live edits without needing to restart Winamp. So I’d briefly started on working out what was needed to get a replacement coded and had been slowly working on it when the urge took me (which is why I’ve not really mentioned it until now).

Well I’ve now finished off a replacement global hotkeys plug-in which adds live removal support of a registered hotkey which I’ll have to add support for into PLFR . I’ve not yet merged the hotkeys from ‘Global Hotkeys Extra’ as a few have their own config options and I want to provide a means so it’s possible to access that from within the normal global hotkeys preferences page instead of via the plug-in type’s config button action.



The penultimate thing is one of those weird ones that came to mind during Sunday night when I was going over the podcasts that had been downloaded over the weekend. What I wanted to know was what the downloaded file was about and I didn’t want to have to look in the podcasts view and select the file(s) to see what the associated description is.

So me wanting to save a few clicks led to causing me more coding and ended up with a tooltip on the downloads view as well as the podcasts view where if an in-file comment (if available) or the podcast description will be shown without having to always click the file / feed item to see it. The end result is something like the following:

downloads_tooltip_love.png

One thing I have found with the testing of this tooltip addition is that not all podcast downloads have the comment already set within the file’s tag. So I’m tempted to add it into the downloaded file’s comment tag field if a comment tag is not already present. Then thinking the idea on further, this could also be expanded to some of the other default tag fields as sadly not everyone seems to properly tag their podcasts.


The final thing is that at the start of week 34 I’d started on getting a patreon page setup though I’ve yet to finish if off as with how these update posts can ramble on, I’m trying not to do that with the information on the patreon page but it’s really hard :)


So that’s it for this combined update which now I’ve done it, I hadn’t realised how much I’d managed to get done over the last 2 weeks with everything else that’s been going on. Here’s a general summary of what was talked about:

  • Target date for first beta missed due to real life
  • Fixing the library view sorting with selection issues isn’t easy
  • Library history plug-in replacement created
  • More library playlist work such as to not really delete playlists & to track their origin for later possible features
  • Global hotkeys plug-in replacement created to help with the Playlist File Remover plug-in and more
  • Using tooltips on the podcasts and downloads views to better see what the download / podcast is about without clicking on everything first
  • Fixing minor bugs and maligning native podcast plug-in design decisions
  • Preparing a patreon page but it’s not yet finished as I ramble too much

-dro

p.s. There are a few comments on some of the older blog posts that I’ve still to fully reply to which will be done over the next day or so (aka I’ve not forgotten ;o) ).


Comments:

  1. Hi DrO,

    Thanks for all the great work, I can’t wait for the beta.
    Playlists: Something that would be great in the playlists are the ability to customise the visible columns (both visible and the display sequence), Would it be possible to easily add this type of functionality everywhere it makes sense?

    ie. have the ability to hide the external column in the playlists root view, or move it to be the first column.

    Regards

  2. Schalk: Complete customisation of things is the eventual aim (as per https://getwacup.com/blog/index.php/2016/07/07/library-playlists-looking-for-ideas-for-its-replacement/) though. Hiding columns is possible with my replacement as i’ve replicated the auto-resizing behaviour of the native plug-in but have done it so as soon as you change the column width then that is what is used which makes it possible to hide columns or force a fixed size whilst keeping some that will just fill the rest of the space.

    Coping with column re-ordering is something I think should be simple enough to do, is just how to ensure the auto-sizing aspects work could be maintained (as it’s done against a fixed order assumption). Definitely something I’ll want to look into as I’ve had a few times where I wouldn’t mind having it myself :)

    For the actual library view itself, it’s going to happen later on having them able to be more local library like but for the moment I just want to have the basis of the replacement working correctly before adding the bells and whistles for the view changes :)

  3. “One thing I have found with the testing of this tooltip addition is that not all podcast downloads have the comment already set within the file’s tag. So I’m tempted to add it into the downloaded file’s comment tag field if a comment tag is not already present. Then thinking the idea on further, this could also be expanded to some of the other default tag fields as sadly not everyone seems to properly tag their podcasts.”

    Please do this! I think that I mentioned in a prior thread (or email or something) how not all metadata would be downloaded to the file with the native podcast plugin. I know that you mentioned that the problem with probably be fixed with your new version, but this would take it one step further to being better. It also MIGHT be a good idea to include functionality to turn this feature off if you do not want metadata assigned automatically. So maybe a checkbox that says “Assign metadata from feed if not present” Or something like that. Hard to imagine but some people might not want the feeds original data altered.

  4. Juanus: Done :) So if enabled (will be by default) it will fill the following tag fields (subject to file / tag support) only if they are not found:

    title (episode title), artist (feed name), genre (just set as ‘podcast’), year (using published date information) & comment (episode or feed description depending on what is available).


Add comment:

Fill out the form below to add your own comments