On 22 December 2011 10:16, Martin Gräßlin mgraesslin@kde.org wrote:
On Thursday 22 December 2011 10:00:45 Calvin Morrison wrote:
Hello martin!
I think we will need a private debugging session because after all my attempts, I still cant use kwin with trinity, or within it's own X11 session. I have installed kwin from the Ubuntu mirrors.
Yet when I launch kwin everything sort of freezes up! It's quite strange. I'm running the Intel Sandy Bridge. Both raster and openGL don't work.
I don't know about issues with Sandy Bridge, but I recommend to update the drivers and in doubt disable KWin's compositing support.
KWIN_COMPOSE=N kwin --replace &
Thanks I'll give it a try :)
I think i'll try and spend more time over the holidays working on this. I've also noticed that a large amount of dependencies are pulled in, but probably ones that we can remove with a small amount of work. Any Akonadi or Nepomonk or virtuoso should be avoided.
Two comments towards that:
- this is just a packaging issue. KWin doesn't require Akonadi or Nepomuk.
Though KWin uses Nepomuk if it is available. 2. personal note: the "fear" of Akonadi and Nepomuk/Virtuosu is irrational. Those who oppose it mostly don't understand what it is about. Especially Akonadi is nothing bad but something good. I have worked with Akonadi during my Master Thesis and it's a great technology [1]. It's just that it got some bad press. Nepomuk is one of the primary technologies used by Plasma Active targeted at embedded devices. Somehow that contradicts all the "Nepomuk is slow/wastes memory", doesn't it ;-)
As for the packaging issue, I'd rather let users install the standard Kwin repository provided by their distribution. Maybe we could get a command line setting to disable Akonadi/Nepomuk (or whatever way we can configure it easily) even if it is available? I think that would be a good way to avoid the overhead while still using the upstream packages.
As for Nepomuk/Plasma active - we aren't as semantic desktop and don't have use for the extra services. I am not naysaying them, but I am saying we don't need them ( no demand for them ).
I'm always rather disappointed and feel with the developers when reading comments like that. KWin had to go through something similar and nowadays nobody would call KWin slow or inferior compared to other technologies. I think backing the developers by showing faith in their technology would motivate them to fix the remaining issues to make it technology everybody wants to use :-)
By that I do not request that Trinity should switch to Akonadi or Nepomuk. It's just a hint to be open to new technology and not talking bad about it :-)
I agree with this point. I think we need to guard ourselves against being
close minded about using new technologies, but I do think we need to be very careful if we choose anything.
I'd like to push for this - but only as beta. great :-)
Bug report has been filed to allow for other managers.
I think twin has never failed me as a good, standard, well thought out manager - but it doesn't hurt to explore new options.
Well I know of serious regressions introduced in TWin in comparison to KWin 3. With serious I mean runtime breakage being as severe as TWin no longer starting. I am very concerned about such developments as it harms also the name of KWin. We are known to be a rock solid window manager and I am afraid of a fork introducing patching causing such severe regressions without consulting the KWin development team.
I can't speak about this, I don't know to much.
I want to reiterate how time limited the project is already. I think almost all new features are being pushed back to R14.
Thank you for taking the time to work with us, Calvin Morrison