20 Apr
2012
20 Apr
'12
11:26 a.m.
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
20 Apr
20 Apr
3:45 p.m.
New subject: [trinity-devel] Resolving the TWin/KWin Fork Issue
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
--
David C. Rankin, J.D.,P.E.
6 p.m.
New subject: [trinity-devel] Resolving the TWin/KWin Fork Issue
On Friday 20 April 2012 10:45:43 David C. Rankin 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.
That would
be a good start, yes. But I want to see more.
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 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
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.
> = 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.
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.
= 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. 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.
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.
Sorry I don't get what you want to tell me here.
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.
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... 
6:33 p.m.
<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
6:56 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
<snip>
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
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 
21 Apr
21 Apr
7:57 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
8:53 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
9:13 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 21 April 2012 10:53:35 Werner Joss wrote:
On Saturday 21 April 2012 09:57:36 François ANDRIOT
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)
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 :)
of course you could just switch to the
plastique style which is the same as
the KDE 3 style :-)
Cheers
Martin
9:24 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 21 April 2012 11:13:25 Martin Gräßlin wrote:
where would I do this ?
additional note:
clipboard doesn't work anymore with kwin, which is a show-stopper, IMHO.
Werner
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 :-)
9:31 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 21 April 2012 11:24:18 Werner Joss wrote:
On Saturday 21 April 2012 11:13:25 Martin Gräßlin
wrote:
where would I do this ?
systemsettings -> Application Appearance -> Style
-> Widget style: Plastique
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 :-)
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
9:38 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 21 April 2012 11:31:55 Martin Gräßlin wrote:
I have set plastik in kcontrol-appearnce-style, which is obviously ignored by
kwin.
why does then clipboard work ok when using twin ?
Werner
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.
9:47 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 21 April 2012 11:38:59 Werner Joss wrote:
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 11:31:55 Martin Gräßlin
wrote:
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.
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. 
10:12 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 21 April 2012 13:47:57 Martin Gräßlin wrote:
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.
systemsettings -> Application Appearance ->
Style -> Widget style:
Plastique
I have set plastik in kcontrol-appearnce-style, which is obviously ignored
by kwin.
10:24 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 21 April 2012 14:12:53 Ilya Chernykh wrote:
On Saturday 21 April 2012 13:47:57 Martin Gräßlin
wrote:
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
systemsettings -> Application Appearance ->
Style -> Widget style:
Plastique
I have set plastik in kcontrol-appearnce-style, which is obviously
ignored
by kwin.
10:09 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 21 April 2012 13:13:25 Martin Gräßlin wrote:
Not entirely the same.
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 :-) 
11:10 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On 21 Apr 2012, Martin Gräßlin spake thusly:
On Saturday 21 April 2012 10:53:35 Werner Joss wrote:
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
On Saturday 21 April 2012 09:57:36 François
ANDRIOT 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) 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}
22 Apr
22 Apr
8:03 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
9:55 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
10:30 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Sunday 22 April 2012 11:55:09 Martin Gräßlin wrote:
On Sunday 22 April 2012 10:03:50 Werner Joss wrote:
yes.
ksnapshot is working as expected (obviously).
Werner
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?
10:05 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Sunday 22 April 2012 00:10:36 Nix wrote:
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.
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).
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
21 Apr
21 Apr
9:17 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
9:49 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
Le 21/04/2012 11:17, Martin Gräßlin a écrit :
On Saturday 21 April 2012 09:57:36 François ANDRIOT
wrote:
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.
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. 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
10:35 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
27 Apr
27 Apr
10:30 a.m.
Martin Gräßlin wrote:
On Saturday 21 April 2012 09:57:36 François ANDRIOT
wrote:
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
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. 
3:59 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
5:08 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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.
28 Apr
28 Apr
9:52 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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.
9:58 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 28 April 2012 11:52:55 Martin Gräßlin wrote:
On Friday 27 April 2012 10:08:25 Darrell Anderson
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.
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.
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.
5:30 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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.
6:03 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 28 April 2012 19:30:38 Werner Joss wrote:
On Saturday 28 April 2012 11:58:04 Martin Gräßlin
wrote:
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.
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.
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
6:36 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 28 April 2012 20:03:19 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.
Werner
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.
7:14 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 28 April 2012 20:36:55 Werner Joss wrote:
On Saturday 28 April 2012 20:03:19 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.
Cheers
Martin
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.
7:34 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 28 April 2012 21:14:11 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.
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
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.
8:03 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 28 April 2012 21:34:07 Werner Joss wrote:
On Saturday 28 April 2012 21:14:11 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.
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.
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. 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.h…
which got never integrated.
29 Apr
29 Apr
8:15 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 28 April 2012 22:03:24 Martin Gräßlin wrote:
I do.
FF&TB are slow, ugly + bloated, so I won't use them (anymore).
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.
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
11:10 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Sunday 29 April 2012 10:15:36 Werner Joss wrote:
out of
curiosity: which browser are you using then? I am not aware of any
browser which does not come with a database.
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.
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. 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
11:37 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Sunday 29 April 2012 13:10:14 Martin Gräßlin wrote:
I use chromium, which does not depend on any database.
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 :)
ok, will try that, at some point.
I'm aware of this, didn't try so far, however, after the horrible koffice 2.x
experience...
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. 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.
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.
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. 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. 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
11:57 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Sunday 29 April 2012 13:37:32 Werner Joss wrote:
aptitude search kdevelop:
-> kdevelop-php
I'm aware of this, didn't try so far, however, after the horrible koffice
2.x experience...
have fun the first
time you get an dotx :-)
Cheers
Martin
On Sunday 29 April 2012 13:10:14 Martin Gräßlin
wrote:
I use chromium, which does not depend on any database.
but why does
apt-cache showsrc chromium
list libsqlite3-dev as a build dependency?
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. 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. 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. 
3:22 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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 :-)
4:42 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
5:13 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
--
7:11 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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:
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
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.
5:38 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
7:15 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Sunday 29 April 2012 19:38:28 Mag. Dr. Nikolaus Klepp wrote:
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
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.
30 Apr
30 Apr
8:26 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
8:47 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
--
9:17 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
Am 30.04.2012 10:47, schrieb Slávek Banko:
On Monday 30 of April 2012 10:26:21 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
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
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.
12:22 p.m.
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.
12:39 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
4:01 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Monday 30 April 2012 14:39:10 Mag. Dr. Nikolaus Klepp wrote:
probably a setting in the color
scheme or compositing related.
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
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 outlined the
reasons, please read them up. I'm not going to repeat them :-)
Cheers
Martin
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? 
11:47 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
3:53 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Monday 30 April 2012 04:47:30 jamesg(a)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
29 Apr
29 Apr
2:59 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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).
--
NULL && (void)
28 Apr
28 Apr
9:50 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
1:52 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
Martin Gräßlin wrote:
On Friday 27 April 2012 17:59:31 Julius Schwartzenberg
wrote:
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
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.
3:46 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 28 April 2012 15:52:13 Julius Schwartzenberg wrote:
Martin Gräßlin wrote:
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.
On Friday 27 April 2012 17:59:31 Julius
Schwartzenberg wrote:
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. 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.
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
9:56 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
Martin Gräßlin wrote:
Alright, that makes sense :)
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
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. 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 
10:01 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Sat, 28 Apr 2012 23:56:01 +0200
Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> wrote:
Martin Gräßlin wrote:
Alright, that makes sense :)
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.
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. 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
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(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)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
10:15 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Sunday 29 April 2012 00:01:35 /dev/ammo42 wrote:
Apparently XRender libraries are missing from the
linker command ;)
Or alternatively some #ifdef's are missing around the XRender code.
ifdef's
are missing :-)
10:14 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Saturday 28 April 2012 23:56:01 Julius Schwartzenberg wrote:
Martin Gräßlin wrote:
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.
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. 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
29 Apr
29 Apr
10:24 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
Martin Gräßlin 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.
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?
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 Saturday 28 April 2012 23:56:01 Julius
Schwartzenberg wrote:
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.
Martin Gräßlin wrote:
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. 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. 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 :-) 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.
30 Apr
30 Apr
3:50 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
4:31 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
Martin Gräßlin wrote:
On Monday 30 April 2012 00:24:11 Julius Schwartzenberg
wrote:
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
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.
5 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
27 Apr
27 Apr
5:13 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On 04/27/2012 06:30 AM, Andy wrote:
Martin Gräßlin wrote:
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.
On Saturday 21 April 2012 09:57:36 François
ANDRIOT wrote:
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). 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. 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
6:05 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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
7:25 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Fri, 27 Apr 2012 11:05:12 -0700 (PDT)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
[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)
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.
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(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)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
28 Apr
28 Apr
9:29 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Friday 27 April 2012 11:05:12 Darrell Anderson wrote:
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
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.
27 Apr
27 Apr
6:26 p.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
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...
--
David C. Rankin, J.D.,P.E.
28 Apr
28 Apr
9:47 a.m.
New subject: [trinity-devel] Re: Resolving the TWin/KWin Fork Issue
On Friday 27 April 2012 12:30:10 Andy wrote:
Martin Gräßlin wrote:
Please appologise for
calling me arrogant!
On Saturday 21 April 2012 09:57:36 François
ANDRIOT wrote:
Martin, this is wrong and IMHO very arrongant from you 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. (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
20 Apr
20 Apr
7:10 p.m.
New subject: [trinity-devel] Resolving the TWin/KWin Fork Issue
-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+RtJEACgkQZMpuZ8CyrcgTzwCeO4JaSUIQNsgEH9LXxDBuaOv+
NPEAn25hIz8ReWGDwYb3AywtQGoH6/kt
=3pew
-----END PGP SIGNATURE-----
7:40 p.m.
New subject: [trinity-devel] Resolving the TWin/KWin Fork Issue
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:
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.
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.
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
9:23 p.m.
New subject: [trinity-devel] Resolving the TWin/KWin Fork Issue
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/20/2012 02:40 PM, Martin Gräßlin wrote:
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.
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. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+R09IACgkQZMpuZ8CyrcgwFwCfUK8Rx3H/SXLpxSi5nm0IPlaV
LmkAn1x9+s4TOmFU+gUZ1Nj0lU19E4je
=1DWR
-----END PGP SIGNATURE-----
21 Apr
21 Apr
6:20 a.m.
New subject: [trinity-devel] Resolving the TWin/KWin Fork Issue
On Friday 20 April 2012 16:23:30 David C. Rankin wrote:
KDE does not have an "svn tree" any more. It's all git
nowadays.
Cheers
Martin
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. 
7:39 a.m.
New subject: [trinity-devel] Resolving the TWin/KWin Fork Issue
On Fri, Apr 20, 2012 at 3:26 PM, Martin Gräßlin <mgraesslin(a)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.
4380
days inactive
4390
days old
74 comments
17 participants
participants (17)
-
/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