122

An alternative for Gnome Shell:
An Activity-Changer-Plasmoid with Layouts.

The User wrote:Hi!
An Idea for Plasma:
It would be nice to have Plasmoids applying Layouts (horicontal, vertical, grid or maybe others) to the containing Plasmoids. So a better Positioning on the Desktop could be enabled. Also the Workspace could get a Layout, e.g. the classical grid.

This forum was a nice idea.
The User

The New Container-Features:
-Container-Classes where you can easily add Plasmoids
-Applying Layouts to such containers
-Scrolling the Container
-Stacked Plasmoids in the Container
-Invisible Containers
-Applying those features to the desktop and the Panels
-Snapping/Rulers

Isn't this reinventing the application window? Boxes with stuff in that it's possible to scroll, align the stuff, and stack on top of each other? Wouldn't it be better to have a "run plasmoid in window" mode instead? I realise this wound not get all you ask for, but I see the current implemenation of plasmoids as clean, intuitive and beautiful. Maybe it would continue to be that way even after all proposed features are added....

Why could Plasmoids in windows replace layout-managers?
The normal Plasma concept should be used. And then there should be some containers organizing the positions in a certain way.
It would not be any other implementation. Just a few new classes would be used.
I do not see any problem.
Look at the Panels: They already have something like Layouts: Contained Plasmoids are positioned such that the full space is used. Why should not that be possible in a more flexible way for the Desktop and Container-Plasmoids?

User: So, essentially, one more plasmoid called container should be enough? In the container settings there would be: layout settings, hide, etc? So the implementations would only have to be changed so a plasmoid could be put inside these containers?

Do I understand your idea?

I think it is an implementation detail if there should be only one container class.
Of course a container could provide all these features like layouts, hiding and add widget.
But there should also be some subclasses e.g. for Panels or the Desktop.
Then it should be possible to add Layout-Plugins.
You hae basically understood it, but the new containers could also replace the normal Desktop or the normal Panels. (of course the normalones should be still supported) You say "only one Plasmoid", but it would be still a great improvement. It is not important for the idea, if there are 10 Plasmoids or 1 combining all features of those 10. (of course 1 Plasmoid is more flexible)
I am unsure, if the container Plasmoid should support the Stack and Scrolling, there could also be seperate Plasmoids. What is your opinion?

The User wrote:................. What is your opinion?

I just didn't understand very well what it was all about. Plasmoids are still a bit exotic to me, but once I realise I can't live without having 20 some of them running, then, definitly, containers, layouts, scrolling and stacking would be necessary not to drown.

But... there exists normal programs that runs in windows, and there exists plasmoids... This devision of the two must have been conscious choice. In the light of that, giving plasmoids more application-like features, might be the wrong way to go.

It, of course, all comes down to how many people really wants to have 20 some plasmoids running. I'm not one of them, but you idea got lot of votes, so I guess there are some out there .

Another thing... Apple inventend the widget stuff first didn't they? Their users should have been getting dependent on them by now and find more and more over time they would like to use. If any desktop would be filled with widgets needing arranging it should be an OS X one. Is there a OS X user willing to speak up about their widget experience?

I'm neutral, but curious, about this idea.

PS Developer considerations:

* Can a plasmoid be placed inside another right now?
* Would there have do be done any changes at all to the plasmoid framework itself or is it just the plasmoids that need to be written? (Not talking about the more extensive idea of placing desktop and panels with subtypes).
* Would it work with things not plasmoids like OS X widgets (that as far as I know, is supposed to work in KDE)?

I'm a Mac OS X user (sometimes).
I think the Mac OS X Dashboard is very chaotic. Maybe you can somtimes arrange them in a nice way, but then you open 2 new widgets and you do not see anything. It's more chaotic than in Plasma, because you have only one Dashboard and not the Desktop or Activities and you can't even scale the widgets.
The first Dashboard-Version was released in 2005, even SuperKaramba was founded in 2003. I think there are also elder Widget-Systems.

20 Plasmoids, that is a small number, if you guess icons and Plasmoids inside Panels.
Just a little example: I have 8 icons for my favourite apps and folders on the Desktop aligned in two rows. With a Layout-Manager I could easily move and rotate them or even add more icons without losing the alignment.

Layouts are not bad: They are already used in the Panels: There is no free space in a Panel.
Don't you align Plasmoids?
Plasma is also used in windows (-> Amarok), Layouts are not specific for normal interfaces.
The role of normal window-applications is not affected by the usage of layouts inside Plasma. It would just improve the usability of the existing Plasmoids.

The Considerations:
-In C++ it is no problem to create a Plasmoid inside anotherone, but I don't know, if the plasma-desktop-appletsrc supports this, Panels aren't normal Plasmoids
-Maybe there would be changes in the configuration and of course the desktop and panels as containers would also cause changes
-Inside C++ every Plasmoid-Type is a Plasma::Applet handled in the same way. But for each Plasmoid there is specific code for drawing and proceeding events (pressed keys, mouse moving). For all MacOS X-widgets there is only one C++-Plasmoid called DashboardApplet, which can be handled like any other Plasmoid, it just uses the Widget's JS and HTML for drawing. So it is no problem. Maybe you have already seen that Dashboard-Widgets and Google-Gadgets can be scaled and rotated inside Plasma. So a Layout-Manager should also be able to scale them.

The Plasmoids provide any feature needed by a layout-manager.

The User

Thanks for explaining!

You got my vote +1.

Do you think there should be special "Plasma Layout Plugins"?

@bratwurst
Thanks.

The User wrote:Do you think there should be special "Plasma Layout Plugins"?

@bratwurst
Thanks.

Really have no idea. From my point of view a container with layout would be sufficient to solve the "chaos" problem. As I said, plasmoids are still kind of exotic to me. I think you have to ask that question to the other visitors of this thread.

"you" can be a plural-form.
I think there should be a simple interface for Layout-Plugins.
The simple implementations could directly use Qt's graphics-layouts.
But they would not have to use them. The graphics-layouts does not really fit into Plasma, because they are items themselves. That's not good for an universal container.

Is there anybody who would implement parts of such containers?
After next monday I'll have a lot of time for containers.

There seem to be other persons who want to have layouts, too.

Sorry, but I have not received any reply in the API-subforum or IRC #plasma:
An most important requirement for those Layots would be the ability to add Applets to a normal containment.
I think the Layout-features should be added directly to Plasma::Containment, because then it would be useful for Desktop and Panel.
Currently it's possible to place a containment on the Desktop. But it is not possible to place Applets inside such containments.There is a very deep delegation for displaying the "Add Widgets"-dialog. I definitely do not understand it.
Maybe this indirect way is useful for very different containment. For example the Amarok-containment needs another "Add Widgets" behaviour then the Panel, it also need other widgets. So I think the type of widgets should be inherited from the parent-containment. Could anybody explain me, how to implement this behaviour? I would love it to start with Layouts.

Currently there is no way (without editing Corona) to have containments inside containments. You can inherit from Plasma::Containment and place it on the desktop. But features like the "add widgets"-dialog aren't available. Now it would be possible to do something hackish. When the applet receives move-events all the Sub-Plasmoids are moved. But that would be really bad. I think such dialogs should be inherited from the parent-containment. Then the internal object-tree-structure of every Plasmoid could be used for these containments. Do you think there could be a way to do that in Plasma? It's a limitation of Corona. Sub-Containments are handled just like normal applets (isContainment = false) and they don't even get the possibility to have child-Plasmoids. I think those limitations should be removed to create a proper layout-implementation.

TheUser: are you still working on this?

containments in containment aren't, and probably will never be, supported. but applets in applet are. that's what the Container plasmoid does (http://kde-look.org/content/show.php/Co ... ent=112094), but this design brings some problems. see http://mail.kde.org/pipermail/plasma-de ... 08052.html for further explaining.
So i think a better way to go would be to embed the layouts directly inside the various containments or inside the containment class in libplasma and enable them through some option