trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: December 2011

Re: Re: Re: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4

From: "Timothy Pearson" <kb9vqf@...>
Date: Sat, 10 Dec 2011 15:27:45 -0600
> On 10 December 2011 15:14, Timothy Pearson
> <kb9vqf@...>wrote:
>
>> > 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
>>
>
> 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