| Summary: | [feature] - expose API for scripting Latte Docks | ||
|---|---|---|---|
| Product: | [Unmaintained] lattedock | Reporter: | Thomas Anderson <me> |
| Component: | application | Assignee: | Michail Vourlakos <mvourlakos> |
| Status: | REPORTED --- | ||
| Severity: | wishlist | CC: | me |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Thomas Anderson
2021-12-09 04:28:15 UTC
why? personally I dont find any use of this. Why dont you create a layout template and tell Latte from cmd to load it? all the above are already support with layout templates and a lot more that just these actions. waiting feedback >Why dont you create a layout template and tell Latte from cmd to load it?
>all the above are already support with layout templates and a lot more that just these actions.
Well this is intriguing to me... but I can't find any documentation about "layout templates". Are you talking about the files in `.config/latte/*.latte` ?
If so, these are the files I would want to generate using a script. Perhaps I want to dynamically add/remove applications based on what's available on the current system, place docks on all available displays, or do any other thing that I might like to with my docks. Not only that, but the way the template files are structured, they seem to bloat pretty quickly when changes are made (hence the `isInLatteDock` config key in each of the files). By the time you've used and tweaked the dock to your liking, you can end up with a complex file that is difficult to understand, and hard to know what from it is still needed.
At the very least, I wouldn't have to make the template by hand (which is prone to error and forgetting what was set). I could instead have a script that is easy to understand that can replicate my template on any system, regardless of latte version, etc.
Also I've heard that moving these files between systems could cause strange issues (crashes, etc) due to containment ID conflicts or missing .desktop files. Is this not true?
Granting the best case scenario for all of that, how would I "tell Latte from cmd to load it"? Is this using kwriteconfig5? And if so, can I tell it which screen I want the dock on, and can I duplicate the dock as needed from the same script? Can I add an application to the dock using the command line?
I think there's a lot of reasons to provide users with a way to automate the configuration of Latte. As it stands, it is near impossible due to how the config is set up (much like `.config/plasma-org.kde.plasma.desktop-appletsrc`)... but the difference is with that file, you can use plasma scripting to easily add/remove/configure panels and widgets. It is understandable and repeatable across systems. I feel users should be able to do the same thing with Latte... and like I said, the functionality already exists in the code, I just need to be able to "hook" into it from the outside. Whether that's through dbus, plasma scripting, or some bespoke shell utility doesn't really matter, as long as there is a way to do it.
Template files are not generated by hand. We talk about v0.10.x anything older is not maintained to create a layout template: "right click dock -> Layouts -> Edit Layouts... -> Choose the layout that corresponds to your liking -> Export -> Export As Template..." you choose afterwards which applets you want to keep their configuration and you export it. By default they are located at "~/.config/latte/templates" . These layout templates can be used afterwards both from cmd for Latte >=0.10.5 and through the Layouts Editor, with the New button. Docks/Panels in v0.10.x have also gained their own Dock/Panel Editor: "right click dock -> Layouts -> Edit Layouts... -> Choose the layout that corresponds to your liking -> Docks/Panels... you can use that editor to change docks/panels basic settings, create new and move them around to screens. ----------------------------- Concluding your case study seems legitimate so I will leave it open as a feature. For this to be merge, someone must implement it and maintain it for at least a year. Personally I am not interested but if someone steps in to implement it and maintain it, I will accept it. |