Synchronize style subscriptions across browsers #82
Comments
|
Currently you can do it only by manual import/export of the style database. |
|
I really like the idea behind a VS Code extension "settings sync", which makes use of Github Gist to synchronize a "cloud" settings.json. I suggest stylish-chrome could do something similar. It's a clever way to allow syncing with zero server costs, just a Github user and access token. Github Gist even tracks revisions, which can be helpful for tracking changes over time. Users could even open a gist to public for others to import. Just throwing it out there as an idea! |
|
browser.storage.sync API |
|
@sabret00the, it's only within one type of browser. The topic however is about browser-independent sync. At least this is how I interpret it. Also, the built-in sync API is too limited. Of course it may be useful in some cases so we'll see. |
|
Any plans to make this happen? I tried to manually sync the local sqlite database (with symlinks and OneDrive) but unfortunately the assigned machine-specific moz-extension UUID is written into the file as well. Firefox reads the file but ignores it because of the different UUID |
|
Well, no one is working on this. |
|
Isn't it just "storage.sync" instead of "storage.local" to enable cloud syncing? I know that, what I meant is the sqlite file created by Firefox's web extension storage API. |
|
Not, it's not because storage.sync is severely limited so we can safely use it only for small stuff like extension settings. |
|
Oh okay, too bad.. |
|
@tophf, couldn't you just sync the name/address of a style (from userstyles.org) and then all we had to do was to update? It would be better than having to export and import stuff. |
|
@FeBe95, you would lose style variables/customizations with that approach so db export is better. |
|
Well, yes you would, it's definitely not a 100% solution, but it would work just fine for people who don't customize. It's much easier just clicking on "update" than having to export the db, move the file to another computer and import the db. Having to constantly do that is a bit annoying. |
|
So you suggest we just ignore the people who do customize their styles? Don't seem to be a good approach. |
|
Well no, of course not. A proper solution should be there, but since it's impossible (for now), why not make some people happy? |
|
I don't see any way of implementing it ("it" being your idea) without pissing off those who do customize styles. Either the customized styles won't be synchronized at all, which is terrible, or their settings won't be synchronized, which is almost as bad. |
|
Hi, I'm interesting in this issue and I'd like to know if there is a problem if I try to implement the ps: later I can try to implement the chrome version of it. |
|
@matheusfaustino To quote tophf:
Not using it for syncing styles was a choice, because many users who create their own styles would have DBs too large for storage.sync. Pretty sure we're all open to alternative methods of syncing through popular storage sites like Google Drive, Dropbox, or others. A PR for that would probably be pretty popular, but nobody has volunteered, as of yet. |
|
Tampermonkey supports many cloud services, why doesn't Stylus do? |
|
Because Tampermonkey is developed by a different developer who dedicates his time to develop his extension. Stylus is not developed by the same developer. Stylus is a community project and is maintained [mostly] by the former users of Stylish. The core maintainers don't need the cloud sync which is why they don't develop it. It'll be added soon anyway, see the pull requests section. |
* Implement Dropbox export (#82) * Remove wrong dropbox api key * Improve implementation of Dropbox by using identity.launchWebAuthFlow api and get rid of web_accessible_resources * We don't need a dropbox receiver anymore, remove constante with the html file * Implement compression in dropbox export * Add LICENSE file from dropbox and zipjs * Fix code style error * Fix code style and folder structure of the feature * Fix eslint error in dropbox implementation * Add real dropbox api key from stylus dropbox account * For test only: fixed addon's ID on firefox * Change the file not found message to a better one * Add dropdown style on export and import buttons * Changes arrow from buttons to svg * Remove applications entry on manifest.json * Remove unnecessary break line
|
I can't disagree with it being a different developer with ability to dedicate efforts etc. with Tampermonkey vs Stylus, but I will absolutely disagree with the "can't" comments above. I personally sync a current total of over 400 userscripts between all my Chrome browsers using the Browser Sync API option in Tampermonkey. That's not all the other cloud backup/restore options (I use both Google and Onedrive for that) - but I find the straight Browser Sync API option to be pretty flawless and after years have yet to run into a single issue or failure with what's being discussed in this enhancement request. Any addition of those other backup/restore options would also make life much easier since many of us have long since (pardon the pun) dropped dropbox. :) +1 on this being raised in priority. TIA! |
|
I also think this feature should be a priority. There's a couple of ways to do it.
|
|
@narcolepticinsomniac why was this issue closed if it is not resolved? It should be left open so someone can see that this is a feature people want… it's harder for someone in the open source community to contribute when they can't see what needs to be done. |
|
It says "narcolepticinsomniac closed this in #787", meaning this issue was automatically closed when the PR which implements this feature was merged into the master. If you can't tell that much, maybe resist the urge to lecture anybody on how open source works. Sync works fine in the master, and should be pushed in an update in the near future. We all took a break over the holidays, and we've run into a minor snag with sync compatibility in Opera and beta. One way or another, we'll work it out, but it isn't even something which can be tested in the master. |
|
This is all I can see in the GitHub Mobile app, my apologies. I based my comment on your initial response above + the issue being closed without knowing why. Now I know that the app leaves out important contextual information, and I'll check the desktop site for things like this going forward. Again, my apologies. Edit 2021-01-28: it looks like the app now shows this information |
|
For those coming here:
|
|
Very cool =) How does it work, where is the PR ? |
|
It was implemented in 2019. Simply use it. |
|
What about Nextcloud? Also, it doesn't seem to work in Vivaldi, at least with Google Drive. It just tries to open some site called "clngdbkpkpeebahjckkjfobafhncgmne.chromiumapp.org", which doesn't exist. |
|
That is a virtual domain used by |
|
As for nextcloud, their API is apparently so complex that it requires using special packages. We're not building an IDE here so ideally adding a new sync client should only require a few lines of code without the need to include special scripts. |
OK, but what about WebDav? I see there is already an issue for that at #1001 |
|
As you can see nothing yet. 99% of sync code is written by @eight04 who doesn't have a lot of time. The rest of us don't use the built-in sync. Personally I think it's even wrong to include this feature as I'm using an automatic backup of the entire user partition for ~20 years. |
|
How would backups help with syncing the styles? |
|
Ah, they won't. My thoughts were about the backup use case, which is not relevant to this topic, sorry. |
Is this somehow possible?
The text was updated successfully, but these errors were encountered: