Version: (using KDE KDE 3.97.0) Hi When reading news about plasma i was really expecting something that would really remove the differences between typical-apps (with their windows, usually very square-like) and desktop-apps (superkaramba themes, for example). This task should be done by plasmoids, but i've found something missing in this engine (imho): As far as i've seen all available plasmoids are in the end like small simple windows. Why can't i split each plasmoid in many different subareas? or assuming you can do it.. how can i control all this? Well, the most important here is the idea (probably needs more job), and is related to have a simple api for controlling multi-area plasmoids (every plasmoid should implement it). Some example code (is written in java, sorry) can be found here: http://phpfi.com/284719 And as a graphical example you can take a look at here: http://img508.imageshack.us/img508/7403/desktopzy8.jpg Every plasmoid is shown using a different color, so the video player hast 3 subareas (i should have changed the color for the "temperature monitor plasmoid" jeje), or 2 for the mail embedded client. This image should look pretty similar to the "plasmoids manager", that should show a map of the running plasmoids, so you would be able to locate each subarea the way you like, even moving them directly from the manager. And thx to another user from kde@irc.freenode.org (holycow) i've seen another extra feature interesting, that is, being able to have a set of "profiles" that would include both the set of plasmoids running each time and also the location for each of its subareas. This system could really help to really embed apps in the desktop. What do you think? Regards
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 ***