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=a... [3] https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=a... [4] http://git.trinitydesktop.org/cgit/tdebase/commit/kwin?id=1f40ada72d693d681e... [5] http://git.trinitydesktop.org/cgit/tdebase/commit/kwin?id=9cc1e2c1aa2629d499...
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
On Saturday 10 December 2011 12:56:07 Nigel Stewart wrote:
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?
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
- Nigel
On Saturday 10 December 2011 20:32:16 Werner Joss wrote:
On Saturday 10 December 2011 20:16:39 Martin Gräßlin wrote:
I would be surprised if your users would use no KDE 4 applications. So I think it is negligible.
YMMD :)
May I ask why?
werner
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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
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, the window styles that come with TDE, and the kcontrol integration. 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. ;-)
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 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.
Martin
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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
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
On 10 December 2011 15:14, Timothy Pearson kb9vqf@pearsoncomputing.netwrote:
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
On 10 December 2011 15:14, Timothy Pearson kb9vqf@pearsoncomputing.netwrote:
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
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
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
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
On 10 December 2011 17:12, Timothy Pearson kb9vqf@pearsoncomputing.netwrote:
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
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
On Sunday 11 December 2011 00:18:39 Calvin Morrison 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
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
*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.
On Sat, Dec 10, 2011 at 9:22 PM, Calvin Morrison mutantturkey@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.
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
On Sun, Dec 11, 2011 at 11:38 AM, Martin Gräßlin mgraesslin@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.
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@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.
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
Martin Gräßlin wrote:
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@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.
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.
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 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@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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
On Sat, Dec 10, 2011 at 7:52 PM, Martin Gräßlin mgraesslin@kde.org 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.
don't get me started on d-bus :)
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.
On Sun, 11 Dec 2011 16:41:22 +0000 Luke Kenneth Casson Leighton luke.leighton@gmail.com wrote:
On Sat, Dec 10, 2011 at 7:52 PM, Martin Gräßlin mgraesslin@kde.org 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.
don't get me started on d-bus :)
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.
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
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@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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
On Sat, Dec 10, 2011 at 7:35 PM, Timothy Pearson kb9vqf@pearsoncomputing.net 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,
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.
Martin Gräßlin wrote:
On Saturday 10 December 2011 12:56:07 Nigel Stewart wrote:
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.
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
On Sat, Dec 10, 2011 at 6:35 PM, Martin Gräßlin mgraesslin@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.
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.
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...
On Sunday 11 December 2011 16:32:23 you wrote:
On Sat, Dec 10, 2011 at 6:35 PM, Martin Gräßlin mgraesslin@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.
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.
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
<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
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
On Sunday 11 December 2011 21:29:03 Werner Joss wrote:
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
well it runs on tablets and smartphones, so I rather doubt that this is "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
On Sun, 11 Dec 2011 21:29:03 +0100 Werner Joss werner@hoernerfranzracing.de wrote:
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
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.
- 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@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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
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
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
On 21 December 2011 17:41, Darrell Anderson humanreadable@yahoo.com wrote:
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 :-)
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
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
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
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
-
/dev/ammo42 -
Baron -
Calvin Morrison -
Darrell Anderson -
Julius Schwartzenberg -
Luke Kenneth Casson Leighton -
Martin Gräßlin -
Nigel Stewart -
Patrick Serru -
Timothy Pearson -
Werner Joss