Hi everybody

Recently i started working on a little project together with amppa, creator of the 3rd party foobar2000 components website (more about that can be found here).
His website provides a convenient way to centrally store all available 3rd party components for foobar and also the functionality for an updater software to automatically find updates for your installed components.
Since right now there is no updater software available i thought this could be something fun and useful to code in my spare time.

At this point all major features are functional, so i thought before gluing together every piece i could ask the community a few questions about what it would prefer.
Please keep in mind that if this poll gets enough hits and the feedback is decent this project will be greatly influenced by all those who vote.

Voting guidelines
(PLEASE READ THE RED COLORED PART BEFORE VOTING)

This poll has 3 questions (as you probably already noticed), if you answer the first question with answer #3 or #4 then please don't answer the second and the third question at all.
If you vote some of the options that contain "(Please specify)", then please post why you've chosen that option, it's the only way for me to know what you think about this project.
The following are some detailed information about the poll options, please read them to be able to better choose your answer.

Please read [Automatic updater - How does it work?] (at the end of this section) to learn how automatic updates in Autoupdate mode will work.

(*1): Standalone mode, the updater will work just like any other windows application, to start it double click its icon.
After gathering some version information the updater will display a window showing you a list of available updates.
This window will allow you to: Directly download the component, copy the direct download link, go to the page where the component is available.

(*2): Autoupdate mode (described below), the updater will start foobar and once in a while also check for updates. If updates are found the same window mentioned above in (*1) will be displayed, showing you any available updates.

(*3): Autoupdate mode (described below), the updater will start foobar and once in a while also check for updates. If updates are found a small popup will be displayed near the system tray to remind you that new updates are available.
Clicking the popup will bring up the same old window mentioned above showing you available updates.
You can choose to ignore the popup, which will disappear after a few moments.
To get the updates you can run the updater in standalone mode or simply wait for the next update interval to happen.

(*4): In Autoupdate mode the launcher will be active not more than a couple of seconds, the time to start Foobar2000.
Only when started in standalone mode or when an update interval is over the updater will actually remain active until you chose to close it.

[Automatic updater - How does it work?]
In autoupdate mode, the updater will work like a launcher application.
That means, when you start the updater it will immediately start Foobar2000, then it will shutdown itself.
At predetermined intervals though, the updater won't shutdown immediately, instead it will gather your components' version information
and download the current list of available components. It will then proceed to compare them and show you any new updates available.
After this process the updater will shutdown. The aforementioned interval will probably be 1 or 2 days and can be manually set by the user.
This way it won't be necessary to remember yourself to check for updates, but also you won't have another piece of software running in the background without reason. Moreover it won't delay you from accessing Foobar (it takes a second longer, that's all). All you have to do is replace your usual Foobar shortcut with the updater shortcut.


Happy voting

EDIT: I am sorry, the the poll contains some bad typos, i hope you understand what they mean since i don't find a way to edit them.

Would be slightly nicer if it worked as as component itself.

I already have a feature request:
* Notify user about new components!

To be honest i thought the same at first, but since i never made any foobar components, doing so would have required quite some time learning how to do it properly. The choice was obvious
On the other hand it also has advantages, why load and keep running a feature you only use once in a while?


Great, i like feature requests!
I'm happy to inform you that i already have a similar idea in my todo list

But for now i'll concentrate on completing the application, there is still some work to do.
As soon as amppa gets those modifications on his data feed done, i'll do some live testing and from there a beta release won't be far.

I haven't voted, I just want to make a comment or two about the user interface:

1. Make it work, before you make it look fancy.
2. The standard Windows controls are compatible with screen readers. A custom control only provides the amount of screen reader support you add, and implementing IAccessible can be a daunting task if you have never done it before.

+1 for component rather than separate application

If you have basic knowledge of C++ it is actually very easy. There is a tutorial which demonstrates how to do it. The basis for a fb2k component with a menu entry is about 10-20 lines of code. Having your component do something on fb2k startup adds about 5 lines of code.

Resources are not an actual concern with this type of component. As long as you don't run any code you won't use the cpu and I don't see any reason why this component would need more that 50k of memory.


There's also one thing you should not forget: Unlike other with software, component versions are quite often not backwards-compatible and a lot of components are to be considered beta, so upgrading might very well introduce new bugs. Bugfix updates are the minority.
Updating will quite always need user interaction and manual tuning of new features etc.
This means: an autoupdate feature is actually quite useless, since you don't want to autoupdate after all. What would be quite usefull is an update finder.
Since you will have to spend some time checking the upgrades you won't want the UI to display automatically (except maybe for the few fb2k-fanatics who don't do anything else the whole day). You should notice the user that there are new upgrades (maybe through a popup, but better through a statusbar icon or something alike), and allow him to run the actual upgrading wizard any time he wants to.

Also note that a changelog compared to my current local version would be very useful, so I can see if I actually want to upgrade or don't care for the new features (in such a case an "ignore this version" (and maybe even an "ignore upgrades to this component") feature would be very usefull)

only small imho on "rather component" issue.

unloading and updating components after foobar comits to run can be imho quite hard to do wouldnt it? components probably dont have any control of main process and restarting foobar to load new components from inside foobar itself could be also tricky... but thats of course imho. i dont know what kind of control and access component have.

This is correct, but this is quite more easy to do than to get the component version numbers from outside foobar .
All you have to do is create a second process and then quit foobar. This should even be possible without a second file, but could rather be included in the dll:
http://simplesamples.info/Windows/Rundll32.php

Actually i don't like to build GUIs at all, i love coding windows services for instance.
This updater will never look like, say, office 2007. If my poll made you all think that i'm trying to make some sort of uber-bloated cool-looking wannabe then i'm sorry, that never was my intention


The updater was made using C# in VS2008 using FW2.0 controls only, so i think compatibility with most stuff should be available.


For all those who still hope to get a component:
I'm am sorry, i won't be able to do this, my spare time is limited and the last time i used C++ was like 10 years ago. I started this project because i was sure i could provide something useful in reasonable times with means i use everyday. Moreover the updater code is already working, the only thing left to do is working on the interface.
Purists will be concerned about this not being an ultra-light C++ coded component and TBH in some other cases i would share their concerns. In this case though, i'm pretty sure there won't be any issues, even if this isn't a 50kb memory footprint component. The application will run only for a very short period of time once in a while and it's not like you are trying to run it on a 486@66mhz. And it won't "pollute" your OS, installation will be a simple unrar/unzip, no strange files or stuff copied anywhere (You just need the .NET Framework 2.0).



Thank Chronial, i wasn't totally aware of this issue. A while back i discussed the "auto update" feature with amppa and also other problems (like trusting the uploaded files) made us decide that the "auto update" feature will only check for available updates and give you the means to download them directly to a folder you choose.

There won't be any interface you don't explicitly request through the options screen. That means that a systemtray icon is what is planed right now to notify the user in case of available updates while automatically checking for them. In the future a popup option might be be implemented, but right now it seems rather useless since there will already be the balloon tooltip on the systemtray icon.

The changelog feature sounds very interesting and could be implemented in the future.


Initially i also thought that could become a problem, but the .NET Framework provides the "FileVersionInfo" class, it is able to read all version information from any file.

I'm sorry, but I guess that won't help :/. The version is not stored as version information in the file (you can easily check that via right-click -> properties -> version tab (if it isn't there, there is no version information)).
Most components only declare their version with the DECLARE_COMPONENT_VERSION macro, which creates an instance of the class "componentversion" (found in componentversion.h) of the SDK. This class provides access to this information via its member function get_component_version().
Accessing this stuff from outside foobar is rather complicated, and you will of course also have to use the SDK. The component dlls export only one function: foobar2000_get_interface(). This function returns a linked list of service_factory_base. I guess you will have to traverse this list and find the componentversion service, from which you can then get the component version.
-> more complicated, using inofficial parts of the API, and you will still have to use the foobar SDK.

I still don't understand why people find this as desirable. It simply adds a slightly longer wait time to the launching of Foobar every time as most of the time it won't even check for updates. It makes complete sense to have the updater as a separate app that can be run on demand to find updates.

Can someone explain why they prefer the auto-foobar-launching-every-once-in-a-while-checking update method?

I understand what you mean fuller, especially since it's not like new foobar components come out every day.
Personally i think that if i would need to check for updates manually for every software i use, i wouldn't be able to remind to check them all regularly and miss them. I guess that's why most ppl like automatic updates.


Guess what, i found out yesterday...
The funny thing about this is that before starting all this i checked "foo_uie_vis_peakmeter_spectrum.dll" and it actually had a version tab, so the win function was able to retrieve the version.
Ironically it's the only component that has version stored the conventional way, guess i shouldn't rush and check better next time, before starting something.
I wonder why foobar doesn't use the conventional way of storing version info for components, though.
Even the foobar assembly uses the conventional way...

Anyway, under these circumstances i guess all this become rather useless, too bad
I'll see if i'll find the time to dig into some C++ when i'm on vacation next month...perhaps i can come up with something.


Thanks everyone for posting and voting, i appreciated it

maybe release sources you already got as some kind of libraries which could some c++ developer use to parse maapas pages and shortly get advantage of everything you already accomplished (under gpl maybe) could make this component live in short time

Well. Do people need to know from which version they are updating?
Checksums is a easy way to check is the file is the same (AFAIK).
The problems are "unofficial" betas and such though... (maybe a "ignore this" choice).

Btw. I just found the filehippo.com update checker and I like it's settings and the way it works. Check it out for some "inspiration" =P

You are right zachastrife, you could calculate the checksum of every dll but that could only tell you if the file is different, thus the updater couldn't see if you local version is newer (it could happen) and replace it with an older one. It also would require amppa to modify his website and add the checksum to every component.
Anyway this way of doing it would just be just wrong, i like to code as perfectly as i can

If the design is properly done, this would not happen. You should associate the checksum with the according version in the hosting db. Much like accuraterip you'll then be able to find the component this way, and check if a newer version is available.

Actually this opens up for another great feature: SHARING OF UNKNOWN COMPONENTS! That would benefit everyone: Devs that forgot to upload a component to fooPDate or components developed by another community etc. You could even make a upload feature to allow users to one-click upload unknown components.

Best thing is that everyone is immediately notified of any updates.

I'm sorry, but i don't see how this could help identifying the local component version.
Even if i know the remote version and checksum, it wouldn't make any difference.
Correct me if i'm wrong, but without the local version number there are only limited and uncertain ways of knowing if an assembly is newer or older.

That sounds a lot like a spontaneous idea that hasn't been thought through at all. It completely ignores copyright issues as well as technical problems. A developer may want to put restrictions on the (re)distribution of a component. Also a component may require additional DLLs or data files to function properly, and there may be other accompanying files (documentation, license, ...). In short, this is a bad idea.

For foobar2000 I personally don't need an updater but for the 3rd party components it would be very nice to have an app. that can check if you have the latest version. The problem of course is that it will be hard to keep that information centralised and up-to-date.
Auto-updating is IMO out of the question with foobar2000, as it has a history of breaking plugin compatibility. In such cases you want to carefully choose the moment you make the "switch".

I don't know if anyone here encodes video, but MeGUI has a nifty updater. You launch the application and it automatically checks for updates silently, for the core program plus every encoder and other component included with the program. I think that would be a nice updated for foobar, though that might be very difficult to implement (it'd need to only check what components you already have and stuff)

i voted "Not at all, there's no need for an updater" because v9.5.2 is the best version.

If you are still talking about getting the version number directly from foobar2000, then no - But why would you do that if you can check the other way round?