|
VVV_Easy_Symenu Posts: 159
06/02/2016
|
Perhaps you can verify if there is an older version in _Trash\*.sps.bak folder.
|
|
|
link
|
|
sl23 Posts: 285
06/02/2016
|
edited by sl23 on 06/02/2016
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
07/02/2016
|
So you are speaking about SPS installed on your local PC.... I understood you need to know if an SPS non installed was totally new or only updated.
Changing the red icon for SPS already installed is quite easy because I already know if an SPS is available for update (last grid column) and if it is new (red icon). I only need to cross the information, but I can't understand what the real utility of this feature is. Maybe I have make the update information more evident?
|
|
|
link
|
|
sl23 Posts: 285
07/02/2016
|
Gianluca wrote:
So you are speaking about SPS installed on your local PC....
No! Not so important. In fact, seems completely pointless in light of my reason for doing so!
Gianluca wrote:
I understood you need to know if an SPS non installed was totally new or only updated.
Yes! Basically so we can see what apps have been added since last check. Currently, looking through the list of apps, there must be around a hundred NEW apps! Except they're not new, they're updates, or most are. The remaining apps are new to SyMenu, ie have only just been added. We need to differentiate between NEW and UPDATED apps.
Ideally, you open SPS Manager, click Get new apps SPS, see what updates are available and see what NEW apps are available. Wouldn't VVV_Easy_Symenu's suggestion of checking the previous SPS list work?
Incidentally, how long does this NEW overlay stay on any specific app?
edited by sl23 on 07/02/2016
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
07/02/2016
|
Probably it could be arranged in that way but you haven't the same a safe method to get this information.
What if you empty the trash?
Moreover if you regularly check for the new SPS with your second check, a previous totally new SPS will results as an updated one.
I should implement a more grained method to understand the whole history of an SPS going back with previous SPS backup but I can't read every backup folder and I can't open all the old SPS to rebuild the entire version history.
Well, indeed I can do it but it will result in a lost of performance. Even the simple check for an unique backup folder is a performance enemy.
Currently the new icon remains for 10 days since the last publication.
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
07/02/2016
|
I would like to explain easier with the sequence:
- the user presses the button SPS Update
- SyMenu makes the _Trash backup
- SyMenu download the new SPS files in _Cache
- SyMenu looks the updated apps -> Red icon
- SyMenu looks if the sps file is in "SyMenuSuite\_Trash\20160206-06.37.56.sps.bak" folder: If NOT -> Blue icon / if YES remains Red.
- SyMenu returns the focus to user.
The only inconvenient is that the icon is set each time the list is displayed, then emptying trash makes all apps new blue.
Solution: Change the behaviour "emptying the trash" always leaving the last backup SPS? -> More lost of performance.
Perhaps the only real good solution is to write the date of creation (first upload?) of the SPS app in the SPS file: If the date the creation is equal ( ten days) of the file date the Blue icon.
|
|
|
link
|
|
sl23 Posts: 285
08/02/2016
|
Yep, that sounds good plan
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
08/02/2016
|
Maybe the solution to write the creation date inside the SPS is the most consistent one. Unfortunately we already have a large SPS library that remains without a creation date so this solution is useless.
Considering the current condition, the solution to check inside the trash is the most effective because it immediately covers all the programs but it is extremely buggy.
Think about this scenario: the partially emptied trash is not a solution because if you check again for new SPS tomorrow and again empty your trash you'll have a red overlay that becomes blue because the item yesterday didn't exist, today exists (so it assumes the red overlay) but tomorrow it becomes blue because you check again the SPS and you'll find an old SPS.
Quite confusing....
|
|
|
link
|
|
sl23 Posts: 285
08/02/2016
|
Would it be possible to write inside the sps file if that data doesn't exist?
How exactly does the SPS Manager currently determine if an sps file is new?
Another possibility: How about a plain text file listing all apps and current version and/or date for the SPS Manager to check?
edited by sl23 on 08/02/2016
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
09/02/2016
|
An SPS is new if the modified date of the SPS physical file is within the 10 days.
In my opinion we can turn around the problem in whatever way but the problem is only one: every historical or statistical information about an SPS can't be included in the file itself, because it's by its nature an external data. The SPS is a way to only install and manage your program, not to create historical and statistical data.
When I read the file last modified date to give the user this "new" information I'm already stretching a lot the SPS nature. Do you want to know my thought? Doing this thing is wrong because infers an information on an accidental and different element.
As we - me and sl23 - already talked about, we can imagine a lot of services tied to the SPS historical, statistical, or grouped data: the number of weekly/monthly download for every program, the stars and the reviews from the users, suggestions about similar programs, about programs installed by users that already have installed a certain program, and so on. You can imagine that all the information available in any smartphone app store could be offered for desktop apps. It would be a revolution! Naturally the information about a totally new SPS or an updated SPS could be easily included.
Why am I speaking with hypothetical sentences?
Because the effort to transform the current SPS architecture this way is over my current possibilities.
I should rethink everything from SyMenu, to the SPS Manager and Builder, to the web site. I estimate an activity of 6/8 months, full time, to create all of this and unfortunately I can do it.
All this talk to justify my sensation about the new/update overlay.
In my opinion we can't entirely solve the problem with the current architecture and the effort to change the current architecture only to give the user a different overlay for the two SPS condition is too much. Unless someone's stroke of genius 
|
|
|
link
|
|
sl23 Posts: 285
09/02/2016
|
OK understood, too much work for such a simple change, not worth it. If you plan on implementing the App Store idea then add it with that, that seems more practical.
Sometimes it's difficult to understand why ideas shouldn't or can't be added when you're not a programmer.
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
09/02/2016
|
I made a little messy VBScript, without any guarantee, to show the "age" of the SPS app.
It has two operating modes "Trash folder" or "Creation Date":
- 0 Tabulations -> Not updates Apps (File DateLastModified out of the last 10 days)
- 6 Tabulations -> Updated Apps (File DateLastModified in the last 10 days).
- 10 Tabulations -> New Apps (File updated but not in _Trash folder or created in the last 10 days)
I hope it have some utility for someone. You can modify as you want.
Note: Perhaps the File Creation Date may be a good substitute for the SPS creation date and the today null file "20160209.sps.zip.date" could be the dates cache file for a filter buttons "Red New" and "Blue New" .
Edito: Script version V1 removed. New version down.
edited by VVV_Easy_Symenu on 13/02/2016
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
10/02/2016
|
I'm really impressed...
Why don't you think to create a plugin for SyMenu? You could include the logic from your script in a more consistent way for example inside a form. You could list the app with their icons and real names too and, if useful, metadata.
Anyway great work.
There are some little issues.
In SyMenu the 10 days range are considered as <= 10 and not < 10. Yes with this rule they becomes 11 and not 10... my fault.
The placeholder date file should be excluded from the final list. It's recognizable because its name ends up for "sps.zip.date" or because it's the only file with a 0 byte size.
As I expeted if you check two times for new sps you loose the information for new SPS in the Trash mode because the second trashed folder already contains all the new files. But it's impossible to workaround that with the current architecture.
Your second approach is more interesting.
Checking the file physical creation date instead of the modified date you have a further information that, incredibly, remains consistent.
I checked an SPS file and it preserves the correct creation date even if it's deleted and modified every time you use the SPS Builder to change something in it. It's counter intuitive but in fact it works. Windows sorceries...
I have to go deep in this but if it is reliable the direct implementation in SyMenu becomes possible.
I told you before... "Unless someone's stroke of genius"
|
|
|
link
|
|
sl23 Posts: 285
12/02/2016
|
Remove the button - Report a broken SPS - and make SPS reviewer clickable to report problems/updates.
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
13/02/2016
|
I modified the script (now, version 2) with the indications of Gian and contemplating the empty Trash situation.
Note: Gian thank you very much for your compliments. I really do not know very much VB even I have not compiler for make a dll for a plugin. I'm a programmer of the time of C ++ (not Visual Windows, of course) and the Z80 assembly !
edited by VVV_Easy_Symenu on 13/02/2016
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
13/02/2016
|
@sl23
Good idea. I'll put it on the TODO list
@VVV_Easy_Symenu
Thanks to your ispiration the different icons for new and updated will be available on the next version. I'm working on that exactly now.
|
|
|
link
|