User:Chani/WayOfThePlasma/Categories/Toolbox: Difference between revisions
Grundleborg (talk | contribs) m (fix formatting) |
(non-aaron explanation of plasma's modularity) |
||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
==Why can't I remove the toolbox?== | ==Why can't I remove the toolbox?== | ||
===Conclusion=== | ===Conclusion=== | ||
The toolbox is part of the default desktop containment. It cannot be removed from this containment. However, a custom containment does not contain the toolbox by default, so all you need to do is create your own custom containment (or use one created by someone else | The toolbox is part of the default desktop containment. It cannot be removed from this containment. However, a custom containment does not contain the toolbox by default, so all you need to do is create your own custom containment ([http://websvn.kde.org/trunk/playground/base/plasma/containments/blankdesktop/ or use one created by someone else]) which does not have the toolbox in it. | ||
===Original Text=== | ===Original Text=== | ||
Line 19: | Line 19: | ||
<tt>while i don't expect you to have figured the answer out, i do expect you to stop arguing with me about it unless you have an understanding of the architecture.</tt> | <tt>while i don't expect you to have figured the answer out, i do expect you to stop arguing with me about it unless you have an understanding of the architecture.</tt> | ||
'''Sebastian Sauer''' | |||
<tt> | |||
as far as I understood it, it will be possible to disable it. Just not in that way. So, rather then to explicit provide options for everything, someone is able to just use another "desktop plugin". The desktop itself is a plugin just like the panel is. That means, it's easy to provide here additional drop-in "replacments". E.g. one desktop where it's enabled while at another one it's not. That sounds pretty cool to me and follows the logic like we have e.g. with the menu launchers. One for kickoff, one for traditional and even more for other cool things. Everybody is able to choose what matches best here for him. | |||
So, as I understood it, we are switching away from a "there is one monolithic thing and you can configure it" to a "there are plugins and that means it's easy to switch one implementation with another". That this is now extended to even the desktop itself and not only to applets and panels sounds imho like a pretty cool way to provide even more choose while keeping the interfaces small. </tt> | |||
===Sources=== | ===Sources=== | ||
[http://mail.kde.org/pipermail/panel-devel/2008-March/008021.html pannel-devel archive (2008-03)] | [http://mail.kde.org/pipermail/panel-devel/2008-March/008021.html pannel-devel archive (2008-03)] | ||
[http://bugs.kde.org/show_bug.cgi?id=154535#c41 Sebastian's explanation on b.k.o] |
Latest revision as of 12:48, 15 March 2008
Why can't I remove the toolbox?
Conclusion
The toolbox is part of the default desktop containment. It cannot be removed from this containment. However, a custom containment does not contain the toolbox by default, so all you need to do is create your own custom containment (or use one created by someone else) which does not have the toolbox in it.
Original Text
Aaron Seigo
~ we stop this conversation right now, so i can get back to work
~ someone (probably me) finishes up containment setting and switching
~ someone creates a CustomContainment that lacks a toolbox (by default a CustomContainment doesn't have one)
~ you use that containment
see why i don't want to add a configuration option for this? because it's *not needed*. it's not rocket science to realize that adding code paths for something that has a proper set of solutions that have already been designed for from the beginning is stupid.
yeah, i don't expect you to have figured out that the answer is "containment switching, of course!" because that requires a deep understanding of the inner workings of plasma, which you have already said you're not particularly interested in to begin with.
while i don't expect you to have figured the answer out, i do expect you to stop arguing with me about it unless you have an understanding of the architecture.
Sebastian Sauer
as far as I understood it, it will be possible to disable it. Just not in that way. So, rather then to explicit provide options for everything, someone is able to just use another "desktop plugin". The desktop itself is a plugin just like the panel is. That means, it's easy to provide here additional drop-in "replacments". E.g. one desktop where it's enabled while at another one it's not. That sounds pretty cool to me and follows the logic like we have e.g. with the menu launchers. One for kickoff, one for traditional and even more for other cool things. Everybody is able to choose what matches best here for him.
So, as I understood it, we are switching away from a "there is one monolithic thing and you can configure it" to a "there are plugins and that means it's easy to switch one implementation with another". That this is now extended to even the desktop itself and not only to applets and panels sounds imho like a pretty cool way to provide even more choose while keeping the interfaces small.