DcUpdater v2 Preliminary Flirtations

[Deozaan]

so the first grouping is separating everything into 4 categories depenging on update status.
then each of those 4 categories is organized by application name.

-mouser

Clear as mud!

-cranioscopical (March 22, 2009, 05:56 PM)

Makes sense to me...

[alivingspirit]

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.

-mouser (March 20, 2009, 05:48 PM)

Why not stick in an option to use the old one?

[mouser]

Let's try not to drive me insane just yet ok?

[Perry Mowbray]

Screenshot with some grouping enabled.

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 together
All 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)

-mouser (March 22, 2009, 05:20 PM)

That's looking really nice.

Would it be possible to have action buttons on the group header, something like Check All, Check None, Check Toggle?

[mouser]

Would it be possible to have action buttons on the group header, something like Check All, Check None, Check Toggle?

possibly.

[Perry Mowbray]

Would it be possible to have action buttons on the group header, something like Check All, Check None, Check Toggle?

possibly.

-mouser (March 22, 2009, 10:07 PM)

Actually, talking about checkboxes: there aren't any? 

[tomos]

Okay, that's clearer now
and you say "Note that grouping is purely optional" so if user applies grouping themselves, they're going to understand

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 together
All other "singleton" programs are grouped under the Uncategorized section.

-mouser (March 22, 2009, 05:20 PM)

You probably have this one covered or I'm still misunderstanding:-

in the screenshot in that post, would it not be more logical to have
Status: Needs Update
     [+] Applications: FARR
           Applications: GridMove
           Applications: Whatever

rather than
Status: Needs Update
     [+] Applications: FARR
     [+] Applications: Ungrouped

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

EDIT/ added status

[justice]

Are program versions not properties from programs?

• 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.

[justice]

Also the left panel has 2 goals at the moment:

• Finding the program you looking for
• Overview mode of the status of programs.

Ideally for the fist goal you would see all programs in one screenful (micro listing). For the latter it's found that people have trouble deciding between more than 6-8 choices.

How many programs have people installed that show up on that listing? the second panel will already be quite text heavy so perhaps try and keep the left panel uncluttered.

[mouser]

in the screenshot in that post, would it not be more logical to have
Status: Needs Update
     

• Applications: FARR

           Applications: GridMove
           Applications: Whatever
rather than
Status: Needs Update
     

• Applications: FARR
• Applications: Ungrouped

- 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.

[Perry Mowbray]

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.

-mouser (March 23, 2009, 07:05 AM)

NANY 2010? 

[tomos]

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.

-mouser (March 23, 2009, 07:05 AM)

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

[Perry Mowbray]

Not that I use it very often, but I like Software Informer's interface: It gives you a compact list with salient details, and expanded details at a click of the mouse.

[phitsc]

Hey, it's over two years since the last presentation of DcUpdater v2.

[justice]

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?

Hope that's useful