I should confess that i have slightly mixed feelings about losing the ultra compact small icon grid display in the old version. But i think on balance it was a tradeoff worth making. If there is real uproar i could always bring back a short 1-line per row view which hides some columns or is usable only by people with huge monitors.

The idea here is that plugins are all grouped together.. If you are watching multiple version of a program (beta vs. stable), these will also be grouped togetherAll other "singleton" programs are grouped under the Uncategorized section.

Note that grouping is purely optional and wouldn't be shown if you are just checking for an update to a single application.(see attachment in previous post)

The idea here is that plugins are all grouped together.. If you are watching multiple version of a program (beta vs. stable), these will also be grouped togetherAll other "singleton" programs are grouped under the Uncategorized section.

If so, add a menu item to 'update to beta versions' for all programs under a view menu or to general preferences

Add functionality to open up the program to show which alternative versions are available for that program to download a specific version rather than the latest one.

If the 'update to beta versions' is ticked then the latest version is the latest version, otherwise its the latest stable version.

Program specific options should be situated in the right panel, as that shows the details for a program. (perhaps 'always update to beta' and 'never update to beta' which overide the general beta properties).

I think the grouping makes the program unnessecarily complex to be honest, even though its an amazing programming feat.

- if they are already grouped by status, why call the Applications (other than FARR) "Applications: Ungrouped"

i can see the confusion. the second level grouping would make more sense as

Applications: FARR

Applications: Other

basically what it's doing is giving a "folder" to anything with more than 1 item, and then putting all other singletons in the "Other" folder.

Let's not get too hung up on this grouping option -- i think i agree with the general sentiment that it just makes things more messy and hard to take the information in. it's main value will be when navigating very large listings -- perhaps if one were viewing potential applications that could be installed or something like that.

i can see the confusion. the second level grouping would make more sense as

* Applications: FARR * Applications: Otherbasically what it's doing is giving a "folder" to anything with more than 1 item, and then putting all other singletons in the "Other" folder.

Let's not get too hung up on this grouping option -- i think i agree with the general sentiment that it just makes things more messy and hard to take the information in. it's main value will be when navigating very large listings -- perhaps if one were viewing potential applications that could be installed or something like that.

okay, (not to get hung up on it) but in case you do go ahead with it -my point was that I thought there was no need to group at all at the second level (apart from stuff like FARR plugins). In fact I think it would just make it harder to see clearly

There are a few things that I think DcUpdater could do that I have stumbled upon whilst developing an app. I'm experimenting with downloading patches and applying these to the main program. From the perspective that dcupdater does not download the whole program, and also the related situation that you want to update from a specific version x to specific version y:

* You can currently append the current version number to the querystring of VersionFileRemote and serverside parse this and return a Version File suitable for the right upgrade path. Alternatively perhaps DcUpdater could support this better?* I'm hoping to have DcUpdater download a zip file composes of a .diff made with gnuwin32 diff utility and a bunch of .bsdiff's created with bsdiff (binary diffs), together with a patcher app. Perhaps DcUpdater could in the future support this better? This helps in my situation where I don't want people to download the whole app using just dcupdater and a .dcupdate definition.* Because of the patches scenario I have to check the base version and get the right patch archive - perhaps I want to run a checksum on a group of files and compare that with a checksum in versioninfo instead of using manual version numbers which are prone to errors (for example I might reissue a version because of a bug). Perhaps DcUpdater could in the future support this better?