10 Dec
2011
10 Dec
'11
6:35 p.m.
Hi Trinity developers,
first of all: this is a serious suggestion and no try to troll you or anything
in that area.
Today I did some bug triaging for old bugs reported against KWin. With old I
mean bugs reported against KDE 3.1 till 3.5. While I did that I realized how
many bugs we fixed in the window manager after the release of KDE 4. All of
those bugs are still valid for KDE 3.5 and your users do not benefit from the
fixes done by us. The last commit done to KWin 3.5 was on October 3rd 2008[1].
Since then we fixed 617 bugs[2] and implemented 119 user wishes[3]. Just think
about theses numbers. All those fixes your users are missing... I also just
did a short count on our commits and only last month we had more than 50
commits, although we entered feature freeze. You see KWin is an active,
maintained and developed project.
Some weeks ago I heard that Krita developers requested a different name for
the fork in Trinity, so I did the same for the fork of KWin. Reason was that I
had looked at some commits done to the fork some time ago and considered them
all in the area from plain wrong to harmful. I just wanted to make clear that
we as upstream developers do not have anything to do with the development of
this product especially as none of the patches were presented for review (all
changes to KWin are peer reviewed).
I had been thinking about the Trinity/KWin relationship for quite some time
and todays triaging showed me that this just does not make sense. I do
understand that you want to provide a KDE 3.5 desktop experience. This is
great and I am all for it. But KWin 4 is a clear continuation of KWin 3. It is
not a rewrite like other parts of the desktop. It is the same application,
with more features, less bugs and in general a better performance. I am only
aware of one feature that got dropped from KWin 4 and this could be easily
maintained in a separate branch.
Working on a window manager and compositor comes with great responsibility. It
is one of the most complex parts of the desktop environment and introduced
bugs affect all users and can be really harmful and very difficult to debug.
Developing a window manager is not trivial and you have to understand how the
window manager works, which - with all respect - is not the case in twin[4,5].
This is not surprising - it took me more than two years to learn KWin and
there are still many areas where I am glad to have a team which can review
suggested changes.
Therefore I suggest to you to discontinue the work on twin and instead switch
to KWin 4 as provided, developed and maintained by the KDE community. We are
currently the window manager to three different desktop environments ranging
from mobile to desktop. I am sure that we can support a fourth one which used
to be the only one some time ago.
For Trinity this gives about 60 kSLOC less code to maintain and develop. It
removes one of the most complex parts and gives you the possibility to work on
what really matters: providing a KDE 3.5 desktop experience by maintaining and
improving kicker and kdesktop.
Kind Regards
Martin Gräßlin
KWin maintainer
[1] http://websvn.kde.org/?view=revision&revision=867241
[2]
https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=…
[3]
https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=…
[4]
http://git.trinitydesktop.org/cgit/tdebase/commit/kwin?id=1f40ada72d693d681…
[5]
http://git.trinitydesktop.org/cgit/tdebase/commit/kwin?id=9cc1e2c1aa2629d49…
10 Dec
10 Dec
6:56 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
I had been thinking about the Trinity/KWin
relationship for quite some time
and todays triaging showed me that this just does not make sense. I do
understand that you want to provide a KDE 3.5 desktop experience. This is
great and I am all for it. But KWin 4 is a clear continuation of KWin 3. It is
not a rewrite like other parts of the desktop. It is the same application,
with more features, less bugs and in general a better performance.
Hi Martin,
What you're proposing makes sense, on the face of it. And I ask these
question not as a troll or flame - and not from the perspective of really
knowing what the KWin component is responsible for:
Is the binary size and performance (desktop latency) going to be
comparable?
Does it drag in other KDE 4 dependencies?
- Nigel
7:16 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Saturday 10 December 2011 12:56:07 Nigel Stewart wrote:
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.
Martin
I had been
thinking about the Trinity/KWin relationship for quite some
time
and todays triaging showed me that this just does not make sense. I do
understand that you want to provide a KDE 3.5 desktop experience. This is
great and I am all for it. But KWin 4 is a clear continuation of KWin 3.
It is not a rewrite like other parts of the desktop. It is the same
application, with more features, less bugs and in general a better
performance.
Hi Martin,
What you're proposing makes sense, on the face of it. And I ask these
question not as a troll or flame - and not from the perspective of really
knowing what the KWin component is responsible for:
Is the binary size and performance (desktop latency) going to be
comparable?
Does it drag in other KDE 4 dependencies?
- Nigel
7:53 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Saturday 10 December 2011 20:32:16 Werner Joss wrote:
On Saturday 10 December 2011 20:16:39 Martin Gräßlin
wrote:
May I ask why?
I would be
surprised if your users would use no KDE 4 applications. So I think it is
negligible.
YMMD :)
werner
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net Read list messsages on the
Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not
to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
7:35 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
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.
7:52 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Saturday 10 December 2011 13:35:38 Timothy Pearson wrote:
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.
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. 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.
Martin
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net Read list messsages on the
Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not
to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
8:14 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Saturday 10 December 2011 13:35:38 Timothy Pearson
wrote:
application.
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.
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
Does it drag in other KDE 4 dependencies?
Obviously it depends on kdelibs and kde-runtime like any KDE 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, 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.
9:22 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On 10 December 2011 15:14, Timothy Pearson <kb9vqf(a)pearsoncomputing.net>wrote;wrote:
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
On Saturday 10
December 2011 13:35:38 Timothy Pearson wrote:
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
> 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, to
migrate to Qt 4 and with that D-Bus anyway this sounds to me like a clear
plus.
you
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 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.
about
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
9:27 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
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
10:03 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Saturday 10 December 2011 15:27:45 Timothy Pearson wrote:
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?
You know that such a configuration
module exists and that there is no need to
ask for the executable, right? You can just specify the desktop files. To be
precise: you have to specify a desktop file as it won't work with a binary...
Martin
10:12 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Saturday 10 December 2011 15:27:45 Timothy Pearson
wrote:
Where? At the very least it needs to be moved to a more logical place as
I have never seen it in the years that I have been using KDE/TDE.
And yes, I am fully aware of the internals of TDE and the fact that WMs
can be autodetected with the .desktop files. I mentioned the end effect
(the user can choose which WM executable to use) to be precise.
Tim
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?
You know that such a configuration
module exists and that there is no need
to
ask for the executable, right? You can just specify the desktop files. To
be
precise: you have to specify a desktop file as it won't work with a
binary...
Martin
11 Dec
11 Dec
5:18 a.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On 10 December 2011 17:12, Timothy Pearson <kb9vqf(a)pearsoncomputing.net>wrote;wrote:
Unfortunately .desktop files won't work for all WM's. I think it would be
simpler to just have a command line option. this also makes it easy to use
certain flags for your WM
On Saturday 10
December 2011 15:27:45 Timothy Pearson wrote:
need
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?
You know that such a configuration
module exists and that there is no to
ask for the executable, right? You can just specify the desktop files. To
be
precise: you have to specify a desktop file as it won't work with a
binary...
Martin
Where? At the very least it needs to be moved to a more logical place as
I have never seen it in the years that I have been using KDE/TDE.
And yes, I am fully aware of the internals of TDE and the fact that WMs
can be autodetected with the .desktop files. I mentioned the end effect
(the user can choose which WM executable to use) to be precise.
Tim
9:18 a.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Sunday 11 December 2011 00:18:39 Calvin Morrison wrote:
*sigh* it *has* to be .desktop files as that's how
the code to start another
window manager works. And yes each window manager can be started with a
.desktop file. If not the window manager is so broken that you cannot use it
for TDE anyway.
Where? At the
very least it needs to be moved to a more logical place as
I have never seen it in the years that I have been using KDE/TDE.
And yes, I am fully aware of the internals of TDE and the fact that WMs
can be autodetected with the .desktop files. I mentioned the end effect
(the user can choose which WM executable to use) to be precise.
Tim
Unfortunately .desktop files won't work for all WM's. I think it would be
simpler to just have a command line option. this also makes it easy to use
certain flags for your WM 
4:44 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Sat, Dec 10, 2011 at 9:22 PM, Calvin Morrison <mutantturkey(a)gmail.com> wrote:
Honestly, I miss fvwm :P
*waggles eyebrows*.... if you're serious about that, try this:
http://lkcl.net/.fwvm2rc - the main thing is the 6x4 desktop (line 9)
- the rest is pretty standard stuff... err... from 8 years ago - been
using it and happy with it ever since :)
l.
11:38 a.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Saturday 10 December 2011 14:14:50 Timothy Pearson wrote:
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.
Once again: kwin4 is the continuation of kwin3. It is the same
application!
This would not be anything like "drop or replace things on a whim". (Btw. this
sounds like a reference to KDE 4. I would suggest you to get away from such an
attitude if you want to be on good speaking terms with KDE. Nobody in KDE
replaces 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.
To make it quite clear: we have our own release cycle and our own goals.
There
is no way to tell us that we have to fix specific bugs. We fix bugs based on
how many users are affected or if we think it is a bug which needs to be fixed
based on our goals.
If Trinity needs Trinity specific patches to KWin those would have to go into
a branch.
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.
I think that
this process would not apply to such a change. Once again: it's
the same application. I'm not asking you to replace twin by Compiz or any
other window manager. It is just a later version. It's nothing like developing
a new system such as udev support in replacement of HAL.
Once again I urge you to think about what you want to achieve and what you
want to provide to your users.
"This project aims to keep the KDE3.5 computing style alive, as well as polish
off any rough edges that were present as of KDE 3.5.10. Along the way, new
useful features will be added to keep the environment up-to-date."
KWin4 still offers the same KDE3.5 computing style, but is highly polished and
many rough edges which were present as of KDE 3.5.10 were removed. Just think
about the 600 fixes I mentioned in my first mail.
I think that you want to provide the best possible KDE 3.5 computing
experience to your users. Do you have to develop your own window manager for
that? Do you have to work on a field which you do not understand? Is it not
better to use what KDE provides in that area? An actively developed and
maintained window manager with developers working for years on window
managers?
I don't care what you want to develop on. I just see that you are not able to
develop a window manager and what I offer here is help. Help to no longer need
to develop a window manager. You can think about it and come to your own
conclusion, or block everything without even considering it by just mentioning
formal processes.
Think about what you want to achieve. What is the long term goal of Trinity.
Somehow I have the feeling that you never really thought about where to go in
two, three years.
Kind Regards
Martin Gräßlin
4:50 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Sun, Dec 11, 2011 at 11:38 AM, Martin Gräßlin <mgraesslin(a)kde.org> wrote:
If Trinity needs Trinity specific patches to KWin
those would have to go into
a branch.
... where it would be better than nothing but would still ultimately
end up as bit-rot unless extreme care was taken. whether the code
ends up as bit-rot or ends up properly incorporated into KDE very much
depends on whether the KDE team can develop trust of the Trinity team.
as it would be a step in the right direction, can i recommend to the
trinity desktop developers to consider taking up this offer, if it is
at all possible? it's still possible to use git-svn btw.
l.
5:31 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Sunday 11 December 2011 16:50:09 Luke Kenneth Casson Leighton wrote:
On Sun, Dec 11, 2011 at 11:38 AM, Martin Gräßlin
<mgraesslin(a)kde.org> wrote:
KWin
currently comes in master in two flavors and we are able to support that.
As well we currently have one long-living branch and due to feature freeze
several short living branches.
As long as Trinity developers follow the KWin development on the files they
change from time to time there should not be any problem. Even merging could
be done automatically.
Martin
If Trinity needs Trinity specific patches to KWin
those would have to go
into a branch.
... where it would be better than nothing but would still ultimately
end up as bit-rot unless extreme care was taken. whether the code
ends up as bit-rot or ends up properly incorporated into KDE very much
depends on whether the KDE team can develop trust of the Trinity team. 
7:19 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
Martin Gräßlin wrote:
On Sunday 11 December 2011 16:50:09 Luke Kenneth
Casson Leighton wrote:
The offer of a special branch seems nice. I suppose that the kwin
dependencies on libraries like kdelibs and Qt may not be that
sophisticated that it would be possible to have a KWin version that
compiles against the Trinity equivalents of these libraries. Maybe with
trivial improvements on both sides, for example making certain Trinity
APIs more KDE4-like or disabling certain advanced features on the KWin
side (when compiling with Trinity), I could imagine the current KWin
versions could be made source compatibile with Trinity.
In the end, the main question is whether it will be easier to maintain
Trinity's TKWin or enabling source compatibility with KDE4's KWin. If
you consider all the Freedesktop specs and how subtle WM bugs can be
with different applications, I can imagine the second option is indeed
the most attractive long term.
On Sun, Dec 11, 2011 at 11:38 AM, Martin Gräßlin
<mgraesslin(a)kde.org> wrote:
KWin
currently comes in master in two flavors and we are able to support that.
As well we currently have one long-living branch and due to feature freeze
several short living branches.
As long as Trinity developers follow the KWin development on the files they
change from time to time there should not be any problem. Even merging could
be done automatically. If Trinity needs Trinity specific patches to KWin
those would have to go
into a branch.
... where it would be better than nothing but would still ultimately
end up as bit-rot unless extreme care was taken. whether the code
ends up as bit-rot or ends up properly incorporated into KDE very much
depends on whether the KDE team can develop trust of the Trinity team.
8:29 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Sunday 11 December 2011 20:19:31 Julius Schwartzenberg wrote:
The offer of a special branch seems nice. I suppose
that the kwin
dependencies on libraries like kdelibs and Qt may not be that
sophisticated that it would be possible to have a KWin version that
compiles against the Trinity equivalents of these libraries. Maybe with
trivial improvements on both sides, for example making certain Trinity
APIs more KDE4-like or disabling certain advanced features on the KWin
side (when compiling with Trinity), I could imagine the current KWin
versions could be made source compatibile with Trinity.
Disabling parts of KWin is
certainly the way to go. That's what we already do
for Plasma Active (our mobile offerings). So this is certainly possible.
Now here the list of libraries KWin links against (from CMakeLists)
* ${KDE4_KDEUI_LIBS}
* ${KDE4_PLASMA_LIBS}
* ${KACTIVITIES_LIBRARY}
* ${QT_QTDECLARATIVE_LIBRARY} and kdeclarative
* kephal
* kworkspace
* kdecorations
* kwineffects
* ${X11_LIBRARIES}
* ${X11_Xrandr_LIB}
* ${X11_Xcomposite_LIB}
* ${X11_Xdamage_LIB}
* ${X11_Xrender_LIB}
* ${X11_Xfixes_LIB}
* ${QT_QTSCRIPT_LIBRARY}
* ${QT_QTXML_LIBRARY}
* ${OPENGL_gl_LIBRARY} or ${OPENGLES_LIBRARIES}
Some remarks for the specific imports:
= KDE4_KDEUI_LIBS =
Required for KWindowSystems. It is possible to split this out as done for
WMIface[1]. So that it is a Qt only dependend library. For Frameworks 5 it
will become an own library.
= KDE4_PLASMA_LIBS =
Required for integration parts in the effects and some other parts. Most
likely we will be able to drop this dependency in 4.9 as we migrate these
parts to QML and Plasma would only be a runtime requirement. This could be
replaced by Trinity with QML files not using Plasma
= KACTIVITIES_LIBRARY =
Integration with Activities. Can be patched out.
= QT_QTDECLARATIVE_LIBRARY and kdeclarative =
In fact could be patched out, but not without losing large parts (e.g.
Alt+Tab).
= kephal =
Small library for screen handling. Depends itself only on Qt and KDE_UI.
= kworkspace =
Some small libraries. Not sure at the moment why we need them (I think it was
just for KActivities and they got moved out).
= kdecorations and kwineffects =
KWin internal
= Xlib stuff =
Yes we want that ;-)
= QT_QTSCRIPT_LIBRARY =
Already optional for scripting support.
= QT_QTXML_LIBRARY =
Will be dropped in 4.9
= OpenGL or ES =
both optional
Overall the dependencies to kdelibs will become better once Frameworks 5 is
out. We currently have no plan to add more dependencies except Wayland ;-)
So I think from a Trinity perspective only the "Plasma" part is probably
something not liked and that is probably going away or easily to patch out. It
is only used for Plasma styled graphics view and I want to get rid of graphics
view in the next cycle.
Cheers
Martin
[1] http://blogs.kde.org/node/4016
In the end, the main question is whether it will be easier to maintain
Trinity's TKWin or enabling source compatibility with KDE4's KWin. If
you consider all the Freedesktop specs and how subtle WM bugs can be
with different applications, I can imagine the second option is indeed
the most attractive long term.
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net Read list messsages on the
Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not
to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
4:41 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Sat, Dec 10, 2011 at 7:52 PM, Martin Gräßlin <mgraesslin(a)kde.org> wrote:
don't get me started on d-bus :)
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
no, martin, they don't. they want to use QT3, stay there, and
continue to maintain QT3 as a proper honest-to-god _real_ and _active_
Free Software Community Project (*1). it consumes significantly less
resources. you remember KDE 3 minimum requirements from 8 years ago?
i do. 500mhz Pentium III and only 128mb of RAM.
l.
(*1) nokia / trolltech's one-way-push of source code - 6 months late -
is *not* a community-driven project.
5:27 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Sun, 11 Dec 2011 16:41:22 +0000
Luke Kenneth Casson Leighton <luke.leighton(a)gmail.com> wrote:
On Sat, Dec 10, 2011 at 7:52 PM, Martin Gräßlin
<mgraesslin(a)kde.org>
wrote:
don't get me started on d-bus :)
I doubt it ran well with such
hardware; I already tried to use KDE 3.1
with a 350MHz K6-II and 224 MB RAM and it was dog slow compared to
the old GNOME2 provided by the distribution (distribution: Mandrake
9.1). As a comparison, I already ran the Fedora 14 KDE LiveCD (KDE
4.5.2) with a 2004 entry-level desktop (2,4 GHz Celeron, 256 MB RAM)
and the performances were better than Mandriva 2006 (KDE 3.4.2) as a
LiveCD on the K6-II.
That's all for KDE3 supposedly being incredibly lighter than KDE4 (and
no is isn't the graphics card, unless you consider an Intel 845G as a
good graphics card).
There are only a few things that are missing from KDE4 to be a really
great desktop out of the box:
-sane default options
-good graphics drivers on the underlying OS
-sane default options
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
no, martin, they don't. they want to use QT3, stay there, and
continue to maintain QT3 as a proper honest-to-god _real_ and _active_
Free Software Community Project (*1). it consumes significantly less
resources. you remember KDE 3 minimum requirements from 8 years ago?
i do. 500mhz Pentium III and only 128mb of RAM.
l.
(*1) nokia / trolltech's one-way-push of source code - 6 months late -
is *not* a community-driven project.
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
4:37 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Sat, Dec 10, 2011 at 7:35 PM, Timothy Pearson
<kb9vqf(a)pearsoncomputing.net> wrote:
Right away AFAIK we would lose DCOP integration,
if that's inevitable, can i recommend using FreeDCE [with a temporary
DCOP "wrapper" to help provide a transition]?
you would then gain the benefit of being able to run entire
applications remotely: remote admin would become an accidental
feature. and no, it's *not* the same as running X-Windows or VNC
remotely: the amount of network traffic generated by an application
using DCE/RPC is vastly less, giving much lower latency and
responsiveness, because the GUI portion runs on the sysadmin's *local*
system, but the actual configuration etc. takes place actually on the
*user's* machine via a FreeDCE-ified service.
l.
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.
11:17 a.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
Martin Gräßlin wrote:
On Saturday 10 December 2011 12:56:07 Nigel Stewart
wrote:
Some system on which I run TDE are very memory constrained. They have
only 128MB maybe 256MB of RAM. On such systems I do not tend to have any
KDE 4 applications installed.
It's definitely true that window managers are very difficult to
maintain. I know that some tests in Wine's test suite were failing on
kwin in Trinity because of bugs that had only been fixed in kwin for KDE
4. I wonder how strong the newer kwin series depend on KDE 4 and whether
it could be made to compile against Trinity as well.
In any case good integration between KDE 4 and Trinity components so
they can be mixed already seems good at least for high end systems.
Julius
What you're proposing makes sense, on the
face of it. And I ask these
question not as a troll or flame - and not from the perspective of really
knowing what the KWin component is responsible for:
Is the binary size and performance (desktop latency) going to be
comparable?
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.
4:32 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Sat, Dec 10, 2011 at 6:35 PM, Martin Gräßlin <mgraesslin(a)kde.org> wrote:
Hi Trinity developers,
Therefore I suggest to you to discontinue the work on
twin and instead switch
to KWin 4 as provided, developed and maintained by the KDE community. We are
martin,
i was happy to accept - with reservations - what you were saying
right up until the point where you effectively ordered everyone to
quit.
the gist of your message is as follows:
a) you (twin developers) are making mistakes
b) you cannot be trusted not to make mistakes
c) it's a big responsibility and i believe that you're not up to the job
d) therefore you should quit.
i was prepared to accept that you are perfectly within your rights to
say that mistakes are being made, and it is very useful for you to do
so. however you have absolutely NO right to suggest, recommend, tell
or otherwise imply that the twin developers should do something other
than what they are doing.
now it's my turn to give you a reality-check.
i've been following KDE for a long time, and loved it - it was my
default desktop that i put in front of average users, and i even wrote
an automated debian installer system http://lkcl.net/d-i which did
extensive customisation and package installation. i've done quite a
few bugfixes, including in kdm for use with SE/Linux, and i've done
superkaramba development.
then i heard about plasma, and was initially very enthusiastic (i'm
also a python developer) but the more i learned about it, the more
alarmed i became.
then i heard about the EU Framework funding, and was initially very
enthusiastic, but the more i learned about the direction being taken,
the more alarmed and concerned i became.
then i heard that the KDE team wanted to adopt the entirety of QT4
into libkde and maintain it as part of libkde and i began to realise
that there was something deeply, deeply wrong with KDE's development
direction.
KDE 4 came about at a time when windows vista had just been released.
somewhere, someone decided that it would be a good idea to copy the
UI of windows vista. if i had been consulted, i would have told
whoever who was prepared to listen that this would be a seriously bad
move.
unfortunately, you didn't ask, and so didn't hear, and the
train-wreck just had to proceed. basically, windows vista quickly
became the most hated version of the windows UI ever to hit the
planet... and KDE 4 copied it.
the problem is compounded by the fact that i'm hearing reports that
the key developer behind plasma is basically behaving like a fucking
idiot. just looking at the plasma API and its verbosity makes me
throw up my arms and walk away, so i'm not even going to _remotely_
get involved with plasma or any plasma application development, even
though it would represent an opportunity to write a from-scratch
complete replacement for the existing KDE4 dog's dinner desktop
paradigm with something that i would find palatable.
btw it's also worthwhile reiterating that i did an install of
debian-squeeze recently for a friend. it installed KDE 4 without my
knowledge, and, because their network connection was so slow (15k/sec
- they live in a very remote area) i couldn't get them a replacement
desktop in time. KDE4 was so bad that, *without* telling me they took
the machine to an incompetent who DESTROYED all the work that i'd done
and replaced it with vista.
my friend is now no longer speaking to me because they believe that
it was "my fault" that the virus destroyed their windows partition in
the first place, and that i must have taken advantage of them somehow,
to try to peddle such a deeply-shit replacement desktop at them.
example: we tried for 15 minutes to set the wallpaper. there wasn't
even a menu option anywhere to do it. everything that should have
been intuitive and obvious wasn't. there wasn't a control panel
option to manage the desktop. there wasn't a right-mouse context
option on the desktop itself to set the wallpaper.
example: we tried to mount an NTFS partition (their old windows data
drive). was there any obvious way to do it? was there fuck. did the
drives appear automatically on the desktop? did they fuck.
the whole exercise was a complete utter failure. i couldn't even
tell them how to run applications. i had to press ctrl-alt-f1 and go
and manually locate firefox.desktop in /usr/share/applications, and
copy it into their home directory.
_everything_ about KDE4 was a complete utter failure - it was the
worst desktop "manager" i've ever encountered in my life, and i had to
find this out right in front of a friend who was trusting _me_ with
their precious documents that had not been backed up.
i trusted _you_ - the KDE developers who had been funded to the tune
of $EUR 10 million - to do a decent job, and you completely and
utterly failed to do that.
now in that context, you might now appreciate why i may be taking a
dim view of KDE developers telling the Trinity Desktop developers that
they should "quit".
here's what i believe that _you_ should be doing, in a series of alternatives:
* you should consider dropping - entirely - the KDE4 codebase and
return to KDE 3.5. i am deadly serious.
* you should make room for the Trinity Desktop developers to
accommodate the KDE 3.5 applications within the KDE4 infrastructure.
* you should make room for the KDE codebase to be compiled
successfully with QT3 (so that the Trinity Developers don't have to do
it).
* you should abandon the KDE codebase entirely and join the Trinity
Desktop team.
* you should help the Trinity Desktop team by keeping an eye on them
and doing specific code-reviews and making useful bugreport comments
so that they don't make mistakes (that took you 2 years to learn
about).
* you should add comprehensive (automated) unit tests to KDE so that
the Trinity Desktop team can pick those up and ensure that the code
that they develop has self-checking.
just one last thing: you have to bear in mind that i am an embedded
systems developer, as well as many other things. i've compiled
pywebkitqt4 for a (very good) 400mhz ARM9 that had access to 800mhz
DDR2 RAM. pywebkitqt4 ran so slowly that it put the entire project
into jeapordy. qt4 itself consumed vast amounts of resources (over
128mb of RAM), and took over 90 seconds to start up.
an analysis of the various options (pywebkitgtk and webkit for
enlightenment) wasn't much better, but it wasn't 256mb of RAM. i then
had to help the directfb developers port webkit to directfb, and the
startup time was reduced to under 6 seconds, and the RAM used reduced
to about 128mb (GTK was about 130mb).
the bottom line is that if you believe that qt4 or qt5 is going to be
suitable for low-memory usage you are due for yet another train wreck.
qt3 - precisely because it has *not* had massive amounts of
development or interference - is still suitable for use on systems
even with as little as 64mb of RAM... with *no* swap space. perhaps
running such large systems as KDE3 in only 64mb of RAM is too much to
hope for, but because qt3 was designed for such tiny resource usage
and does *not* have massive feature-bloat, it won't be far off.
i'm sorry i had to break the request of the trinity developers not to
appear to be "adversarial", but, martin, the KDE team _really_ need a
serious, serious reality check. you should, instead of asking the
trinity developers to quit, be encouraging them to explore their
chosen path (which you have absolutely no control over) with
enthusiasm, and offering to help guide them to success.
l.
5:03 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
Le dimanche 11 décembre 2011, Luke Kenneth Casson Leighton a écrit :
i'm sorry i had to break the request of the
trinity developers not to
appear to be "adversarial", but, martin, the KDE team _really_ need a
serious, serious reality check. you should, instead of asking the
trinity developers to quit, be encouraging them to explore their
chosen path (which you have absolutely no control over) with
enthusiasm, and offering to help guide them to success.
+10
The KDE4 project is where it is because of the way of thinking of
Martin.
I am stupid enougth to imagine that the leader of the KDE developpment
team could receive two salaries: with one coming from MS. I see KDE as
something self destroying!
>>>>> first of all: this is a serious
suggestion and no try to troll you or
anything in that area.
Lol
NB: I am more a user than a developper.
6:24 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Sunday 11 December 2011 16:32:23 Luke Kenneth Casson Leighton wrote:
i'm sorry i had to break the request of the
trinity developers not
to appear to be "adversarial", but, martin, the KDE team _really_
need a serious, serious reality check. you should, instead of asking
the trinity developers to quit, be encouraging them to explore their
chosen path (which you have absolutely no control over) with
enthusiasm, and offering to help guide them to success.
l.
100% On the nail !
Well said Luke...
--
Best Regards:
Baron.
7:05 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Sunday 11 December 2011 16:32:23 you wrote:
On Sat, Dec 10, 2011 at 6:35 PM, Martin Gräßlin
<mgraesslin(a)kde.org> wrote:
of course I have the right to suggest that Trinity should
make use of KWin4
instead of doing an improper fork. I do not see how I should not have that
right. I think that is very well covered by freedom of speech.
Hi Trinity developers,
Therefore I suggest to you to discontinue the work on twin and instead
switch to KWin 4 as provided, developed and maintained by the KDE
community. We are
martin,
i was happy to accept - with reservations - what you were saying
right up until the point where you effectively ordered everyone to
quit.
the gist of your message is as follows:
a) you (twin developers) are making mistakes
b) you cannot be trusted not to make mistakes
c) it's a big responsibility and i believe that you're not up to the job
d) therefore you should quit.
i was prepared to accept that you are perfectly within your rights to
say that mistakes are being made, and it is very useful for you to do
so. however you have absolutely NO right to suggest, recommend, tell
or otherwise imply that the twin developers should do something other
than what they are doing.
now it's my turn to give you a reality-check.
* skip long bitching on KDE 4 *
Now I do not understand what you want to achieve with your bitching of KDE 4.
It is completely irrelevant in the scope of my suggestion to use KWin. As I
have pointed out several times by now KWin 4 is the direct continuation of
KWin 3 and not a rewrite or anything else in that manner. Does anything else
about KDE 4 matter if we look at [t|k]win and KWin4? Not at all!
Furthermore it is completely irrelevant as I as current KWin maintainer
received commit rights to the KDE source repository after the release of KDE
4.0. Whatever the KDE developers did what does not please you, I have not been
involved.
Now let me add a little bit to the bitching. First of all, I did not read it,
I could not care less. But I find it completely unacceptable to see something
like that written and it is completely unacceptable that other people think
that this is great writing.
I come here as the maintainer of a main component of the KDE Plasma Workspaces
to offer help. Because I see the issues with maintaining a fork of KWin. And
that is a reply? What do you want your relationship to KDE be? Do you want to
be seen as the bunch of disappointed users one should ignore or do you hope to
be able to collaborate with KDE developers? Because collaboration is what you
need. There will be the time that you don't understand code, that you need
help. How do you want to get the help if *that* is the way to response to help
offered to you by KDE developers in an altrustic way.
After that experience I cannot recommend any KDE developer to interact with
Trinity developers. And that's a pity. This harms the development of the
Trinity project. Think about the impact of me writing e.g. a blog post about
my experience with the Trinity project. Given that my blog is read by media
this could seriously harm the project. I don't want to do that, because I want
a working collaboration between Trinity and KDE. But you just have to be aware
how you harm your own case.
Think about what you want to achieve and how you want to interact with the KDE
community. I think an appology would help in such cases.
Best Regards
Martin Gräßlin
7:33 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
<snip>
I come here as the maintainer of a main component of
the KDE Plasma
Workspaces
to offer help. Because I see the issues with maintaining a fork of KWin.
And
that is a reply? What do you want your relationship to KDE be? Do you want
to
be seen as the bunch of disappointed users one should ignore or do you
hope to
be able to collaborate with KDE developers? Because collaboration is what
you
need. There will be the time that you don't understand code, that you need
help. How do you want to get the help if *that* is the way to response to
help
offered to you by KDE developers in an altrustic way.
After that experience I cannot recommend any KDE developer to interact
with
Trinity developers. And that's a pity. This harms the development of the
Trinity project. Think about the impact of me writing e.g. a blog post
about
my experience with the Trinity project. Given that my blog is read by
media
this could seriously harm the project. I don't want to do that, because I
want
a working collaboration between Trinity and KDE. But you just have to be
aware
how you harm your own case.
Think about what you want to achieve and how you want to interact with the
KDE
community. I think an appology would help in such cases.
Best Regards
Martin GräÃlin
Please don't take the posting of one person as representative of the
entire TDE project. I am guardedly open to the idea, but I need more
information before making an informed decision, hence the steps I outlined
previously. A major concern for me is the dependence on KDE4 libraries,
but it sounds like steps are being taken to resolve that.
I think we could all take a single message from any open source project's
list and make the entire project look bad with it. If everyone did that
the entire open source community would be the laughingstock of the
software world, and I for one am glad that most people are relatively
polite, even when they disagree.
To the users here: please don't bash KDE4 itself when the discussion is
revolving around kwin. ;-) Keep things on topic--if there are aspects of
kwin4 you can't stand please bring them up politely and ask for them to be
resolved. It is quite possible that upstream can be more responsive than
TDE due to more developer resources; what we will need to gauge is
upstream's openness to our suggestions.
Thank you Martin for providing a different perspective on things; this is
good. To the users on this list: remember we do have the right to make
the final decision once sufficient evidence is gathered; no flame wars are
needed or desired.
Tim
8:29 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Sunday 11 December 2011 20:33:36 Timothy Pearson wrote:
To the users here: please don't bash KDE4 itself
when the discussion is
revolving around kwin. ;-) Keep things on topic--if there are aspects of
kwin4 you can't stand please bring them up politely and ask for them to be
resolved. It is quite possible that upstream can be more responsive than
TDE due to more developer resources; what we will need to gauge is
upstream's openness to our suggestions.
correct.
however, it is clear that there _are_ serious disagreements on how to best
provide a 'kde 3.5 computing style' to users.
martin, e.g., claims that all what is needed for that would be to port kicker
+ kdesktop from kde 3.5 to kde4, but it is not:
- kde 4 performance/responsiveness on some older hardware is absolutely poor,
thats simply a fact
- the kde 3.5 experience does also consist of the
simplicity/robustness/maintainability (from user's perspective) of
applications
- this means: no nepomuk, no local database server, no akonadi, no virtuoso,
just plain text data/config files (and no, I don't want to discuss the pros
and cons of these components, its just the fact that they can no longer be
disabeled without losing basic functionality)
there is more, of course, but it should be clear that what trinity wants to
provide (and is supposed to) just cannot be achieved by simply porting 2
applications.
werner
8:43 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Sunday 11 December 2011 21:29:03 Werner Joss wrote:
On Sunday 11 December 2011 20:33:36 Timothy Pearson
wrote:
well it runs on tablets and smartphones, so I rather
doubt that this is
"simply a fact".
To the users here: please don't bash KDE4
itself when the discussion is
revolving around kwin. ;-) Keep things on topic--if there are aspects of
kwin4 you can't stand please bring them up politely and ask for them to be
resolved. It is quite possible that upstream can be more responsive than
TDE due to more developer resources; what we will need to gauge is
upstream's openness to our suggestions.
correct.
however, it is clear that there _are_ serious disagreements on how to best
provide a 'kde 3.5 computing style' to users.
martin, e.g., claims that all what is needed for that would be to port
kicker + kdesktop from kde 3.5 to kde4, but it is not:
- kde 4 performance/responsiveness on some older hardware is absolutely
poor, thats simply a fact - the kde 3.5 experience does also consist of the
simplicity/robustness/maintainability (from user's perspective) of
applications
- this means: no nepomuk, no local database server, no akonadi, no virtuoso,
just plain text data/config files (and no, I don't want to discuss the pros
and cons of these components, its just the fact that they can no longer be
disabeled without losing basic functionality)
What you mention is all irrelevant
when discussing kwin. We neither use a
database server, nor akonadi, nor virtuoso. We are as robust as ever
(currently one reproducable crash) and more robust than the fork currently in
Trinity (due to introduced bugs by Trinity and due to more robustness by
KWin).
Btw. I really, really recommend you to not going into the direction of FUD
with Trinity. Claiming for example that Trinity is better because it does not
use Akonadi/Databases/$foo is just bad. It only illustrates that you don't
understand the problem at all.
My recommendation to you: concentrate on the 3.5 desktop experience and don't
mention KDE 4 technology. It will only result in rejection from KDE. That's no
help for you.
there is more, of course, but it should be clear that what trinity wants to
provide (and is supposed to) just cannot be achieved by simply porting 2
applications.
Then think about what you want to provide and what you can provide.
You don't
have the manpower to develop all of KDE 3. This is no offense, it's a fact.
From what I have seen when looking at the commit history the Trinity team is
smaller than the KWin team. And with each day passing it will become for you
more and more you have to maintain. Think of HAL...
Best Regards
Martin
werner
8:59 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Sun, 11 Dec 2011 21:29:03 +0100
Werner Joss <werner(a)hoernerfranzracing.de> wrote:
On Sunday 11 December 2011 20:33:36 Timothy Pearson
wrote:
Did you look at
https://wiki.archlinux.org/index.php/KDE#Troubleshooting ? It has
solutions for bad performance of KDE4. Personally I make no trick of
this kind and didn't find KDE4 slow with anything better than my 1,2 GHz
Athlon box (except if KWin desktop effects are activated, but they're
optional). And even with this Athlon system KDE4 remains usable, just a
bit sluggish.
To the users here: please don't bash KDE4
itself when the
discussion is revolving around kwin. ;-) Keep things on topic--if
there are aspects of kwin4 you can't stand please bring them up
politely and ask for them to be resolved. It is quite possible
that upstream can be more responsive than TDE due to more developer
resources; what we will need to gauge is upstream's openness to our
suggestions.
correct.
however, it is clear that there _are_ serious disagreements on how
to best provide a 'kde 3.5 computing style' to users.
martin, e.g., claims that all what is needed for that would be to
port kicker
+ kdesktop from kde 3.5 to kde4, but it is not:
- kde 4 performance/responsiveness on some older hardware is
absolutely poor, thats simply a fact - the kde 3.5 experience does also consist of the
simplicity/robustness/maintainability (from user's perspective) of
applications
- this means: no nepomuk, no local database server, no
akonadi, no virtuoso, just plain text data/config files (and no, I
don't want to discuss the pros and cons of these components, its just
the fact that they can no longer be disabeled without losing basic
functionality)
Since KDE maintains binary and source compatibility within major
releases nothing should stop you from using kdepim 4.4.10 with any KDE
4.(4+), which doesn't need Akonadi to work.
there is more, of course, but it should be clear that what trinity
wants to provide (and is supposed to) just cannot be achieved by
simply porting 2 applications.
werner
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
21 Dec
21 Dec
9:59 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
Hi,
I just wanted to ask whether you thought about it and maybe even someone gave
a try to run Trinity with KWin 4. I really would like to see this happen and I
think you and most important your users would benefit from that :-)
I wish you a Merry Christmas and a successful year 2012 for Trinity.
Kind Regards
Martin Gräßlin
10:41 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
I just wanted to ask whether you thought about it and
maybe
even someone gave
a try to run Trinity with KWin 4. I really would like to
see this happen and I
think you and most important your users would benefit from
that :-)
Hi Martin,
My observations:
Currently Tim is busy with the sudden loss of server mirrors, SVN to GIT transition, and
the TDE renaming project. He is busy --- swamped. He is the project lead but I won't
be surprised if he does no testing of kwin4 for several months. :)
When the GIT transition and renaming project are completed, there will be a huge effort to
merge patches sitting in wait in the bugzilla. Then there will be a lot of building and
testing to ensure all merged patches function for all distros and users.
Then there will be a huge effort to focus on significant bugs that need attention for the
next release.
Possibly somebody in the TDE community might start testing and provide reports, but for
the developers and packagers our immediate goals are GIT, renaming project, web site
improvements, and bugs. Thus, other than individuals, any possible team testing of kwin4
likely would happen after the next release, tentatively in May.
Just sharing my observations --- I have no official capacity to represent opinions of
others on the team. :)
Darrell
22 Dec
22 Dec
3 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On 21 December 2011 17:41, Darrell Anderson <humanreadable(a)yahoo.com> 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 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.
I'd like to push for this - but only as beta. I think twin has never failed
me as a good, standard, well thought out manager - but it doesn't hurt to
explore new options.
Calvin
I just wanted
to ask whether you thought about it and maybe
even someone gave
a try to run Trinity with KWin 4. I really would like to
see this happen and I
think you and most important your users would benefit from
that :-)
3:16 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
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 &
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:
1. 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 ;-)
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'd like to push for this - but only as beta.
great :-)
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.
Cheers
Martin
[1] http://www.amazon.com/Implementation-Proactive-Spam-Fighting-
Techniques/dp/3639289935/ref=sr_1_1?ie=UTF8&qid=1324566570&sr=8-1
Calvin
8:17 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On 22 December 2011 10:16, Martin Gräßlin <mgraesslin(a)kde.org> wrote:
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 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
On Thursday 22 December 2011 10:00:45 Calvin Morrison
wrote:
Thanks I'll give it a try :)
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 &
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:
1. 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 ;-)
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.
23 Dec
23 Dec
5:48 p.m.
New subject: [trinity-devel] Suggestion to drop [t|k]win from Trinity and replace it by KWin4
On Thursday 22 December 2011 15:17:13 Calvin Morrison wrote:
As for the packaging issue, I'd rather let users
install the standard Kwin
repository provided by their distribution.
Oh I think having a different KWin with
less dependencies just for Trinity
would be just fine. That's what we do for Plasma Active, where KWin is
compiled with completely different compile flags (e.g. no Window Decorations).
Also in 4.8 the standard KWin is built twice with different dependencies: once
the classic KWin with OpenGL and once as kwin_gles with OpenGL ES 2.0.
So having some build options to e.g. disable Nepomuk integration and Plasma
integration should be possible and could result in a kwin_trinity binary or
something in that direction.
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.
At least Akonadi is
never used by KWin. Nepomuk is indirectly used through
Activities. I have never tried running KWin standalone since Activities were
introduced, so I don't know whether the daemon is started. But I think it's
not.
I want to reiterate how time limited the project is
already. I think almost
all new features are being pushed back to R14.
Exactly! And that's one of the
reasons why I want to push for KWin in Trinity.
It takes away the burden to develop a window manager and hands it of to those
who do it anyway. And as I said in the end only the users matter :-)
Thank you for taking the time to work with us,
Thanks as well for considering
working together with KDE. I really hope that
those two siblings can come closer together again in 2012 :-)
Merry Christmas
Martin Gräßlin
4514
days inactive
4527
days old
37 comments
11 participants
participants (11)
-
/dev/ammo42 -
Baron -
Calvin Morrison -
Darrell Anderson -
Julius Schwartzenberg -
Luke Kenneth Casson Leighton -
Martin Gräßlin -
Nigel Stewart -
Patrick Serru -
Timothy Pearson -
Werner Joss