On Monday 29 March 2010 10:11:02 Will Stephenson wrote: > On Saturday 27 March 2010 15:49:28 Kevin Ottens wrote: > > Let me recap the reasoning: > > - Solid::Control was here to allow having different implementations of > > > > policy agents in the user session; > > > > - The fact is that there's really only one of those agents for each type > > > > (power, network, etc.) so there's no real advantage of exporting a lib; > > > > - If there's no need for a lib, we can just roll it back into each of > > the > > > > agents and make it disappear; > > > > - With the organization we have right now the policy itself is isolated > > in > > > > a kded module anyway so the system abstraction can be done there > > directly; - This way we can still have several competing ui so we don't > > loose that much. > > I've already started squashing the NM 0.8 backend into > Solid::Control::Network*. Dario, this effectively kills your wicd backend > (as well as the NM 0.6 backend) in this design - are you cool with that?
Totally. It would need a complete rework anyway. Just move the code somewhere else, so the day that I start working again on it I have a good reference of at least DBus communication. > Following on from that I will remove much of the abstraction from the > backend parts of NetworkManagement, and if you ever get time to work on > wicd, you will have to replace the whole network management kded module. Ok, I'm completely fine with that > The connection UI and storage will stay in a library as you said that this > would be useful to you as it covers what wicd supports. Definitely. > > Getting rid of two abstractions will simplify the code and increase my > motivation to work on it. Then just go for it, why are you even asking? ;) > > Will > _______________________________________________ > Kde-hardware-devel mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/kde-hardware-devel -- ------------------- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-hardware-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-hardware-devel
