Feature Suggestion: conditional synchronisation of Start Menu groups between devices

Feature Suggestion: conditional synchronisation of Start Menu groups between devices.

  • This is a windows product so lets assume OneDrive is available.
  • Via one drive export Start11 menu pin configurations to a sync config file with a standard or customisable expected %onedrive% relative path.
  • NB this is an automated, ongoing, 'syncing' featureNot one time settings backup > import.
  • The following would need to consider the types of personalisation that apply and don't apply between different Start menu styles, and how to analog from one to another.
  • The config file records groups and locations and major start menu configuration.
  • The config file records pinned items and location.
  • Some major configuration is opt in/out locally for sync at each local device. (e.g. do you want the start style syncing for this machine or not?)
  • The config file perpetually remembers at which device a Pin/group was last created/changed.
  • There is a concept of 'Remote': i.e. any Start11 pin/group 'not' created/last-changed at the local device currently reading the sync file. There is also a concept of local, self explanatory.
  • Remote Pins/groups are recreated/updated locally, but changes should be 'smart':
    • If the Pin is for a 'registered' application, the Pin should only be created if the registered application is present at the destination device.
    • If the Pin is not for a registered file system object, then the pin should only be created if for example File Exists is true. Approached naively, but should look to identify relative to any environment variable paths.
    • If the Pin is removed because the item is detected as no longer available locally, this reason is recorded in sync, so that remotes can decide whether to honour the the removal also, or become become new local owner.
    • It can vary as to how any precise location personalisation is honoured, depending on differences between any Start11 menu styles..
  • It is optional as to whether groups are created if they would be created empty.
  • It can be optional that if a group becomes empty as result of synchronising, it can be deleted from the local device.
  • Manual deletions at remote are typically deleted at local, but this can be optional.
  • If a remote Pin/group is changed at local, then local becomes owner of that Pin/group, and the previous local device would now see that object as remote. The change is synced. (suggest guids or something)
  • suggest guids for many of these sync entries.

This is an implementation heavy way of describing the suggestion, and most of that should probably be thrown in the bin and done a better way, but its the laziest way for me personally to describe the suggestion. I'm sure you get the idea.

This basically just looks like 'delete aware' file mirroring, except at the level of individual Start11 config/settings rather than individual files.

 

 

8,646 views 3 replies
Reply #1 Top

Hello,
I have forwarded your request to the Stardock Support Team for their review and recommendations. Please keep an eye on this thread for any updates. We really do appreciate your feedback, Thanks

Basj,
Stardock Community Assistant.

Reply #2 Top

I've realized that if this were implemented, it may be well to implement it along the lines of a 'rules' based system such as is used to implement fences groupy.
A universal rules framework would be lovely to see.

Start11/Stardock could even provide some defaults for popular applications.
Here are some common groups.
Here are some common applications that by default will go into those groups.
Here are some common auto arrangements for those groups.
Here are the custom rules, which take precedence over the above.

Reply #3 Top
  • Any device that implements as per remote, needs to record such.
  • Any device that removes as per remote, needs to record such.

This way any deletions can eventually be expunged from settings.

Can elect to force ignore/expunge certain devices.

Can request a device's re-accounting on some next occurrence.

Timing/triggering of the above is a separate matter.