Hi all,
I had to see that there is still development going on in your fork of KWin and I am very unhappy about that. This is something I really want to see resolved, any development to KWin should happen in KWin, it's such a waste to work on the same project without coordination.
Let's first recapture the state of TWin: = Why does TWin exist? = Because KWin got forked together with everything else from KDE 3.5 to form the Trinity Desktop Environment (TDE).
= Why has the TDE fork happened? = The TDE fork existist because of a combination of the following reasons: * Parts of KDE had to be rewritten in order to be ported to Qt 4 * Early versions of KDE 4.x were lacking functionality compared to KDE 3.5 * Early versions of KDE 4.x had quality and stability issues compared to KDE 3.5 * A general disagreement with some project decisions * KDE 4.x introduced new technologies unliked by some (e.g. Nepomuk or Akonadi)
= Do these reasons hold for KWin? = No! None of the reasons stated above has ever been true for KWin. KWin is a direct continuation of the KDE 3 version. The codebase did not get rewritten, the quality of the window manager did not suffer, new functionality got added as optional addons.
= Is there any other reason justifying the TWin fork? = Maybe the fact that KWin depends on Qt4/kdelibs4 which is not liked by TDE.
= Is that a reason for a hostile fork as it is at the moment? = No, the fact that TWin requires Qt 3 is no reason to have the current state with the hostile fork. Best would be a solution of no fork, but a collaborative friendly fork should be possible, given that KWin and TWin share a large code base.
= What can KDE do about the fork? = Actually pretty much nothing. The license allows TDE to fork KWin - whether we like it or not. All we can do is force you to change the name and urge you to work together with us.
= Why do I actually care? = The KWin development team is rather small. I would like to see more involvment inside KWin than to see duplicated work in a fork.
Furthermore KWin 3.5 has a very good reputation and is known as rock solid. I see this reputation questioned if the TWin fork is continued without the quality checks performed in the KWin development.
Lets have a look at the recent patch for TWin called "Mac Like Switching Panel". This introduces a new feature to switch through applications and references an implementation in window maker. To be clear: this functionality has been present in KWin since version 4.4 (I added it). A little bit of coordination here would have prevented the duplication of development.
But is there a problem when Trinity adds code, should I care? Well the code is wrong (review based on patch2.patch on mailing list). In an attempt to copy everything from window maker code got added to KWin (particular readClass) which already existed. Lack of knowledge about the KWin source code are probably the reason that it is unknown that KWin::Client::resourceName()/resourceClass() provide the window class attribute.
Another problem is that the code is crashy. For me as an experienced KWin developer I only need to look at the code and see immediately were it is likely that the code will crash. Consider that start is NULL and the following line of code: start->readClass().
How likely is it that a non KWin developer would have spotted this crashy code? How likely is it that you know how to create such a situation? (I know it exactly).
It is not surprising that you are not able to add code to KWin which is correct - hardly anybody not knowing the code base is able to do so. That's why we perform code review and help new developers to get the code into a state that it works correctly. We are happy to accept patches from the Trinity team to KWin as well (of course we only accept patches for current master). The important difference is that in KWin there is a quality assurance through the code review by *experienced* KWin developers. This is impossible in TDE as there are no experienced developers for KWin.
Now I'm not writing this mail to blame you for writing wrong code. If I would be "evil" I would sit back, relax and wait to see TDE hit the wall which is approaching faster and faster when crashy code gets added. Remember: one of the reasons for Trinity is the (no longer) bad quality of KDE 4 code. And you even use that in your external communication - such crashy changes might backfire and then you cannot blame KDE.
I'm here now to resolve this issue about TWin together with you. I want to see the hostile fork go away. From all we see TDE is unable to maintain or even develop TWin. Please accept this fact as it is. It is nothing bad, I needed three years of strong involvment in KWin developer before becoming maintainer and there are still large areas of code blocks where I have no clue about.
Based on that fact we have to look for a solution. In my opinion the best would be to just use our KWin. And we have some quite useful things about that in our current development version: * no longer depends on anything else from kde-workspace * build options to disable "KDE 4" features (see http://techbase.kde.org/Projects/KWin/Build_Options) * mostly runtime dependencies to libplasma * desktop integration possible through custom QML additions like e.g. Alt+Tab * currently integrates with three desktop shells * (under review) build option to change the name of the binary, which would allow you to generate a kwin_tde or twin binary (automatic adjustment of all configuration files, etc.) (see https://git.reviewboard.kde.org/r/104299/) * after feature freeze: branch to build kwin standalone without the need to run cmake in kde-workspace.
As you can see this is a rather impress list of features which would allow TDE to use KWin instead of their fork.
Of course KWin depends on Qt 4 and kdelibs 4. We have no interest to support anything below Qt 4.7 and are currently preparing the transition to Qt 5 and KDE Frameworks 5. I think that this is only a minor issue to Trinity as to my understanding TDE can also use Qt 4.
We are open to discuss any concerns regarding integration a Qt4/kdelibs4 based application into TDE. I am very sure that most of your possible concerns are rather non-issues and that they can all be easily resolved.
I hope that you consider dropping your hostile fork of KWin and start to collaborate with your upstream pears at KDE more closely.
Thanks for your time
Martin Gräßlin KWin maintainer
On 04/20/2012 06:26 AM, Martin Gräßlin wrote:
Hi all,
I had to see that there is still development going on in your fork of KWin and I am very unhappy about that. This is something I really want to see resolved, any development to KWin should happen in KWin, it's such a waste to work on the same project without coordination.
Let's first recapture the state of TWin: = Why does TWin exist? = Because KWin got forked together with everything else from KDE 3.5 to form the Trinity Desktop Environment (TDE).
= Why has the TDE fork happened? = The TDE fork existist because of a combination of the following reasons:
- Parts of KDE had to be rewritten in order to be ported to Qt 4
- Early versions of KDE 4.x were lacking functionality compared to KDE 3.5
- Early versions of KDE 4.x had quality and stability issues compared to KDE
3.5
- A general disagreement with some project decisions
- KDE 4.x introduced new technologies unliked by some (e.g. Nepomuk or
Akonadi)
= Do these reasons hold for KWin? = No! None of the reasons stated above has ever been true for KWin. KWin is a direct continuation of the KDE 3 version. The codebase did not get rewritten, the quality of the window manager did not suffer, new functionality got added as optional addons.
= Is there any other reason justifying the TWin fork? = Maybe the fact that KWin depends on Qt4/kdelibs4 which is not liked by TDE.
= Is that a reason for a hostile fork as it is at the moment? =
Whoa, whoa whoa.... Martin -- hang on, I think you have the wrong idea concerning the TDE fork. I am in agreement that there is no reason to duplicate work and if there is a way to collaborate that helps kwin/twin, then that is something that should we should do.
Note, these are my thoughts and not the thoughts of TDE. In reading though your post, I see the good intent and the opportunity for both projects to do something good, but I was struck by a few of your comments. Now, I understand, I may not have gleaned from reading the intent you meant to convey, but there are several point I want to comment on.
"A 'hostile' fork?", that strikes me as a laughable attempt to rewrite history. TDE is a group of good people doing good work trying to support the continuation of a desktop they prefer as a 'matter of choice' for their Linux desktop. Never forget:
(1) any group of people have an absolute right to fork any OSS project at any time consistent with any applicable licensing agreements for any purpose what so ever; and (the way I saw it -- yes I was there)
(2) kde turned kde3 into a bastard child of a desktop, completely disowning and disavowing the 'old' code in its own fork that went off chasing plasma eyecandy widgets and a dumbed-down desktop UI that prioritized form and glitz well above core user function. It did so in a manner that maligned anyone who voiced an opinion that they preferred the kde3 interface to kde4. (not to mention the outright hostile responses on the kde mailing list to anyone mentioning anything to do with kde3 that I 'personally' was on the receiving end of)
The Berlin meeting in March 2005 held largely in secret with 15 or so in attendance marked the radical departure of kde away from kde3 and toward an 'experiment' to create a completely new desktop built around the Oxygen, Marble and Plasma projects. Those 15 at Berlin, decided on a fork that ignored, to a large extent, the needs and desires of the kde community essentially usurping a community project to satisfy the whims of a few to experiment with what they wanted in a desktop notwithstanding the 'choice' of the community.
A fine goal to be sure, but beginning in 2008, it was to give us all a lesson in how NOT to manage an OSS project by releasing the first 'official' non-beta release of KDE 4.0. The joke (on the kde user base) was that 4.0 was barely alpha-quality code when 'officially' released that lacked nearly all usable features of kde 3.5, had horrible crippled implementations of core desktop tools (konqueror file manager -- relied upon for years by users), and was in short -- was unusable. While at the same time pressuring all major Linux distributions to discontinue kde3 by halting all support for the 'old' version (kde 3.5.10 released only months earlier)
Four years later, kde4 still struggles to provide a usable replacement for the kdePIM.
No, the fact that TWin requires Qt 3 is no reason to have the current state with the hostile fork. Best would be a solution of no fork, but a collaborative friendly fork should be possible, given that KWin and TWin share a large code base.
Here is where you and I agree. Our effort should be focused on a port of kde3 kwin (along with all its desktop styles, look and feel, etc.), to the Qt4 environment. The problem is there are many shortcomings in Qt4 that prevent adaption of the existing code. A glaring example is the column widget in Qt4 (such as used in konqueror file manager - detailed view) has never been capable of correctly handling column sizing (especially the rightmost column) and has failed to provide any consistent persistence in column size. That is merely the tip of the iceberg.
While I agree that ultimately, this port to Qt4 is the future for TDE, this type of limitation makes focusing on the port now an effort in futility. I'm sure if these problem were coordinated with Riverbank, they could be overcome. But, as with anything when relying on a 3rd party toolset, the timing of when this will take place is something that is out of our control.
It comes down to this. The existing TDE codebase, built on Qt3/TQt3 allows for the continued development of TDE with its traditional look and feel and without the additional layer of uncertainty that comes with using a toolset that is still in a state of flux. Continuing TDE development on TQt3 is something that is doable now -- not at some faroff time in the future whenever Riverbank decides to fix the shortcomings with Qt4 that will allow a port to function properly on that toolset.
= What can KDE do about the fork? = Actually pretty much nothing. The license allows TDE to fork KWin - whether we like it or not. All we can do is force you to change the name and urge you to work together with us.
We agree. We have all licked our wounds from the battle of the direction kde should take and are willing to do what is best for both desktops, TDE and KDE.
There is no question that if what you are offering is a willingness to embrace effort to help bring TDE back into KDE as something like "KDE-Classic" then it makes perfect sense from a resource standpoint to see if we can find common-ground and a path forward that will meet the needs of both communities.
But understand, TDE is a project we are proud of that continues to meet the needs of those that prefer, 'as a matter of choice', the functionality that the kde3 interface provides. After being told (as a community) by kde.org "it's my way or the highway - kde3 is dead", you can understand the skepticism that many may feel in getting back in bed with you.
However, collaboration and further development benefits everyone. Even if it ends in failure, there are many lessons learned and the code, in some respect, is advanced regardless.
= Why do I actually care? = The KWin development team is rather small. I would like to see more involvment inside KWin than to see duplicated work in a fork.
Furthermore KWin 3.5 has a very good reputation and is known as rock solid. I see this reputation questioned if the TWin fork is continued without the quality checks performed in the KWin development.
This is a good argument - but it is just that - an argument. A desktop either provides sufficient checks to be stable or it doesn't run. Quality checks? Recall the official release of KDE 4.0.4?
Lets have a look at the recent patch for TWin called "Mac Like Switching Panel". This introduces a new feature to switch through applications and references an implementation in window maker. To be clear: this functionality has been present in KWin since version 4.4 (I added it). A little bit of coordination here would have prevented the duplication of development.
This is smart. Martin, this is exactly the type of collaboration that is open and welcomed without qualification. To do this we should identify those features (current or planned) in TDE that are the same or similar to what exists in kwin and make sure the implementations are the same. Beginning this now will just ease the transition in the future to Qt4.
But is there a problem when Trinity adds code, should I care? Well the code is wrong (review based on patch2.patch on mailing list). In an attempt to copy everything from window maker code got added to KWin (particular readClass) which already existed. Lack of knowledge about the KWin source code are probably the reason that it is unknown that KWin::Client::resourceName()/resourceClass() provide the window class attribute.
Again, this is a great opportunity for getting it done right the first time. If code implementation can be consistent from the beginning, it just helps in the end.
Another problem is that the code is crashy. For me as an experienced KWin developer I only need to look at the code and see immediately were it is likely that the code will crash. Consider that start is NULL and the following line of code: start->readClass().
If you and Will have time, please help out. You are correct -- your experience as a kwin developer is 'valued' and likely exceeds the combined kwin experience of everyone here. There is no replacement for experience to help guide development. If there is something that we can do better, please let us know.
In looking to coordinate the development between twin/kwin, one of the first helpful undertakings would be to identify those areas in twin that can/should be changed or rewritten to work better now as well as work when transitioned to Qt4.
How likely is it that a non KWin developer would have spotted this crashy code? How likely is it that you know how to create such a situation? (I know it exactly).
It is not surprising that you are not able to add code to KWin which is correct - hardly anybody not knowing the code base is able to do so. That's why we perform code review and help new developers to get the code into a state that it works correctly. We are happy to accept patches from the Trinity team to KWin as well (of course we only accept patches for current master). The important difference is that in KWin there is a quality assurance through the code review by *experienced* KWin developers. This is impossible in TDE as there are no experienced developers for KWin.
Everyone has a right to vent, but if we are going to make positive progress going forward, let's just agree to be candid and respectful between projects. We are all here to learn and help, but no one is here to be insulted.
Again, these comments are mine and not the comments of the project. I believe that coordination and collaboration is a win-win for twin/kwin (pardon the pun), and I look forward to it benefiting the codebase. I agree with you that an ultimate transition/port to Qt4 is the future. At present Qt3 provides a working and workable toolset for TDE.
What I am most interested in is your thoughts on how best to transition twin to kwin. I have thoughts from other kwin devs, but I'm interested in what order and how best you see it can be done.
In short -- what do you propose?
I am also interested in the thoughts of the TDE community on this issue as well.
Now I'm not writing this mail to blame you for writing wrong code. If I would be "evil" I would sit back, relax and wait to see TDE hit the wall which is approaching faster and faster when crashy code gets added. Remember: one of the reasons for Trinity is the (no longer) bad quality of KDE 4 code. And you even use that in your external communication - such crashy changes might backfire and then you cannot blame KDE.
Why then to you still have to press 'F9' twice to have the folder pane appear in 'konqueror --profile filemanagement' every time it is opened??
Yes -- in upstream.
Regardless -- I am in full agreement that the blame-game is unproductive, and I again think you miss the point if you believe that the reason for TDE's existence is because kde4 is crashy -- for me it's not. For me it because I can't stand the kde4 UI. That's why I like twin -- as a matter of choice.
If there is a way to have twin migrate back into the supported codebase, then that is worth discussing. If there is a way to benefit and help the twin transition to Qt4 while maintaining the look, feel and functionality of twin -- let's do it.
I'm here now to resolve this issue about TWin together with you. I want to see the hostile fork go away. From all we see TDE is unable to maintain or even develop TWin. Please accept this fact as it is. It is nothing bad, I needed three years of strong involvment in KWin developer before becoming maintainer and there are still large areas of code blocks where I have no clue about.
Again, it is not a hostile fork - it is what OSS is all about. When kde.org decided to disown kde3, and dropped all support for it, OSS did what it was designed to do - it provided for the continuation of what we believe is the finest desktop ever created - through a fork to tde. Linus is smiling...
The following is for those that know to comment on.
Based on that fact we have to look for a solution. In my opinion the best would be to just use our KWin. And we have some quite useful things about that in our current development version:
- no longer depends on anything else from kde-workspace
- build options to disable "KDE 4" features (see
http://techbase.kde.org/Projects/KWin/Build_Options)
- mostly runtime dependencies to libplasma
- desktop integration possible through custom QML additions like e.g. Alt+Tab
- currently integrates with three desktop shells
- (under review) build option to change the name of the binary, which would
allow you to generate a kwin_tde or twin binary (automatic adjustment of all configuration files, etc.) (see https://git.reviewboard.kde.org/r/104299/)
- after feature freeze: branch to build kwin standalone without the need to
run cmake in kde-workspace.
As you can see this is a rather impress list of features which would allow TDE to use KWin instead of their fork.
Of course KWin depends on Qt 4 and kdelibs 4. We have no interest to support anything below Qt 4.7 and are currently preparing the transition to Qt 5 and KDE Frameworks 5. I think that this is only a minor issue to Trinity as to my understanding TDE can also use Qt 4.
We are open to discuss any concerns regarding integration a Qt4/kdelibs4 based application into TDE. I am very sure that most of your possible concerns are rather non-issues and that they can all be easily resolved.
I hope that you consider dropping your hostile fork of KWin and start to collaborate with your upstream pears at KDE more closely.
Thanks for your time
Martin Gräßlin KWin maintainer
On Friday 20 April 2012 10:45:43 David C. Rankin wrote:
On 04/20/2012 06:26 AM, Martin Gräßlin wrote: "A 'hostile' fork?", that strikes me as a laughable attempt to rewrite history. TDE is a group of good people doing good work trying to support the continuation of a desktop they prefer as a 'matter of choice' for their Linux desktop. Never forget:
I called TWin a hostile fork and not complete TDE. TWin is a hostile fork of KWin as the reasons for the TDE fork are - as explained in my previous mail - not valid for KWin and the maintainer has tried in the past to merge the products again - without success. As the fork clearly has not the blessing of the developers it cannot be considered as a friendly fork and by that is a hostile fork. Furthermore no attempts are done to upstream any changes done to the fork.
This has nothing to do with "rewriting the history". There has never been a reason to fork KWin.
<skipping a larg part of bad mouthing the KDE development process which has nothing to with KWin>
No, the fact that TWin requires Qt 3 is no reason to have the current state with the hostile fork. Best would be a solution of no fork, but a collaborative friendly fork should be possible, given that KWin and TWin share a large code base.
Here is where you and I agree. Our effort should be focused on a port of kde3 kwin (along with all its desktop styles, look and feel, etc.), to the Qt4 environment. The problem is there are many shortcomings in Qt4 that prevent adaption of the existing code. A glaring example is the column widget in Qt4 (such as used in konqueror file manager - detailed view) has never been capable of correctly handling column sizing (especially the rightmost column) and has failed to provide any consistent persistence in column size. That is merely the tip of the iceberg.
this again has nothing to do with KWin. Luckily a window manager does not use the column widget. Please keep that on topic. KWin has been running well on Qt 4 for more than four years, please keep that in mind.
= What can KDE do about the fork? = Actually pretty much nothing. The license allows TDE to fork KWin - whether we like it or not. All we can do is force you to change the name and urge you to work together with us.
But understand, TDE is a project we are proud of that continues to meet the needs of those that prefer, 'as a matter of choice', the functionality that the kde3 interface provides. After being told (as a community) by kde.org "it's my way or the highway - kde3 is dead", you can understand the skepticism that many may feel in getting back in bed with you.
which again has nothing to do with TWin as KWin is the direct continuation of KWin as of KDE 3.5. Please keep this discussion on topic. Whatever you think about KDE and the desktop of KDE is completely irrelevant when looking on whether there is need to continue the fork of KWin
However, collaboration and further development benefits everyone. Even if it ends in failure, there are many lessons learned and the code, in some respect, is advanced regardless.
= Why do I actually care? = The KWin development team is rather small. I would like to see more involvment inside KWin than to see duplicated work in a fork.
Furthermore KWin 3.5 has a very good reputation and is known as rock solid. I see this reputation questioned if the TWin fork is continued without the quality checks performed in the KWin development.
This is a good argument - but it is just that - an argument. A desktop either provides sufficient checks to be stable or it doesn't run. Quality checks? Recall the official release of KDE 4.0.4?
I cannot remember that KWin 4.0.4 had been unstable (see http://ur1.ca/91qsv). Please keep in mind that I am writing about the window manager and not about the desktop shell. The new functionality in KWin back then was disabled by default. Apart from that nobody cares today about 4.0.
Lets have a look at the recent patch for TWin called "Mac Like Switching Panel". This introduces a new feature to switch through applications and references an implementation in window maker. To be clear: this functionality has been present in KWin since version 4.4 (I added it). A little bit of coordination here would have prevented the duplication of development.
This is smart. Martin, this is exactly the type of collaboration that is open and welcomed without qualification. To do this we should identify those features (current or planned) in TDE that are the same or similar to what exists in kwin and make sure the implementations are the same. Beginning this now will just ease the transition in the future to Qt4.
That would be a good start, yes. But I want to see more.
If you and Will have time, please help out. You are correct -- your experience as a kwin developer is 'valued' and likely exceeds the combined kwin experience of everyone here. There is no replacement for experience to help guide development. If there is something that we can do better, please let us know.
I'm sorry but I want to see the development of KWin go ahead. I have no interest whatsoever in seeing the hostile fork of KWin continue. My aim here is to stop the hostile fork and that means that there is no need to help you developing TWin. If you want to work on KWin (also for TDE) you are more than welcome to do so.
In looking to coordinate the development between twin/kwin, one of the first helpful undertakings would be to identify those areas in twin that can/should be changed or rewritten to work better now as well as work when transitioned to Qt4.
don't invest time on TWin! Drop it! Right now!
How likely is it that a non KWin developer would have spotted this crashy code? How likely is it that you know how to create such a situation? (I know it exactly).
It is not surprising that you are not able to add code to KWin which is correct - hardly anybody not knowing the code base is able to do so. That's why we perform code review and help new developers to get the code into a state that it works correctly. We are happy to accept patches from the Trinity team to KWin as well (of course we only accept patches for current master). The important difference is that in KWin there is a quality assurance through the code review by *experienced* KWin developers. This is impossible in TDE as there are no experienced developers for KWin.
Everyone has a right to vent, but if we are going to make positive progress going forward, let's just agree to be candid and respectful between projects. We are all here to learn and help, but no one is here to be insulted.
It was not my intention to insult anyone. I just stated the obvious: you have no experience in developing KWin. I doubt there is anything to discuss here.
Again, these comments are mine and not the comments of the project. I believe that coordination and collaboration is a win-win for twin/kwin (pardon the pun), and I look forward to it benefiting the codebase. I agree with you that an ultimate transition/port to Qt4 is the future. At present Qt3 provides a working and workable toolset for TDE.
You can use Qt3 for all of TDE and just transit TWin to be KWin based on Qt 4/kdelibs 4. This resolves the issue in a very nice way.
What I am most interested in is your thoughts on how best to transition twin to kwin. I have thoughts from other kwin devs, but I'm interested in what order and how best you see it can be done.
In short -- what do you propose?
1. git rm -rf twin 2. git add kwin 3. call it a day
That is: just do it!
I am also interested in the thoughts of the TDE community on this issue as well.
Now I'm not writing this mail to blame you for writing wrong code. If I would be "evil" I would sit back, relax and wait to see TDE hit the wall which is approaching faster and faster when crashy code gets added. Remember: one of the reasons for Trinity is the (no longer) bad quality of KDE 4 code. And you even use that in your external communication - such crashy changes might backfire and then you cannot blame KDE.
Why then to you still have to press 'F9' twice to have the folder pane appear in 'konqueror --profile filemanagement' every time it is opened??
Yes -- in upstream.
Sorry I don't get what you want to tell me here.
Regardless -- I am in full agreement that the blame-game is unproductive, and I again think you miss the point if you believe that the reason for TDE's existence is because kde4 is crashy -- for me it's not. For me it because I can't stand the kde4 UI. That's why I like twin -- as a matter of choice.
That's great: then you can just use KWin. KWin does not have any "UI". It's all styles and the style of KDE 3 times is still available and currently even shipped with KWin. We even have multiple theme engines in KWin and we want to transit the legacy themes to these theme engines in future.
If there is a way to have twin migrate back into the supported codebase, then that is worth discussing. If there is a way to benefit and help the twin transition to Qt4 while maintaining the look, feel and functionality of twin -- let's do it.
how good that there is nothing to do in that case: all the styles are still there :-) All Plasma integration (what you probably don't like) can be exchanged with another style and everything else is pure QML.
I'm here now to resolve this issue about TWin together with you. I want to see the hostile fork go away. From all we see TDE is unable to maintain or even develop TWin. Please accept this fact as it is. It is nothing bad, I needed three years of strong involvment in KWin developer before becoming maintainer and there are still large areas of code blocks where I have no clue about.
Again, it is not a hostile fork - it is what OSS is all about. When kde.org decided to disown kde3, and dropped all support for it, OSS did what it was designed to do - it provided for the continuation of what we believe is the finest desktop ever created - through a fork to tde. Linus is smiling...
Again I am talking about KWin and not about KDE in general. The fork of KWin is hostile as the reasons to fork KDE are not valid for KWin.
Please keep this thread on topic. It's about TWin/KWin and not about TDE or KDE in general. I am only discussing this one application and don't care about anything else.
Thank you Martin
<snip>
Please keep this thread on topic. It's about TWin/KWin and not about TDE or KDE in general. I am only discussing this one application and don't care about anything else.
This is so important. KDE is a large collection of separate projects with many developers. kwin is part of the KDE collection, but that doesn't mean they did exactly as most of KDE did, scrap the code. KWin is a continuation, an improvement, an developed active codebase.
Martin said to me privately (I paraphrased a bit to make sure it made sense):
"There is no such thing like "kde", kde is a community of developers producing different products. I assume you mean with kde our workspaces "KDE Plasma". In fact KWin is part of the KDE Plasma Workspaces but that does not mean that we are heavily integrated into it. There are three desktop shells we currently support which makes it impossible to heavily integrate into one."
I see no reason why we couldn't at least make the effort to having a build of kwin that fits our needs in the long run.
Calvin
<snip> > Please keep this thread on topic. It's about TWin/KWin and not about TDE > or > KDE in general. I am only discussing this one application and don't care > about > anything else.
This is so important. KDE is a large collection of separate projects with many developers. kwin is part of the KDE collection, but that doesn't mean they did exactly as most of KDE did, scrap the code. KWin is a continuation, an improvement, an developed active codebase.
Martin said to me privately (I paraphrased a bit to make sure it made sense):
"There is no such thing like "kde", kde is a community of developers producing different products. I assume you mean with kde our workspaces "KDE Plasma". In fact KWin is part of the KDE Plasma Workspaces but that does not mean that we are heavily integrated into it. There are three desktop shells we currently support which makes it impossible to heavily integrate into one."
I see no reason why we couldn't at least make the effort to having a build of kwin that fits our needs in the long run.
Calvin
As I have stated before I have absolutely no problem with the general concept. Calvin, have you tried switching your TDE session to use kwin? Does it work well? Any problems to report or did all go well?
I absolutely refuse to yank a critical part of TDE until I know its replacement works not just as well as the original, but better.
Tim
Le 20/04/2012 20:56, Timothy Pearson a écrit :
As I have stated before I have absolutely no problem with the general concept. Calvin, have you tried switching your TDE session to use kwin? Does it work well? Any problems to report or did all go well?
I absolutely refuse to yank a critical part of TDE until I know its replacement works not just as well as the original, but better.
Tim
Hello, from my user and packager point of view, we should not need to provide any kwin4 or kde4 or qt4 stuff in TDE binary packages. We should use the existing kwin4 provided by various distributions, if any.
All distro do not have the bleeding edge QT4 or KDE4 version. For example, RHEL use QT 4.6 and KDE 4.3 . In that case, is TDE supposed to provide QT 4.7 (or newer) and the latest kdelibs just to provide the latest kwin ? I don't think so.
At maximum, we should re-package the distro-provided kwin to disable these dependancies. For example, I could rebuild RHEL6's kwin with disabled nepomuk etc ... and make a Trinity package with it, that would not require to add any other library to the system.
At the moment, for testing purposes, I'm using Fedora 16 with TDE 3.5.13 and Kwin4 from KDE 4.8. It looks like it works well. To achieve this, I just have to add "export KDEWM=/usr/bin/kwin" to my .bashrc .
Maybe we should start with this trivial solution: add condition in "starttde", like this:
if [ -x "${USER_KDEWM}" ]; then # Use the user-defined window manager, if set. KDEWM="${USER_KDEWM}" elif [ -x /usr/bin/kwin_trinity ]; then # Use the stripped-down KWIN4 version, if available KDEWM=/usr/bin/kwin_trinity elif [ -x /usr/bin/kwin ]; then # Use the full KWIN4 version, if available KDEWM=/usr/bin/kwin else # Fallback to TWIN if KWIN is not present. KDEWM=twin fi export KDEWM
What TDE lacks currently, is a KWIN4 configuration panel. We should at least be able to change window decoration and behavior without using the complete KDE4 control panel.
Francois
On Saturday 21 April 2012 09:57:36 François ANDRIOT wrote:
At the moment, for testing purposes, I'm using Fedora 16 with TDE 3.5.13 and Kwin4 from KDE 4.8. It looks like it works well. To achieve this, I just have to add "export KDEWM=/usr/bin/kwin" to my .bashrc .
out of curiosity, I just tried the same here on my debian squeeze/trinity 3.5.13 install: aptitude install kwin pulls in:
Die folgenden NEUEN Pakete werden zusätzlich installiert: kde-window-manager{a} kdebase-runtime{a} kdelibs5-plugins{a} kwin libkdecorations4{a} libkephal4{a} libkwineffects1a{a} libkworkspace4{a} libnepomuk4{a} libnepomukquery4a{a}
- seems to work, window captions have tiny font size, though, and right click gives ugly kde4 config dialog :)
werner
On Saturday 21 April 2012 10:53:35 Werner Joss wrote:
On Saturday 21 April 2012 09:57:36 François ANDRIOT wrote:
At the moment, for testing purposes, I'm using Fedora 16 with TDE 3.5.13 and Kwin4 from KDE 4.8. It looks like it works well. To achieve this, I just have to add "export KDEWM=/usr/bin/kwin" to my .bashrc .
out of curiosity, I just tried the same here on my debian squeeze/trinity 3.5.13 install: aptitude install kwin pulls in:
Die folgenden NEUEN Pakete werden zusätzlich installiert: kde-window-manager{a} kdebase-runtime{a} kdelibs5-plugins{a} kwin libkdecorations4{a} libkephal4{a} libkwineffects1a{a} libkworkspace4{a} libnepomuk4{a} libnepomukquery4a{a}
Just for the record, 4.9 (current development) does not depend on libkephal, does not depend on libkworkspace4 and that should also remove the dependency to libnepomuk4 (though that could be a dependency of kdebase-runtime)
- seems to work, window captions have tiny font size, though, and right
click gives ugly kde4 config dialog :)
of course you could just switch to the plastique style which is the same as the KDE 3 style :-)
Cheers Martin
On Saturday 21 April 2012 11:13:25 Martin Gräßlin wrote:
Just for the record, 4.9 (current development) does not depend on libkephal, does not depend on libkworkspace4 and that should also remove the dependency to libnepomuk4 (though that could be a dependency of kdebase-runtime)
it is, in fact.
- seems to work, window captions have tiny font size, though, and right
click gives ugly kde4 config dialog :)
of course you could just switch to the plastique style which is the same as the KDE 3 style :-)
where would I do this ?
additional note: clipboard doesn't work anymore with kwin, which is a show-stopper, IMHO.
Werner
On Saturday 21 April 2012 11:24:18 Werner Joss wrote:
On Saturday 21 April 2012 11:13:25 Martin Gräßlin wrote:
Just for the record, 4.9 (current development) does not depend on libkephal, does not depend on libkworkspace4 and that should also remove the dependency to libnepomuk4 (though that could be a dependency of kdebase-runtime)
it is, in fact.
- seems to work, window captions have tiny font size, though, and right
click gives ugly kde4 config dialog :)
of course you could just switch to the plastique style which is the same as the KDE 3 style :-)
where would I do this ?
systemsettings -> Application Appearance -> Style -> Widget style: Plastique
additional note: clipboard doesn't work anymore with kwin, which is a show-stopper, IMHO.
probably unrelated, KWin does not have anything to do with the clipboard, that's a functionality provided by the XServer.
Cheers Martin
On Saturday 21 April 2012 11:31:55 Martin Gräßlin wrote:
where would I do this ?
systemsettings -> Application Appearance -> Style -> Widget style: Plastique
I have set plastik in kcontrol-appearnce-style, which is obviously ignored by kwin.
additional note: clipboard doesn't work anymore with kwin, which is a show-stopper, IMHO.
probably unrelated, KWin does not have anything to do with the clipboard, that's a functionality provided by the XServer.
why does then clipboard work ok when using twin ?
Werner
On Saturday 21 April 2012 11:38:59 Werner Joss wrote:
On Saturday 21 April 2012 11:31:55 Martin Gräßlin wrote:
where would I do this ?
systemsettings -> Application Appearance -> Style -> Widget style: Plastique
I have set plastik in kcontrol-appearnce-style, which is obviously ignored by kwin.
that's why I wrote "systemsettings". Obviously KWin is a Qt 4 application and needs to have a configured Qt4 style and not a Qt3 style.
additional note: clipboard doesn't work anymore with kwin, which is a show-stopper, IMHO.
probably unrelated, KWin does not have anything to do with the clipboard, that's a functionality provided by the XServer.
why does then clipboard work ok when using twin ?
I don't know, but I'm quite sure it's unrelated :-)
Cheers Martin
On Saturday 21 April 2012 13:47:57 Martin Gräßlin wrote:
systemsettings -> Application Appearance -> Style -> Widget style: Plastique
I have set plastik in kcontrol-appearnce-style, which is obviously ignored by kwin.
that's why I wrote "systemsettings". Obviously KWin is a Qt 4 application and needs to have a configured Qt4 style and not a Qt3 style.
qtconfig also does not affect Kwin4. To change its settings one have to install KDE4 desktop.
On Saturday 21 April 2012 14:12:53 Ilya Chernykh wrote:
On Saturday 21 April 2012 13:47:57 Martin Gräßlin wrote:
systemsettings -> Application Appearance -> Style -> Widget style: Plastique
I have set plastik in kcontrol-appearnce-style, which is obviously ignored by kwin.
that's why I wrote "systemsettings". Obviously KWin is a Qt 4 application and needs to have a configured Qt4 style and not a Qt3 style.
qtconfig also does not affect Kwin4. To change its settings one have to install KDE4 desktop.
no of course not, just run: kcmshell4 style
according to debian package info that requires the package "systemsettings".
Of course the style setting is just a config option, so you could also just use kwriteconfig with the correct file, group and key/value and restart kwin.
Cheers Martin
On Saturday 21 April 2012 13:13:25 Martin Gräßlin wrote:
Die folgenden NEUEN Pakete werden zusätzlich installiert: kde-window-manager{a} kdebase-runtime{a} kdelibs5-plugins{a} kwin libkdecorations4{a} libkephal4{a} libkwineffects1a{a} libkworkspace4{a} libnepomuk4{a} libnepomukquery4a{a}
Just for the record, 4.9 (current development) does not depend on libkephal, does not depend on libkworkspace4 and that should also remove the dependency to libnepomuk4 (though that could be a dependency of kdebase-runtime)
- seems to work, window captions have tiny font size, though, and right
click gives ugly kde4 config dialog :)
of course you could just switch to the plastique style which is the same as the KDE 3 style :-)
Not entirely the same.
On 21 Apr 2012, Martin Gräßlin spake thusly:
On Saturday 21 April 2012 10:53:35 Werner Joss wrote:
On Saturday 21 April 2012 09:57:36 François ANDRIOT wrote:
At the moment, for testing purposes, I'm using Fedora 16 with TDE 3.5.13 and Kwin4 from KDE 4.8. It looks like it works well. To achieve this, I just have to add "export KDEWM=/usr/bin/kwin" to my .bashrc .
out of curiosity, I just tried the same here on my debian squeeze/trinity 3.5.13 install: aptitude install kwin pulls in:
Die folgenden NEUEN Pakete werden zusätzlich installiert: kde-window-manager{a} kdebase-runtime{a} kdelibs5-plugins{a} kwin libkdecorations4{a} libkephal4{a} libkwineffects1a{a} libkworkspace4{a} libnepomuk4{a} libnepomukquery4a{a}
Just for the record, 4.9 (current development) does not depend on libkephal, does not depend on libkworkspace4 and that should also remove the dependency to libnepomuk4 (though that could be a dependency of kdebase-runtime)
So... you suggest that Trinity switch to KWin4, even though in order to avoid depending on big chunks of KDE4 this would require us to switch from a stable window manager to the *trunk* of kwin 4 -- this in a system for which stability is the entire reason for its continued existence... and even though this would suddenly mean that we would completely lose kcmshell integration (since kcms for kcontrol 4 are hardly going to work in kcontrol 3). You suggested running 'kcmshell4 style' by hand, but I hope you were joking: we can't expect end users to do that for no reason other than 'keeping Martin happy'.
This change would also foul up the look and feel, since Qt4 and Qt3 themes simply do not look that similar -- even what is allegedly the same theme has disconcerting differences in appearance, and now those differences would be reflected in the decorations of every single window.
This is not looking like a net benefit. Not at all.
-- N., uses fvwm so has no dog in this race
just an additional note on what I meant with 'clipboard not working' with kwin (from kde4): it is not that the clipboerd itself is not working (it does, in fact) but it is copy/paste via shortcut: the usual keypress 'alt+print' normally copys screen content to clipboard, which can then be pasted in other applications. with kwin, this gives an error when trying to paste, something like 'the application which copied to clipboard has been closed' so I'm pretty sure this has something to do with kwin.
Werner
On Sunday 22 April 2012 10:03:50 Werner Joss wrote:
just an additional note on what I meant with 'clipboard not working' with kwin (from kde4): it is not that the clipboerd itself is not working (it does, in fact) but it is copy/paste via shortcut: the usual keypress 'alt+print' normally copys screen content to clipboard, which can then be pasted in other applications. with kwin, this gives an error when trying to paste, something like 'the application which copied to clipboard has been closed' so I'm pretty sure this has something to do with kwin.
This only affects alt+print?
We have removed the support for alt+print as on modern systems alt+print is in general reserved to the kernel for sys rq and there is ksnapshot.
Cheers Martin
On Sunday 22 April 2012 11:55:09 Martin Gräßlin wrote:
On Sunday 22 April 2012 10:03:50 Werner Joss wrote:
just an additional note on what I meant with 'clipboard not working' with kwin (from kde4): it is not that the clipboerd itself is not working (it does, in fact) but it is copy/paste via shortcut: the usual keypress 'alt+print' normally copys screen content to clipboard, which can then be pasted in other applications. with kwin, this gives an error when trying to paste, something like 'the application which copied to clipboard has been closed' so I'm pretty sure this has something to do with kwin.
This only affects alt+print?
yes. ksnapshot is working as expected (obviously).
Werner
On Sunday 22 April 2012 00:10:36 Nix wrote:
Just for the record, 4.9 (current development) does not depend on libkephal, does not depend on libkworkspace4 and that should also remove the dependency to libnepomuk4 (though that could be a dependency of kdebase-runtime)
So... you suggest that Trinity switch to KWin4, even though in order to avoid depending on big chunks of KDE4 this would require us to switch from a stable window manager to the *trunk* of kwin 4 -- this in a system for which stability is the entire reason for its continued existence...
First of all you should not imply that the stability of "trunk" is a problem at all. KWin has a policy to never introduce stability issues. We have many developers running the KDE Plasma Workspaces from git master and of course we never want to break their setup.
Furthermore I have been using KWin from git master for several years now without any issues. Trust me I don't want an unstable window manager - that really sucks.
Now to whether I want you to depend on the git master version: we are two or three weeks before feature freeze of 4.9. At the time of feature freeze the version is "done" and we developers start to concentrate on the next version 4.10. So yes if I want that Trinity is using KWin I suggest to use 4.9 which is from developer perspective already the current version.
and even though this would suddenly mean that we would completely lose kcmshell integration (since kcms for kcontrol 4 are hardly going to work in kcontrol 3).
No, you missed an important part I already pointed out: our configuration modules have hardly changed since 3.5 due to the fact that they don't use ui files. You can just continue to use kcontrol 3 modules to configure a KWin 4. There are things which have new controls but in that case the functionality did not yet exist and the configuration of the window manager is accessible without using kcontrol or systemsettings at all.
You suggested running 'kcmshell4 style' by hand, but I hope you were joking: we can't expect end users to do that for no reason other than 'keeping Martin happy'.
No I'm not expecting users to do that. I'm expecting that TDE would install a default configuration file with the appropriate setting. My understanding is that this is a developer mailinglist, so what I write here is addressed at *developers* and not at *users*. Giving *developers* the information how to setup is the requirement that *developers* are able to ensure that *users* don't have to do so.
This change would also foul up the look and feel, since Qt4 and Qt3 themes simply do not look that similar -- even what is allegedly the same theme has disconcerting differences in appearance, and now those differences would be reflected in the decorations of every single window.
No the decorations do not use the Qt style at all. Decorations use the KWin style and the style does the complete rendering. E.g. the KWin style Plastik (used to be the default in KDE 3) has not changed at all in KWin 4.
This is not looking like a net benefit. Not at all.
So you say it's better to keep a fork alive which you cannot maintain because the looks mismatch instead of just implementing a theme which looks pixel perfect the same. Good idea!
Cheers Martin
On Saturday 21 April 2012 09:57:36 François ANDRIOT wrote:
All distro do not have the bleeding edge QT4 or KDE4 version. For example, RHEL use QT 4.6 and KDE 4.3 . In that case, is TDE supposed to provide QT 4.7 (or newer) and the latest kdelibs just to provide the latest kwin ? I don't think so.
I highly recommend to not use KWin 4.3 anymore. And RHEL or SLES are very bad examples. Users of those want the old versions and do neither want to install a recent version of KDE software nor of TDE software. They use the old system because of the provided security by RedHat or SUSE. Installing anything third party invalidates the reason to use RHEL/SLES in the first place.
At maximum, we should re-package the distro-provided kwin to disable these dependancies. For example, I could rebuild RHEL6's kwin with disabled nepomuk etc ... and make a Trinity package with it, that would not require to add any other library to the system.
kwin 4.3 does not use anything of Nepomuk. That indirect and optional runtime (!) dependency got added around 4.7.
Cheers Martin
Le 21/04/2012 11:17, Martin Gräßlin a écrit :
On Saturday 21 April 2012 09:57:36 François ANDRIOT wrote:
All distro do not have the bleeding edge QT4 or KDE4 version. For example, RHEL use QT 4.6 and KDE 4.3 . In that case, is TDE supposed to provide QT 4.7 (or newer) and the latest kdelibs just to provide the latest kwin ? I don't think so.
I highly recommend to not use KWin 4.3 anymore. And RHEL or SLES are very bad examples. Users of those want the old versions and do neither want to install a recent version of KDE software nor of TDE software. They use the old system because of the provided security by RedHat or SUSE. Installing anything third party invalidates the reason to use RHEL/SLES in the first place.
Well, in fact, I'm using RHEL at work (I've not chosen to, It was already there). Some day I opened a support case to indicate that the KDE4 they provided did not work as expected, whereas KDE3 had no problem in previous RHEL releases. The only answer I got from RH was "would you mind switching to gnome ?".
The funny thing is that, if they had solved my KDE4 problem, I would never have built TDE for RHEL :-) The TDE community can thank the RHEL tech support.
kwin 4.3 does not use anything of Nepomuk. That indirect and optional runtime (!) dependency got added around 4.7. Cheers Martin
Okay, nepomuk was just an example, I do not know what Kwin 4.3 requires exactly to run. My wish is that we could install a kwin4 version on every distro, that would NOT require a QT4 upgrade and/or lots of unwanted KDE4 stuff .
My guess is that kwin 4.9 will not build against older qt4/kde4. That's why I suggested to stick with the distribution-provided Kwin version, modifying just the small parts that we want.
If I'm wrong and that there is a way to build Kwin 4.9 on older QT4/KDE4, I would of course prefer using Kwin 4.9 .
Francois
On Saturday 21 April 2012 11:49:44 Francois Andriot wrote:
My guess is that kwin 4.9 will not build against older qt4/kde4. That's why I suggested to stick with the distribution-provided Kwin version, modifying just the small parts that we want.
if you use kwin 4.3 you cannot integrate it with TDE as all the features to make KWin work with other desktop shells have been added recently. You get hard coded Plasma dependencies and there is no way to change that.
If I'm wrong and that there is a way to build Kwin 4.9 on older QT4/KDE4, I would of course prefer using Kwin 4.9 .
KWin 4.9 currently requires Qt 4.7 and kdelibs 4.9 (which is the same as 4.7).
Cheers Martin
Martin Gräßlin wrote:
On Saturday 21 April 2012 09:57:36 François ANDRIOT wrote:
All distro do not have the bleeding edge QT4 or KDE4 version. For example, RHEL use QT 4.6 and KDE 4.3 . In that case, is TDE supposed to provide QT 4.7 (or newer) and the latest kdelibs just to provide the latest kwin ? I don't think so.
I highly recommend to not use KWin 4.3 anymore. And RHEL or SLES are very bad examples. Users of those want the old versions and do neither want to install a recent version of KDE software nor of TDE software. They use the old system because of the provided security by RedHat or SUSE. Installing anything third party invalidates the reason to use RHEL/SLES in the first place.
Martin, this is wrong and IMHO very arrongant from you (and from what I have seen it's typical of the attitude of some KDE4 devs). There are many people (including myself) using RHEL6 (or rather one of it's clones Centos6 and SL6) on the desktop because it provides a >>STABLE BASE SYSTEM<<.
Most desktop users of EL6 clones will then make use of third party repos (as you might know there are several very large ones) in order to add desktop applications (not old versions!) and other enhachements including alternative DEs.
RHEL6/clones are actually a perfect match for TDE users as both the base system and the desktop can be considered conservative (not in the political sense) and stable.
If a switch to KWin4 would mean that new releases of TDE no longer work on RHEL6 and clones then I think this is a very bad move.
Also I fear that if TDE adopts KWin4 it will not have any influence on the direction of KWin4, basically it will be a 'take it or leave it' adoption. The IMHO quite condescending attitude that Martin has displayed in this thread makes that very likely.
Andy
Andy wrote:
If a switch to KWin4 would mean that new releases of TDE no longer work on RHEL6 and clones then I think this is a very bad move.
Initially I would expect kwin4 to be shipped next to twin, so this issue will never occur.
Also, I do not think the impact of shipping a Trinity specific Qt4 that only contains the dependencies needed for kwin4 would be a huge issue. Maybe it is even possible to compile kwin4 statically on such platforms?
Basically what is needed now is that a Trinity (or maybe just a non-KDE4 specific package?) is provided. The next step would be testing.
Then maybe some work could be done to enable configuration in a proper way. Of course right now configuration would be a mess because each DE has its own Control Center/System Settings and the window managers that exist now all integrate into their original target DE only regarding configuration.
My prediction, as someone who is just observing:
Nothing is going to happen on the Trinity side regarding this (soon). Not because people are not interested, but because of limited developer resources. Twin works and the work needed to get kwin4 is cleanly integrated at least _appears_ to be bigger than keeping twin fixed. Keeping twin fixed right now is just a single fix at a time. Integrating kwin4 is a single big job which would prevent regular fixing from the Trinity side only in the future. The big job is just not appealing at this time.
If the two steps I indicated above could be done by others, I would give kwin4 adoption by Trinity a much bigger chance of succeeding.
Maybe the kwin4 developers themselves could provide a stripped-down version of kwin4 for multiple popular distributions? I would imagine starting with adding a kwin-lite package to Debian/Ubuntu which would only have the limited set of dependencies. Maybe people on other DEs would like to use this package as well.
The second problem is the integration of the configuration. This is not a Trinity+kwin4 specific issue. Also KDE4 and Gnome for example have issues where two configuration panes are required to configure certain settings. It would be the cleanest to develop a generic solution for this through freedesktop.org that can be used by all DEs and WMs.
Once these two problems are solved, I expect Trinity would implement the required freedesktop.org standards to allow configuration pane integration with other DEs. I think there is already an option to switch to another WM in Trinity. I also think Martin's claims about the superiority of kwin4 over twin are true, so I would expect most Trinity users to switch to kwin4 because they will enjoy the better experience. At this point twin will be deprecated.
Julius
If a switch to KWin4 would mean that new releases of TDE no longer work on RHEL6 and clones then I think this is a very bad move.
Initially I would expect kwin4 to be shipped next to twin, so this issue will never occur.
Also, I do not think the impact of shipping a Trinity specific Qt4 that only contains the dependencies needed for kwin4 would be a huge issue. Maybe it is even possible to compile kwin4 statically on such platforms?
Basically what is needed now is that a Trinity (or maybe just a non-KDE4 specific package?) is provided. The next step would be testing.
Then maybe some work could be done to enable configuration in a proper way. Of course right now configuration would be a mess because each DE has its own Control Center/System Settings and the window managers that exist now all integrate into their original target DE only regarding configuration.
My prediction, as someone who is just observing:
Nothing is going to happen on the Trinity side regarding this (soon). Not because people are not interested, but because of limited developer resources. Twin works and the work needed to get kwin4 is cleanly integrated at least _appears_ to be bigger than keeping twin fixed. Keeping twin fixed right now is just a single fix at a time. Integrating kwin4 is a single big job which would prevent regular fixing from the Trinity side only in the future. The big job is just not appealing at this time.
If the two steps I indicated above could be done by others, I would give kwin4 adoption by Trinity a much bigger chance of succeeding.
Maybe the kwin4 developers themselves could provide a stripped-down version of kwin4 for multiple popular distributions? I would imagine starting with adding a kwin-lite package to Debian/Ubuntu which would only have the limited set of dependencies. Maybe people on other DEs would like to use this package as well.
The second problem is the integration of the configuration. This is not a Trinity+kwin4 specific issue. Also KDE4 and Gnome for example have issues where two configuration panes are required to configure certain settings. It would be the cleanest to develop a generic solution for this through freedesktop.org that can be used by all DEs and WMs.
Once these two problems are solved, I expect Trinity would implement the required freedesktop.org standards to allow configuration pane integration with other DEs. I think there is already an option to switch to another WM in Trinity. I also think Martin's claims about the superiority of kwin4 over twin are true, so I would expect most Trinity users to switch to kwin4 because they will enjoy the better experience. At this point twin will be deprecated.
Those all are good points.
Tim has shared, several times, emphatically, that twin is going nowhere any time soon. In other words, don't panic.
With that said, Tim has provided initial hooks and foundations for other window managers. There is even a bug report addressing the issue.
The door is open and will remain open.
The question then is who wants to use a window manager other than twin? In the spirit of how these projects work, those who want window manager integration, including kwin4, will provide the necessary sweat equity. kwin4 --- adapted for Trinity, must be developed with full assurance that no KDE4 dependencies exist. Period. That is not negotiable. Word has been given that doing so is technically possible.
Those who want these new features must be prepared to accept responsibility. Whoever provides that sweat equity must perform significant testing and handling of all related bug reports. All issues must be resolved before the code will be considered mainstream and pushed to the main source tree.
Theoretically then, all that remains is sweat equity. Remember, the door is open. Put up or shut up.
Sharing code base is a non issue. A proverbial red herring. Trinity users either want other window managers or they don't.
Overall I wish folks would let this topic die. Or start hacking. Or block certain email addresses.
Darrell
On Friday 27 April 2012 10:08:25 Darrell Anderson wrote:
Overall I wish folks would let this topic die. Or start hacking. Or block certain email addresses.
Do I understand correctly that my offer to help Trinity is answered with that you want to block my email address?
I hope the Trinity community stands up against such behavior on the mailing list.
On Saturday 28 April 2012 11:52:55 Martin Gräßlin wrote:
On Friday 27 April 2012 10:08:25 Darrell Anderson wrote:
Overall I wish folks would let this topic die. Or start hacking. Or block certain email addresses.
Do I understand correctly that my offer to help Trinity is answered with that you want to block my email address?
I hope the Trinity community stands up against such behavior on the mailing list.
It is especially important to step up against such behavior if the person who shows such behavior is spreading misinformation about KDE as illustrated in this thread by the claim that Akonadi/Nepomuk/Strigi are hard dependencies of KDE.
People showing such behavior are harming Trinity as they lead in KDE moving further away from Trinity. But you need KDE. KDE can help Trinity and it would be great to get Trinity and KDE closer together and stop the competition.
So please stand up and show that behavior which is harming Trinity is not an acceptable behavior on this mailinglist. If you don't stand up it's clear that this behavior is acceptable and this mindset is shared on this mailinglist.
On Saturday 28 April 2012 11:58:04 Martin Gräßlin wrote:
It is especially important to step up against such behavior if the person who shows such behavior is spreading misinformation about KDE as illustrated in this thread by the claim that Akonadi/Nepomuk/Strigi are hard dependencies of KDE.
they might not be 'hard' dependencies, so, in theory, one can install kde without them, but what is the result ? no mail, no contacts, no calendar, no search, no integration of whatsoever, in short: something that has probably less functionality than xfce or icewm. so, insead of installing kde without all the above, razor-qt seems to be a better choice...
werner p.s: I'm all against blocking people from mailinglists as long as they have at least _some_ valid points which can be discussed. however, I really dislike the way you use to attack anyone here who has other views about kde than yours. especially with regard to your trinity-bashing all over (mostly) german forums etc.
On Saturday 28 April 2012 19:30:38 Werner Joss wrote:
On Saturday 28 April 2012 11:58:04 Martin Gräßlin wrote:
It is especially important to step up against such behavior if the person who shows such behavior is spreading misinformation about KDE as illustrated in this thread by the claim that Akonadi/Nepomuk/Strigi are hard dependencies of KDE.
they might not be 'hard' dependencies, so, in theory, one can install kde without them, but what is the result ? no mail, no contacts, no calendar, no search, no integration of whatsoever, in short: something that has probably less functionality than xfce or icewm. so, insead of installing kde without all the above, razor-qt seems to be a better choice...
sorry, but you just mix up things: razor-qt is a desktop shell like Plasma. Neither razor-qt provide mail, calendar or anything nor does Plasma.
Mail is provided by external software which can be used together with Plasma or razor-qt. E.g.: * KMail 1 * KMail 2 * Mozilla Thunderbird * Mozilla Firefox going to GMail
of all these solutions only KMail 2 requires Akonadi. So no, unless you really want to have KMail 2 you don't require Akonadi at all.
Now Nepomuk: again you are misinformed. You don't need Nepomuk to perform searches. You can still use KRunner/Kickoff to search through your installed applications, recent documents and so on. And you can still use KFind to search for files.
Nepomuk gives you a semantic search, something like Spotlight on OS X or Tracker on GNOME or Google Desktop Search on Windows. You don't have to use it. Neither razor-qt nor Plasma require you to use it, both work completely without such searches.
Please don't mix up things like what is a desktop shell, what is a mail program, what is a search application and so on.
werner p.s: I'm all against blocking people from mailinglists as long as they have at least _some_ valid points which can be discussed. however, I really dislike the way you use to attack anyone here who has other views about kde than yours.
Like what I just pointed out in this mail? That you just mix up things? So should I not correct you when you incorrectly assume that you need Nepomuk to run Plasma or that you need Akonadi to run Plasma or that you think that there is one large "KDE" thing?
I think I have to correct such misconceptions as I help you with that. It prevents you from spreading wrong information and basing solutions on wrong assumptions.
especially with regard to your trinity-bashing all over (mostly) german forums etc.
<offtopic>Well it's not on the mailing list, isn't it? But I don't write anything else on the German forums (esp. pro-linux) than what I do here. And it's all based on *facts*. If I find crashers in the TWin code (as in that case) it's nothing you can deny when I point that out and if I read that someone recommends Trinity and spreads misinformation like the one in your mail, I correct that. Sorry :-)</offtopic>
Cheers Martin
On Saturday 28 April 2012 20:03:19 Martin Gräßlin wrote:
they might not be 'hard' dependencies, so, in theory, one can install kde without them, but what is the result ? no mail, no contacts, no calendar, no search, no integration of whatsoever, in short: something that has probably less functionality than xfce or icewm. so, insead of installing kde without all the above, razor-qt seems to be a better choice...
sorry, but you just mix up things: razor-qt is a desktop shell like Plasma. Neither razor-qt provide mail, calendar or anything nor does Plasma.
no. I don't think I mix up things here. maybe I was just not clear enough in stating that plasma/kde workspace alone (without akonadi/nepomuk/strigi...) is not of much functional difference than xfce/icewm/razor-qt or anything else which does not provide native mail/contacts/calendars etc.
Werner
On Saturday 28 April 2012 20:36:55 Werner Joss wrote:
On Saturday 28 April 2012 20:03:19 Martin Gräßlin wrote:
they might not be 'hard' dependencies, so, in theory, one can install kde without them, but what is the result ? no mail, no contacts, no calendar, no search, no integration of whatsoever, in short: something that has probably less functionality than xfce or icewm. so, insead of installing kde without all the above, razor-qt seems to be a better choice...
sorry, but you just mix up things: razor-qt is a desktop shell like Plasma. Neither razor-qt provide mail, calendar or anything nor does Plasma.
no. I don't think I mix up things here. maybe I was just not clear enough in stating that plasma/kde workspace alone (without akonadi/nepomuk/strigi...) is not of much functional difference than xfce/icewm/razor-qt or anything else which does not provide native mail/contacts/calendars etc.
Now I don't get what you complain about. If the environment does not provide calendar integration you complain. If it does provide the integration you complain because of the used technology to get this integration.
Sorry, but that doesn't make any sense. Either you want or you don't want integration.
Cheers Martin
On Saturday 28 April 2012 21:14:11 Martin Gräßlin wrote:
no. I don't think I mix up things here. maybe I was just not clear enough in stating that plasma/kde workspace alone (without akonadi/nepomuk/strigi...) is not of much functional difference than xfce/icewm/razor-qt or anything else which does not provide native mail/contacts/calendars etc.
Now I don't get what you complain about. If the environment does not provide calendar integration you complain. If it does provide the integration you complain because of the used technology to get this integration.
Sorry, but that doesn't make any sense. Either you want or you don't want integration.
I don't complain. I just state what is provided by current projects, and what is not. and yes: I want integration. but not at the cost of having to run mysql servers on my single user desktop which proved more than once to be an unreliable beast and whatnot. and I'm not alone with this experience. mailinglists/forums are full of posts from frustrated users who have been bitten. exactly that is where trinity comes in: provide the well known, rock solid, snappy, lightweight, easy to maintain/backup kdepim from kde 3.5 on modern distros - well integrated with the rest of the DE/applications.
Werner
On Saturday 28 April 2012 21:34:07 Werner Joss wrote:
On Saturday 28 April 2012 21:14:11 Martin Gräßlin wrote:
no. I don't think I mix up things here. maybe I was just not clear enough in stating that plasma/kde workspace alone (without akonadi/nepomuk/strigi...) is not of much functional difference than xfce/icewm/razor-qt or anything else which does not provide native mail/contacts/calendars etc.
Now I don't get what you complain about. If the environment does not provide calendar integration you complain. If it does provide the integration you complain because of the used technology to get this integration.
Sorry, but that doesn't make any sense. Either you want or you don't want integration.
I don't complain. I just state what is provided by current projects, and what is not. and yes: I want integration. but not at the cost of having to run mysql servers on my single user desktop which proved more than once to be an unreliable beast and whatnot. and I'm not alone with this experience. mailinglists/forums are full of posts from frustrated users who have been bitten.
Which has nothing to do with MySQL. Yeah I have heard that argument a thousand times and I have spoken face to face with the developers about it and have even used Akonadi to write my Master thesis, so I think I know a little bit about it.
I'm not going to repeat everything what has been said about it, but I have so far not seen any *valid* complain about the usage of a database server for Akonadi. Nobody complains that Firefox includes a full blown database server. Nobody complains that Thunderbird includes a full blown database server. Nobody complains that Amarok uses an embedded MySQL.
Everybody complains about Akonadi using MySQL. That's just irrational and doesn't make sense. People just don't understand it, but if everybody repeats the sh** they read on slashdot it *has* to be true. It says so in the Internet, running MySQL is evil! It's much better to reinvent the wheel and write your own database!!!! Nobody can complain then and it totally doesn't matter that you have no idea how to implement a DBMS, but people cannot complain anymore \o/
The only valid complain about MySQL is for the usage of NFS shared home directories, but that's nicely documented and admins can easily take care about it.
exactly that is where trinity comes in: provide the well known, rock solid, snappy, lightweight, easy to maintain/backup kdepim from kde 3.5 on modern distros - well integrated with the rest of the DE/applications.
NO! Trinity does not provide *any* integration between DE and Kontact. That does not exist and has never existed [1].
Integration into the desktop shell (e.g. appointments in the calendar) is something which only became possible with Akonadi.
Cheers Martin
[1]: There seems to be a hacky patch to the clock applet at http://pinaraf.blogspot.de/2007/07/quick-and-dirty-clock-applet-patch-for.ht... which got never integrated.
On Saturday 28 April 2012 22:03:24 Martin Gräßlin wrote:
I don't complain. I just state what is provided by current projects, and what is not. and yes: I want integration. but not at the cost of having to run mysql servers on my single user desktop which proved more than once to be an unreliable beast and whatnot. and I'm not alone with this experience. mailinglists/forums are full of posts from frustrated users who have been bitten.
Which has nothing to do with MySQL. Yeah I have heard that argument a thousand times and I have spoken face to face with the developers about it and have even used Akonadi to write my Master thesis, so I think I know a little bit about it.
I'm not going to repeat everything what has been said about it, but I have so far not seen any *valid* complain about the usage of a database server for Akonadi. Nobody complains that Firefox includes a full blown database server. Nobody complains that Thunderbird includes a full blown database server.
I do. FF&TB are slow, ugly + bloated, so I won't use them (anymore).
Nobody complains that Amarok uses an embedded MySQL.
amarok-trinity uses libsqlite3, not mysql.
btw., from a users view, it doesn't make much difference if mysql or anything else is the culprit for the whole akonadi mess, which _has_ happened. I remember well the days when I used kubuntu with akonadi based addressbook (forced upon the users as usual as the next 'stable' version). every day then, it was just a matter of good luck or so if akonadi wouldn't crash, leaving my addressbook unusable until having deleted all mysql data etc. etc. and then started over - until next crash... then came the point where I decided to have my $HOME as a symlink to a directory on another physical partition. this worked ok for kde3/trinity/icewm/e17... but not for kde4: immediate, unrecoverable akonadi crash. just ridiculous. at that point, I gave up on kde (which was my favourite desktop until then from the 1.4.x days). since then, I'm using trinity, which has its own quirks, like outdated khtml rendering engine (for which is hope to have it replaced by webkit at some point in the future). but I have _never_ had disfunctional address books/calendars nor lost/duplicated/corrupted emails with it. plus, with only few essential files (std.vcf, std.ics..) in my dropbox account (and email on my imap server), I always have the most important data accessible wherever I am, regardless of OS/device available.
not to mention applications which are still only available in trinity (quanta+) or a fast, simple office suite (koffice 1.6.3) which does just what I need without beeing dead slow or even corrupt my data (which koffice 2.x has done more than once).
to sum it up: trinity _is_ a valid choice for me, I am very grateful that Tim and all others who put their time in it keep this running.
YOU ROCK, folks.
Werner p.s.: all this does not mean I will not try kde4 again at some point in future, but surely not before 4.9.x
On Sunday 29 April 2012 10:15:36 Werner Joss wrote:
I'm not going to repeat everything what has been said about it, but I have so far not seen any *valid* complain about the usage of a database server for Akonadi. Nobody complains that Firefox includes a full blown database server. Nobody complains that Thunderbird includes a full blown database server.
I do. FF&TB are slow, ugly + bloated, so I won't use them (anymore).
out of curiosity: which browser are you using then? I am not aware of any browser which does not come with a database.
Nobody complains that Amarok uses an embedded MySQL.
amarok-trinity uses libsqlite3, not mysql.
fair enough, you know what I had to do when using Amarok 1.4? I had to install MySQL because Amarok was unable to handle my music collection with sqlite.
then came the point where I decided to have my $HOME as a symlink to a directory on another physical partition. this worked ok for kde3/trinity/icewm/e17... but not for kde4: immediate, unrecoverable akonadi crash. just ridiculous.
If you move sockets around, you should know what you do. Given that it's a bad idea to use symlink if you could use a loop mount which would have worked.
That's I'm sorry a user issue.
at that point, I gave up on kde (which was my favourite desktop until then from the 1.4.x days).
Please see: you complain about a PIM suit which has nothing to do with the "desktop". You could just have continued to use the KDE desktop with other software for PIM.
It's irrational to switch the desktop because another product of the same community gives you problems. Would you stop using google as a search engine just because you don't like Google Mail?
That's one of the thing which I try to get into the head of the people here: there is no such thing as "KDE". It's a developer community producing hundreds of software products which have nothing to do with each other. Referring to all software as "KDE" is wrong and to be honest quite mean.
not to mention applications which are still only available in trinity (quanta+)
instead of quanta+ you can use kdevelop with php support.
or a fast, simple office suite (koffice 1.6.3) which does just what I need without beeing dead slow or even corrupt my data (which koffice 2.x has done more than once).
You might have missed the news: there is no Koffice 2.x any more. The community forked and there is now Calligra which I have heard works fine.
But feel free to continue using KOffice 1.x which to my knowledge does not even support ODF.
p.s.: all this does not mean I will not try kde4 again at some point in future, but surely not before 4.9.x
Remember: there is no such thing as "kde4". You can give a try to the KDE Plasma Workspaces or to some of the KDE Applications, but there is no such thing as one "KDE".
I would recommend you to give a try to the KDE Plasma Workspace in version 4.8.2 and also even to Kontact in version 4.8.2. I've heard many problems have been resolved in the latest versions :-)
Oh but Dolphin had a major release in version 4.8, so there might be some things missing compared to 4.7. But that's just what I explain: the different products have nothing to do with each other.
Cheers Martin
On Sunday 29 April 2012 13:10:14 Martin Gräßlin wrote:
FF&TB are slow, ugly + bloated, so I won't use them (anymore).
out of curiosity: which browser are you using then? I am not aware of any browser which does not come with a database.
I use chromium, which does not depend on any database.
Nobody complains that Amarok uses an embedded MySQL.
amarok-trinity uses libsqlite3, not mysql.
fair enough, you know what I had to do when using Amarok 1.4? I had to install MySQL because Amarok was unable to handle my music collection with sqlite.
no problems here (maybe my music collection is just not large enough :)
then came the point where I decided to have my $HOME as a symlink to a directory on another physical partition. this worked ok for kde3/trinity/icewm/e17... but not for kde4: immediate, unrecoverable akonadi crash. just ridiculous.
If you move sockets around, you should know what you do. Given that it's a bad idea to use symlink if you could use a loop mount which would have worked.
ok, will try that, at some point.
That's I'm sorry a user issue.
at that point, I gave up on kde (which was my favourite desktop until then from the 1.4.x days).
Please see: you complain about a PIM suit which has nothing to do with the "desktop". You could just have continued to use the KDE desktop with other software for PIM.
sure, and in fact, this is what most linux users I know personally, did: switch to TB or something else, or even abandon kde as a whole, as I did.
instead of quanta+ you can use kdevelop with php support.
this is not (yet) available for debian, AFAIK.
or a fast, simple office suite (koffice 1.6.3) which does just what I need without beeing dead slow or even corrupt my data (which koffice 2.x has done more than once).
You might have missed the news: there is no Koffice 2.x any more. The community forked and there is now Calligra which I have heard works fine.
I'm aware of this, didn't try so far, however, after the horrible koffice 2.x experience...
But feel free to continue using KOffice 1.x which to my knowledge does not even support ODF.
it does. not to all recent specs, but enough for my use cases. I can read my files with OO/LO or even MSoffice w.o. problems.
Werner
On Sunday 29 April 2012 13:37:32 Werner Joss wrote:
On Sunday 29 April 2012 13:10:14 Martin Gräßlin wrote:
FF&TB are slow, ugly + bloated, so I won't use them (anymore).
out of curiosity: which browser are you using then? I am not aware of any browser which does not come with a database.
I use chromium, which does not depend on any database.
but why does apt-cache showsrc chromium list libsqlite3-dev as a build dependency?
instead of quanta+ you can use kdevelop with php support.
this is not (yet) available for debian, AFAIK.
aptitude search kdevelop: -> kdevelop-php
or a fast, simple office suite (koffice 1.6.3) which does just what I need without beeing dead slow or even corrupt my data (which koffice 2.x has done more than once).
You might have missed the news: there is no Koffice 2.x any more. The community forked and there is now Calligra which I have heard works fine.
I'm aware of this, didn't try so far, however, after the horrible koffice 2.x experience...
But feel free to continue using KOffice 1.x which to my knowledge does not even support ODF.
it does. not to all recent specs, but enough for my use cases. I can read my files with OO/LO or even MSoffice w.o. problems.
have fun the first time you get an dotx :-)
Cheers Martin
it does. not to all recent specs, but enough for my use cases. I can read my files with OO/LO or even MSoffice w.o. problems.
have fun the first time you get an dotx :-)
I do, and there's no office package that can handle docx the "correct" way despite M$-Office.
I don't get the point of this prolonged discussion: let's state somebody would really want to trade twin for something else, why should he use kwin? What's the benefit? As I see it, there's simply no point to prefer kwin to e.g. fvwm or openbox.
By the way, I still have the infamouse problem of slugish qt4 experience.
Nik
On Sunday 29 April 2012 17:22:03 Mag. Dr. Nikolaus Klepp wrote:
I don't get the point of this prolonged discussion: let's state somebody would really want to trade twin for something else, why should he use kwin? What's the benefit? As I see it, there's simply no point to prefer kwin to e.g. fvwm or openbox.
well using fvwm or openbox is a completely different kettle. Of course you can question whether it makes sense to use KWin or TWin at all. A good reference for comparison is of course [1]. (Note that KWin is the only window manager having a yes in all listed categories)
The Trinity Desktop Environment is a fork of KDE 3.5. KDE 3.5 used as desktop shell KDesktop and Kicker and as a window manager KWin. TWin is the fork of this version of KWin. Obviously KWin is very well integrated with the rest of the desktop environment (e.g. uses same toolkit) and has been developed especially for the needs of this environment in comparison to things like openbox which is actually a standalone window manager and includes things you don't need. Using openbox will therefore result in higher RAM consumption than using KWin.
So to me the question whether openbox or fvwm should be used instead of KWin or TWin is just invalid.
This means the question is what are the advantages of using KWin over TWin. Well I'm not going to repeat what I have written in the past [2].
Cheers Martin
[1]: http://en.wikipedia.org/wiki/Comparison_of_X_window_managers [2]: http://trinity-devel.pearsoncomputing.net/?0::4312
On Sunday 29 of April 2012 18:42:34 Martin Gräßlin wrote:
The Trinity Desktop Environment is a fork of KDE 3.5. KDE 3.5 used as desktop shell KDesktop and Kicker and as a window manager KWin. TWin is the fork of this version of KWin. Obviously KWin is very well integrated with the rest of the desktop environment (e.g. uses same toolkit) and has been developed especially for the needs of this environment in comparison to things like openbox which is actually a standalone window manager and includes things you don't need. Using openbox will therefore result in higher RAM consumption than using KWin.
So you said this very descriptive! KWin4 is tightly integrated with rest of desktop environment == KDE4 (uses the same toolkit, etc). And just as TWin is tightly integrated with rest of desktop environment == TDE (uses the same toolkit, etc). Each lives in a different environment. KWin is NOT integrated with TDE and includes things that we do not need. Using KWin4 means outside TQt3 still have QT4 tooklit == higher RAM consumption than using TWin.
Slávek --
On Sunday 29 April 2012 19:13:35 Slávek Banko wrote:
On Sunday 29 of April 2012 18:42:34 Martin Gräßlin wrote:
The Trinity Desktop Environment is a fork of KDE 3.5. KDE 3.5 used as desktop shell KDesktop and Kicker and as a window manager KWin. TWin is the fork of this version of KWin. Obviously KWin is very well integrated with the rest of the desktop environment (e.g. uses same toolkit) and has been developed especially for the needs of this environment in comparison to things like openbox which is actually a standalone window manager and includes things you don't need. Using openbox will therefore result in higher RAM consumption than using KWin.
So you said this very descriptive! KWin4 is tightly integrated with rest of desktop environment == KDE4 (uses the same toolkit, etc). And just as TWin is tightly integrated with rest of desktop environment == TDE (uses the same toolkit, etc). Each lives in a different environment. KWin is NOT integrated with TDE and includes things that we do not need. Using KWin4 means outside TQt3 still have QT4 tooklit == higher RAM consumption than using TWin.
ah yes I knew that this conclusion would be drawn but it is incorrect. You can easily see that when you closely follow what I have written about the relationship between KWin and TWin and the relationship between KWin and Plasma and the possibilities to trim down KWin.
Cheers Martin
So to me the question whether openbox or fvwm should be used instead of KWin or TWin is just invalid.
No, the question stays unanswerd: Kwin = QT4, TWin = TQt3. So where is the point to switching?
This means the question is what are the advantages of using KWin over TWin. Well I'm not going to repeat what I have written in the past [2].
That does not answer the question, either. In fact it puts KWin on par to fvwm, openbox etc. as far as it's relation to TDE is concerned.
Nik
On Sunday 29 April 2012 19:38:28 Mag. Dr. Nikolaus Klepp wrote:
So to me the question whether openbox or fvwm should be used instead of KWin or TWin is just invalid.
No, the question stays unanswerd: Kwin = QT4, TWin = TQt3. So where is the point to switching?
This means the question is what are the advantages of using KWin over TWin. Well I'm not going to repeat what I have written in the past [2].
That does not answer the question, either. In fact it puts KWin on par to fvwm, openbox etc. as far as it's relation to TDE is concerned.
no it doesn't. KWin provides the same level of integration to Trinity as it has ever done, whether you call it KWin or TWin or FooBar doesn't change the fact that it is afterall KWin. Just for the fun of it, I just searched for the term "kicker" in KWin's source code and it still finds 11 reference.
So no, the question whether TWin or KWin is a completely different one to whether TWin or openbox.
Cheers Martin
no it doesn't. KWin provides the same level of integration to Trinity as it has ever done, whether you call it KWin or TWin or FooBar doesn't change the fact that it is afterall KWin. Just for the fun of it, I just searched for the term "kicker" in KWin's source code and it still finds 11 reference.
So no, the question whether TWin or KWin is a completely different one to whether TWin or openbox.
Sorry, I still don't get the point. What is the "integretion" you talk about? Is there a testcase where you can show the advantage of kwin above any other wm? As I see it - from a users point of view - the only difference between twin and any other wm is the configuration dialog. Is this valid for kwin, too?
Nik
On Monday 30 of April 2012 10:26:21 Mag. Dr. Nikolaus Klepp wrote:
Sorry, I still don't get the point. What is the "integretion" you talk about? Is there a testcase where you can show the advantage of kwin above any other wm? As I see it - from a users point of view - the only difference between twin and any other wm is the configuration dialog. Is this valid for kwin, too?
Exactly. The TWin advantages are obvious - the same toolkit (TQt3), Twin settings are integrated with other TDE settings. The KWin not even one of them. That is like any other window manager - it is a foreign element.
Slavek --
Am 30.04.2012 10:47, schrieb Slávek Banko:
On Monday 30 of April 2012 10:26:21 Mag. Dr. Nikolaus Klepp wrote:
Sorry, I still don't get the point. What is the "integretion" you talk about? Is there a testcase where you can show the advantage of kwin above any other wm? As I see it - from a users point of view - the only difference between twin and any other wm is the configuration dialog. Is this valid for kwin, too?
Exactly. The TWin advantages are obvious - the same toolkit (TQt3), Twin settings are integrated with other TDE settings. The KWin not even one of them. That is like any other window manager - it is a foreign element.
guys, I have written this multiple times: * KWin still includes exactly the same window decoration as the one used by TWin * all your configuration dialogs are basically unchanged - you can continue to use them
I don't know how often I have to write it: TWin and KWin are the same window manager.
The only difference is that KWin uses Qt 4 which is not visible when configured correctly (we already discussed that in this thread, haven't we?)
Cheers Martin
Martin Gräßlin wrote:
The only difference is that KWin uses Qt 4 which is not visible when configured correctly (we already discussed that in this thread, haven't we?)
It's very visible with regards to memory consumption though (as qt4 shared libs will be used in addition to qt3 libs) and since KWin not only requires qt4 but actually requires at least qt 4.7 (as you said) it means long term release distros like RHEL6 or older Ubuntu and Debian releases would no longer be able to run TDE.
Martin, you seem to be incapable of understanding that the real world doesn't live on the bleeding edge and doesn't want to upgrade to the latest bleeding edge distro release every 6 months! You don't seem to have any clue about average user requirements and this is certainly noticeable with KDE4, too.
I still cannot understand how the same group of people (or did most of the KDE team change?) who made one of the best (most practical, usable, intuitive and at the same time powerfull, flexible and configurable) Linux DEs ever (KDE3) managed to then move on to produce such an abomination as KDE4.
guys, I have written this multiple times:
- KWin still includes exactly the same window decoration as the one
used by TWin
- all your configuration dialogs are basically unchanged - you can
continue to use them
Ok, now I got that point. For those without fear - and running wheezy in a test environment:
# apt-get install kde-window-manager $ export KDEWM=/usr/bin/kwin $ export WINDOWMANAGER=/opt/trinity/bin/startkde $ startx
The window decorations are not the same, I got a light 1px border on my dark theme, although most of my setting is quoted. Side effects like semitransparent windows when moving, some strange behavour when moving a window to the screens top, but basicly it works. It's not as slugish as KDE4 but clearly slower than twin.
I am couriouse, if that works on other distos, too.
Besides from the proof of principle, I still do not see why anybody would like to jettison twin.
I don't know how often I have to write it: TWin and KWin are the same window manager.
The only difference is that KWin uses Qt 4 which is not visible when configured correctly (we already discussed that in this thread, haven't we?)
Yes, but where's the point? twin works and is fast. Why change?
Nik
On Monday 30 April 2012 14:39:10 Mag. Dr. Nikolaus Klepp wrote:
guys, I have written this multiple times:
- KWin still includes exactly the same window decoration as the one
used by TWin
- all your configuration dialogs are basically unchanged - you can
continue to use them
Ok, now I got that point. For those without fear - and running wheezy in a test environment:
# apt-get install kde-window-manager $ export KDEWM=/usr/bin/kwin $ export WINDOWMANAGER=/opt/trinity/bin/startkde $ startx
The window decorations are not the same, I got a light 1px border on my dark theme, although most of my setting is quoted.
probably a setting in the color scheme or compositing related.
Side effects like semitransparent windows when moving
A configurable feature to use translucency when moving windows
some strange behavour when moving a window to the screens top,
Quick Maximization and Quick Tiling on screen edges. That has everyone nowadays :-) (Read e.g. the release announcment of today's XFCE release). And of course it can be turned off
but basicly it works. It's not as slugish as KDE4 but clearly slower than twin.
no it isn't :-) I'm very sure about that. Please note that you used KWin with enabled OpenGL Compositing while it is disabled with TWin. Depending on hardware and driver that might result in a performance impact, though in general nowadays driver issues are resolved.
I am couriouse, if that works on other distos, too.
Besides from the proof of principle, I still do not see why anybody would like to jettison twin.
I don't know how often I have to write it: TWin and KWin are the same window manager.
The only difference is that KWin uses Qt 4 which is not visible when configured correctly (we already discussed that in this thread, haven't we?)
Yes, but where's the point? twin works and is fast. Why change?
I outlined the reasons, please read them up. I'm not going to repeat them :-)
Cheers Martin
At the risk of a repeated question (I've been unable to keep up with this thread):
Are there any components of TWin and KWin4 that do not directly interact with graphical libraries, compositing, and the like, that are still interchangeable or close to interchangeable with each other and their root ancestor of KWin3?
My understanding is that a fork is probably necessary given certian mutually exclusive objectives (ie Qt3 and legacy support versus optimization for the latest hardware), but is there a portion of code shared between the two that is basically not part of that fork that we might be able to separate out, possibly as a library?
James Gholston
On Monday 30 April 2012 04:47:30 jamesg@dimensionality.com wrote:
At the risk of a repeated question (I've been unable to keep up with this thread):
Are there any components of TWin and KWin4 that do not directly interact with graphical libraries, compositing, and the like, that are still interchangeable or close to interchangeable with each other and their root ancestor of KWin3?
My understanding is that a fork is probably necessary given certian mutually exclusive objectives (ie Qt3 and legacy support versus optimization for the latest hardware),
KWin does not optimize for the latest hardware. It does so for a certain degree as a compositor but you can just use KWin as a non-compositing window manager like TWin :-)
but is there a portion of code shared between the two that is basically not part of that fork that we might be able to separate out, possibly as a library?
sorry I don't think I get the question correctly.
Are you asking whether there is any code which code be moved from KWin to TWin? If yes, no, I want to resolve the fork and not create a Frankenstein.
Cheers Martin
On 29 Apr 2012, Werner Joss stated:
On Saturday 28 April 2012 22:03:24 Martin Gräßlin wrote:
I'm not going to repeat everything what has been said about it, but I have so far not seen any *valid* complain about the usage of a database server for Akonadi. Nobody complains that Firefox includes a full blown database server. Nobody complains that Thunderbird includes a full blown database server.
Because they don't. They use sqlite. sqlite, you will note, works basically everywhere, including NFS-shared home directories, without incident. (Of course, strigi doesn't work on NFS-shared home directories anyway, but thats less strigi's fault than the fault of the kernel hackers for implementing a filesystem notification feature which silently fails to work properly on network filesystems).
I do. FF&TB are slow, ugly + bloated, so I won't use them (anymore).
I take it you don't use Chrome, either (which also uses sqlite, if anything much more heavily than FF).
On Friday 27 April 2012 17:59:31 Julius Schwartzenberg wrote:
Maybe the kwin4 developers themselves could provide a stripped-down version of kwin4 for multiple popular distributions? I would imagine starting with adding a kwin-lite package to Debian/Ubuntu which would only have the limited set of dependencies. Maybe people on other DEs would like to use this package as well.
KDE developers do not do packaging. We have distributions for that. We only provide source code and the source code can be stripped down: http://techbase.kde.org/Projects/KWin/Build_Options
If anyone wants to have stripped down packages he has to do it. The KWin developers will not do that for you, sorry. I am not so stupid to assume I could make packages- I leave that to experts in packaging.
Cheers Martin Gräßlin
Martin Gräßlin wrote:
On Friday 27 April 2012 17:59:31 Julius Schwartzenberg wrote:
Maybe the kwin4 developers themselves could provide a stripped-down version of kwin4 for multiple popular distributions? I would imagine starting with adding a kwin-lite package to Debian/Ubuntu which would only have the limited set of dependencies. Maybe people on other DEs would like to use this package as well.
KDE developers do not do packaging. We have distributions for that. We only provide source code and the source code can be stripped down: http://techbase.kde.org/Projects/KWin/Build_Options
If anyone wants to have stripped down packages he has to do it. The KWin developers will not do that for you, sorry. I am not so stupid to assume I could make packages- I leave that to experts in packaging.
True of course, but in this case there is a chicken and egg problem. The kwin4 developers would like to see kwin4 being used outside of KDE4 and currently distribution packagers assume kwin4 is only meant to be part of KDE4 and package it as such.
I'm not a packaging expert either. Although I may be able to look into this in the future, I guess for now it would be good to create a report maybe on Launchpad.
Martin, do you have a proposal for the name of this package? There seem to be multiple kde-window-manager* packages already on Ubuntu. Would a -lite suffix seem appropriate to you?
With which options exactly would you compile this version? Would disabling *all* build options give a representable build of kwin4? There are some options that are not fully obvious to me. What happens when kwin4 wouldn't have decorations?
If there would be a short set of complete commands to fetch the source, configure it with limited dependencies, etc. it could also be put on the Trinity wiki to encourage testing.
Best regards, Julius
On Saturday 28 April 2012 15:52:13 Julius Schwartzenberg wrote:
Martin Gräßlin wrote:
On Friday 27 April 2012 17:59:31 Julius Schwartzenberg wrote:
Maybe the kwin4 developers themselves could provide a stripped-down version of kwin4 for multiple popular distributions? I would imagine starting with adding a kwin-lite package to Debian/Ubuntu which would only have the limited set of dependencies. Maybe people on other DEs would like to use this package as well.
KDE developers do not do packaging. We have distributions for that. We only provide source code and the source code can be stripped down: http://techbase.kde.org/Projects/KWin/Build_Options
If anyone wants to have stripped down packages he has to do it. The KWin developers will not do that for you, sorry. I am not so stupid to assume I could make packages- I leave that to experts in packaging.
True of course, but in this case there is a chicken and egg problem. The kwin4 developers would like to see kwin4 being used outside of KDE4 and currently distribution packagers assume kwin4 is only meant to be part of KDE4 and package it as such.
No, distributions package for what is demand. E.g. Kubuntu is shipping in 12.04 four versions of KWin.
As we are currently talking of a not yet released version of KWin anyway it does not make much sense to say there is a chicken-egg problem.
I'm not a packaging expert either. Although I may be able to look into this in the future, I guess for now it would be good to create a report maybe on Launchpad.
Martin, do you have a proposal for the name of this package? There seem to be multiple kde-window-manager* packages already on Ubuntu. Would a -lite suffix seem appropriate to you?
I have nothing to do with packaging. I cannot give any recommendations. That's up to the Ubuntu community.
But honestly I doubt that Ubuntu would include any Trinity specific version of KWin given that there are no other packages for Trinity available.
With which options exactly would you compile this version? Would disabling *all* build options give a representable build of kwin4? There are some options that are not fully obvious to me. What happens when kwin4 wouldn't have decorations?
well the options do what they name. If you disable decorations there won't be decorations, quite simple :-) It's a build option used for KDE's tablet user interface.
So no turning all build options off doesn't make any sense.
If there would be a short set of complete commands to fetch the source, configure it with limited dependencies, etc. it could also be put on the Trinity wiki to encourage testing.
Excerpt from my Jenkins build job to test the compile options used for Plasma Active: mkdir $WORKSPACE/../build cd $WORKSPACE/../build cmake - DCMAKE_PREFIX_PATH=/usr/share/tomcat7/.jenkins/jobs/kdelibs-4.8/install/ \ -DNepomuk_FOUND=FALSE \ -DWITH_OpenGL=OFF \ -DKWIN_PLASMA_ACTIVE=ON \ -DCMAKE_INSTALL_PREFIX=$WORKSPACE/../install \ -DCMAKE_BUILD_TYPE=RelWithDebInfo \ $WORKSPACE/../../kde-workspace/workspace cd kwin make -j3 make install
So yes it is possible to have a small script :-)
Cheers Martin
Martin Gräßlin wrote:
But honestly I doubt that Ubuntu would include any Trinity specific version of KWin given that there are no other packages for Trinity available.
Yes, that's true. But wouldn't you agree that this package would be suitable for more than just Trinity? :) There are more window-managers packaged that are not related to a specific DE. I would treat this version of kwin4 as such as well.
With which options exactly would you compile this version? Would disabling *all* build options give a representable build of kwin4? There are some options that are not fully obvious to me. What happens when kwin4 wouldn't have decorations?
well the options do what they name. If you disable decorations there won't be decorations, quite simple :-) It's a build option used for KDE's tablet user interface.
So no turning all build options off doesn't make any sense.
Alright, that makes sense :)
If there would be a short set of complete commands to fetch the source, configure it with limited dependencies, etc. it could also be put on the Trinity wiki to encourage testing.
Excerpt from my Jenkins build job to test the compile options used for Plasma Active: mkdir $WORKSPACE/../build cd $WORKSPACE/../build cmake - DCMAKE_PREFIX_PATH=/usr/share/tomcat7/.jenkins/jobs/kdelibs-4.8/install/ \ -DNepomuk_FOUND=FALSE \ -DWITH_OpenGL=OFF \ -DKWIN_PLASMA_ACTIVE=ON \ -DCMAKE_INSTALL_PREFIX=$WORKSPACE/../install \ -DCMAKE_BUILD_TYPE=RelWithDebInfo \ $WORKSPACE/../../kde-workspace/workspace cd kwin make -j3 make install
I used these commands now:
git clone git://anongit.kde.org/kde-workspace mkdir build
cmake -DNepomuk_FOUND=FALSE -DWITH_OpenGL=OFF -DKWIN_PLASMA_ACTIVE=OFF \ -DKWIN_BUILD_XRENDER_COMPOSITING=OFF -DKWIN_BUILD_ACTIVITIES=OFF \ ../kde-workspace
cd kwin make -j3
But it fails with this compilation error:
[ 44%] Built target oxygen-shadow-demo /home/julius/src/kwin4/kde-workspace/kwin/kcmkwin/kwincompositing/main.cpp:97:0: warning: "XRENDER_INDEX" redefined [enabled by default] /home/julius/src/kwin4/kde-workspace/kwin/kcmkwin/kwincompositing/main.cpp:93:0: note: this is the location of the previous definition [ 44%] Building CXX object kwin/effects/CMakeFiles/kwin4_effect_builtins.dir/magnifier/magnifier.o [ 44%] Building CXX object kwin/effects/CMakeFiles/kwin4_effect_gles_builtins.dir/magnifier/magnifier.o
/home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp: In member function 'virtual void KWin::MagnifierEffect::paintScreen(int, QRegion, KWin::ScreenPaintData&)': /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:173:20: error: 'XTransform' does not name a type /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:179:20: error: 'XTransform' does not name a type /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:185:42: error: 'PictOpSrc' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:186:105: error: 'XRenderComposite' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:188:13: error: 'xform' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:188:57: error: 'XDoubleToFixed' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:190:87: error: 'XRenderSetPictureTransform' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:191:112: error: 'XRenderSetPictureFilter' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:195:82: error: 'identity' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:200:13: error: 'XRenderColor' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:200:26: error: expected ';' before 'c' /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:201:91: error: 'c' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:201:102: error: 'XRenderFillRectangles' was not declared in this scope make[2]: *** [kwin/effects/CMakeFiles/kwin4_effect_builtins.dir/magnifier/magnifier.o] Error 1 make[1]: *** [kwin/effects/CMakeFiles/kwin4_effect_builtins.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... [ 44%] Building CXX object kwin/effects/CMakeFiles/kwin4_effect_gles_builtins.dir/snaphelper/snaphelper.o /home/julius/src/kwin4/kde-workspace/kwin/effects/snaphelper/snaphelper.cpp: In member function 'virtual void KWin::SnapHelperEffect::postPaintScreen()': /home/julius/src/kwin4/kde-workspace/kwin/effects/snaphelper/snaphelper.cpp:168:17: error: 'XRenderColor' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/snaphelper/snaphelper.cpp:168:30: error: expected ';' before 'c' /home/julius/src/kwin4/kde-workspace/kwin/effects/snaphelper/snaphelper.cpp:169:50: error: 'PictOpOver' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/snaphelper/snaphelper.cpp:169:96: error: 'c' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/snaphelper/snaphelper.cpp:169:107: error: 'XRenderFillRectangles' was not declared in this scope make[2]: *** [kwin/effects/CMakeFiles/kwin4_effect_gles_builtins.dir/snaphelper/snaphelper.o] Error 1 make[2]: *** Waiting for unfinished jobs.... [ 44%] Building CXX object kwin/kcmkwin/kwincompositing/CMakeFiles/kcm_kwincompositing.dir/__/__/compositingprefs.o /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp: In member function 'virtual void KWin::MagnifierEffect::paintScreen(int, QRegion, KWin::ScreenPaintData&)': /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:173:20: error: 'XTransform' does not name a type /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:179:20: error: 'XTransform' does not name a type /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:185:42: error: 'PictOpSrc' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:186:105: error: 'XRenderComposite' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:188:13: error: 'xform' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:188:57: error: 'XDoubleToFixed' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:190:87: error: 'XRenderSetPictureTransform' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:191:112: error: 'XRenderSetPictureFilter' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:195:82: error: 'identity' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:200:13: error: 'XRenderColor' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:200:26: error: expected ';' before 'c' /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:201:91: error: 'c' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:201:102: error: 'XRenderFillRectangles' was not declared in this scope make[2]: *** [kwin/effects/CMakeFiles/kwin4_effect_gles_builtins.dir/magnifier/magnifier.o] Error 1 make[1]: *** [kwin/effects/CMakeFiles/kwin4_effect_gles_builtins.dir/all] Error 2 [ 44%] Building CXX object kwin/kcmkwin/kwincompositing/CMakeFiles/kcm_kwincompositing.dir/__/__/libkwineffects/kwinglobals.o /home/julius/src/kwin4/kde-workspace/kwin/kcmkwin/kwincompositing/main.cpp: In constructor 'KWin::KWinCompositingConfig::KWinCompositingConfig(QWidget*, const QVariantList&)': /home/julius/src/kwin4/kde-workspace/kwin/kcmkwin/kwincompositing/main.cpp:96:8: error: 'class Ui::KWinCompositingConfig' has no member named 'xrenderGroup' make[2]: *** [kwin/kcmkwin/kwincompositing/CMakeFiles/kcm_kwincompositing.dir/main.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [kwin/kcmkwin/kwincompositing/CMakeFiles/kcm_kwincompositing.dir/all] Error 2 make: *** [all] Error 2
Are my KDE libraries too old?
One small thing. Right now it is necessary to check out the complete kde-workspace to compile kwin. It would seem easier if kwin would be separate from the rest of kde-workspace. Or does kwin depend on most of kde-workspace anyhow?
Thanks, Julius
On Sat, 28 Apr 2012 23:56:01 +0200 Julius Schwartzenberg julius.schwartzenberg@gmail.com wrote:
Martin Gräßlin wrote:
But honestly I doubt that Ubuntu would include any Trinity specific version of KWin given that there are no other packages for Trinity available.
Yes, that's true. But wouldn't you agree that this package would be suitable for more than just Trinity? :) There are more window-managers packaged that are not related to a specific DE. I would treat this version of kwin4 as such as well.
With which options exactly would you compile this version? Would disabling *all* build options give a representable build of kwin4? There are some options that are not fully obvious to me. What happens when kwin4 wouldn't have decorations?
well the options do what they name. If you disable decorations there won't be decorations, quite simple :-) It's a build option used for KDE's tablet user interface.
So no turning all build options off doesn't make any sense.
Alright, that makes sense :)
If there would be a short set of complete commands to fetch the source, configure it with limited dependencies, etc. it could also be put on the Trinity wiki to encourage testing.
Excerpt from my Jenkins build job to test the compile options used for Plasma Active: mkdir $WORKSPACE/../build cd $WORKSPACE/../build cmake - DCMAKE_PREFIX_PATH=/usr/share/tomcat7/.jenkins/jobs/kdelibs-4.8/install/ \ -DNepomuk_FOUND=FALSE \ -DWITH_OpenGL=OFF \ -DKWIN_PLASMA_ACTIVE=ON \ -DCMAKE_INSTALL_PREFIX=$WORKSPACE/../install \ -DCMAKE_BUILD_TYPE=RelWithDebInfo \ $WORKSPACE/../../kde-workspace/workspace cd kwin make -j3 make install
I used these commands now:
git clone git://anongit.kde.org/kde-workspace mkdir build
cmake -DNepomuk_FOUND=FALSE -DWITH_OpenGL=OFF -DKWIN_PLASMA_ACTIVE=OFF \ -DKWIN_BUILD_XRENDER_COMPOSITING=OFF -DKWIN_BUILD_ACTIVITIES=OFF \ ../kde-workspace
cd kwin make -j3
But it fails with this compilation error:
[ 44%] Built target oxygen-shadow-demo /home/julius/src/kwin4/kde-workspace/kwin/kcmkwin/kwincompositing/main.cpp:97:0: warning: "XRENDER_INDEX" redefined [enabled by default] /home/julius/src/kwin4/kde-workspace/kwin/kcmkwin/kwincompositing/main.cpp:93:0: note: this is the location of the previous definition [ 44%] Building CXX object kwin/effects/CMakeFiles/kwin4_effect_builtins.dir/magnifier/magnifier.o [ 44%] Building CXX object kwin/effects/CMakeFiles/kwin4_effect_gles_builtins.dir/magnifier/magnifier.o
/home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp: In member function 'virtual void KWin::MagnifierEffect::paintScreen(int, QRegion, KWin::ScreenPaintData&)': /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:173:20: error: 'XTransform' does not name a type /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:179:20: error: 'XTransform' does not name a type /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:185:42: error: 'PictOpSrc' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:186:105: error: 'XRenderComposite' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:188:13: error: 'xform' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:188:57: error: 'XDoubleToFixed' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:190:87: error: 'XRenderSetPictureTransform' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:191:112: error: 'XRenderSetPictureFilter' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:195:82: error: 'identity' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:200:13: error: 'XRenderColor' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:200:26: error: expected ';' before 'c' /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:201:91: error: 'c' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:201:102: error: 'XRenderFillRectangles' was not declared in this scope make[2]: *** [kwin/effects/CMakeFiles/kwin4_effect_builtins.dir/magnifier/magnifier.o] Error 1 make[1]: *** [kwin/effects/CMakeFiles/kwin4_effect_builtins.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... [ 44%] Building CXX object kwin/effects/CMakeFiles/kwin4_effect_gles_builtins.dir/snaphelper/snaphelper.o /home/julius/src/kwin4/kde-workspace/kwin/effects/snaphelper/snaphelper.cpp: In member function 'virtual void KWin::SnapHelperEffect::postPaintScreen()': /home/julius/src/kwin4/kde-workspace/kwin/effects/snaphelper/snaphelper.cpp:168:17: error: 'XRenderColor' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/snaphelper/snaphelper.cpp:168:30: error: expected ';' before 'c' /home/julius/src/kwin4/kde-workspace/kwin/effects/snaphelper/snaphelper.cpp:169:50: error: 'PictOpOver' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/snaphelper/snaphelper.cpp:169:96: error: 'c' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/snaphelper/snaphelper.cpp:169:107: error: 'XRenderFillRectangles' was not declared in this scope make[2]: *** [kwin/effects/CMakeFiles/kwin4_effect_gles_builtins.dir/snaphelper/snaphelper.o] Error 1 make[2]: *** Waiting for unfinished jobs.... [ 44%] Building CXX object kwin/kcmkwin/kwincompositing/CMakeFiles/kcm_kwincompositing.dir/__/__/compositingprefs.o /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp: In member function 'virtual void KWin::MagnifierEffect::paintScreen(int, QRegion, KWin::ScreenPaintData&)': /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:173:20: error: 'XTransform' does not name a type /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:179:20: error: 'XTransform' does not name a type /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:185:42: error: 'PictOpSrc' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:186:105: error: 'XRenderComposite' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:188:13: error: 'xform' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:188:57: error: 'XDoubleToFixed' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:190:87: error: 'XRenderSetPictureTransform' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:191:112: error: 'XRenderSetPictureFilter' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:195:82: error: 'identity' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:200:13: error: 'XRenderColor' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:200:26: error: expected ';' before 'c' /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:201:91: error: 'c' was not declared in this scope /home/julius/src/kwin4/kde-workspace/kwin/effects/magnifier/magnifier.cpp:201:102: error: 'XRenderFillRectangles' was not declared in this scope make[2]: *** [kwin/effects/CMakeFiles/kwin4_effect_gles_builtins.dir/magnifier/magnifier.o] Error 1 make[1]: *** [kwin/effects/CMakeFiles/kwin4_effect_gles_builtins.dir/all] Error 2 [ 44%] Building CXX object kwin/kcmkwin/kwincompositing/CMakeFiles/kcm_kwincompositing.dir/__/__/libkwineffects/kwinglobals.o /home/julius/src/kwin4/kde-workspace/kwin/kcmkwin/kwincompositing/main.cpp: In constructor 'KWin::KWinCompositingConfig::KWinCompositingConfig(QWidget*, const QVariantList&)': /home/julius/src/kwin4/kde-workspace/kwin/kcmkwin/kwincompositing/main.cpp:96:8: error: 'class Ui::KWinCompositingConfig' has no member named 'xrenderGroup' make[2]: *** [kwin/kcmkwin/kwincompositing/CMakeFiles/kcm_kwincompositing.dir/main.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [kwin/kcmkwin/kwincompositing/CMakeFiles/kcm_kwincompositing.dir/all] Error 2 make: *** [all] Error 2
Are my KDE libraries too old?
Apparently XRender libraries are missing from the linker command ;) Or alternatively some #ifdef's are missing around the XRender code.
One small thing. Right now it is necessary to check out the complete kde-workspace to compile kwin. It would seem easier if kwin would be separate from the rest of kde-workspace. Or does kwin depend on most of kde-workspace anyhow?
Thanks, Julius
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages 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 28 April 2012 23:56:01 Julius Schwartzenberg wrote:
Martin Gräßlin wrote:
But honestly I doubt that Ubuntu would include any Trinity specific version of KWin given that there are no other packages for Trinity available.
Yes, that's true. But wouldn't you agree that this package would be suitable for more than just Trinity? :) There are more window-managers packaged that are not related to a specific DE. I would treat this version of kwin4 as such as well.
That's true, but those window managers can be used standalone (e.g. openbox) while that is not the case with KWin. Given the mission statement KWin is not meant to be used as a standalone window manager but together with a Desktop Shell.
The idea is that each Desktop Shell which uses KWin has to provide it's own KWin as currently done by the KDE Plasma Desktop/Netbook workspaces and KDE Plasma Active.
cmake -DNepomuk_FOUND=FALSE -DWITH_OpenGL=OFF -DKWIN_PLASMA_ACTIVE=OFF \ -DKWIN_BUILD_XRENDER_COMPOSITING=OFF -DKWIN_BUILD_ACTIVITIES=OFF \ ../kde-workspace
You don't need to have -DKWIN_PLASMA_ACTIVE=OFF - that's the default.
My recommendation would be to keep OpenGL enabled (disabling OpenGL means you use OpenGL ES which is not supported by all hardware) and also XRender enabled. Turning off Nepomuk btw has no influence on KWin, it's a leftover from my Jenkins when I built complete workspace instead of just KWin.
Are my KDE libraries too old?
no you found a combination which does not build (disabling XRender). I have not yet set up my Jenkins to build all combinations. This will be done when we are in feature freeze and I have time for such things :-)
One small thing. Right now it is necessary to check out the complete kde-workspace to compile kwin. It would seem easier if kwin would be separate from the rest of kde-workspace. Or does kwin depend on most of kde-workspace anyhow?
It only depends indirectly. The default window decoration Oxygen requires another lib from kde-workspace (can be disabled by build option to turn off decorations) and two D-Bus interfaces are generated at compilation.
Unfortunately it is non-trivial to split out kwin from kde-workspace as it's one git repository and the code moved around in the past quite often.
Cheers Martin
Martin Gräßlin wrote:
On Saturday 28 April 2012 23:56:01 Julius Schwartzenberg wrote:
Martin Gräßlin wrote:
But honestly I doubt that Ubuntu would include any Trinity specific version of KWin given that there are no other packages for Trinity available.
Yes, that's true. But wouldn't you agree that this package would be suitable for more than just Trinity? :) There are more window-managers packaged that are not related to a specific DE. I would treat this version of kwin4 as such as well.
That's true, but those window managers can be used standalone (e.g. openbox) while that is not the case with KWin. Given the mission statement KWin is not meant to be used as a standalone window manager but together with a Desktop Shell.
I would say there are more. Like Sawfish and Metacity which were originally used as part of Gnome, but are now also on their own.
The idea is that each Desktop Shell which uses KWin has to provide it's own KWin as currently done by the KDE Plasma Desktop/Netbook workspaces and KDE Plasma Active.
Yes, then it would indeed seem to make sense to ship it with Trinity maybe. Let's see. In the end, the goal is to also get Trinity itself into distributions.
cmake -DNepomuk_FOUND=FALSE -DWITH_OpenGL=OFF -DKWIN_PLASMA_ACTIVE=OFF \ -DKWIN_BUILD_XRENDER_COMPOSITING=OFF -DKWIN_BUILD_ACTIVITIES=OFF \ ../kde-workspace
You don't need to have -DKWIN_PLASMA_ACTIVE=OFF - that's the default.
My recommendation would be to keep OpenGL enabled (disabling OpenGL means you use OpenGL ES which is not supported by all hardware) and also XRender enabled. Turning off Nepomuk btw has no influence on KWin, it's a leftover from my Jenkins when I built complete workspace instead of just KWin.
Are my KDE libraries too old?
no you found a combination which does not build (disabling XRender). I have not yet set up my Jenkins to build all combinations. This will be done when we are in feature freeze and I have time for such things :-)
Alright, thank you very much! I managed to compile it now. I used these options: -DWITH_OpenGL=ON -DKWIN_BUILD_XRENDER_COMPOSITING=ON -DKWIN_BUILD_ACTIVITIES=OFF
I suppose I could even leave out the first two, as I guess they are on by default as well. Other than activities (which doesn't seem like a large difference to me for a fully separate build) are there other things I could disable? I guess the webpage you linked to doesn't let all the new options from the GIT version yet? Maybe there is also a list in the source tree?
One small thing. Right now it is necessary to check out the complete kde-workspace to compile kwin. It would seem easier if kwin would be separate from the rest of kde-workspace. Or does kwin depend on most of kde-workspace anyhow?
It only depends indirectly. The default window decoration Oxygen requires another lib from kde-workspace (can be disabled by build option to turn off decorations) and two D-Bus interfaces are generated at compilation.
Unfortunately it is non-trivial to split out kwin from kde-workspace as it's one git repository and the code moved around in the past quite often.
Yep, I expected it. I guess it's also a limitation of GIT. It makes more sense to hope GIT will one day support it rather then going through the all effort to split kwin out now I think.
Thanks, Julius
On Monday 30 April 2012 00:24:11 Julius Schwartzenberg wrote:
Alright, thank you very much! I managed to compile it now. I used these options: -DWITH_OpenGL=ON -DKWIN_BUILD_XRENDER_COMPOSITING=ON -DKWIN_BUILD_ACTIVITIES=OFF
I suppose I could even leave out the first two, as I guess they are on by default as well.
correct
Other than activities (which doesn't seem like a large difference to me for a fully separate build) are there other things I could disable? I guess the webpage you linked to doesn't let all the new options from the GIT version yet? Maybe there is also a list in the source tree?
The web page lists everything currently supported to be disabled in the git tree. But soon there will come more things, like how to define a different name and after feature freeze I will create a branch for standalone building which will add a few more build options.
Cheers Martin
Martin Gräßlin wrote:
On Monday 30 April 2012 00:24:11 Julius Schwartzenberg wrote:
Other than activities (which doesn't seem like a large difference to me for a fully separate build) are there other things I could disable? I guess the webpage you linked to doesn't let all the new options from the GIT version yet? Maybe there is also a list in the source tree?
The web page lists everything currently supported to be disabled in the git tree. But soon there will come more things, like how to define a different name and after feature freeze I will create a branch for standalone building which will add a few more build options.
Great, then I think it will be good to continue based on this branch at this point. Having a different executable name is indeed something that is also missing now and crucial to get a separate kwin4 for Trinity.
I guess kwin4 will not fully replace twin short term, but any work towards making it easily available to Trinity users should enable replacing it in the long term at least.
One thing that is not fully clear yet however. Kwin4 is not able to integrate anymore with a Qt3 and kdelibs-v3 (Trinity) based environment as far as I am aware. Basically the sources have been migrated to the newer libraries, which is the reason for the current fork. In another message in this thread however, there was a mention that kwin4 still has references to kicker in its source. What about other facilities like DCOP? Basically my question would be, which advantages would kwin4 have at this point over other window managers like Metacity or Sawfish regarding integration with the rest of Trinity? The toolkit difference seems to be equal to me and I would expect the integration problems to be the same as well.
The current advantage I do see for kwin4 over the others is that its behavior is the closest to twin, because it's the same code but evolved. Another is that the themes are the same. I guess there are more advantages though? It would be interesting to have a good overview of this.
Thanks, Julius
On Monday 30 April 2012 18:31:12 Julius Schwartzenberg wrote:
One thing that is not fully clear yet however. Kwin4 is not able to integrate anymore with a Qt3 and kdelibs-v3 (Trinity) based environment as far as I am aware. Basically the sources have been migrated to the newer libraries
Yes, the sources have been adjusted to Qt4/kdelibs4 and I have no idea whether it would be possible to get it Qt3/kdelibs3 way again.
The sources will soon start to be adjusted to Qt 5 and kde frameworks 5 which will result in a much smaller library footprint, btw.
, which is the reason for the current fork.
no, the reason for the current fork is that Trinity forked everything and the kitchen sync instead of concentrating on what is missing from KDE 3.5 in current KDE 4.x versions.
Applications like KWin should never had been forked in the first place.
In another message in this thread however, there was a mention that kwin4 still has references to kicker in its source. What about other facilities like DCOP?
DCOP has been completely replaced by D-Bus.
Basically my question would be, which advantages would kwin4 have at this point over other window managers like Metacity or Sawfish regarding integration with the rest of Trinity?
You cannot easily switch window managers for a desktop environment. There are very often quite specific hacks and slight mis-interpretations of the EWMH specification and there are many KDE specific extensions to NETWM which only make sense in the context of a KDE desktop environment.
It is unlikely that an application like Kicker would work correctly with another window manager. E.g. it never worked correctly with Compiz.
The toolkit difference seems to be equal to me and I would expect the integration problems to be the same as well.
The toolkit difference is much smaller and actually a non-issue. As I mentioned in this thread a few times: the visual part of the window manager is the window decoration which is basically unchanged between KWin 3 and 4.
Apart from that there is the window menu which can be rendered using the Plastique Qt 4 style which is AFAIK the same as the one of KDE 3.
This means visually there is just no difference.
Furthermore any developer who worked with Qt 3 will be able to still work on KWin 4 - the basic concepts like Signal'n'Slot or C++ are unchanged.
Also it remains whether Qt 3 is the future of Trinity of whether the problem will go away by Trinity transiting to Qt 4. But that's nothing for this thread :-)
The current advantage I do see for kwin4 over the others is that its behavior is the closest to twin, because it's the same code but evolved. Another is that the themes are the same. I guess there are more advantages though? It would be interesting to have a good overview of this.
A good plus is that the code is maintained (which is not the case for Metacity for example), actively being developed, bugs get fixed in a short time. Crash free, one of the three largest window managers in use (together with Mutter and Compiz). Supports Desktop Integration through for any desktop environment through KWin scripting. Allows adjustment of window manager behavior for basically any use case through scripting (side note: my talk at this years Akademy has the title "Window Manager construction toolkit").
Overall KWin has features to build your own window manager for your desktop shell. That's something no other window manager provides to my knowledge. We already can serve as the Window Manager for three desktop shells, which can also not be reached by any other window manager.
KWin scored 4th place in the category "best window manager" of this years Linux Questions Member Choice Awards although KWin does not belong in this category (it means "standalone" window managers). It scored first place in the category of best Desktop Shell, though :-)
Cheers Martin
On 04/27/2012 06:30 AM, Andy wrote:
Martin Gräßlin wrote:
On Saturday 21 April 2012 09:57:36 François ANDRIOT wrote:
All distro do not have the bleeding edge QT4 or KDE4 version. For example, RHEL use QT 4.6 and KDE 4.3 . In that case, is TDE supposed to provide QT 4.7 (or newer) and the latest kdelibs just to provide the latest kwin ? I don't think so.
I highly recommend to not use KWin 4.3 anymore. And RHEL or SLES are very bad examples. Users of those want the old versions and do neither want to install a recent version of KDE software nor of TDE software. They use the old system because of the provided security by RedHat or SUSE. Installing anything third party invalidates the reason to use RHEL/SLES in the first place.
Martin, this is wrong and IMHO very arrongant from you (and from what I have seen it's typical of the attitude of some KDE4 devs).
Let's not start blasting our lasers. Every time we generalize and say "KDE4" devs it is not ok. That kind of blanket statement generates a lot of animosity. It would be like me saying 'all BLACK people' or some other stereotype. I think we need to avoid this.
There are many people (including myself) using RHEL6 (or rather one of it's clones Centos6 and SL6) on the desktop because it provides a>>STABLE BASE SYSTEM<<.
Most desktop users of EL6 clones will then make use of third party repos (as you might know there are several very large ones) in order to add desktop applications (not old versions!) and other enhachements including alternative DEs.
RHEL6/clones are actually a perfect match for TDE users as both the base system and the desktop can be considered conservative (not in the political sense) and stable.
Trinity is definitely a good target for Enterprise and Enterprise Clone Linux systems.
If a switch to KWin4 would mean that new releases of TDE no longer work on RHEL6 and clones then I think this is a very bad move.
Ok, so now we are getting to the actual point :-). I agree with you. Many current systems still do not even support the latest KWin4. this could be supplemented however if a Trinity branch/package of KWin was provided by TDE with minimal dependencies. Anyhow I see it unlikely that TWin would ever be abandoned totally, even if steps towards KWin were made. Tim has stated in the past he is not in favor of using KWin as default, and there is a similar sentiment among the list.
Also I fear that if TDE adopts KWin4 it will not have any influence on the direction of KWin4, basically it will be a 'take it or leave it' adoption. The IMHO quite condescending attitude that Martin has displayed in this thread makes that very likely.
I mean if we started using kwin, we would definitely have influence upon it because we would be the users. Reporting bugs requesting features. I am not sure what else you mean by "influence". KWin4 does everything TWin does.
Let's keep it friendly and to the point. Calvin
I mean if we started using kwin, we would definitely have influence upon it because we would be the users. Reporting bugs requesting features. I am not sure what else you mean by "influence". KWin4 does everything TWin does.
One of the points of contention with this and other related topics is how much influence do KDE4 users have? Please notice I did not write users have no influence. Nor did I write developers don't listen or respond to users. I only asked rhetorically how much influence.
Consider that nepomuk/akonadi/strigi remain non negotiables, despite users requesting this from Day One. The argument that these services can be disabled is not the same as not installing them in the first place. When other apps depend upon the libraries of those three packages then disabling the services accomplishes little. The overhead remains. The dependencies remain.
Many non enterprise users have no need or interest in social networking, regardless of the potential merits. The entire nepomuk/akonadi/strigi philosophy never has been optional within KDE4. Few people have argued that those features be ripped from KDE4. They argued that they should be optional. Truly optional. People who run a half dozen KAlarm events and check email twice a day don't need or want a caching engine running in the background. They don't care about sharing desktops or activities with other people. They don't care or need massive meta data indexing.
Yet building KDE4 without those three modules is not possible. Much like using Windows without IE is impossible. Where is the true choice and influence (other than using a different desktop environment)?
If I could use KDE PIM apps without akonadi then likely I would be using KDE4 part time. Not to mention that I still read reports that KMail remains broken to one degree or another --- four years later.
How much influence would Trinity users have with kwin4 development? I don't know. I have read too many KDE bug reports that were closed as Won't Fix.
Those are some of my thoughts about influence.
A significant point about this kwin4 discussion is if kwin4 integration is doable then let the hacking begin. Put up or shut up (not you Calvin but anybody who wants this integration should put up or shut up, including those proposing the idea). We Trinity folks don't go pimping in the KDE4 forums. If we tried that we would be banned in less than 24 hours. Why do certain individuals think that pimping KDE4 products here in the Trinity lists is any more acceptable?
Certain people need to stop acting like a telemarketer. Annoying. Leave us alone. The proposal has been made. The door to integration is open. Let the hacking begin.
Let's keep it friendly and to the point.
Indeed. Be friendly. Be open. Stay focused. Block email addresses.
Darrell
On Fri, 27 Apr 2012 11:05:12 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
I mean if we started using kwin, we would definitely have influence upon it because we would be the users. Reporting bugs requesting features. I am not sure what else you mean by "influence". KWin4 does everything TWin does.
One of the points of contention with this and other related topics is how much influence do KDE4 users have? Please notice I did not write users have no influence. Nor did I write developers don't listen or respond to users. I only asked rhetorically how much influence.
Consider that nepomuk/akonadi/strigi remain non negotiables, despite users requesting this from Day One. The argument that these services can be disabled is not the same as not installing them in the first place. When other apps depend upon the libraries of those three packages then disabling the services accomplishes little. The overhead remains. The dependencies remain.
[disclaimer: I'm not a KDE4 developer and I don't receive any dividend on the success of either KDE or TDE] Writing a program in C++ has some overhead, compared to writing it directly in asm or in C (for example, the brain-dead name mangling in the GNU v3 ABI, which brings an overhead for the dynamic linker). Removing your C++ compiler will accomplish little in building a lighter TDE. The overhead remains. The dependency on a C++ compiler remains.
Considering that, do you see people requesting TDE or KDE being rewritten in C or x86 asm ? I think with Akonadi this is the same. Akonadi uses an industrial-strength DB engine, which is (in the case of MySQL at least) geared for servers with GBs of RAM. On the performance side, it takes ~150M of RAM on a x86_64 system where KMail handles ~14K mails weighing ~800M and where there is ~1,5G more free RAM; IMHO it is satisfactory. (and for nepomuk and strigi, they are not really mandatory AFAIK)
Many non enterprise users have no need or interest in social networking, regardless of the potential merits. The entire nepomuk/akonadi/strigi philosophy never has been optional within KDE4. Few people have argued that those features be ripped from KDE4. They argued that they should be optional. Truly optional. People who run a half dozen KAlarm events and check email twice a day don't need or want a caching engine running in the background. They don't care about sharing desktops or activities with other people. They don't care or need massive meta data indexing.
Sharing desktops and activities _are_ optional in KDE4, since I don't use it. And the data indexing won't be massive if there isn't much data to index.
Yet building KDE4 without those three modules is not possible. Much like using Windows without IE is impossible. Where is the true choice and influence (other than using a different desktop environment)?
Using KDE without Qt is impossible. Where is the true choice and influence ?
If I could use KDE PIM apps without akonadi then likely I would be using KDE4 part time. Not to mention that I still read reports that KMail remains broken to one degree or another --- four years later.
IIRC the old KMail in KDE 4.4 didn't require Akonadi. Since KDE is backwards compatible between major version numbers you should be able to use it even on KDE 4.8/4.9.
How much influence would Trinity users have with kwin4 development? I don't know. I have read too many KDE bug reports that were closed as Won't Fix.
Those are some of my thoughts about influence.
A significant point about this kwin4 discussion is if kwin4 integration is doable then let the hacking begin. Put up or shut up (not you Calvin but anybody who wants this integration should put up or shut up, including those proposing the idea). We Trinity folks don't go pimping in the KDE4 forums. If we tried that we would be banned in less than 24 hours. Why do certain individuals think that pimping KDE4 products here in the Trinity lists is any more acceptable?
Certain people need to stop acting like a telemarketer. Annoying. Leave us alone. The proposal has been made. The door to integration is open. Let the hacking begin.
Let's keep it friendly and to the point.
Indeed. Be friendly. Be open. Stay focused. Block email addresses.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Friday 27 April 2012 11:05:12 Darrell Anderson wrote:
I mean if we started using kwin, we would definitely have influence upon it because we would be the users. Reporting bugs requesting features. I am not sure what else you mean by "influence". KWin4 does everything TWin does.
One of the points of contention with this and other related topics is how much influence do KDE4 users have? Please notice I did not write users have no influence. Nor did I write developers don't listen or respond to users. I only asked rhetorically how much influence.
Consider that nepomuk/akonadi/strigi remain non negotiables, despite users requesting this from Day One. The argument that these services can be disabled is not the same as not installing them in the first place. When other apps depend upon the libraries of those three packages then disabling the services accomplishes little. The overhead remains. The dependencies remain.
Many non enterprise users have no need or interest in social networking, regardless of the potential merits. The entire nepomuk/akonadi/strigi philosophy never has been optional within KDE4. Few people have argued that those features be ripped from KDE4. They argued that they should be optional. Truly optional. People who run a half dozen KAlarm events and check email twice a day don't need or want a caching engine running in the background. They don't care about sharing desktops or activities with other people. They don't care or need massive meta data indexing.
Yet building KDE4 without those three modules is not possible.
Please, please do your homework before doing such statements: * akonadi *not* a mandatory build dependency * strigi *not* a mandatory build dependency * nepomuk *not* a mandatory build dependency
I have pointed out this point several times on this mailing list. And still this wrong statement is done.
Akonadi is only a build dependency for Kontact and Akonadi has been developed for it. But it's not a requirement to use Kontact at all. It's an advanced application not targeting the "average" users (those who do complain btw).
Please also note that KDE only provides sources. It's the distribution's task to compile the software, so any request to have *packages* without Nepomuk/Akonadi/Strigi has to go to the distributions and *not* to the KDE developers.
Thanks for no longer spread misinformation about KDE.
Martin Gräßlin
On 04/27/2012 12:13 PM, Calvin Morrison wrote:
I mean if we started using kwin, we would definitely have influence upon it because we would be the users. Reporting bugs requesting features. I am not sure what else you mean by "influence". KWin4 does everything TWin does.
Let's keep it friendly and to the point. Calvin
Both Andy's and Calvin's points are well taken,
The 'influence' issue is actually a 'kwin responsiveness' issue. If there are specific needs or bugs associated with TDE users of kwin, then regardless of how many patches or bug reports are filed, if they are ignored and not implemented in kwin4, then Andy is correct -- there is no influence. At this point, that is a pure hypothetical. I personally don't see it being a problem with kwin as it was with KDE4. That was the straw that finally broke the camel's back for me with kde4 (as a global collection of apps). I authored over 200+ bug reports to help kde4 become usable in the 4.0.4 - 4.3.X time frame and 4 years later most are still unresolved or closed WON'T FIX.
That is both an influence and responsiveness issue. The desktop simply failed to meet the needs of the user in my case and it was abandoned. With twin, we have an excellent WM that is very responsive to this projects needs. If kwin can do the same, there is no reason not to see what it can provide. Equally true is that there is no need to abandon twin to do this. If somebody has the know how to build an install around kwin and test, then we can get an idea of where the shortcomings regarding TDE needs are and what can be done to address them. Until then, it is always good to think through the what if's of any situation, but as for whether and how well kwin can be used as a replacement for twin to allow a merge -- until it's done, it's all just speculation...
On Friday 27 April 2012 12:30:10 Andy wrote:
Martin Gräßlin wrote:
On Saturday 21 April 2012 09:57:36 François ANDRIOT wrote:
All distro do not have the bleeding edge QT4 or KDE4 version. For example, RHEL use QT 4.6 and KDE 4.3 . In that case, is TDE supposed to provide QT 4.7 (or newer) and the latest kdelibs just to provide the latest kwin ? I don't think so.
I highly recommend to not use KWin 4.3 anymore. And RHEL or SLES are very bad examples. Users of those want the old versions and do neither want to install a recent version of KDE software nor of TDE software. They use the old system because of the provided security by RedHat or SUSE. Installing anything third party invalidates the reason to use RHEL/SLES in the first place.
Martin, this is wrong and IMHO very arrongant from you
Please appologise for calling me arrogant!
(and from what I have seen it's typical of the attitude of some KDE4 devs). There are many people (including myself) using RHEL6 (or rather one of it's clones Centos6 and SL6) on the desktop because it provides a >>STABLE BASE SYSTEM<<.
Most desktop users of EL6 clones will then make use of third party repos (as you might know there are several very large ones) in order to add desktop applications (not old versions!) and other enhachements including alternative DEs.
You cannot use a modern DE with an outdated stack, that's just not supported. How do you get: * consolekit * sytstemd * Mesa 8 * recent X versions * Wayland (yes that's right now included in quite some distributions) * make your DE work with HAL again?
Linux is a system were everything is rolling-release and depends on each other. You cannot just take one component and use it with components of a different age. Especially Trinity should now that (HAL anyone?).
You cannot use a modern KWin with something like RHEL 6 as it does not meet minimum requirements we have (and that's not only Qt). But KWin 4.3 in RHEL does not meet the requirements for using KWin in Trinity.
RHEL6/clones are actually a perfect match for TDE users as both the base system and the desktop can be considered conservative (not in the political sense) and stable.
TDE is anything but stable - sorry, just look at the mailinglist and count your "does not compile", "crashes" and other things.
If a switch to KWin4 would mean that new releases of TDE no longer work on RHEL6 and clones then I think this is a very bad move.
You don't have to provide it for outdated software. Concentrate on the future :-)
Also I fear that if TDE adopts KWin4 it will not have any influence on the direction of KWin4, basically it will be a 'take it or leave it' adoption. The IMHO quite condescending attitude that Martin has displayed in this thread makes that very likely.
KWin has like any other KDE project a meritocratic development approach. The best way to get influence is by getting involved in development. The requirments to get features inside KWin are outlined in http://community.kde.org/KWin/Mission_Statement
Of course you cannot tell us what we have to work on - nobody can do that. Any feature request is evaluated based on the Mission Statement and only if it is considered as extremely important chances are that it gets implemented.
So if you have thinks you want to get into KWin you need to write the code - just like with TWin. If the code gets not accepted there are very good reasons for it (mostly quality).
Cheers Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/20/2012 01:00 PM, Martin Gräßlin wrote:
this again has nothing to do with KWin. Luckily a window manager does not use the column widget. Please keep that on topic. KWin has been running well on Qt 4 for more than four years, please keep that in mind.
Martin,
I do apologize for the kwin/kde grouping. I did not recognize where the boundary line was drawn between kwin and kde. As for the thrust of my original response -- I agree with you, if we can avoid duplication of effort and prevent creating inconsistencies in twin/kwin -- it makes sense. The only sticking point there would arise if there was functionality that twin needed that kwin did not. In that case, the only option would be to have separate patches to kwin to provided needed twin functionality (if that is maintainable) or continue with the fork.
I have a practical question. If twin and kwin were to merge, how would that impact the current GIT hosting of the code? Would the twin code be included in the TDE GIT tree as a submodule our would the TDE git tree just receive updates from kwin as needed? Thoughts?
- -- David C. Rankin, J.D.,P.E.
On Friday 20 April 2012 14:10:09 David C. Rankin wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/20/2012 01:00 PM, Martin Gräßlin wrote:
this again has nothing to do with KWin. Luckily a window manager does not use the column widget. Please keep that on topic. KWin has been running well on Qt 4 for more than four years, please keep that in mind.
Martin,
I do apologize for the kwin/kde grouping. I did not recognize where the boundary line was drawn between kwin and kde.
to explain it: KWin is a KDE application. That means it is developed by the KDE community. There is no such thing as "KDE" as a software product. KDE represents the KDE Community. The KDE Community produces a few products and there are three software bundles which are released together twice a year: * KDE Platform * KDE Applications * KDE Plasma Workspaces
This is often for historical reasons referred to as "KDE". But it is incorrect. There is no such thing as a KDE prodcut. The only relationship between the products is that all these products use the KDE Platform and are released on the same day. All the KDE Applications can be used on many Plattforms: GNOME Shell, Unity, XFCE, OS X, Mircosoft Windows, MeeGo Harmattan and the KDE Plasma Workspaces.
The KDE Plasma Workspaces represent the desktop shell and what belongs to it, that is the Plasma Desktop, Systemsettings, KDM and KWin. It is kind of the descendent of what "KDE 3.5" used to be or what you mostly mean when talking about KDE 3.5. KWin is the window manager and compositor used in the KDE Plasma Workspaces. It integrates with the KDE Plasma Workspaces, but does not require them, most of the Plasma integration is at runtime, everything else can be disabled at compile time (though there are at the moment still one or two calls to libplasma, which are going to be dropped soon).
I hope this helps you understand a little bit better how the KDE Community works and why you should not consider "KDE" as one thing. This also explains hopefully why e.g. the transition in kdepim has nothing to do with the desktop and that there is no such thing as a global version. Different software has different release cycles, that they by incident have the same version number does not mean anything.
As for the thrust of my original response -- I agree with you, if we can avoid duplication of effort and prevent creating inconsistencies in twin/kwin -- it makes sense. The only sticking point there would arise if there was functionality that twin needed that kwin did not. In that case, the only option would be to have separate patches to kwin to provided needed twin functionality (if that is maintainable) or continue with the fork.
As stated before KWin has not dropped or removed any code (with a few exceptions). Based on that there should not be anything in TWin which you need and which is not present in KWin. If there have been additions to TWin which are not present in KWin they need to be upstreamed. We accept code if it matches our goals and our quality standards.
I have a practical question. If twin and kwin were to merge, how would that impact the current GIT hosting of the code? Would the twin code be included in the TDE GIT tree as a submodule our would the TDE git tree just receive updates from kwin as needed? Thoughts?
The best solution would be to not host the code at all in TDE git tree. If you use a plain kwin you could just use our release tar-balls and add the patches from my (to be created) branch to build kwin standalone. A submodule is probably not possible as kwin is part of a greater kde-workspace repository.
Cheers Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/20/2012 02:40 PM, Martin Gräßlin wrote:
I hope this helps you understand a little bit better how the KDE Community works and why you should not consider "KDE" as one thing. This also explains hopefully why e.g. the transition in kdepim has nothing to do with the desktop and that there is no such thing as a global version. Different software has different release cycles, that they by incident have the same version number does not mean anything.
It does -- Thank you for taking the time to explain that.
<snip>
I have a practical question. If twin and kwin were to merge, how would that impact the current GIT hosting of the code? Would the twin code be included in the TDE GIT tree as a submodule our would the TDE git tree just receive updates from kwin as needed? Thoughts?
The best solution would be to not host the code at all in TDE git tree. If you use a plain kwin you could just use our release tar-balls and add the patches from my (to be created) branch to build kwin standalone. A submodule is probably not possible as kwin is part of a greater kde-workspace repository.
Well, logistically I guess it doesn't really matter. The only issue would be a matter of updating kwin from the kde.org svn tree before a TDE release. From a packaging standpoint, all current distro TDE build systems rely on getting the code from the TDE git tree -- which makes it very convenient. For those developing and packaging TDE, if there were a merge of twin/kwin I guess the simplest thing to do would be to simply mirror the kwin code in the GIT tree so that the merge is transparent to the TDE packagers, etc..
For someone to update the GIT tree with new kwin code from kde.org svn would be fairly trivial. I would just like to prevent fragmenting the tdebase source location for TDE. Right now, the TDE GIT repository is essentially a one-stop-shop.
- -- David C. Rankin, J.D.,P.E.
On Friday 20 April 2012 16:23:30 David C. Rankin wrote:
The best solution would be to not host the code at all in TDE git tree. If you use a plain kwin you could just use our release tar-balls and add the patches from my (to be created) branch to build kwin standalone. A submodule is probably not possible as kwin is part of a greater kde-workspace repository.
Well, logistically I guess it doesn't really matter. The only issue would be a matter of updating kwin from the kde.org svn tree before a TDE release. From a packaging standpoint, all current distro TDE build systems rely on getting the code from the TDE git tree -- which makes it very convenient. For those developing and packaging TDE, if there were a merge of twin/kwin I guess the simplest thing to do would be to simply mirror the kwin code in the GIT tree so that the merge is transparent to the TDE packagers, etc..
For someone to update the GIT tree with new kwin code from kde.org svn would be fairly trivial. I would just like to prevent fragmenting the tdebase source location for TDE. Right now, the TDE GIT repository is essentially a one-stop-shop.
KDE does not have an "svn tree" any more. It's all git nowadays.
Cheers Martin
On Fri, Apr 20, 2012 at 3:26 PM, Martin Gräßlin mgraesslin@kde.org wrote:
Hi all,
I had to see that there is still development going on in your fork of KWin and I am very unhappy about that. This is something I really want to see resolved, any development to KWin should happen in KWin, it's such a waste to work on the same project without coordination.
Let's first recapture the state of TWin: = Why does TWin exist? = Because KWin got forked together with everything else from KDE 3.5 to form the Trinity Desktop Environment (TDE).
= Why has the TDE fork happened? = The TDE fork existist because of a combination of the following reasons:
- Parts of KDE had to be rewritten in order to be ported to Qt 4
- Early versions of KDE 4.x were lacking functionality compared to KDE 3.5
...
And now it is not lacking that functionality from KDE 3.5?
I watch TDE more than year and conclude that it has a number of serious shortages:
1. Very small number of developers (3-4). 2. No or weak development policy. The development is spontaneous. 3. Insufficient development experience.
I would have placed problem number 3 as the basis of all troubles. The project now plays the role of training playground. Which may be benefit for those who learns. But is unexpected from the rest of TDE users.
-
/dev/ammo42 -
Aleksey Midenkov -
Andy -
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Francois Andriot -
François ANDRIOT
-
Ilya Chernykh -
jamesg＠dimensionality.com -
Julius Schwartzenberg -
Mag. Dr. Nikolaus Klepp -
Martin Gräßlin -
Nix -
Slávek Banko -
Timothy Pearson -
Werner Joss