|
Deozaan
|
 |
« Reply #25 on: March 22, 2009, 06:09:23 PM » |
|
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. Clear as mud! Makes sense to me...
|
|
|
|
|
Logged
|
|
|
|
|
alivingspirit
|
 |
« Reply #26 on: March 22, 2009, 06:13:53 PM » |
|
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.
Why not stick in an option to use the old one?
|
|
|
|
|
Logged
|
|
|
|
|
mouser
|
 |
« Reply #27 on: March 22, 2009, 06:42:59 PM » |
|
Let's try not to drive me insane just yet ok?
|
|
|
|
|
Logged
|
|
|
|
|
|
Perry Mowbray
|
 |
« Reply #28 on: March 22, 2009, 10:06:48 PM » |
|
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)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?
|
|
|
|
|
Logged
|
|
|
|
|
mouser
|
 |
« Reply #29 on: March 22, 2009, 10:07:33 PM » |
|
Would it be possible to have action buttons on the group header, something like Check All, Check None, Check Toggle? possibly.
|
|
|
|
|
Logged
|
|
|
|
|
Perry Mowbray
|
 |
« Reply #30 on: March 22, 2009, 10:09:19 PM » |
|
Would it be possible to have action buttons on the group header, something like Check All, Check None, Check Toggle? possibly. Actually, talking about checkboxes: there aren't any? 
|
|
|
|
|
Logged
|
|
|
|
|
tomos
|
 |
« Reply #31 on: March 23, 2009, 03:33:58 AM » |
|
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.
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: Whateverrather 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
|
|
|
|
« Last Edit: March 23, 2009, 03:35:56 AM by tomos »
|
Logged
|
|
|
|
|
justice
|
 |
« Reply #32 on: March 23, 2009, 05:26:12 AM » |
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
justice
|
 |
« Reply #33 on: March 23, 2009, 05:34:17 AM » |
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
mouser
|
 |
« Reply #34 on: March 23, 2009, 07:05:24 AM » |
|
in the screenshot in that post, would it not be more logical to have Status: Needs Update 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.
|
|
|
|
|
Logged
|
|
|
|
|
Perry Mowbray
|
 |
« Reply #35 on: March 23, 2009, 07:17:48 AM » |
|
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.
NANY 2010? 
|
|
|
|
|
Logged
|
|
|
|
|
tomos
|
 |
« Reply #36 on: March 24, 2009, 07:00:51 AM » |
|
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.
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
|
|
|
|
|
Logged
|
|
|
|
|
Perry Mowbray
|
 |
« Reply #37 on: March 26, 2009, 08:02:50 AM » |
|
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. 
|
|
|
|
|
Logged
|
|
|
|
|
phitsc
|
 |
« Reply #38 on: April 15, 2011, 06:02:36 AM » |
|
Hey, it's over two years since the last presentation of DcUpdater v2. 
|
|
|
|
|
Logged
|
|
|
|
|
justice
|
 |
« Reply #39 on: May 25, 2011, 02:55:46 AM » |
|
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 
|
|
|
|
|
Logged
|
|
|
|
|