View Issue Details

IDProjectCategoryView StatusLast Update
0001640SUMoRefactoringpublic2013-01-13 00:25
ReporterpoutnikgAssigned ToKyle_Katarn 
PrioritynormalSeveritytweakReproducibilityalways
Status resolvedResolutionfixed 
PlatformNotebook Lenovo T400OSWindows XPOS VersionProfesional SP3
Product Version3.3.0 
Target VersionFixed in Version3.5 
Summary0001640: SUMO update check as the first operation
DescriptionI think SUMO update check should be performed as the first operation.

Currently it loads applications at startup,
then load them again during check.

After update check is done,
it finally check SUMO update and offer to download new SUMO.

It should be reversed.
TagsNo tags attached.

Relationships

related to 0001596 resolvedKyle_Katarn Autoupdate feature of SUMO itself 
related to 0001881 acknowledgedKyle_Katarn Indication of last scan / last check 
related to 0001565 resolvedKyle_Katarn Update + control for new apps 

Activities

bytehead

2012-07-20 20:35

reporter   ~0000971

Last edited: 2012-07-21 18:01

View 3 revisions

Fully agree, but how much time it usually takes for SUMo update check? If it's more than say 1-2 sec, maybe it should also notify user about such a process going on, e.g. with a small pop-up window with a Cancel button saying "Looking for SUMo updates...".

bytehead

2012-07-20 20:41

reporter   ~0000972

Last edited: 2012-07-21 18:02

View 2 revisions

Also, there must exist a max timeout, let's say 5-10 sec. If an update is found a user should be notified, if timeout expires -> an error message -> then continue as normal, if there's no new version -> *silently* continue as normal.

poutnikg

2012-07-22 15:09

reporter   ~0000974

I do not suppose SUMO update check timeout is an issue, it can be easily managed by reused code for SW item update check timeouts.

For such short time the Cancel button does not make much sense, IMHO.
If would have more sense, if there was implemented SUMO selfupdating,
as requested in http://www.kcsoftwares.com/bugs/view.php?id=1596

If SUMO is to be checked or not, is already set in Settings.

bytehead

2012-07-22 17:49

reporter   ~0000975

My point was that the idea of checking for new SUMo version *before* starting SW checks is good by itself, but I want to be sure this will not introduce any new noticeable delays before I can hit "check" and then switch to other tasks. Otherwise, this will not be an improvement of UX.

I use SUMo quite often on different machines and I've seen some software that does exactly what I'm afraid of here. So, regardless of what code will be used/reused for this function, if its timeout value is > 1..2 sec max, then I as a user would like to be notified that some "long" operation takes place and be able to cancel it if I don't feel like waiting this time around (permanently turning it off in the settings is not a good idea anyway). Although if its *always* less than that, then I don't care.

I agree with you on selfupdating feature though, this would be a very natural and welcome improvement. But it also needs to be implemented carefully, I mean it shouldn't be intrusive and get in the way of normal workflow, and in no case should introduce any noticeable pauses.

Imho, ideally SUMo should be able to do everything in the background, during Windows start-up or via script and then just notify you via balloon in the tray if it actually needs your attention (and only launch GUI after you click on it), otherwise just check and quit silently. It could also be done to autoupdate silently. And all this should be controlled via command line options. That's my dream... ;)

P.S. Filehippo is a great example of how it can done almost perfectly in this respect.

poutnikg

2012-07-22 17:57

reporter   ~0000976

Last edited: 2012-07-22 17:57

View 2 revisions

In my case SUMO always performs startup load,
which take much longer than any usual update check time out.

I agree notifying user, e.g. in status line, would be good.

OTOH if all operations are done, and SUMO realizes after that there is an update, all those operations ca be waste of time, as newer version could eventually do it better.

bytehead

2012-07-22 18:45

reporter   ~0000977

I don't argue on your last post's statements, although my biggest gripe with SUMo has always been that it requires too much attention from user as it is. It absolutely shouldn't. It should be made much more simple and unobtrusive to operate, it should be smarter, more reliable, more automated and scriptable in all respects. This is my ultimate goal, that's why I'm here. I plan on opening a series of formal bug reports to accomplish this eventually, step by step.

To recap, I agree on your general suggestion here.

poutnikg

2012-07-22 18:49

reporter   ~0000978

Last edited: 2012-07-22 18:51

View 2 revisions

I agree.
As a good startup SUMO should be configurable what of scan / load / check operations should be done automatically at startup without bothering user.

As another step these operations can be integrated into single operation.

Kyle_Katarn

2012-07-22 22:13

administrator   ~0000981

Right !

Kyle_Katarn

2012-07-22 22:14

administrator   ~0000982

Glad to see that you're both in line ! Sorry not to have so much time to implement as fast as you make suggestions. I'm the sole developper and i'm currently waiting for my 2nd child... i'll probably pause the update frequency for a few weeks in august.

poutnikg

2012-08-09 10:57

reporter   ~0001069

I wish good luck and health and happiness to the family.

Related to http://www.kcsoftwares.com/bugs/view.php?id=1596

0001596: Autoupdate feature of SUMO itself

as SUMO should first check the SUMO update ( if set so in settings ),
and eventually offer SUMO autopdate.

And after that is done, it would continue with other operations.

Kyle_Katarn

2012-08-09 23:54

administrator   ~0001075

Thanks !

Issue History

Date Modified Username Field Change
2012-07-20 12:17 poutnikg New Issue
2012-07-20 20:35 bytehead Note Added: 0000971
2012-07-20 20:41 bytehead Note Added: 0000972
2012-07-21 18:01 bytehead Note Edited: 0000971 View Revisions
2012-07-21 18:01 bytehead Note Edited: 0000971 View Revisions
2012-07-21 18:02 bytehead Note Edited: 0000972 View Revisions
2012-07-22 15:09 poutnikg Note Added: 0000974
2012-07-22 17:49 bytehead Note Added: 0000975
2012-07-22 17:57 poutnikg Note Added: 0000976
2012-07-22 17:57 poutnikg Note Edited: 0000976 View Revisions
2012-07-22 18:45 bytehead Note Added: 0000977
2012-07-22 18:49 poutnikg Note Added: 0000978
2012-07-22 18:51 poutnikg Note Edited: 0000978 View Revisions
2012-07-22 22:13 Kyle_Katarn Note Added: 0000981
2012-07-22 22:13 Kyle_Katarn Assigned To => Kyle_Katarn
2012-07-22 22:13 Kyle_Katarn Status new => acknowledged
2012-07-22 22:14 Kyle_Katarn Note Added: 0000982
2012-08-09 10:57 poutnikg Note Added: 0001069
2012-08-09 14:25 bytehead Relationship added related to 0001596
2012-08-09 23:54 Kyle_Katarn Note Added: 0001075
2012-12-29 19:15 Kyle_Katarn Relationship added related to 0001881
2013-01-07 01:04 bytehead Relationship added related to 0001565
2013-01-13 00:25 Kyle_Katarn Status acknowledged => resolved
2013-01-13 00:25 Kyle_Katarn Fixed in Version => 3.5
2013-01-13 00:25 Kyle_Katarn Resolution open => fixed