> On Jan. 26, 2015, 9:08 a.m., Marco Martin wrote:
> > where do you want to use it?
> > Iirc Bhushan is working o a global way to make series of kcms accessible 
> > from plasmoids
> 
> David Edmundson wrote:
>     Generic is always better.
>     KDeclarative is used from places outside Plasma. Applications in future 
> will need to open KCMs too.
>     If we put it in Plasma in one year we'll end up with this anyway and we 
> end up maintaining a weird system used only by us.
>     
>     Also from a discussion on IRC you'll end up guessing the name to put in 
> the UI. This will lead to blocking developers from being able to do the right 
> thing by trying to be too clever.
> 
> Bhushan Shah wrote:
>     My suggestion is to have both this can be used by applets if they don't 
> like solution provided by plasma-framework OR optionally turn this into 
> simple processrunner, there are use cases for both methods
> 
> Marco Martin wrote:
>     apart that reading an "always" makes me cringe :p
>     what I really don't like is the ui inconsistencies that this will cause 
> (an encourages). They will happen anyways true, but at least a timid attempt 
> at fighting that could be done (this was always been a problem in KDE, wasn't 
> it..), creating a path of least resistence and trying to enforce it is an 
> approach.
>     
>     in the end is mostly a technical problem, since the actual proper 
> solution (putting them in the configure dialog) is not possible anymore. if 
> some day this will be possible again (for instance kcms in qml) that should 
> be the preferred way again, so both approaches are in the end just 
> workarounds, so... whatever (/me shrugs)
> 
> Bhushan Shah wrote:
>     Or another option is something like https://paste.kde.org/pirqonxvl 
>     
>     so that you can just do plasmoid.openConfigurationModules()

It would be possible if we made the applet's config dialog a QWidget (the KCM 
container) and put a QML container into that to load the actual config modules 
for the applet. The problem with this approach is that it's the exact opposite 
direction we have been going to, but at least it's not hidden from the API.

I'm not proposing this, just bringing it up since it came up in my head: food 
for thought.


- Sebastian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122239/#review74750
-----------------------------------------------------------


On Jan. 24, 2015, 11:54 p.m., Kai Uwe Broulik wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122239/
> -----------------------------------------------------------
> 
> (Updated Jan. 24, 2015, 11:54 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> -------
> 
> Since there are already like 10 copies of the ProcessRunner for all kinds of 
> plasmoids wanting to open a KCM, this adds a KCMShell.open("foo") and 
> KCMShell.open(["foo", "bar", "baz"]) singleton.
> 
> 
> Diffs
> -----
> 
>   src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 65e28ff 
>   src/qmlcontrols/kquickcontrolsaddons/kcmshell.h PRE-CREATION 
>   src/qmlcontrols/kquickcontrolsaddons/kcmshell.cpp PRE-CREATION 
>   src/qmlcontrols/kquickcontrolsaddons/kquickcontrolsaddonsplugin.cpp 289f1ed 
> 
> Diff: https://git.reviewboard.kde.org/r/122239/diff/
> 
> 
> Testing
> -------
> 
> Works. Dunno if the name causes clashes or this is the right place to put it.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Reply via email to