17 hours ago
Topic:
Adding other repositories?
sl23Posts: 295
|
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
|
|
|
1 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
```
|
|
|
1 days ago
Topic:
Adding other repositories?
GianlucaAdministrator Posts: 1320
|
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.
|
|
|
2 days ago
Topic:
Adding other repositories?
sl23Posts: 295
|
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
|
|
|
3 days ago
Topic:
Adding other repositories?
GianlucaAdministrator Posts: 1320
|
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.
|
|
|
7 days ago
Topic:
Adding other repositories?
sl23Posts: 295
|
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: 1320
|
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: 1320
|
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: 1320
|
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: 1320
|
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: 1320
|
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: 1320
|
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
|
|
|
28/03/2025
Topic:
Adding other repositories?
rjtemplePosts: 2
|
Hey Gianluca!
Thank you so much for this fantastic response. 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?
Could the site used be something as simple as Dropbox?
There are not many products that I cannot get through SyMenu. The ones I would like, but cannot find are:
- Don'tPanic
- HijackThis
- PortExpert
- Trellix Stinger
- uTorrent
I agree that SyMenu is 1000% better than PA. Thank you for this amazing product and thank you for your support!
|
|
|
28/03/2025
Topic:
Adding other repositories?
GianlucaAdministrator Posts: 1320
|
Thank you for your question, it allows me to delve into SyMenu's history.
At one point, I added a plugin to download apps from PortableApps.com, naively believing that a community promoting openness and freeware would genuinely embrace those principles.
However, the PA community is an unusual case because it's owned by an individual and operates as a private company, despites the license telling us something different. The boss wants the PA apps to be available only via the PA launcher, otherwise, you can fu**k off.
Despite giving credit, backlinks, and visibility to PA.com I was accused of being a thief because I used to waste PA's bandwidth (???WTF???). I was discredited, accusing me of distributing software against their license (???##!!). PA's founder, smiling John, embedded code in every PAF app to block execution if launched through SyMenu. Since the malicious code was in the packer for PAF this sabotage extended to apps like OpenOffice, even though portable OpenOffice is packed and distributed by its own foundation, not by PA.
For these reasons, I decided to move on and remove the plugin.
Meanwhile, SPS suites were evolving. Initially, there were three of them: SyMenu Suite, NirSoft, and Sysinternals. It became soon clear to me that thematic suites, focused on specialized areas, were more practical than publisher-specific suites. And in fact integrating Sysinternals into the main suite proved beneficial. NirSoft still remains separate, but merging it into the main suite is a thing I have to do in the future.
Thematic suites instead open exciting possibilities: a forensic suite, a school tools suite, an office suite, or even a suite dedicated to games. But, managing a single generic suite is already overwhelming, which has kept me from pursuing thematic suites further.
That said, I introduced the concept of custom suites for users, that is probably the thing you want to know.
Custom suites are simple: users can define an online endpoint for their SPS library, similar to SyMenu's endpoint.
Your endpoint might look like:
https://www.mypersonalwebsite.com/getSPSSuite
Once the endpoint is entered in SyMenu, the system queries it to retrieve suite details, including its name, description, download links, and login requirements (if restricted to certain users).
As you can see, with this kind of feature, I have no control over these custom suites.
For example, if someone uses SyMenu to distribute pirated software I can't prevent it. Absurdly if smiling John decides to use SyMenu to distribute PA because SyMenu is way better than PA launcher, I can't prevent it It'd be hilarious!
However, this lack of control isn’t why the custom suite is still inactive. The real reason is simple: there's been no demand for this feature, despite its potential to push SPS technology further and I need to work with someone to put it in line because it's huge and complex.
|
|
|
27/03/2025
Topic:
Adding other repositories?
rjtemplePosts: 2
|
I recall seeing somewhere online that you could also add other apps from PortableApps.com and a few other repositories.
Has this functionality been removed, or is there a method for adding them? I poked around the manual and forums a bit and haven't come up with anything yet.
Thanks!
|
|
|
18/03/2025
Topic:
Pin to Desktop
GianlucaAdministrator Posts: 1320
|
No, it isn't.
I understand what you desire: a thing visible only when the desktop portion where it's placed is visible.
I fear it's not possible because the sense of the pin is to always show the menu, no matter what. And BTW, in my opinion the pin thing is pretty useless... I don't even know why I've implemented it.
Anyway I have a workaround for you.
If you'd have the menu on the desktop level, you should make at least one action to make it visible. I mean you always need to do something like minimize a window or click on the Windows shortcut WIN+M or switch tabs to the desktop. In your note, you have to do a click with the mouse or to press some keys on the keyboard.
So you don't use the SyMenu shortcut to make the contextual menu appear?
It's equally a single action (default CTRL+F3 but it's customizable) and you make the menu appear in a blink of an eye.
Or if you are a mouse type, you can click on the always visible system tray icon and the menu appears the same.
What do you think?
|
|
|