22 days ago
Topic:
Adding other repositories?
sl23Posts: 301
|
Ah, I just created the post. I'll amend it at to add that info.
https://www.portablefreeware.com/forums/viewtopic.php?t=26554
No idea why you're having issues with email. I only use that email address and receiving other emails ok.
|
|
|
22 days ago
Topic:
Adding other repositories?
GianlucaAdministrator Posts: 1326
|
sl23 wrote:
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.
Yes but ask Andrew before creating the post. If he thinks that's no space to go further we have to respect his will.
sl23 wrote:
Also, as a side note, I got stuck on the first hurdle! [...] Perhaps it's a little early for this yet!
Yes it is. As I told you, we should study that before going, otherwise it's a waste of time.
BTW. I've got a problem in reaching you with your usual email... you know sl....@...
Can you please contact me with another email? Because I fear your email provider is going nuts.
|
|
|
22 days ago
Topic:
Adding other repositories?
sl23Posts: 301
|
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!
|
|
|
22 days ago
Topic:
check for github releases
GianlucaAdministrator Posts: 1326
|
ronen1n wrote:
Maybe is it best to open source the "SPS Published App Track" if you allowed and it's safe to do
I agree and it'll be the best thing to do but only when someone takes care of it.
Open source means there's always someone in charge to review the pull requests and accept or refuse them.
|
|
|
22 days ago
Topic:
check for github releases
ronen1nPosts: 18
|
Like I said I also use this tool by adding elements to track with distill.io chrome extension and exporting the data to json and putting it in tracked_elements.json
https://github.com/ronen1n/Website-Change-Tracker
Maybe is it best to open source the "SPS Published App Track" if you allowed and it's safe to do
|
|
|
22 days ago
Topic:
check for github releases
GianlucaAdministrator Posts: 1326
|
Great tool. Thank you.
So we have:
- https://newreleases.io
- SPS Published App Track (PAT)
If someone knows or uses other free tools please report them here.
And BTW, the SPS Published App Track author, my old and good friend Cesar the Great, gave me permission to use his source code to follow the program's development.
If someone is interested, please contact me in private and we can speak about that.
PAT is written in .NET.
|
|
|
22 days ago
Topic:
Adding other repositories?
GianlucaAdministrator Posts: 1326
|
sl23 wrote:
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?
Thank you but, don't lose your time.
The data needs to be studied beforehand. One of my rules is "never do work without studying it".
sl23 wrote:
But the SPS system needs updating to auto-update itself via the RSS Feed
This is the point!
Is TPFC an inspiration, a guide, to find and publish new programs or could it be a data source for SPS?
The real game changer is clearly the latter option.
I personally don't need a new channel that inspires me and I think the other editors don't need it either. We are already overwhelmed with the programs we manage today.
In the same way I don't need a channel that alerts me about program updates because I already have tools to be alerted of new versions.
You are talking about an SPS that auto-updates itself so you are exactly on my same page.
So let's analyze the second option: an hypothetical use of TPFC as a data source for SPS.
As a source Andrew suggests the RSS instead of the website scraping but unfortunately the RSS is a simple list of the latest new/updated programs. If we need the program details - and yes we need them to fill an SPS - it's necessary to follow the RSS link to an HTML page. Well it's the exact purpose of RSS: you read the announcement on your aggregator and then you go to the website to deepen it.
We need the detail so the HTML scraping thing comes again to life.
Well, scraping is not impossible even if, as I said, it is unreliable and complex. But anyway let's see which data we can find on the program detail page. Or better let's see which data we need that we can't find there.
The detail page doesn't contain the program "Author" but, as a workaround, we should use the website URL from the "Publisher website" field.
Packer format and Main exe names are information drowned into open text ("How to extract" field), so they are not structured data. It's a big problem because those fields are mandatory in SPS or, better, they are two of the most important data because they teach SyMenu how to manage the program.
Probably other fields, not mandatory but useful in several programs, are inside this text too ("Script before install", "Installation arguments", "Create files on install", "Ignore on update" and others).
The last big obstacle is the Download url. SPS needs to download a program, TPFC needs to bring you to the download page. Well, when we update an SPS, 90% of the time we need to change the download URL so it's the single most important data we need to automate the process.
Want to know what I realized?
The TPFC detail page is a subset of an SPS, so it's impossible to use the TPFC page to fill an SPS.
What is possible instead is to go the other direction. From an SPS it is possible to fill a TPFC detail page. And this approach could break new ground for a reciprocal collaboration.
If the TPFC editors will use the SPS to update the program and naturally TPFC use the updated SPS to publish the announcement page and detail pages, it'll be a win-win game for both our users: TPFC instantly has a desktop launcher for all its program, SyMenu will instantly has a new suite with hundreds of new programs.
Anyway this means a lot of changes for me, for Andrew, and for our communities. I don't think Andrew could agree with such a big change but... why don't you ask him to read this post?
Maybe if he's willing to speak about that, even if only hypothetically, we can open a new thread on the TPCF forum and see if something arises.
What do you think about all the reasoning?
|
|
|
23 days ago
Topic:
check for github releases
ronen1nPosts: 18
|
Update:
Looks like it's working great it just notified me for rustdesk update that released 10min ago
Releases · rustdesk/rustdesk
|
|
|
23 days ago
Topic:
Adding other repositories?
sl23Posts: 301
|
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
|
|
|
24 days ago
Topic:
Adding other repositories?
sl23Posts: 301
|
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
|
|
|
25 days ago
Topic:
Adding other repositories?
sl23Posts: 301
|
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.
|
|
|
25 days ago
Topic:
Adding other repositories?
GianlucaAdministrator Posts: 1326
|
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.
|
|
|
25 days ago
Topic:
Adding other repositories?
sl23Posts: 301
|
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.
|
|
|
25 days ago
Topic:
Adding other repositories?
GianlucaAdministrator Posts: 1326
|
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...
|
|
|
26 days ago
Topic:
Adding other repositories?
sl23Posts: 301
|
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
|
|
|
27 days ago
Topic:
check for github releases
ronen1nPosts: 18
|
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
```
|
|
|
27 days ago
Topic:
Adding other repositories?
GianlucaAdministrator Posts: 1326
|
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.
|
|
|
27 days ago
Topic:
Adding other repositories?
sl23Posts: 301
|
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
|
|
|
29 days ago
Topic:
Adding other repositories?
GianlucaAdministrator Posts: 1326
|
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.
|
|
|
01/05/2025
Topic:
Adding other repositories?
sl23Posts: 301
|
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
|
|
|