On Saturday 10 December 2011 13:35:38 Timothy Pearson wrote:
Does it drag in other KDE 4 dependencies?
Obviously it depends on kdelibs and kde-runtime like any KDE
application.
The dependencies will of course be better once frameworks 5 are released.
Considering the impact on a running environment I would say that all depends whether your users are using any KDE 4 applications or none. I would
be
surprised if your users would use no KDE 4 applications. So I think it
is
negligible.
Right away AFAIK we would lose DCOP integration,
which should not be any issue for a window manager. Window managers use X for IPC as well you get D-Bus integration. Given that in the long run you want to migrate to Qt 4 and with that D-Bus anyway this sounds to me like a clear plus.
the window styles that come with TDE
you are aware that KWin 4 ships the same window decorations (some got moved to kdeartworks) plus a theme engine? Do I have to point out that you broke all 3rd party decorations for kwin3 in such a way that kwin won't start if you selected one of those?
, and the kcontrol integration.
Which is no issue as KWin allows to access the complete configuration from each window. You could even ship the old KCMs for KDE 3.5 as those have hardly changed.
Users can already run different window managers (compiz anyone?) so I would say this decision should be made on a per-user basis. A set of instructions on the Wiki for configuring a users' session to use kwin4 wouldn't hurt. ;-)
I can only recommend you to consider this offer from our side. Think about what you actually want for your users. What is really important to you and if you really want to develop a window manager.
Regardless, the process to drop/replace something is not trivial. This project is not like other desktops; we don't just drop or replace things on a whim.
The process would be: 1.) Develop a procedure to replace twin with kwin4 on users' test systems 2.) Those users would need to thoroughly test the replacement for many months, noting any regressions and having them fixed upstream. Upstream's response time and overall regression rate would also be evaluated at this time. 3.) If the replacement after testing looks viable then a deployment procedure would be created. twin would still be available, but kwin4 would be an option, either in build or in package installation (preferred). 4.) If the majority of end-users choose kwin4 at this point, then twin would be deprecated but still maintained as compilable in the TDE source tree.
As you can see this is not trivial. These guidelines are be applied to any integral component of TDE, including the HAL replacement, and are not meant to be an onerous set of rules to prevent progress. Rather they are meant to lessen the possibility of sudden unexpected breakage for corner case users, as has been seen many times before in open source history.
Tim