Closed mdaffin closed 11 years ago
james fantastic.... I will accept it but I was thinking to create a new C++ class e.g. Parameters which is going to handle all the plasmoids properties with Q_PROPERTY in order to be directly accessible from the QML. In that way in Activities.qml the
/-------------------Loading values-------------------/ function setShowWindows(v){ mainView.showWinds = v; oxygenT.windowsChecked = v; } function setLockActivities(v){ mainView.lockActivities = v; oxygenT.lockerChecked = v; }
.......................
can be removed because these values can be directly accessible...
I was thinking the same thing.
I think the best solution would be to write a plasma plugin to expose these values so that the main c++ code does not have to deal with them and the qml code can import them directly (see the homerun widget for an example of this).
This has the advantage of decoupling the qml code from the c++ code more and lets it run in a more independent state (should you wish to create other application that use it, ie a kwin effect).
Michael I dont know about the plasma plugin because I think that in that way we create a singleton between the workflow plasmoids( all the plasmoids will have the same properties right ? ). But the use case for the workflow plasmoid is that the user can add more than one with different values (e.g. one in the dashboard and one in the panel).
For the workareas that we need to be consistent between different plasmoids (e.g. there is a thought to create a new plasmoid like the pager one but for workareas) I believe the road of data engines is the best one...
See #51 for a better solution, I think with this solution these settings will be unique to each plasmoid (though it will need to be tested) I have started an attempt to convert to it now so we should know if it is usable soon.
Cleans up the way the WorkFlow class works mostly with whitespace and saving values.