|
tosiabunio Posts: 16
10/02/2018
|
App management is currently a nightmare. It's extremely slow and doesn't really help in the most frequent action which is updating the apps.
First of all, all definitions should be downloaded only once, when the app manager is open. There's no need to re-download them every time I do some action in the manager. Currently the definitions are re-downloaded every time I switch the suite, change filtering, perform a search, or apply the changes. Usually this means multiple download during each update session, each taking several seconds.
I should be able to switch suite tabs, filtering, or search almost immediately, as any modern application does, without additional annoying waiting.
I still don't understand how exactly update slider works. It seems that I need to do the same actions no matter how the slider is set, i.e. manually filter Updated apps for each suite and install them. The same for new apps. We definitely need a simplified update mode, which shows updated apps for all suites and allows to update them via a single click. Actually I would like to have this option for all updated and new apps.
There's no easy way to permanently exclude 32-bit (or 64-bit for that matter). Searching doesn't do much good because there's not option for apps not containing e.g. (x86). Even if it was, different suites use different standard - e.g. not marking 32-bit versions at all in case of having the versions available. Also there is another way of marking 32-bit apps used: x32. The definition should contain a setting informing the manager that there's 64-bit version of the app available and 32-bit shouldn't be visible at all. Currently I simply keep both version because that is easier, but this is just unnecessary clutter.
All those things make the whole experience bad. Can be something done to improve it?
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
11/02/2018
|
"App management is currently a nightmare" ¡Wow! I do not agree at all
BTW, I don't see many concrete suggestions only the increase the speed that I'm sure that we all agree but ¿how do that without penalize the portability (SyMenu use the Win standard .NET Framework 2.0)?
IMHO, there is two kind of SyMenu users:
"USB users": They make a Portable suite once at home and use it in not internet access enviroment (work, school, etc).
"Portable lovers": Even they have all the possibilities in his PC they prefers use portable apps.
Thinking in this two kind of users ¿Can you concrete your suggestion for have an opinion and try to help Gian to find the better solution?
For the second question: X86 and X64 apps. As App Publisher I know this problem and I can tell you what I do:
• Apps with one version: No (X86) or (X64) in his name.
• Apps with the two version in the same package: No (X86) or (X64) in his name but (X86) or (X64) in the SyMenu menu executable name.
• Apps with two versions in two packages: It can be separately installed, so (X86) and (X64) in his name and in the SyMenu menu executable name. If it is heavy resources Apps, for instance Avidemux or DBeaver, I only publish the X64 version because no user ask for the X86 version
With this information ¿what to do to distinguish X86 and X64 apps? ¿Put always in the name (X86), (X64) or (X86X64)? ¿It really worth? ¿How many time will last the X86 apps?
BTW, perhaps it can be helpful for you: there is a solution for users who change their environment in the Topic: Autorun 32 or 64 bit version of app
Note: Every App has his Publisher so if you have some suggestion over the app (for instance change in the name X32 by X86) I may advise you to ask the publisher kindly but do not offer money because he works for free.
|
|
|
link
|
|
tosiabunio Posts: 16
11/02/2018
|
First of all, I consider SyMenu to be the best portable apps suite there is. But this doesn't mean it's perfect. There's a lot of improvement to be made and we should discuss it. Of course the final decision belongs to the author - these are only suggestions.
VVV_Easy_Symenu wrote:
"App management is currently a nightmare" ¡Wow! I do not agree at all
Sure, you can have your opinion about that, but I will stick to mine.
VVV_Easy_Symenu wrote:
BTW, I don't see many concrete suggestions only the increase the speed that I'm sure that we all agree but ¿how do that without penalize the portability (SyMenu use the Win standard .NET Framework 2.0)?
Well, I don't think that current performance problems are due to usage of .NET 2.0, but are rather consequence of how the whole process is structured and how many times the definitions are downloaded.
I did a timing test. I wanted to know how long does it take to check for updated and new apps in all 3 suites I have installed. The whole process - just displaying the results, not downloading and installing - took me 2 minutes 12 seconds. During that time the definitions were downloaded several times unnecessary (it takes 20 seconds to download the largest definitions set).
- Start the app manager
- SyMenu suite is active
- Wait for definitions download
- Switch to Update filter
- Wait for definitions download
- >> No apps to update
- Switch to New filter
- Wait for definitions download
- >> No new apps to install
- Switch to NirSoft suite
- Wait for definitions download (small suite, faster download)
- No filter switch is necessary (New filter is active)
- >> No new apps to install
- Switch to Update filter
- Wait for definitions download (small suite, faster download)
- >> No apps to update
- Switch to Sysinternals suite
- Wait for definitions download (small suite, faster download)
- No filter switch is necessary (New filter is active)
- >> No new apps to install
- Switch to Update filter
- Wait for definitions download (small suite, faster download)
- >> No apps to update
- Done - the manager can be closed
This is a sequence of actions necessary to check if I have any updated or new apps waiting across all three suites I use.
There are no progress bars during those download times. Sometimes the end of download is difficult to notice if there's a filter active and none apps get shown - the message regarding the downloading simply disappears.
This is definitely an UX nightmare.
VVV_Easy_Symenu wrote:
IMHO, there is two kind of SyMenu users:
"USB users": They make a Portable suite once at home and use it in not internet access enviroment (work, school, etc).
"Portable lovers": Even they have all the possibilities in his PC they prefers use portable apps.
Thinking in this two kind of users ¿Can you concrete your suggestion for have an opinion and try to help Gian to find the better solution?
The first group isn't updating their SyMenu too often, so for them the complexity isn't probably an issue but they would definitely appreciate any streamlining of this process.
The second group is probably having SyMenu installed on multiple machines with entire suites installed and they want those apps updated regularly.
I definitely belong to the second group. I have SyMenu installed on 4 different machines and I try to keep it updated on them regularly. Currently this process is lengthy and cumbersome (as described above), especially if repeated on multiple machines.
I've been using portable apps for almost a decade now. For most of this time I had used LiberKey which handled the process much better:
I got notifications about newly added apps and I could decided if I want them added.
I got notifications about updated app (usually a list of those) and the whole process was reduced to a single confirmation click.
Such approach is definitely acceptable for both types of users but I understand that it's too big of a change at the moment so we should focus on improving what we have.
My suggestions:
1. We should reduce number of definitions downloads. Preferably to just one for all suites, of at least to one per suite. All other operations - filtering, searching, should work on already downloaded data.
2. It would be great to have a combined New and Updated filter with the ability to make it default. This way most of the time I would get the list I'm interested in most.
VVV_Easy_Symenu wrote:
With this information ¿what to do to distinguish X86 and X64 apps? ¿Put always in the name (X86), (X64) or (X86X64)? ¿It really worth? ¿How many time will last the X86 apps?
I think this information should belong to metadata instead of app's name. We should be able to specify that we prefer x64 app and work only with those if there are two types available (and with 32-bit if there's only one version). I understand that some users can have opposite preference.
VVV_Easy_Symenu wrote:
BTW, perhaps it can be helpful for you: there is a solution for users who change their environment in the Topic: Autorun 32 or 64 bit version of app
I do not want to see or download (and maintain) 32-bit versions if there are their 64-bit counterparts. That is waste of space and bandwidth.
VVV_Easy_Symenu wrote:
Note: Every App has his Publisher so if you have some suggestion over the app (for instance change in the name X32 by X86) I may advise you to ask the publisher kindly but do not offer money because he works for free.
Changing name is not a good solution - it should be handled at the manager level. But again, even if we had an uniform naming solution, there would be no way to exclude 32-bit apps permanently through search or filtering anyway.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
11/02/2018
|
Hello guys.
So many topics here...
For now I only want to explain the definitions update process.
SyMenu is an offline tool. When you configure your suite you don't need to download anything anymore.
If you want to remain updated you need the program definitions.
You can update your definitions automatically using a custom interval, setting the days slider. If you need to update only once a week, put it to 7 days.
Every suite has its own definitions. This is a thing I want to improve: one only suite containing everything with a better search. For now every suite needs an update every 7 days, if your setting defines this particular interval.
When your three definitions are downloaded, nothing more is downloaded for one entire week. Put on a profiler like Fiddler to check this.
The delay you experience when you change the current suite or use the filter is due to a slow disk device or a generic slow IO access because SyMenu needs to reload the definitions and read the zip file from the FS. FS access, not Internet.
This is another thing I can improve when the suites will be unified.
edited by Gianluca on 11/02/2018
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
11/02/2018
|
tosiabunio wrote:
I have SyMenu installed on 4 different machines and I try to keep it updated on them regularly. Currently this process is lengthy and cumbersome (as described above), especially if repeated on multiple machines.
In my home, I have a similar use. I can tell you my trick  : I update in the "principal" PC and then I synchronize with FastCopy the others machines (I made a little batch). It's posible use DSynchronize too.
|
|
|
link
|
|
tosiabunio Posts: 16
22/12/2019
|
With the size of SyMenu library, it still would be good to have the option to exclude 32-bit versions of apps that have both 32 and 64-bit versions. There's no way filter them out easily as they are not clearly marked (x86/x64 is sometimes used but not all the time). Any chance for such feature?
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
22/12/2019
|
It's impossible.
SyMenu distributes third party software and it's on the respective software authors to decide how to package their programs.
Anyway are you sure that the disk space could be a real problem today?
|
|
|
link
|
|
tosiabunio Posts: 16
22/12/2019
|
But this isn't a matter of changing anything regarding the packages - the package director needs the information whether the app is 32-bit or 64-bit and we need the way to filter out 32-bit ones for those that also have their 32-bit counterpart.
Actually space is a problem if you keep SyMenu on system SSDs. Currently, my SyMenu installation is over 45 GB and is by far the biggest part (besides the system itself, of course) and this is a problem for my laptops and even desktops where my system SSD is mere 250GB. Also SSDs don't like to be used at their capacity as this lowers their performance.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
23/12/2019
|
tosiabunio wrote:
the package director needs the information whether the app is 32-bit or 64-bit and we need the way to filter out 32-bit ones for those that also have their 32-bit counterpart.
Let's remove from our discussion all the programs that are already tagged from their authors and that we make recognizable with the (x86) and (x64) suffixes. These ones are already filterable and I think your problem is not on them.
We remain with two kind of programs:
- those ones that have both the executable in the same package;
- those ones that are compiled for a certain platform (32bit or 64bit) but the author doesn't specify which one directly in the program name.
The first ones are impossible to unpack correctly. Nobody except the author can know which are the subordinate files needed from one platform and the other. We can't reverse engineer every single program published in the SyMenu Suite. Remember that here you find everything for free and the contributors are all volunteers. These are the available resources so the activity you propose is too demanding
The second one will be theoretically viable but it represents an aggravation of the editing work that is senseless. Again everyone here work for free! We all have 64bit platform today, so who does care if the only version available of a certain program is for 32bit or 64bit? In so many years nobody asked me if SyMenu is for 32 or 64bit platform...
tosiabunio wrote:
Actually space is a problem if you keep SyMenu on system SSDs. Currently, my SyMenu installation is over 45 GB and is by far the biggest part (besides the system itself, of course) and this is a problem for my laptops and even desktops where my system SSD is mere 250GB.
Dear friend, with all my respect, your problem is not the way SyMenu manage its programs, your problem is your need for software.
My SyMenu installation is around 10GB and it's quite enough for my use.
I'm not saying that you installed more programs than you need, I'm just saying that your needs should suggest you to upgrade your disk.
|
|
|
link
|