19 hours ago
Topic:
Adding other repositories?
sl23Posts: 297
|
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.
|
|
|
19 hours ago
Topic:
Adding other repositories?
GianlucaAdministrator Posts: 1322
|
sl23 wrote:
The import feature seems a good call, except i do not use the floating icon.
Well the drag and drop action works on the floating icon and on the configuration form. So there's no need to activate the floating icon only to get this feature.
You select your 100 folders you want to import and drop them onto the configuration treeview. There's an advantage in doing this: you can decide in which SyContainer to drop the 100 folder to scan while dropping in the floating icon puts your items in the menu root. It's even better this way.
I think I'm quite convinced about this approach.
sl23 wrote:
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. 
Well you know I'm always opened to any collaboration so if you want to try feel free to do it.
I only ask to myself what would be the benefit for PF?
The website scraping would take their content without crediting them in any way. Even if Andrew Lee accepts to consider this collaboration, what can SyMenu offer as a counterpart? A back link put in some SPS field would be enough for him?
The other problem is technical. Scraping a website is a nightmare and even if you succeeded this method is not reliable over time. If PF has a sort of web API to publish its data it'll be fantastic but I never find any of that.
There are several doubts but, as I told you, if you think it's a good idea, go for it. If there's an interested on the other part I can contribute.
|
|
|
20 hours ago
Topic:
Adding other repositories?
sl23Posts: 297
|
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.
|
|
|
1 days ago
Topic:
Adding other repositories?
GianlucaAdministrator Posts: 1322
|
Still speaking about the massive import feature, I'm trying to figure out a real life case.
You have your, let's call it, "folder based suite" (so nothing to do with the SPS suite).
The first import has been done and you made some modification through the configuration form. For example the folder 'MyFirstProgram' has two executables but 'start.exe' is the good one while 'uninstall.exe' is the bad one and, obviously, you deleted the logical item related to the bad one and preserved the good one.
Now you added some other programs to the suite folder and want SyMenu to scan it again. But SyMenu needs to do a lot of consideration about the old folder 'MyFirstProgram' that is still in its place.
It's true, it has been already scanned but it contains an executable that has not been converted into a logical item.
Has it been deleted by the user?
Is it a new exe for the program (a new version of it)?
Is it the reason for which you are asking to rescan the folder because you mistakenly delete it?
SyMenu is entirely based on files... not database... so it preserves no tracks of your previous actions. I would have to understand what happened without a clue of the previous history.
Plus I hate this kind of synchronization analysis... it's difficult to manage, complex to project, prones to errors, slow.
If I have an alternative it's more than welcome.
And probably I have one.
When you create three new folders in your folder based suite, you, as a user, know perfectly what you are doing, so do that all the way: you can explicitly add the new folders to the import function.
We already have an import function. It's the drag and drop over the floating icon or over the configuration form. What this feature is not able to do is the scanning thing... if you drop a folder over it, it adds the folder as a SyContainer that it's a bit pointless.
When you drop a folder instead SyMenu could scan it to find executables inside it. So if you drop three folders SyMenu could scan all of them. If you drop a folder and a file SyMenu could scan the folder and add the file.
It seems very flexible, easy to implement, and consistent with the current working.
Even if you want to add 100 programs at one time, you can select all the folders from FS and drop them on SyMenu.
What do you think about it?
sl23 wrote:
[...]a much more complex solution, which I could help with, is to create a database of all portable-freeware apps. [...] it may just be simple as extending the SPS library, but without the version/update info.
The file system documentation for every program could be a great solution but we have no resources to accomplish that. And even if we have plenty of people helping in this huge work I doubt it's worth it. The only use of this amount of data would be the automatic recognition of the files that have to become logical items. Consider that the import of a new program is a thing that happens once. And above all consider that the preferred way to do that is called SPS: add a program with SPS and you'll have no problem at all, do that by hand (or with the auto import) and you will have to manage it by yourself.
So I think it is an over engineered solution for a problem like that.
sl23 wrote:
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? 
Well it would demonstrate interest in this topic but still it's not my interest for the reasons I told you.
BTW it's a perfect side project to be integrated in SyMenu without my help. Exactly as you can integrate a PAF program or any other kind of portable program.
sl23 wrote:
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.
It would be terrific. A sort of wiki DB containing the details of any programs available on the Internet.
You are right, with a tool like that SPS will become obsolete and probably a lot of other features will arise: it could be a safe place to download the programs, to interact with the programs' authors, to allow authors to earn something with advertising, it could collect statistical data, suggestions.... well... isn'it an app store like Google Play or Apple App store?
Yes, it is.
As usual we always end up there. You know how many years I've been dreaming about that. I don't care if it could be born from SyMenu/SPS or any other technology, if it is a collaborative thing like a Wiki or an authoritative place. If something like this needs to be built I want to be in. But before that, let's find the money for this because it's huge.
To understand the size, let's consider SPS as the first stone for this building... well, here we are speaking of a 100 story skyscraper...
|
|
|
1 days ago
Topic:
Adding other repositories?
sl23Posts: 297
|
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
|
|
|
2 days ago
Topic:
check for github releases
ronen1nPosts: 16
|
Very easy site to track tools releases from github and other packages
I just now added all my githubs to follow but still didnt get any email so cant confirm the quality so if someone wants to try it here is where i got it from
Copied from infosec channel on telegram:
```
• Look what a cool and useful service I came across: https://newreleases.io (https://newreleases.io/) . The trick is that this service monitors the release of updates to various projects and sends you a notification by email, Telegram or Discord. Well, that is, if you need to know when a conditional grafana or docker will be updated, then you specify a link to the repo and receive a message as the update occurs.
• Here is a list of sources that you can specify to track information:
GitHub, GitLab, Codeberg, Gitea, Bitbucket, GNU Savannah, Python PyPI, Node.js NPM and Yarn, GitHub NPM, Java Maven, Ruby Gems, PHP Packagist, . NET NuGet, Rust Cargo, Erlang/Elixir Hex, Perl CPAN, Docker Hub, GitHub Container Registry, Google Container Registry, Artifact Hub, SourceForge, Debian GitLab, Freedesktop GitLab, GNOME Gitlab, KDE GitLab and Xfce GitLab.
• And the service is completely free, so take it and use it:
➡️ https://newreleases.io (https://newreleases.io/)
➡️ https://github.com/newreleasesio
```
|
|
|
2 days ago
Topic:
Adding other repositories?
GianlucaAdministrator Posts: 1322
|
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.
Well, for your second point I'll go a bit random.
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.
sl23 wrote:
I've been testing a couple of PA.com apps to see how the launcher fair in certain circumstances. [...] There are actually several faults with the PA launcher I can't abide.
Report to John, he'll be happy to help you 
sl23 wrote:
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.
I understand what you are trying to do but IMHO it's a cumbersome solution. And you can't find all the apps in PA format. And PA is buggy (you told that, not me ). And you have several manual operations to do.
Maybe I have an idea for you: why won't you go with OS virtualization instead?
You can create a virtualized Windows that has access to your local PC apps folder, document folder, and, if you really need that, to the entire real data disk.
When you launch an application, you'll do that from the virtualized PC. This way everything the app writes on the registry will be on the virtualized one. And the same happens for the AppData folder.
Plus if the app is portable, your settings will be written on the hosting PC app folder that is a desired behaviour.
You can even create associations among apps and extensions in the virtual PC if your working files are available there. This is the reason for which I thought the entire data disk should be shared.
And finally when you want to clean up the virtualized environment you can restore a previous snapshot in a blink but, what is really important, is that your hosting PC will stay clean and untouched.
sl23 wrote:
As such, I have tried every launcher around. [...]
Well I don't agree with you here. You made a list of portabilizer tools and added SyMenu. SyMenu with its SPS technology has never been intended to be a portabilizer tool but a launcher and a portable freeware hub.
It's true, SyMenu has the skill to rewrite some environment variables and this is enough for some apps to become portable and, in some cases, even stealth. But it's incidental because the purpose is different.
sl23 wrote:
[...] 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
Again, SyMenu has no real and solid portabilizer skills so it's not correct to demand too much from it.
Well you probably now understand why a SyLauncher is not in my list.
Anyway SyMenu is open and can include programs with any kind of portabilizer technology so if someone wants to create a portabilizer system and, above all, include it in some programs' original package, well I'm more than willing to include these programs in the suite.
But, you know what...? It sounds like another PAF system that, I think, it's the last survivor of this species. So probably the best thing could be to revive one of the others and drag it to the present day. What I'm really sure of is that it's not my mission.
|
|
|
3 days ago
Topic:
Adding other repositories?
sl23Posts: 297
|
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
|
|
|
4 days ago
Topic:
Adding other repositories?
GianlucaAdministrator Posts: 1322
|
Hi sl23,
You know how much I respect your opinion so... prepare yourself for a very looooong response.
1) Folder watcher to add applications automatically to SyMenu
Well, PA is able to do this magic because it knows a priori how the PAF applications are structured.
So when the launcher scans its own program folder and finds a new one, it's easy for it to analyze and understand if it's a PAF program, what its name is, and add it to the menu.
Infact if you try to add a folder containing a normal program (not PAF), PA will add all the executable files it finds on the root using the product name as a new item name. Not different from what SyMenu does when you drag an executable over the floating icon.
It's true, with the SPS, SyMenu has a minimum track of what the program found in the watched folder could be because the SPS contains the physical executable name. If a program is one with a valid SPS, it could be added with all the bells and whistles. But... are we really sure that an executable name is enough for linking it with an SPS? IMHO it's not. Think about an executable called DiskInfo64.exe... Are we really sure that name is used only by CrystalDiskInfo? HostMan uses hm.exe... even more dangerous. Further we already have collisions in the SPS collection. Try to install Keepass Professional and Keepass Classic. Both have an executable called Keepass.exe.
Since SPS doesn't modify the original packages to be able to include a program in the suite, it means it can't add metadata to a package. With no metadata it is impossible to recognize an SPS program only by its FS structure and file names. This is the reason for which SPS needs to be always in charge.
Indeed it's possible to implement this feature for the PAF only, exactly what PA does, but what's the point of this? I'm trying to clean up the suite from the PAF programs so I can't create features for them.
What you already have is the option to drag a program (the executable) over the SyMenu floating icon. When the exe is dragged, SyMenu adds it to the menu regardless of its physical position on the FS. What SyMenu can't do is to link it with a suite SPS. So you are allowed to do that but you have to manage it as an external program. This is the best it can do.
I know it's bothersome to add the external program one by one and probably to change their names too but I can improve only this approach, not the other one.
2) Stealth portability
IMHO the title is not really explicit. What you are asking is not something related to the program's stealthiness but the option to launch any program (stealth or not) preserving the configuration it could have in its SPS. I hope you can agree with my refrasing.
Well, to reach this goal I don't need to extract a portion of SyMenu logic and create a new program because a similar option already exists.
Follow me.
- Find one of the SPS programs you already installed with the redirection for the AppData folder. For my example I'll use Obsidian
- Open SyMenu and go to the Configuration form.
- Find and select the program to see its SyMenu details.
- Now flag the Desktop shortcut checkbox and save.
From this moment on whenever you start SyMenu a new desktop shortcut for Obsidian will be created on your desktop and you can use it to execute the program.
Now try to open the shortcut properties.
Can you see it? It's not a shortcut to the program (Obsidian in my case) but it's a shortcut to SyMenu with a command to open that program.
It's your launcher.
The only problem is that the shortcut will be deleted when SyMenu closes because SyMenu is a clean and organized guy but instead you desire to have that shortcut even when SyMenu is closed (hey... Why do you close SyMenu???? ).
Well, so easy. Since you have the shortcut property form still opened, empty the Comment field and close it. From this moment on your shortcut will remain on your desktop until you delete it or move it.
If you click on it and SyMenu is closed, the shortcut opens SyMenu, SyMenu launches Obsidian, and then closes itself. The perfect launcher.
What I've described here is a workaround not a feature. A feature could be to have a new checkbox/button to create a persistent desktop shortcut in one shot but before introducing such a new feature, as usual, I would like to understand if it could be a good solution and how many users will be happy with this.
|
|
|
8 days ago
Topic:
Adding other repositories?
sl23Posts: 297
|
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
|
|
|
08/04/2025
Topic:
Adding the default search patterns
GianlucaAdministrator Posts: 1322
|
Yes it is.
And it's even possible to reset the filters with the special button to go back to the initial ones.
Ok, so no work for me... good!
|
|
|
08/04/2025
Topic:
Adding the default search patterns
ronen1nPosts: 16
|
At first, I didn't know i came with some list by default so i suggested to add the filers that we see in the `?` icon
But it still possible to add the rest of them
|
|
|
08/04/2025
Topic:
Adding the default search patterns
GianlucaAdministrator Posts: 1322
|
We are not understanding each other.
The list you are seeing is exactly what it is expected as a default.
So, what are you suggesting?
To change them?
To increase the number?
To delete anything?
|
|
|
08/04/2025
Topic:
Adding the default search patterns
ronen1nPosts: 16
|
Oh, ok maybe i deleted them sometime and i don't remember
this is the default list i see
|
|
|
08/04/2025
Topic:
Adding the default search patterns
GianlucaAdministrator Posts: 1322
|
I checked with a fresh SyMenu and it already works this way: the seven patterns are clickable and activate that same search.
|
|
|
08/04/2025
Topic:
Adding the default search patterns
GianlucaAdministrator Posts: 1322
|
Isn't it already this way?? Is it a bug? I have to check it.
|
|
|
08/04/2025
Topic:
Adding the default search patterns
ronen1nPosts: 16
|
We have 7 search patterns, but we need to write them down to search
I think that by default it will be better if all of them will be added like in the picture that we can click on them to search and don't have to write them down
|
|
|
08/04/2025
Topic:
Adding the default search patterns
GianlucaAdministrator Posts: 1322
|
Excuse me but I can't understand what you are asking for.
The default filters for a freshly new SyMenu installation already include :update.
Are you suggesting adding :newest too?
Indeed the example filters (they are currently 7) are only a way to show you what you can do with the search, it's not a way to include the most useful searches.
Anyway I'm open to changing the default list if it's useful, but please let me understand better what you are suggesting.
|
|
|
08/04/2025
Topic:
Adding the default search patterns
ronen1nPosts: 16
|
Hi
I think more people will use the default search patterns if it will come by default and we won't have to write it to filter like the example below
This place is not used anyway and its easier and make more sense to remove (if someone don't like them) them then to add them
|
|
|
28/03/2025
Topic:
Adding other repositories?
GianlucaAdministrator Posts: 1322
|
rjtemple wrote:
So in short I would need to:
1) compile programs as .SPS
2) host a site
3) put those .SPS files on the hosted site
Would this be an accurate understanding?
Not exactly. It's easier than this.
1) SPS is not a packer such as PAF or zip/7zip/rar solid archive, and it's neither a setup like InnoSetup or msi.
It's a structured description that tells SyMenu where to download the file, how to unpack it, and where to find the resulting executable. Plus it contains program description, license, and so on.
The burden to create something with PAF, setup, or whatever other system, is that you have to repack the program at every update. With SPS instead you just need to change some strings of text inside the SPS file itself.
You can find a lot of material to understand what a SPS is and naturally you can download the magic SPS Builder from SyMenu itself or from its own page (https://www.ugmfree.it/spsbuilder)
2) Easier. You don't need an entire website but some sort of web service, one endpoint, that returns json information. The json information can be dynamically created or fixed... so in the simpler scenario you need to publish somewhere a plain text file.
3) ... or in any kind of file hosting depending on how you want to distribute your suite.
rjtemple wrote:
Could the site used be something as simple as Dropbox?
The endpoint can be hosted anywhere, even in Dropbox if you link a direct URL and not the dropbox download page.
rjtemple wrote:
There are not many products that I cannot get through SyMenu...
Excuse me but there's a more direct way to have what you need in SyMenu. Probably this is the reason because we don't still have the custom suite feature. You can become an SPS editor for the main SyMenu suite.
The SyMenu suite is open to collaboration from everyone.
So you have to download the SPS Builder, try to understand how it works by consulting some existing SPS, fill your SPS, upload it through the SPS Builder.
When a new SPS from a fresh editor arrives in the system, I'll be notified and review the work, help the new editor to understand how SPS really works, eventually ask for corrections, and afterwards publish his work.
As I told you the custom suite is a feature not activated because it needs a lot of work so today the only way to publish something is through the main suite.
edited by Gianluca on 28/03/2025
|
|
|