10/01/2018 Topic: Import dialog ignores Folder Depth Gianluca Administrator	It is redundant only because you already know what you'll find inside the analyzed folders. The batch import purpose is to scan unknown folders to find something useful to link in SyMenu.
15/01/2018 Topic: Feature Req: New "Action Modifier" = "Uninstall" Gianluca Administrator	Indeed your second option already works even if it's limited to the SPS programs. Let's see the full procedure with its relative effects: - open the context menu - select the Action modifier - Configure Item - click on the required item (must be an SPS one) - the configuration form opens with the clicked item selected - delete the item from the list - save and close At this point the item has been logically removed but the related physical folder still exists on your FS. Anyway the first time you enter inside the Get new apps form, the orphan entries will be trashed from the file system too. Why does this work only for SPS? Because, normally, it's really difficult to determine if a folder and its related program could be removed from the file system. Case 1) Think about a program that has more than one linked item. The removal of one of them can't cause the automatic program uninstallation. A real example: I have several programs launched through the Java executable. So my main program is actually the java.exe executable and the real program is only linked in the command line. If I remove one of this entry because I don't want the program anymore, the system will remove the java executable and not the linked program. Case 2) I linked a regular program from my FS to a SyMenu item. With "regular" I intend an installed one. If I remove the logical item I don't want to remove the program and it would be even worst than the case 1) because a regular installed program can be removed only with a regular uninstallation. I don't know if we can have other cases but they are enough for me. Why can I remove an SPS instead? Because the SPS thing are almost under my control. I know where they are located, I know that they was installed by SyMenu, I know how many logical entries they have. This simplify the management of logical and physical objects. But guys, if you engage in this mission very hard, you'll find a lot of way to create misalignment in the SPS too.
16/01/2018 Topic: Feature Req: New "Action Modifier" = "Uninstall" Gianluca Administrator	@VVV_Easy_Symenu I don't like very much this solution because: - the new action modifier should have two different behaviors depending on the item. This kind of discrepancies are difficult to justify or explain to the user so I always avoid them in SyMenu: the gold rule is consistency above all; - the a) case, compared to the b) case, spares only a single operation to the user (the DEL key pressing) and it's a too little benefit to justify a full new action modifier implementation; - one rule we should follow to maintain consistency in SyMenu is that the context menu allows to do something (actions), the configuration form allows to do something but mainly to manage your menu (move, add, rename, delete, and so on). I don't intend to include managing activities in the context menu.
17/01/2018 Topic: Feature Req: New "Action Modifier" = "Uninstall" Gianluca Administrator	Even this way it doesn't work because we have inconsistencies at the UI level. When the user enters the configuration form, he doesn't know if a certain item is belonging to an SPS suite or not. He can recognize it only analyzing the executable path. In this case a different explicit action (uninstall vs. delete logical item) should appear according to its nature. It's confusing. You can assert that the two SyMenu behaviors towards the file system could be confusing the same (SPS case it cleans up, not SPS it leaves the program) but, at least, it's not a UI problem and it's an issue that remains unsolved with your solution too. Let's analyze your request from another point of view. Since the SPS introduction I noted that more and more users are approaching SyMenu because of the integrated applications (SPS). I received support requests from users that didn't have any idea that a custom program can be added or that a configuration form even exists. A normal user adds, updates and removes items only from the get new apps form. Because of this I'm starting to consider the configuration form like an advanced feature. This is the reason because I implemented the options form access, directly from the context menu too (you know that it exists, don't you? It's so handy...). I'm even thinking to remove the configuration form from the base contextual menu configuration, leaving it only for the expert mode or the custom mode. And this is the reason for which my recent developing efforts are so concentrated on the SPS instead of the other SyMenu fields. Thus if I have to choose among an UI and FS inconsistencies vs. a FS inconsistency alone, I prefer the latter, because, more likely, it affects an advanced user rather than a normal one that doesn't use the custom item but can occasionally use the configuration form (to move or reorganize its items). For these reasons I would leave everything as it is now. This is the action flow: - open the context menu; - select the new Action modifier - "Configure Item"; - click on the required item; - the configuration form opens with the item selected; - click on the keyboard DEL button; - click on the form Save button. From a logical point of view the item will be removed From a FS point of view we have two cases: - SPS - the first time you enter the SPS Manager form the system scans your items and removes the installed one from the FS if it's no more available as a logical item; - Custom - you remain with an orphan program, but it's not an easily solvable issue. I know that the second case is really annoying but I have a new idea to help the FS managing. We already have a tool that scans a folder and its subfolders searching for programs. It's the batch importer. I can implement inside it, a new search option to exclude any program already linked with a SyMenu logical item. Naturally an excluded item will exclude any of its subfolders too. The remain found items will be the real orphan programs and the programs linked in strange ways (as a command line argument for example). Anyway the number of elements to manage will decrease dramatically and helps a lot to maintain the FS aligned. Plus I can implement a function to open the selected folder directly from inside the batch import form. With the folder opened you can easily delete the entire program if it is your intention. What do you think?
25/01/2018 Topic: Update apps manually when SPS is not updated Gianluca Administrator	Welcome to the forum Baol. I'm extremely surprised how much you dig in this SPS thing. If you like this technology so much, I'm always opened to recruit new editors I will try to reply to all your questions and to clarify some little details you probably haven't considered. Yes it's true, there's life outside PC but there's a human being behind every SPS too. So if an SPS is outdated it's probably because the editor didn't notice this change. You have a link inside SyMenu that is called Contact reviewer. Use it to ring an alert to the editor. This is surely the main reason for which an SPS is outdated, but we have others. Some programs, starting from a certain version, have become shareware or subject to a fee. Since the SyMenu suites only host freeware software, we are forced to maintain the last free version and avoid any further update. There are programs that have a more recent version but without a corresponding portable version. We publish only portable programs. Some programs strongly use the beta channel to release their new version. And some of them never go official. We publish only official versions. Probably there are other reasons but I don't remember any other in this moment. You ask for a workaround. If the message to the editor doesn't work, the easiest way to workaround the issue is to create your own suite: https://www.ugmfree.it/SyMenuManual.aspx#CustomSuites Probably your attempt with the _CacheCustom folder comes from an outdated document you find somewhere on this web site, I guess the source could be this same forum... shame on me... I should clean up outdated thread. The right way to create your custom suite is creating a new folder at the same level at the other ones, and inside the new folder create a _Cache subfolder. Inside the _Cache folder you can add the original SPS grabbed from the zip. At this point you can modify the extracted SPS as you like for example using the SPS Builder, and, since it is located inside a custom suite, no one will change it except you.... but, man, you are almost an SPS editor at this point, so you can help the entire project taking care of that poor SPS for all the users. Another workaround is to move the SPS program directly inside the SyMenu ProgramFiles folder and add the corresponding item manually in SyMenu, and, again, no one will touch it. The SPS system is an extremely controlled system. This strict control puts SyMenu in charge for everything so the user can only choose to add, update, remove a program, all the other details are transparent. Obviously every attempt to force the system is treated as an anomaly to fix. Tell me if it's all clear and feel free to contact me in private if you want to speak in Italian
29/01/2018 Topic: Feature Req: New "Action Modifier" = "Uninstall" Gianluca Administrator	It's not hard to code, it's inconsistent. The action modifiers are born with others purposes in mind, so I'm a bit reluctant to add a delete/uninstall feature. It's a modification feature and action modifier is not suitable for that. Plus, as we have already seen, the delete/uninstall is an inconsistent action in itself, because it has so many different consequences according to the item you are dealing with. One inconsistency in a planned feature makes me ring the alarm bell, think about what are ringing in my mind in this exact moment that we have two Anyway I agree with you that going to the configuration form/SPS Manager only to remove an item is boring and since SyMenu is not a boring dog, let's think to another solution. Since we can't use the action modifier (well I don't want to use the action modifiers... it's different), the most obvious way would be to use the right click. In the Windows world the right click is something magical, you can use it to do anything you can't do in other way (the right one, the left click). Unfortunately the right click in SyMenu is already taken. SyMenu uses the right click as a cycler for the action modifier. And I don't want to change such a consolidated function. At this point our mouse has become useless and for this reason, the natural subsidiary, is the keyboard. We already use the keyboard in the contextual menu. We can select an item, execute an item, cycle the action modifiers (CTRL), change the search mode (F3), use the cursor keys to move the selection, use the letter keys as a shortcut to the items, hide the menu (ESC), show the menu (CTRL+F1). Probably the only thing we can't do with the keyboard is to pin the menu... and it's not intentional, because I love using the keyboard instead of the mouse. So my proposal here is to implement the delete/uninstall as a feature only available through the keyboard. The magic key could be the DEL one (CANC in my Italian keyboard but it's not a relevant topic here). Implementing the feature in this way, leaves it hidden from normal users but, since I'm not granted that a normal user doesn't accidentally press the DEL key, I strongly prefer, for a while, to implement it in an experimental way to check for your feedback. So you will probably have to activate this feature in the options form before using it. And I have to be sure of your intentions so prepare to be asked for a confirmation before every cancellation. I fear for the consequences of this new feature because it's a destructive one and because it's the first time a configuration is directly possible from the contextual menu. But I agree with you when you tell me that it should be very convenient. What do you think about it?
29/01/2018 Topic: SyMenu behaviour "Build in updater" apps Gianluca Administrator	Leave the choice for an SPS update or a native update to the users is a brilliant idea: a base user will allow the system to choose the best option for him, while an advanced user will choose independently the right option. The problem here is that a change at this level in the SPS system is so big. Currently the SPS Manager doesn't care about different versions among a program SPS and what the file system is telling, if it find the version placeholder file "0.00.sps.version". This file is the way the SPS Manager understands that it isn't in charge for updates. But I agree, it's not a perfect way. At the time of its implementation it was a fast system to solve the problem of the double updates (one because the program and one because the SPS). I have to think about a more flexible solution. Probably your suggestion is the right path even if I prefer an explicit choice per program instead of one for all of them. But, as I told you, I have to study it a lot.
31/01/2018 Topic: SyMenu behaviour "Build in updater" apps Gianluca Administrator	Unfortunately the version attribute is not used in a consistent way in all the programs. Some of them (Tor browser for example) use a shortcut that has no version inside. Some others use a laucher that never changes its version (Firefox launche is 2.1, the program is 58.0 instead). Again, others (SUMo) fill the file version attribute but leave to zero the product version. Others, such as the entire OK suite, use a version and declare another created combining the minor and build number (DesktopOk is 4.9.4.0 but the web site declares a 4.94). The program versioning is a real mess, well, BTW developers are all crazy... me too anyway , and for this reason is impossible to safely check anything from the program executable.
05/02/2018 Topic: SyMenu behaviour "Build in updater" apps Gianluca Administrator	Well sl23, It's a brilliant idea and easy to implement (these are the ideas I like more!). I haven't thought I can use the version file as a DB file even if it's a natural thing to to. And your approach to check only the size could work well if we only need to track the version information. Anyway a little detail needs a clarification. You said "when an app does auto update, the file has something written to it...". The question here is how is SyMenu supposed to be notified about a "private" update just happened? Because I presume SyMenu should be in charge to write something inside the version file after the program updates by itself.
05/02/2018 Topic: Advanced Parameters EnvVar. Gianluca Administrator	Yes definitely it's a possible bug. Anyway I should analyze some of these apps because your environment variables redefinition seems correct. I suspect these apps don't count on environment variable for the paths resolution. Can you give me a complete example? I need: - a download url to check the same program you are testing; - a list of all the folder full paths it creates without the env var redefinition - a list of all the folder full paths it creates with the env var redefinition To help you understanding which folders the program creates you could use Sysinternals Process Monitor. It gives you all the resources accessed by a certain process. Thanks
05/02/2018 Topic: thumbapps Suite? Gianluca Administrator	Welcome to the forum FlyingSheep. My approach with entire suites topic is lately changed and I would like to tell you the entire history. Let's start from the assumptions that the search tool in the SPS Manager can easily filter whatever you like. So if you want to filter the entire SoftwareOK suite, which is currently drowned inside the main SyMenu suite, you can search for "SoftwareOK" and you'll get it. The question is: why the hell do we still have two external suites (Sysinternals and NirSoft) if the search bar can replace them? Simply because the search bar is not so smart to support a suite filter along with a description filter. What if I need all the program from SoftwareOK related to the desktop managment? I can write "desktop SoftwareOK" or "SoftwareOK desktop" or even "SoftwareOK desktop pleaseee...." but nothing happens. Well it's another of my dozens of TODO entry. I need to solve it sooner or later. Second question: since the search bar doesn't work, why don't you add the Thumbapps suite in the meanwhile? You are even partner. Two reasons here: - adding a new suite is an huge job, I prefer to work on the search bar. When the search bar will be OK, I can add a list of predefined searches and, among them, the searches for the suites. So we will have more than three suites in an easier way; - in the SyMenu world a custom suite is a collection of original software and not a collection of generic software. Thumbapps doesn't produce original software but repacks freeware software. With this assumption the only suites I could add today are: SoftwareOK, Skwire Empire, IObit, SterJo, XnSoft, Piriform... Third question: why don't I add all the Thumbapps application to the main suite? Because I'm already overwhelmed by the programs I have to manage today (more than 500) and the other SPS editors are overloaded too. But, since the SPS is opened and anyone can become an editor, I'm really confidant that someone can take the Thumbapps programs on himself and create the missing SPS. It will be you?
06/02/2018 Topic: Advanced Parameters EnvVar. Gianluca Administrator	Well I don't understand. Did you solve it? If the problem is the lacking Roaming folder inside your redefined path, it's easy to workaround it and quite understandable. The puzzling thing is that when the program doesn't find the Roaming folder it writes its files on the drive root. The fall-back folder should be the usual C:/.../AppData/Roaming instead. Probably it's a program bug.
06/02/2018 Topic: Advanced Parameters EnvVar. Gianluca Administrator	BTW did you already try with the LOCALAPPDATA redefinition?
07/02/2018 Topic: Advanced Parameters EnvVar. Gianluca Administrator	Let's go deep to this topic using one of your example. According to my tests GlaryUtilities has a slightly different behavior than you described. If you add this environment variable: APPDATA=.\appdata it correctly uses the appdata folder inside the program root regardless the appdata folder already exists. In fact if it doesn't exist it creates it and inside it, it creates its own GlarySoft one. The problem is that it creates that same folder inside the C:\Users[user]\AppData\Local folder too. I think it's because GlarySoft is not a program but a complete suite of programs. Probably some of them inherit the environment variables from the launcher (which is integrator.exe) others don't. The general problem is that every program can adopt a different strategy to discover the system folders it needs. The common strategy they use, is querying the environment variables but which ones? If a program doesn't query the most obvious environment variables you are screwed. Examples I create a program that needs to resolve the folder C:\Users[user]\AppData\Local to write its settings. The obvious strategy would be to query the env var LOCALAPPDATA. In this scenario if SyMenu redefines the env var this way, LOCALAPPDATA=.\, the program will be forced to write its own settings right in the program root folder. Mission accomplished. But, as a developer, I could use a different strategy and I could query the env var USERPROFILE that resolves the folder C:\Users[user] Now I can manually add the missing path chunk (AppData\Local) and your previous env var redefinition won't work anymore. You should redefine the USERPROFILE env var but the problem is: how can you know what kind of env var my program is querying? I could even query for HOMEDRIVE (C:\) and HOMEPATH (\Users[user]) and, I guess, you will never have me. Beside that scenario consider that some environment variables are read only and can't be redefined. So if I use the SystemDrive env var I'll get C:\ and you can't redefine it not even if you start crying. Solution Forcing a program to be really portable, is not a new problem and we don't need to reinvent the wheel. We already have various portabilizer platforms, such as .paf, x-launcher, yap, LiberKey and others. Every platform works in a very similar way: they tracks the FS and Registry changes a program does and they rollback these changes when the program closes. If a program is not thought to be portable, this is the only way we have to force it. The SyMenu approach has others purposes and it's not intended to be a perfect portabilizer (for example we lack the entire Registry control). I hope this can enlighten the topic a bit more, and can explain why certain things don't work in SyMenu. So if you need an unruly program to be portable, please use a real portabilizer platform... and if you like share your work as SPS
07/02/2018 Topic: Advanced Parameters EnvVar. Gianluca Administrator	Well Glary is working differently on two of my PC too... and works differently even if I redefine the env var APPDATA... I am not the Glary's author and I can't understand how it works so the question is difficult to reply.
11/02/2018 Topic: Better apps management Gianluca Administrator	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
16/02/2018 Topic: Feature Req: Drag & Drop or Import .LNK/.URL files Gianluca Administrator	D&D works regularly. The problem is that the source (Windows Explorer) and the target (SyMenu) must run with the same privilege level. You are probably running SyMenu in elevated mode (admin mode) while Windows Explorer always runs with normal privilege.
16/02/2018 Topic: Improved layout ? Gianluca Administrator	Hi Eduard, Welcome to the forum. I always love when a new user arrives because it brings new ideas and, I have to admit, yours are great! Your solution to have the action modifiers as an extension of any item, in the form of a dropdown menu, is really smart. I have no objection to implement it. Probably it'll be technically hard to develop it but I'll do my best, because I like the solution so much and it allows me to extend the idea in the future. It's a good solution even because it expands the native action modifier tool without replacing it. The search bar you read about in the forum is not the contextual menu ones, but the SPS app manager one. A powerful search for SPS has been lately strongly requested by several users and it's a priority. Anyway I like your solution to split the contextual menu search bar from the results is brilliant. Some of the details you are suggesting are not feasible but I can implement the main concept.
16/02/2018 Topic: One thread for version updates Gianluca Administrator	It could be a valid approach but I like to have feedback from the users for every version. Probably a better solution could be to create a new discussion channel dedicated to the new versions, couldn't be?
20/02/2018 Topic: Feature Req: Drag & Drop or Import .LNK/.URL files Gianluca Administrator	Yes it should. It's probably a bug related to the D&D on the configuration form. If you try to do the same on the floating icon (D&D multiple program) does it work correctly instead?

---