10 Dec
2011
10 Dec
'11
9:27 p.m.
On 10 December 2011 15:14, Timothy Pearson
<kb9vqf(a)pearsoncomputing.net>wrote;wrote:
use X
about
I always seem to miss the most interesting posts while I'm at work!
I have actually had a mostly good experience with KWin from the 4.X series
( maybe 4.6? ). That being said I'd really like the option to be able to
run any window manager. Often I used to run Openbox with Gnome and I think
many other users have done this (think compiz etc).
Wouldn't it be the best option to let users pick any one they wanted?
Obviously the side effect is that they loose their kcontrol integration,
but that's that.
Honestly, I miss fvwm :P
Calvin Morrison
Now that I could see as a simple yet very useful enhancement for
R14.0--the ability to configure/select the WM executable in kcontrol. Can
you file a bug report requesting this ability?
Thanks!
Tim
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 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.
broke
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 all
3rd party decorations for kwin3 in such a way that kwin won't start if
you
selected one of those?
from
, and the kcontrol integration.
Which is
no issue as KWin allows to access the complete configuration 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 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