Persisting tiles config across launcher app switches about plasma-applet-tiledmenu HOT 3 OPEN

Now is there no way to persist the tile configuration when switching to an alternative launcher and back to tiled menu?

No, because the other menus only store the favourites as a list of urls. And newer versions store the favourites in a SQLite database using a C++ QML plugin.

I could save the JSON to a file using python or some roundabout method, but that's more effort than I'm willing to do for a new user removing the widget, sorry.

from plasma-applet-tiledmenu.

Thanks. I don't think the usability effect is that trivial as a user might spend good time arranging their tasks and configuring the launcher, and then lose all of it without warning by trialing another launcher and switching back.

Please allow me to explore this a bit further, as I or someone else might get a better idea about implementation. So I understand from what you wrote that there's an easy implementation used by other menu applets that just stores the favorites as a list of URL's in a SQLite table, and that in your case you're using a Json representation because of the more involved config. Wouldn't it then be trivial or not too effortful to map the Json into a list of URL's with the extra per task config added as parameters for each URL, and then use the the available QML plugin persistence mechanism?

Cheers.

from plasma-applet-tiledmenu.

Wouldn't it then be trivial or not too effortful to map the Json into a list of URL's with the extra per task config added as parameters for each URL, and then use the the available QML plugin persistence mechanism

No. Because it's not just a "list of urls", it's a list of urls, group labels, possibly widgets, and possibly nested folders of urls.

I'm not going to abuse kicker's favourites model. I'm unlikely to use QML's sqlite LocalStorage. I'd probably serialize to a json file.

The major problem with serializing to a persistent file/database, is that you need other widgets (like on a second screen) to communicate with each other. So if you make a change in widget A, there needs to be some sort of signal to widget B to update. You see, deleting a widget A, will create a new Widget B, so they need that persistent data.

• There is no way to do that with writing to a json file with python, without polling the file every second, which is ridiculous.
• Discover a way to hook SQLite row updates with the LocalStorage api... bleh. Would probably be the first person to do that so takes a lot of work.
• Royally abuse the "notes" widget C++ plugin, and require people to install the kdeplasma-addons package to install the widget... No.

The proper way to do this would be through a C++ plugin, which cannot be done as a downloadable widget from OpenDesktop.org without forcing the user to manually compile.

The second proper way would be to write a plasma widget File I/O API for Plasma, then wait for 5.15 to be released before I could start developing on it. That said, the C++ api already exists so they're probably unlikely to approve a patch like that.

Third proper way would be to make this a KDE project and utilize their packaging infastructure, though the obvious Win10 look clone might raise a few alarms so probably best to not do that.

from plasma-applet-tiledmenu.