On Thursday 01 May 2014 17:25:27 Daniele wrote:
Il 01/05/2014 12:20, Jos Poortvliet ha scritto:
On Monday 28 April 2014 19:58:27 Daniele wrote:
Il 28/04/2014 17:56, šumski ha scritto:
On Monday 28 of April 2014 10:37:44 Anton Aylward wrote: ...
All this is just an example of how determining options at run time rather than compile time gives more flexibility.
Indeed. And also creates a maintenance nightmare.
Why ? I think that only basic widely used features should be hardcoded, everything else should be a runtime dep, maybe plugin based.
Funny thing is: Baloo and Akonadi are exactly what you want: modular, super complex. That is why they have been so problematic for so long: it is very hard to get such a flexible, plugin based technology stable and performant. No they are not, I cannot choose an alternative to akonadi/baloo without touching code...
They have a lot of choice in the back end for developers. Multiple databases can be used, multiple indexers... Having alternatives to baloo would be up to application developers, create a plugin mechanism in their applications etc. I'm quite glad they don't, I'd rather have one thing work well than 10 things that don't... It took years to get this one thing to work half-way decent, imagine we added even more complexity.
Making everything runtime/plugin based increases complexity. If you want it simple, fast and stable (but not flexible and everything hard coded) use GNOME. Or accept that it takes a bit longer and that it takes more testing (did you help test?) to get it right the way KDE is doing it.
Daniele.
I accept the situation 'cause there are not better alternatives. I have some hopes in lxqt.
Daniele.
-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org