| Summary: | Profile save/restore of configured widget sets | ||
|---|---|---|---|
| Product: | [Unmaintained] plasma4 | Reporter: | Mamonetti <freddy2_es> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | wishlist | CC: | aseigo |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Mamonetti
2007-12-22 13:11:52 UTC
This is pretty much already possible with the current framework. In your mockup, each square would be an applet and applets of the same color would be using the same data engine - several views on to the same data. Does that sound like it covers what your asking? Well, can you really have a "map" of the current location for each applet? i think that's very important, cause depending on the colors of your desktop and applets it may be difficult to locate all of them (simply think about transparencies) On the other hand it's important that you can save/restore exactly the same configuration that you have. At my desktop example the video player had 3 subareas, but maybe not all them are mandatory. Some people would have defined a set of global keyboard shortcuts so no "control subarea" would be needed, or simply other people should not show the playlist. According to this it would be interesting to add a pair of methods to the interface for "int getCurrentStatusID" and "setStatusID(int)". At the video player getCurrentStatusID could return a value of 1 with the 3 areas visible, 2 with control+video, 3 with only video, an so on. So when loading a profile the manager would need to: 1. launch the plasmoid 2. use the setStatusID with the saved value 3. place every subarea in the right position by calling the setAreaLocation method If all this can be done right now then it's right for me Anyway here are imho the most important topics: - have a visual way to configure and place the plasmoids (also showing which are related, that is, a way to represent multi-area plasmoids or whatever name you use for it) - true save/restore options, assuming that those multi-area can have some of them optional Regards Using your video player widgets as an example, the design is more that the three could be added independently. I don't think being able to save a set of applets and their positions as a profile is on anybody's todo list yet though. > that the three could be added independently. I don't think being able to
> save a set of applets and their positions as a profile is on anybody's todo
> list yet though.
it should actually not be too hard to implement saving the entire plasma
configuration to another file, or loading from one. I'm not sure about saving
just a subset of the running applets.
Anyway, what about being able to control from outside (from the plasmoids manager) the location of each one? for me the "map" feature is very interesting either (as i've said maybe you have some applets very similar to the desktop theme and you really want to know what is desktop and what are applets). Furthermore if you add the 3 parts of the video player with 3 different applets, could all them be launched automatically by adding only 1 plasmoid "pack/theme"? if so, how could you control that maybe only 2 of them should be visible according to the profile that you're trying to restore? Regards erg. i really dislike having this conversations on b.k.o. they don't belong here. anyways, this is one of the things that motivated me to implement single-file load/restore for layouts of applets, containments, etc. plasmoid layout management is one of those things we're working towards. as for "mapping" plasmoids, just do it with the usual drag and drop methods. i don't yet see the need for using layouts for this purpose though that would be easy to add if it becomes apparent that it would be substantially useful. nor do i see the reason to colour plasmoids differently; grouping plasmoids would likely be useful, multiple selection will be coming which may also be necessary. in any case, this BR is an odd mix of multiple requests that will require a series of implementation discussions and patches. i'm not going to close it since some of the ideas are valid, but .. yeah ... i really don't think this is the venue for these discussions. i'll leave the status up to the reporter. > you have some applets very similar to the desktop theme and you > really want to know what is desktop and what are applets). no, one of the plasma ideas is that objects are all equal. there is no difference between "what is desktop" and "what are applets". that is intentional, purposeful and will remain that way. > Furthermore if you add the 3 parts of the video player with 3 different > applets, could all them be launched automatically by adding only 1 > plasmoid "pack/theme"? no reason why not. that could even be done right now with an applet that loads other applets on being started. very easy. > if so, how could you control that maybe only 2 of them should be visible > according to the profile that you're trying to restore? personally i don't think this is a useful level of configurability. it'll just be added complexity (to both user and the code base) that can be easily achieved with a bit of manual work. > > you have some applets very similar to the desktop theme and you > > really want to know what is desktop and what are applets). > > no, one of the plasma ideas is that objects are all equal. there is no > difference between "what is desktop" and "what are applets". that is > intentional, purposeful and will remain that way. sure, it was only related to the time you have to "configure it".. when using plasmoids that's exactly its goal, sure > > > Furthermore if you add the 3 parts of the video player with 3 different > > applets, could all them be launched automatically by adding only 1 > > plasmoid "pack/theme"? > > no reason why not. that could even be done right now with an applet that > loads other applets on being started. very easy. > > > if so, how could you control that maybe only 2 of them should be visible > > according to the profile that you're trying to restore? > > personally i don't think this is a useful level of configurability. it'll > just be added complexity (to both user and the code base) that can be easily > achieved with a bit of manual work. > having a way to load/save config should be implemented or not, but not partially.. if you want to save current status you want it exactly as it is, not "only certain plasmoids because it's easier to implement" maybe the point are not certain aspects of the load/save system, but the system itself.. i can understand you don't want to have this feature (in fact it's not something mandatory), but assuming that you want to it should be right done ______________________________________________ oops, those final lines were automatically added by yahoo, sorry This is possible with current framework, but I think this idea is to complicated, why to split something which is designed to act together? I really don't understand purpose of this feature. If you really love this idea, IMHO the best way to make it happen is to make, at least, prototype in c++/qt4/KDE4/plasma. *** This bug has been marked as a duplicate of bug 132399 *** |