02/04/2024
Topic:
SyMenu 8.01
sl23
|
Ok, yeah, when you put it like that, it sounds like a good plan!  |
25/04/2024
Topic:
Who (the hell) are the SyMenu users?
sl23
|
Will that limit backups? eg. I have a main SyMenu on D:/ which is backed up on E:/ But then I have a second version on E:/ for apps not used much, like CCleaner, Minitool Partition Wizard, etc.Which is also backed up.
So I have one on D:/ Two on E:/ Those two are also backed up On F:/ And just to be sure, These are also backed up further onto a USB Stick. Seven versions of SyMenu in all, although some are just copies of others as they are merely backups and not new instances. But would that count as more than five?
Gets a bit complex looking at it that way. Hopefully the version on D:/ backed up onto E, F and G:/ counts as one installation as it is an exact copy? Same with the other version on E:/ backed up to F and G:/ meaning I actually only have two instances.
How would that work exactly? |
30/04/2024
Topic:
Who (the hell) are the SyMenu users?
sl23
|
How about creating a branch or 2nd profile? Using one main version but having different profiles available? For example, for the two versions on E:/ each would have their own profile. I could copy one to D:/ and have both backed up on F:/ allowing me to then also use a separate version on my laptop. That then gives SyMenu more functionality whilst keeping it tied to a single account and allowing more versatility.
Over the years, I have tried several different configurations that suit me and this current setup is the best yet. I really do not want to have all my apps in one SyMenu as It becomes distracting. But, of course, many are very useful in certain circumstances.
Anyway, just an idea I thought may help  |
11/05/2024
Topic:
Who (the hell) are the SyMenu users?
sl23
|
Well, if the number of duplications is high enough to allow for circumstances such as mine, then I'm happy for it to stay as is and forget the profile idea. It was just a suggestion to see if that suited your idea of dealing with this issue.  |
25/07/2024
Topic:
Placement on Windows taskbar?
sl23
|
If you go to the SyMenu root folder, drag and drop the SyMenu.exe to the taskbar, doesn't that do what you want? |
05/02/2025
Topic:
öneri;
sl23
|
Are you close to giving up on SyMenu? That would indeed be a real shame, perfectly understandable, but a real shame! Just sent a donation! I should do this more, I am so forgetful, apologies for that. You're efforts are so appreciated by myself and I'm sure others. If you do decide to finally give it up, I can appreciate the why. Don't feel bad either! You've done some amazing work here! Thank you so much for every single ounce of effort you have given to this project 
edited by sl23 on 05/02/2025 |
05/02/2025
Topic:
SyMenu 8.05
sl23
|
Thanks for your continued work! |
05/02/2025
Topic:
SyMenu 8.06
sl23
|
Thanks again  |
05/02/2025
Topic:
Non SyMenu apps - Update them with Rainmeter skin
sl23
|
Not sure if anyone here would be interested, but if you like to use Rainmeter, I designed a skin for it that is similar to the PublishedAppTrack. It needs some user setting up, so isn't a one stop fix for everyone I'm afraid. All the instructions are on the skins' download page.
Basically, you set the RegEx requirements used to search a web page. It checks for a version number and a download link. Personally, I find it easier to use than PAT and it shows a visual indication of whether the app has an update or not. The download button will download the latest version.
There is a limitation of this functionality though. It doesn't work with pages using javascript. Like some of my examples, you may be able to get only a version info or download link but not both.
Anyway, I just thought it may be useful here as many people here likely use apps not included in the SPS ecosystem. |
06/02/2025
Topic:
Non SyMenu apps - Update them with Rainmeter skin
sl23
|
Yeah, it can be used to check for any changes on a website. So it's limited by your imagination only! and of course, lack of javascript support!  |
07/02/2025
Topic:
Merged my 2 SyMenu's into 1. Now use Rainmeter...
sl23
|
I had two setups for SyMenu. One for my main daily most used apps, and a second installation for every other app I use, however rarely. It worked well for about three years or so. But recently, I found it becoming a chore to keep both up to date, backing each one up, managing two separate SyMenu's was a bit annoying.
I started this as I got fed up having all apps merged in one menu. As apps I rarely use, just got in the way when looking for an app I wanted.
Now I've gone back to basics, set up one menu and coded a Rainmeter skin using a shortcuts folder to launch apps. It's not quite finished yet, in fact, I'm adapting an older skin to look like SyMenu and work in a similar way. The difference however is that you don't have the R-click context menu that SyMenu offers and folders are not opened in the same way as in SyMenu, they open like in Windows Explorer. You enter into a folder and come back out of it using a back button.
Still, I thought I'd point to it here in case anyone is interested. This is just a mock-up so far, no folders and looks will be changed.

edited by sl23 on 07/02/2025 |
10/02/2025
Topic:
Merged my 2 SyMenu's into 1. Now use Rainmeter...
sl23
|
Here's the finished skin:

(Sorry, attached gif refuses to show!)
You need to create a button in another skin. I use one on the taskbar. Then click the skin to activate it. Once the skin loses focus, much like SyMenu, it gets deactivated. If anyone is interested in using it, I'll post the relevant code here.
edited by sl23 on 10/02/2025 |
01/05/2025
Topic:
Adding other repositories?
sl23
|
You know how much I appreciate your work Gian, and am deeply thankful for your continued effort.
May I respectfully make a, hopefully positive, criticism...
PortableAppsMenu has two features that are far superior to SyMenu, but these two things are something that could be added to SyMenu as well. I think this is something that would greatly improve user experience and get a one up on PA.com!
1. Instantly dropping an apps folder into the PortableApps folder automatically shows the app in the menu list. To get an idea of it's implementation and usage: - Obviously for each folder this requires delicate operations. - For the SyMenu Suite, dropping a previously deleted but archived copy of an apps folder would mean that if the folder name is correct and the sps version file are intact, they are automatically added to the menu at the bottom of the list. - The same situation for NirSoft apps.
- Now the tricky part. Creating a parent folder and adding apps to the SyMenu/ProgramFiles directory would auto add that app. So for example, If you have SyMenu/ProgramFiles/MyApps/Foobar2000/foobar.exe then, foobar.exe would be added to the menu list.
So you could set up your own Suites like this: SyMenu/ProgramFiles/MyApps1/ SyMenu/ProgramFiles/MyApps2/ SyMenu/ProgramFiles/MyApps3/
My usage is that I archive older or less used apps. I can simply unpack in the correct location, SyMenu would then auto add the app and check for updates if it is a SyItem. If it's a custom user item, then it is just added to SyMenu.
I suggest using the SyMenu/ProgramFiles folder for Custom Suites due to using a shorter path and it is clear it is completely separate from SyMenu. It would be useful to have a Readme file here explaining the usage of Custom Suites, eg, folder structure.
2. Stealth portability. You may remember some years ago, I edited several SPS files and added the ability to save AppData files within the programs folder. I suggest making a launcher to do this separately from SyMenu. In other words, completely remove the code from SyMenu and create a Launcher in a similar fashion to X-Launcher, YAP, etc. Having a separate app allows these settings to be preserved if a user adds them to many apps and removes them from SyMenu but later adds them, again, as I stated above.
Having a separate SyLauncher allows users to use the feature apart from SyMenu, allows preservation of these settings, but also, allows this data to be saved in a separate folder within the app folder. forcing Stealth on the app.
I currently use X-Launcher_x64, though ideal, it cannot be integrated with SyItems.
Anyway, just a couple of suggestions for improvement... 
edited by sl23 on 01/05/2025 |
06/05/2025
Topic:
Adding other repositories?
sl23
|
Gianluca wrote:
Hi sl23,
Hi and thanks for the looong explanations 
1. Well, I see the point is well made here wrt the SPSSuite of apps. Would you consider adding the other option, ability to drop apps into a User Suite contained within SyMenu/ProgramFiles/ e.g. SyMenu/ProgramFiles/MyApps/ so any apps dropped here are auto added?
2. Rephrasing is good! Sorry, I didn't explain too well the full reason for a separate launcher. We have discussed those desktop shortcuts in the past and that's not really going to help here. Due to many Sy apps "poor" construction, many apps are portable, but not stealth. I say "poor" but I mean the SPS lacking in detail about files being left anywhere they please.
I've been testing a couple of PA.com apps to see how the launcher fair in certain circumstances. Several years ago, I asked a user to create a PA launcher for MuLab. It worked wonders, but, and this is a very big but, If you were perusing those folders on launch or exit of MuLabPortable (the PA launcher version of MuLab) the entire User folder would be deleted!! Many of their apps do this. I also found that associated extensions to a PA launcher file would launch the actual app instead of the PA launcher??? So instead of launching ChromePortable.exe (the PA launcher for Chrome) it would actually bypass this and launch the app itself. Same goes for pinning to the taskbar or anything else. There are actually several faults with the PA launcher I can't abide.
I actually just been through my entire collection of apps and tried switching all common apps to PA.com versions. I then remembered why I disliked their apps so much. The main reason I tried to switch is for point one above. I have archived all rarely used apps, keeping only essentials. When I need an archived app, I unpack it into the PA.com directory and it is automatically recognised and then updated. When finished, it is overwritten in the archive. I've tried all sorts of ways to reduce clutter without getting rid of many essential but rarely used apps. So far this is my favourite solution. Time will tell how good this method is.
As such, I have tried every launcher around. LWC AutoRunMenu is the second best only to WinPenPack's X-Launcher. I worked with "rbon" a member of the portablefreeware forum and the AutoIT guys to get a 64 bit version working. It works well, but on compiling still has errors I can't fix. LWC Menu is good but doesn't portablise correctly, in fact, it's on a par with SyMenu here. I have no idea why, but X-Launcher is by far the best around. It's simple and it just works, I mean it works with every single app I try it with. LWC Menu and SyMenu seem to struggle at times with no explanation.
That's the background. So having a separate SyLauncher would mean apps added to SyMenu would need to be added to a SyLauncher package in a similar fashion to LW Menu / X-Launcher. So, why do this? It means all SPS Authors now use this SyLauncher to create stealthy apps, but also mainly so that non-stealthy associated apps aren't launched without bypassing this portablisation process that is currently built into SyMenu. This would mean that things like Taskbar pinning, etc, also work correctly. With the added bonus of having a launcher to portablise other non PA or Sy apps.
Unless there is a way around the issues above, which I am doubtful, then those are my reasons for these FR's.
Perhaps you disagree though?
I have no idea as to why X-Launcher seems to work when all others fail, but maybe that mystery can be worked out and the issue removed?
edited by sl23 on 06/05/2025 |
08/05/2025
Topic:
Adding other repositories?
sl23
|
Gianluca wrote:
sl23 wrote:
1. Well, I see the point is well made here wrt the SPSSuite of apps. Would you consider adding the other option, ability to drop apps into a User Suite contained within SyMenu/ProgramFiles/ e.g. SyMenu/ProgramFiles/MyApps/ so any apps dropped here are auto added? Yes it could be a good feature. What I have to understand is how this feature should work. For example, what if SyMenu finds no .exe files but only folders inside the main program folder? Should it analyze every subfolder to find anything? I think it shouldn't, probably in this case it should do nothing. What if it finds more than one executable? It probably has to create one logical item for every executable found. How should the found logical items be named? Is it good to adopt the same PA strategy using the .exe property Product name? Where do the found logical items have to be placed in the contextual menu? A special SyContainer maybe? From that container they can be moved in the right container by the user and in the meanwhile they don't crowd the menu root?
Probably a lot of other questions will arise when I start studying this feature but, as I told you, it's a good one. I'll try to answer with some suggestions to resolve these issues, but as you say, there are likely more after studying. No EXE found - The simplest here is to only look in the apps root, ignoring sub-folders. More than one EXE - Again the simplest would be to just add those found. Naming of found EXE's - Simplest is to just add as is. Where to add found EXE's - I suggest the best solution here would be ratherr than add all found EXE's to the root and create a mess, instead, create a folder for the found EXE's depending on it's Suite name. For example, if you have a custom Suite called MyApps, then SyMenu will find all apps located and add any EXE's in a Container folder called MyApps on the root of the Menu. If you have a few custom Suites, then found EXE's will be separated into their parent Container folder. Does that make sense?
More complex answer - For None, more than one and naming of EXE's, a much more complex solution, which I could help with, is to create a database of all portable-freeware apps. This database could contain simple details of apps, like where the EXE is located if not in the app root, which EXE is to be added thus ignoring those not required and the name if an alternate is required. I mean, in actual fact, you could add full SPS data if required. Not sure about this aspect, but it may just be simple as extending the SPS library, but without the version/update info. Though questions arise about this approach: 1. Would it affect performance? 2. How do you go about monitoring? Is it live or manual checks? As they are custom Suites, maybe manual check is better, so as not to impact SyMenu's auto-checking and general performance.
Gianluca wrote:
sl23 wrote:
Due to many Sy apps "poor" construction, many apps are portable, but not stealth. I say "poor" but I mean the SPS lacking in detail about files being left anywhere they please. You probably know better than me how complex it is to track what an app touches during its execution. When I need to find it out, I use Sysinternals Process Monitor and DevEnterprise Software Directory Monitor but it's a really time consuming task and probably not worth it.
So if an SPS is not so accurate on this aspect, I think it's not a drama. Our users want the apps, a lot of apps, a mountain of apps, and if some of them leave tracks behind, it's not a problem for them. I do so manually. I just go through all the system folders where apps store files, there's only about six or seven. I am not really confident with messing with registry entries so I just leave that side of it alone. And from what I've learnt, messing with the registry is best not done and not needed as a fragmented or large bloated registry has no bearing on performance. I do clean it regularly though and have never had an issue, so that's a practice I will maintain.
As for the SyLauncher idea, I see you aren't bothered by apps not being Stealth, but many users are. I respect and understand that you are the developer and it's your choice, maybe if other users chime in? 
I tried mentioning about the faults with PA.com launcher deleting files while perusing their directories, but nothing came of it. IMHO it's a serious flaw that if you are looking in the settings directory of say, CudaText, then launch it and close ti, you lose all settings data the launcher moves the files on launch/exit. Really stupid way of doing things. This is why I have tried every launcher/menu I have come across, no idea why you think I haven't? SyMenu is simply the best Menu/App launcher, but X-Launcher is without a doubt king of portablising apps.
I get the way of working is cumbersome, but I tried Virtual Machine and it just got so complex I just couldn't be bothered with it. I was testing VirtualBox, but want it also to be portable, it isn't, well, it is, but only outdated version of it are. So I gave up. I don't want to rely on others portablising it.
The thing I've found with SyMenu, is that yes I can add data to any SyItem to help make it more stealthy, it doesn't always work and mainly, if I delete that particular app, any data I added is lost. This would be another reason for a central datbase, maybe a central database that anyone can add to. Perhaps an online database, that can be edited. Perhaps this could even supercede SPS system? Though, as you've said before, this then creates a reliance on you and a server to provide this database.
Ok, so another solution is to provide a central database online, that can be edited, but when checking for updates, SyMenu looks for updates to this central database and downloads for local use? To be clear, this database is for any and all apps, not just SyMenu SPS, it also MUST be monitored for changes and abuse and personally I recommend it be used with a preference for creating stealth apps by default.
I suppose their is no reason the database cannot be an extension of the SPS system, where each app has it's own SPS file, just more of them.
Another idea, you remember my Rainmeter skin for checking for app updates? Well, why don't you switch the SPS system to monitor portable-freeware for updates and use this data instead of you personally checking? Someone is already doing the work, then you could literally add every single app listed on PF.com and you would need to do nothing. SyMenu could check if there app updates by auto checking PF.com once a day, or once a week, if there are updates, it then performs the update. All the info is there on PF.com, so why not use it? Though I would contact them to make sure they are ok with you doing so, but it could become a collaboration as well as free you from the monotony and time-consuming aspect of updating SPS files manually. Is that possible do you think? I really hope so, cause I think it would be a game-changer for SyMenu! Imagine having that whole site of apps in SyMenu repository!!! 
edited by sl23 on 08/05/2025 |
29 days ago
Topic:
Adding other repositories?
sl23
|
The import feature seems a good call, except i do not use the floating icon. I find it gets in the way and it is cumbersome to enter Options to enable/disable it. Maybe if there were a menu item that could quickly enable/disable the floating icon, it may be of more use. A menu item that can be located wherever you want in the Structure settings. Least then we can show or hide the button pretty quickly.
Not too sure I understood the first part of your message? But no worries.
I don't think it's too much of a task to use SPS for the online "wiki" database as you called it. I think at present the SPS system works and works very well, so stick with it. But add more and edit the current to use the info from PortableFreeware.com. You can use the download links, descriptions, categories, all of it. Maybe even expand the SPS system to show the screenshots from PF too? Like I said, I would be willing to help with this. But I think it first needs permissions from Andrew at PortableFreeware. If you wish, I can make contact on your behalf? Let me know if you like the idea. I just think it would free up your time from manually updating this stuff when it's already done on their site. You're only using what's already there. It just means designing the SPS system to parse the news pages for updates.  |
29 days ago
Topic:
Adding other repositories?
sl23
|
Ok, I'll make contact. I do see your point though. Maybe add portablefreeware banner and acknowledgements? I have no idea how good or bad it is scraping a website. This is beyond my knowledge. Was just a thought anyway, but if it seems unreliable then not much point. Still, I'll see if I can get something from Andrew's point of view on this. |
28 days ago
Topic:
Adding other repositories?
sl23
|
Great news! Andrew is happy for you to do this with nothing more than acknowledgement for it. Here is the PM I received:
Andrew Lee wrote:
More than happy to help! Here are my attempted answers to your questions:
- 1. Are you happy for this process of obtaining detailed app info from portablefreeware.com. More than happy! - 2. Is there a better way than scraping a website, Gian mentioned something about a web API??? For the latest database updates, how about just parsing the RSS feed (that's a link btw!)? That's much more straightforward than scraping. Is there any other info that the app will need to access? - 3. Is there anything you need or want in return for allowing this? Definitely some kind of attribution (i.e. some note saying this info is obtained from TPFC), since TPFC is very much a group effort and many members contributes to its content. - Thanks you for your time and your efforts with the long standing portablefreeware website, I am a very big fan! 
Thanks for your kind words!!
I believe currently, you are using much info from TPFC like descriptions and maybe site data, but hopefully now, the SPS can grow to basically replicate the TPFC sites data. I will reiterate, I can help create and edit many SPS so as to keep inline with stealthiness of apps, but to also create the new additions in the first place.
What do you think?
edited by sl23 on 10/05/2025 |
27 days ago
Topic:
Adding other repositories?
sl23
|
I can start to create the SPS for every app on here if you'd like, but maybe there are perhaps some that should NOT be included?
Maybe include everything after a certain date? Or perhaps, Windows version?
But the SPS system needs updating to auto-update itself via the RSS Feed. If you think that's an ok way to go? Maybe have a dedicated TEST Suite first? Let me know and I'll start.
edited by sl23 on 11/05/2025 |
26 days ago
Topic:
Adding other repositories?
sl23
|
I don't understand the technicalities nearly as much as you do, but, it sounds like a complicated set up is required. I will ask Andrew about reading your post and to see what he thinks. I think I will also create a new post on TPFC forum and get others idea, point to this topic here, that way can gauge others opinions and hopefully Andrew will join in there.
Does that sound ok with you?
Also, as a side note, I got stuck on the first hurdle! I went to try and start creating SPS for items not currently supported, I went to the Audio/Cataloguers category and the first app was DataCrow, it won't accept the download via SPS and it won't run without Java installed. I do have JAR files associated with PA.com's JavaLauncherPortable, but it still doesn't run! Any idea what to do about these issues? Perhaps it's a little early for this yet! |