|
Gianluca Administrator Posts: 1395
1 days ago
|
Dear all,
A new version has just been released.
The most important changes are:
- A new interface for the plugin system (whatever that means!).
- SyMenu now highlights in the context menu the updates availability in any SPS suite, including custom suites, through a dedicated icon and special text in the context menu.
Let's take a closer look at these two features.
Plugin startup notifications
The new plugin interface allows a plugin to be notified whenever SyMenu starts.
A more consistent implementation might have been to leverage SyMenu's native Autoexec on Start feature. However, that would have required users to enable Autoexec just to execute a plugin during startup. It seemed preferable to let the plugin itself declare its intention to run at that stage.
For those interested in the technical details, the new interface is called ISyPluginNotificationStartup and, as usual, it is exposed through SyMenu.Plugin.Resources.dll.
If you need further information, you know who to contact.
Update notifications for secondary and custom suites
This is a long-awaited feature.
SyMenu can now show update notifications not only for the main suite, but also for the secondary suite (NirSoft) and even for custom suites created by users.
When updates are available, the corresponding context menu entry is highlighted with a dedicated icon and text, making it much easier to spot pending updates.
As always, if you have questions or need additional details, feel free to ask.
|
|
|
link
|
|
sl23 Posts: 314
15 hours ago
|
I sent an email about this, but perhaps it may be better to post here, then users can see how this affects their own suites.
So the idea of this is that for personal/custom suites to notify SyMenu via the blue Get New Apps icon, by turning it green, is that right? Does it extend that far?
But I see you have actually added per item in-menu update notification.
Is there anything an author of a custom suite needs to do? Or is this purely on SyMenu side?
As already discussed via email, I plan on releasing a custom suite for AudioPlugins, will these need to be zipped, as the current two built-in suites are, or do I need to make these individual files?
I am just trying to figure out some things wrt how this will work. For example, for a zipped file that can be easily downloaded by users in one go, it becomes necessary for me to manually add new files however I receive these from others, into the suite. For individual sps files, I don't need to do this, but then how do others download all of the separate files as a suite? Its a bit of a problem either way. I am trying to think of how this could literally be done automatically, I realise checks need to be performed on sps files to avoid spam and malicious sps files, but how do you do this? What is your process?
Essentially, we need to understand the process for creating, sharing, updating custom suites.
Thanks for the update, it is indeed a great thing you've done! 
edited by sl23 on 08/10/2026
|
|
|
link
|
|
Gianluca Administrator Posts: 1395
14 hours ago
|
I confirm that SyMenu uses the notification icon status for custom suites too.
But how does this work? What does a custom suite editor need to do in order to notify SyMenu about updates?
Actually, nothing special is required. The mechanism is exactly the same as the one used by the main suite.
Let me explain.
When SyMenu starts, it checks its endpoint for updated SPS definitions. If newer definitions are available, it downloads them into its _cache folder.
In your scenario, these two tasks are delegated to the plugin.
I agree that distributing the custom suite SPS files as a ZIP archive is the simplest solution. SPS files are very small and compress extremely well, so a ZIP archive grants a small download size and a single file to manage. The only difference between the main suite and a custom suite is that for the main suite SyMenu can read SPS files directly from the ZIP archive, while for the custom suite it needs the files to be extracted first. However, unzipping a file is trivial and the plugin can do that in secs.
Once the plugin has downloaded and extracted the updated SPS files inside the custom suite _cache folder, the situation becomes identical to the main suite. At that point, SyMenu can detect available updates in exactly the same way it does for the official suite.
How?
Through the software version stored in each SPS file.
Let's see the entire workflow.
When a new version of AudioPluginABC is released, you would:
- update the master SPS for AudioPluginABC, changing the version number and, if necessary, the download URL and any other metadata (file size, VirusTotal information, etc.);
- package the updated SPS files into sl23CustomSuiteCollection.v345.zip;
- upload the updated ZIP file to your endpoint;
- let the plugin and SyMenu do the rest.
The plugin is responsible for checking whether a newer SPS collection is available, downloading it, and extracting it.
SyMenu is responsible for determining whether any installed applications in the custom suite require updates by reading the downloaded SPS files.
I also suggest versioning the ZIP filename (for example, v345).
This gives the plugin a simple reference point to determine whether the online definition package is newer than the locally downloaded package.
If you adopt this approach, remember to preserve a version marker that the plugin can compare against. This can be the previous ZIP file itself, an empty file named after the version (for example, v345), or a simple text file containing the current version number.
Another important point is the role of SPS Builder.
You can use it for sure. What you can't do is upload custom suite SPS files to the UGMFree cloud. For a custom suite you can work with local files (SPS Builder does this easier), and upload the definitions manually to your endpoint.
If you need any other information, please ask.
|
|
|
link
|
|
sl23 Posts: 314
12 hours ago
|
ok, I need further information! lol
I'm totally confused! You keep mentioning "the plugin", what plugin is this? Do I need to create one specifically to manage this suite, or is that the part you have done in this update?
So I have to do the following:
1. Create a zip of all sps files contained in the suite.
2. Upload to say, github.
3. But whats the Master SPS you mention and where does this go? Where do I place this? does it become a part of the suite itself? Then I update that whenever theres an updated sps within the suite?
Could I create a SyMenu plugin that does this check automatically? ie, it performs the check online to see if the updated suite matches the latest installed version via a blank versioned file.ini then downloads and installs into the suite if newer.
|
|
|
link
|