Disclaimer: this post represents my personal opinion and does not represent the opinion of any community I’m involved with. The motiviation of this post is mostly the fact that I tried several times to get the project to stop their fork.
This week the Trinity Desktop Project released a bug fix release with very bold statements in their release announcement especially emphasizing on the 141 bug fixes and 1193 applied patches. Given that they include a fork of an application I know quite good I decided to try to validate their work on kwin. The release has been in work about a year and KWin has quite some bug fixes for reports dating back to the times of the forked application. I just used our bug database and searched for all KDE 2/3 bugs we fixed in the last year and I found the following 20 reports:
Bug Fixes
- 70943: Xinerama – position should be transformed to another screen
- 74546: High focus stealing prevention problem with independent configure dialogs
- 78739: Non-critical: Window lower border leaves margins in some cases
- 81271: A minimizied, shaded window shows up as not minimized in kicker
- 81743: Useraction menu closes when focus passes to another window
This change will be available in version 4.9 - 95627: Ghost window after dragging a window to another desktop with special window settings
- 97616: Maximize button not shown when window maximum size becomes larger than work area
- 130190: delayed focus problem when changing active windows
- 136856: Dragging items between desktops not controlable with enabled active desktop borders
Git Commit - 142040: “Focus follows mouse” does not change focus after clicking away a menu
- 146741: Initial fullscreen not set properly
New Features
- 80196: Sending window to background keeps it active
- 80749: Expad a window to one/all xinerama screens
- 90678: Fitts’ Law for decoration buttons
- 92290: JJ: change focus only when moving mouse
This change will be available in version 4.9 - 106818: separate “skip taskbar” from (not) receiving focus
- 107594: JJ: syntax checks for fields of the window-specific settings
- 123420: trying to max. a win. resizable in 1 dimension only should max. the win. in that dimension
- 124612: JJ: kwin fulscreen / un-fullscreen system notifications
This change will be available in version 4.9 - 136194: allow moving and resizing of maximized windows — split
Overall there are eight commits to kwin (Trinity) in the range v3.5.13..v3.5.13.1 performed by exactly one developer. The diffstat is an impressive:
62 files changed, 410 insertions(+), 397 deletions(-)
If I look at current KWin statistics our churn is much bigger, though most changes are most likely introduced by scripty and I don’t know how to filter out those commits.
Now lets have a look at what actually changed and whether the bold statements still hold. I did not expect much but I was really shocked when I looked through the diff. I did not see anything useful. The complete diff is cluttered with garbage like the following:
- positionGeometryTip(); // shown, otherwise it would cause tqrepaint problems in case + positionGeometryTip(); // shown, otherwise it would cause repaint problems in case
or
-// fLay->addColSpacing(0,QMAX(autoRaiseOn->tqsizeHint().width(), -// clickRaiseOn->tqsizeHint().width()) + 15); +// fLay->addColSpacing(0,QMAX(autoRaiseOn->sizeHint().width(), +// clickRaiseOn->sizeHint().width()) + 15);
and even in ui files we find this junk:
diff --git a/kwin/kcmkwin/kwinrules/detectwidgetbase.ui b/kwin/kcmkwin/kwinrules/detectwidgetbase.ui
index af4ca96..b13e794 100644
--- a/kwin/kcmkwin/kwinrules/detectwidgetbase.ui
+++ b/kwin/kcmkwin/kwinrules/detectwidgetbase.ui
@@ -29,7 +29,7 @@
<property name="sizeType">
<enum>Expanding</enum>
</property>
- <property name="tqsizeHint">
+ <property name="sizeHint">
What I can hardly show here in the excerpts but what I had seen in the git diff commit is lots of red. For those not familiar with colorful git diff output: red means introduced whitespace changes. So the script did not only convert nonsense in comments but also introduced trailing whitespaces and replaced either tabs by whitespaces or whitespaces by tabs.
Anyway it looks like they had a stupid script and reverted the changes. That would be in fact quite good to realize it was bad and to revert, unfortunately that is not the case. There is not one commit doing these changes there are four of the eight commits introducing these changes. E.g. "Rename old tq methods that no longer need a unique name". I don’t want to know how much broken code there is still around due to not being able to run a sed script properly and how many more issues got introduced by running such scripts again.
Well anyway there must be something useful in these remaining four commits, right? When I asked them to stop forking an application which they obviously do not understand and cannot develop I pointed out that they introduced possible ABI issues by reordering an enum. That’s now "fixed":
commit a65ae76df3276bf1925673dd6b6ec565448428ba
Author: Timothy Pearson <kb9vqf@pearsoncomputing.net>
Date: Mon Feb 13 13:30:41 2012 -0600
Clean up 9cc1e2c1 changes to enum
This corrects a potential ABI compat problem noted by Martin Gräßlin
(cherry picked from commit 77041d785dbbede734f8dc44aa454d07d14f0317)
diff --git a/kwin/lib/kdecoration.h b/kwin/lib/kdecoration.h
index 5f7e7fb..9d7fe39 100644
--- a/kwin/lib/kdecoration.h
+++ b/kwin/lib/kdecoration.h
@@ -97,10 +97,10 @@ public:
LowerOp,
FullScreenOp,
NoBorderOp,
- ShadowOp,
NoOp,
SetupWindowShortcutOp,
- ApplicationRulesOp ///< @since 3.5
+ ApplicationRulesOp, ///< @since 3.5
+ ShadowOp ///< @since 3.5.12
};
/**
* Basic color types that should be recognized by all decoration styles.
Sorry, you are doing it wrong. Now you fixed the ABI break prior to 3.5.13 by introducing another ABI break to 3.5.13.1. Lucky Trinity users that the ABI is so broken that loading a KWin 3 decoration will just crash KWin (Trinity) – hmm not sure whether that is better… Hint: reverting that change again will introduce another break.
So anything? Maybe one commit which is useful, any problem which is not already fixed in KWin? Well there would be one to workaround a problem with libre office:
commit 2482dd05e5b7806b4bad69ac8e07dbc4dd6714e0
Author: Timothy Pearson <kb9vqf@pearsoncomputing.net>
Date: Sat Mar 3 13:45:23 2012 -0600
Fix hostname display in titlebar with certain programs
This closes Bug 889
Thanks to Slávek Banko for the patch!
(cherry picked from commit 9e3f8a7f0c9f2ed1125c717f5374aaf8d4ec225e)
diff --git a/kwin/utils.cpp b/kwin/utils.cpp
index 34d29f9..a2e563d 100644
--- a/kwin/utils.cpp
+++ b/kwin/utils.cpp
@@ -18,6 +18,8 @@ License. See the file "COPYING" for the exact licensing terms.
#include "utils.h"
#include <unistd.h>
+#include <string.h>
+#include <netdb.h>
#ifndef KCMRULES
@@ -323,6 +325,27 @@ bool isLocalMachine( const TQCString& host )
if( host == hostnamebuf )
return true;
}
+ else
+ { // e.g. LibreOffice likes to give FQDN, even if gethostname() doesn't include domain
+ struct addrinfo hints, *res, *addr;
+ bool is_local = false;
+
+ memset (&hints, 0, sizeof (hints));
+ hints.ai_family = PF_UNSPEC;
+ hints.ai_socktype = SOCK_STREAM;
+ hints.ai_flags |= AI_CANONNAME;
+
+ if( getaddrinfo( host, NULL, &hints, &res ) != 0)
+ return false;
+ for(addr = res; !is_local && addr; addr = addr->ai_next)
+ {
+ if( res->ai_canonname &&
+ host == TQCString( res->ai_canonname ))
+ is_local = true;
+ }
+ freeaddrinfo(res);
+ return is_local;
+ }
}
return false;
}
What a pity that KWin already has a patch for that much longer:
commit c24ea2b4aac214ce29afc013cc037c110a24aa12
Author: Luboš Lu?ák <l.lunak@suse.cz>
Date: Fri Mar 4 16:22:23 2011 +0100
do not show hostname in titlebar if it's FQDN of localhost
diff --git a/kwin/utils.cpp b/kwin/utils.cpp
index 20d2ad0..92a89e5 100644
--- a/kwin/utils.cpp
+++ b/kwin/utils.cpp
@@ -421,6 +421,13 @@ bool isLocalMachine(const QByteArray& host)
*dot = '\0';
if (host == hostnamebuf)
return true;
+ } else { // e.g. LibreOffice likes to give FQDN, even if gethostname() doesn't include domain
+ QByteArray h = hostnamebuf;
+ if( getdomainname( hostnamebuf, sizeof hostnamebuf ) >= 0 ) {
+ hostnamebuf[sizeof(hostnamebuf)-1] = 0;
+ if( host == h + '.' + QByteArray( hostnamebuf ))
+ return true;
+ }
}
}
return false;
What strikes me as odd here is that the comment is exactly the same. Might it be that someone started of with the patch from KWin? If their patch is better why has it not been upstreamed?
Apart from that there is not much. One more commit fixing a warning in kcompmgr melded together with a completely unrelated change in a different application and one commit cleaning the CMakeLists.txt they introduced. Speaking of cmake: why would anyone change to cmake and not delete the Makefile.am files?
So overall none of the bugs fixed in KWin got backported to the fork, no issue from KDE 3.5 time got fixed. The majority of changes are some automated and rather stupid scripts which can nicely be shown by the diffstat without those commits:
4 files changed, 30 insertions(+), 17 deletions(-)
Given that analysis I find it an even more ridiculous joke to include the ohloh.net stats on the main home page. Yeah an impressive 14 developers having developed 14 million lines of code. From those 14 developers one is a KDE admin who created the repository and one automated system. I quite dislike someone who adorns himself with borrowed plumes like in the case of a fork. Even more if the developers still do not know who developed the code base they forked. Hint: KDE e.V. does not develop source code or release software. A nice example for taking credit for what one has not done is this change I run into:
diff --git a/doc/kdm/index.docbook b/doc/kdm/index.docbook index 730eb11..443a8c1 100644 --- a/doc/kdm/index.docbook +++ b/doc/kdm/index.docbook @@ -18,9 +18,9 @@ <title>The &kdm; Handbook</title> <authorgroup> -<author> -&Oswald.Buddenhagen; &Oswald.Buddenhagen.mail; -</author><!-- +<corpauthor> +The &kde; Documentation Team +</corpauthor><!-- <othercredit role="developer"> &Oswald.Buddenhagen; &Oswald.Buddenhagen.mail; <contrib>Developer</contrib>
I think it summarizes nicely what one should expect from this project. I can only recommend everybody to keep away from the junk this project is producing. I’m quite glad they try to cut off all connections to KDE because this project is seriously harming the reputation of KDE.
Why do we have the bug reports on BKO that relate to an unsupported version? Or are they already closed, but Trinity development team ( ‘team’ 🙂 ) is browsing through the closed ones?
Because they are (were) still not fixed in current 4.x. The list Martin quoted is of bugs which are now closed because he actually fixed them. 🙂
Dude please leave Trinity the *censored* alone and fix your own bugs, there are gazillions of bugs in KWin and lots of work to be done and you waste your time bullying a kid in your blog. I can’t understand this.
luckily I live in a free country allowing me the right of speech. If I want to look into Trinity and blog about it, nobody is going to fobid that. In the same way the Trinity developers are allowed to fork KWin.
The gazillions of bugs are by the way exactly 211 open reports (need to clean up a little bit again).
Martin, you are doing a GREAT work.
I hope you didn’t really take him seriously? 🙂
“Do not mind of them, but look and go” (Non ti curar di loro, ma guarda e passa) is a famous citation of Dante Aligheri 🙂
Unfortunately I do mind, because they harm KDE.
I don’t think they do. And with all due respect for your work, I think that negative writeups like this harms KDE more.
We are all part of a community and dependent on the inflow of new people. And If I saw a lot of hurtful texts like this I would be hesitant to join it because I would assume that there is a poisonous atmosphere in the project.
Luckily, this is not the case with KDE so let’s not make it look like there is.
Yes, I understand what you mean and that it is easy to get it wrong if one does not know that I tried to work together with the Trinity project.
I reflected your comment and withdraw it from planet and added a disclaimer that it is my personal opinion.
The typical response from a Trinity guy…
Every time cursing.
It’s really interesting how with this gazillion bugs I use KDE 4.9 and don’t have any problem.
Also on a very weak PC with AMD Athlon 3000+(1.8 GHz), low ram, old video card it works all great with all the gazillion of bugs.
There actually are a few issues with Kwin…
A lot are invisible to most user because they only show themselves when you use several screen (though the multi-screen support seems to have improved quite a bit in recent versions of KDE).
And there are a few spots that could use improvements. But yeah, mostly, Kwin went a long way and is probably on a lot of prospects the best windows manager there is.
I’m even wondering… why use an older version of Kwin ? If Trinity’s goal is to reestablish the look and feel of KDE3.5… is it that much important not to use a recent version of Kwin ? Is it that much linked to other elements of KDE4 ?
Multi-screen is actually working quite fine. Maybe you mean multi-head (one x-server per screen).
That’s exactly what I suggested to the Trinity developers. But they are afraid of getting the “akodani garbage scanner stuff”, but well that was wrong, they were in fact afraid of “I meant nepomuk, not akodanai”. Still Nepomuk is no dependency of KWin *shrug*
and you can turn-off Nepomuk…
1. Correcting bugs that were caused in the previous version does not strike me as less relevant or less important fixes. I find it a bit like when I’m in all KDE 4.9 announcements read that in KWin was fixed almost all errors that were introduced in previous KDE 4.x versions. To me it sounded like it might finally returned to the quality that was before KDE 4.x. 😉
2. If you put the least effort, you may find that the fix from Lukáš Lu?ák is insufficient and simply does not work. I tried to write to Lukáš – no response. I tried to put comment to the corresponding issue in KDE bugzilla – no response. Unfortunately, I did not understand how it is possible in KDE bugzilla poorly patched bug open again – also this my question remained unanswered.
I think I explained it several times to the Trinity devs: KWin in 4.x is the KWin of 3.x + the compositor. You can run KWin without the compositor.
Lubos is no longer active in KWin development. It is in general not a good idea to send mails to individual developers. That’s what mailing lists are for.
I am subscribed to all bug reports for KWin. I am not aware of any bug report for that particular issue. Would you please mind providing me the bug number?
Interesting – I would expect that if you have your comments on the this bug so that it’ll also receive messages.
Also, I assumed that as KDE developers you can collaborate with each other – and that they either Lukáš passes the message to you, or at least be able to reply.
https://bugs.kde.org/show_bug.cgi?id=256258
Must have missed that comment. I had been on a conference that week.
The problem is that we don’t handle patches through bug reports, for that we have to many reports. We use git.reviewboard.kde.org
KDE web is so confusing to me that every time I have a problem to find a way to source code – into GIT. So no wonder that I had not even find information about Review Board. That’s why I did what I could – added comments to Bugzilla.
Earlier in the same way I added some patches from Trinity for kdepim and there was a response essentially instantaneous.
Well that is what we also try to achieve. Most like that has failed due to the fact that I had been abroad and my bug filters only look for open reports.
Ninja trick: http://quickgit.kde.org/
I always use that instead of the projects.kde.org stuff, much quicker.
Great, thank you, this interface is much more usable. I’ll have to bookmark, because next time I visit KDE4 site the address again failed to find….
> Unfortunately, I did not understand how it is possible in KDE
> bugzilla poorly patched bug open again
KDE developers can reopen bugs. I just did that for you.
I see that the “international team of developers” called Timothy Pearson is still “actively maintaining” his code, LOL!
Maybe you should point out that openSUSE is still having KDE3 repositories that are maintained. You can install it right next to KDE4. This is nice for some applications that are not yet ported to KDE 4 like LabPlot. I think you can also install the complete KDE 3 desktop. No distribution will ship it. They rebranded it. I don’t see it harm KDE in any way.
I don’t need to point it out – you just did it 🙂 But yes, I think that the openSUSE way is much better, though some of the problems (like hal going away, linux now being 3.x instead of 2.6.x) apply for all variants of KDE 3.x.
What about the Fedora way? We do not ship a full KDE 3 desktop anymore (in fact we were the first major distribution to drop it, back in Fedora 9), but we maintain kdelibs3 compatibility libraries and so legacy KDE 3 apps still work fine in a current KDE 4 environment.
Not supporting a KDE 3 desktop allowed us to make our kdelibs3 integrate better into KDE Plasma 4, e.g. we fire up the KDE 4 DrKonqi if a KDE 3 app crashes.
Such an approach misses the point completely.
Reasons people want KDE3 are usually not the need to run older applications. I’m meanwhile used to KDE4, but big issues remain continuosu harassments by Nepomuk and Dolphin, the braindead idea of a taskbar that is limited to a single monitor, Kmail that has become a bad joke.
I’m using KDE4 at work and KDE 3.5 at home. I still prefer the latter allthough it slowly but surely becomes unusable due to Khtml not being updated to modern standards, the system below KDE that evolves etc.
Trinity is addressing some of these issues.
I do not tolerate such comments in my blog. Please have a look at the Code of Conduct.
For me it’s the first time that I read anyone would want a panel going over multiple screens. Doesn’t sound like a highly requested feature then…
and none of the issues is helped with forking KWin and that’s what this blog post is all about.
The effect of the taskbar being limited to a single monitor, or wether it spreads to multiple monitors (I have 3 of them) has a large impact on usability, since there is often lack of space on the taskbar to show all open windows. You know the effect, the bars get smaller and smaller until there are just icons.
Especially with multiple monitors, you open lot of windows. The taskbar being one monitor or multiple is then the difference between seeing only the icon (and having to search through windows with the same icon) or being able to read the window title and being able to click the right one instantly.
Perhaps I’m the only one in the world who wants this, perhaps I’m the only one with 3 monitors, but it’s one difference between KDE3 and KDE4 I experience every day.
and why not just put a panel on each screen with a task applet set to show the windows of the current screen? Or use a different task applet which better supports your use cases? Yes it’s possible to replace it! Instead of one-size fitts all, we actually provide multiple tasks applets to support different style of computing. E.g. my tasks applet is on the right of the screen using Icon Only tasks.
Hey man,
Some people REALLY dislike KDE4. They want KDE 3.5.x but they also want bugfixes. Hence, Trinity. I don’t think that Trinity should be dismissed just because you closed the bugs in 4, and I don’t think that it’s wasted effort.
You really think it is a good approach to just fork everything? Sure I understand that one wants to keep kicker around, but why then fork KWin?
The idea of bringing back Kicker and Kdesktop in KDE4 often was brought up by the user community. I even had a short discussion myself with Aaron Seigo on OSNews about it
As I understand it, the KDE team has refused the requests from the user community to bring back kicker and kdesktop. That leaves only two possibilities: Fork KDE4 and bring back kicker & kdesktop, or continue work on KDE3. The latter has now happened.
and you completele missed the third possibility: bring back kicker/kdesktop inside the community. No need to fork either KDE 4 or KDE 3
I don’t think Martin has something against having around a 3.5 thingy, it has something against the way it is done.
Did you see those commits? Aren’t they higly community unfriendly for you?
Also the more forks you have, the less the end-user will make any sense of what’s going on.
I.E. in a game community i follow, there are two competing plugins which are introducing the same functionality. Both have created their own concurring API (ignoring a third one meant for them by the game developers). What have they achieved? Great confusion and a lot of end-user frustration.
You may have great goals, but if you undergo the wrong path, you’ll only get great failures. Sadly this kind failures will never affect only yourself….
How is Trinity harming KDE? A look at the homepage shows no claimed association with KDE. Anyone who uses it knows he is getting a fork of old KDE code. No one is going to use it and say “wow, this years-old KDE code is crap, so current KDE 4.x must be crap.”
That is the point which I question especially given that you find on the web page of the Trinity Desktop the note of “continuation of the K Desktop Environment (KDE) version 3”.
And even if not KDE 3.5 had a very good reputation and given that it is not clear that the code in question is not maintained by the KDE developer community and users cannot even see that the application is now not provided by KDE. They use the same name: KWin, Kate, Konqueror, etc. etc. Seeing a loss in quality harms the reputation KDE 3.5 had – that is how I see it.
You are probably right about the quality loss. Problem is, KDE 3.5 as published by KDE team is frozen in stone. The system below it continues to evolve, Dbus has been introduced, libraries KDE3 depends are being removed, Dbus and so on. The world to which KDE communicates evolves too… Khtml3 becomes slowly but surely unusable to browse the web.
Given the fact that people still see merits in using KDE3, some development is necessary. KDE3 users will have to accept that at least initially the quality of TDE is worse than they were used to and will have to hope it will improve again when the TDE team grows more experience.
so why fork khtml3 if it is no longer up to the web? Why not just use the improved Konqueror from KDE 4 which can use either KHTML4 or WebKit? KDE 3.5 is dead because the world evolved, I would consider it as uncompletely irresponsible to do another 3.5 release based on Qt 3.5 given that it is end-of-life and does not receive security updates.
I don’t see what the problem is.
Why do you tell people not to support this project?
How would you like it if a publication told its readers not to use your software because of accusations of spyware?
I think you have to grow up and move on. This childish writing gets everyone nowhere fast.
If a publication would accuse that my software is spyware and that is not the case than I would take appropriate actions to correct the false claim.
It’s also a very bad comparison as I did not fork any software. I think you should be aware that the software I wrote about here is a fork using the same name as the software I am maintaining. Of course it is my duty to inform the users that the forked software does not have the quality they expect and are used from our software.
The whole point of Trinity is to turn back on life-support, so it becomes resposible to do another 3.5 release.
There is no doubt that a lot of fantastic work has been done in KDE4 and the work on Khtml is certainly work that you want to take advantage of. I consider it a bad side effect that Khtml3 has been forked and as a user you definately want Khtml4. This is a clear disadvantage of the Trinity approach.
An effort to start from KDE4 would also have disadvantages: There is a clear difference in vision: There is the “beyond the desktop” vision of KDE, with Plasmoid, semantic desktops, touchscreen interfaces and there is the “classic lightweight desktop” approach Trinity is taking,
Turning KDE4 into a classic and lightweight desktop that can function as a drop-in replacement for KDE3 enthousiasts would require engineering out a lot of functionality. If it was as easy as adding a few features, some speed optimizations and making a few things more configurable, we would not have had this discussion.
Huh? But this is all possible. You know that KDE currently provides three desktop shells, which can be used as a drop-in replacement and I’m aware of two further shells not being directly part of KDE (but developed by KDE developers) to be a drop-in replacement to Plasma. And then there is razor-qt which quite impressively integrates with KDE technology.
So I hope that it’s just you who is misinformed and not the complete Trinity project being based on such misinformations.
Btw. KDE 3.5 is not leightweight, but old. Old is not the same as leightweight. The difference comes into play when you use leight weight hardware like the raspberry pi I have here on my desk. It shipps with LXDE pre-installed and not with Trinity, surprised? Me, not. But of course it’s no problem to run something like KDE Plasma on it.
tde_on_raspberry_pi.png
http://trinity-devel.pearsoncomputing.net/?0::10122:get:1
Yes, you can compile anything to work on the Pi, but is ARM a regular compile target? Does it make use of hardware acceleration? Is it using Qt 4 which is also running on ARM based smartphones? Is it using multiple threads?
Why do people want to use old releases of software? Sticking with 3.X was a valid choice with early 4.X releases, but today this is just old software that is surrounded by much more evolved ecosystem. We learned new tricks and we know how to make some things better and the inability to use some of those new ways or technologies was one of the reasons we needed KDE 4.X. It simply couldn’t be done without breaking compatibility.
I understand the user frustration when something they now is being replaced by something new, but 4.x isn’t that far away in terms of user experience than 3.X was, it’s basically the same shell just built with new toys, it doesn’t change any paradigm.
Regarding “lightweight nature” of 3.X – start firefox or chrome, open dozen of tabs, and all memory savings will be gone, I don’t think there are many differences in terms of cpu use once You disable compositor in KWin.
Shouldn’t make a difference for CPU and depending on how you use the system (e.g. much moving of windows) CPU is even better due to the double/tripple buffering
“KDE 3.5 is not leightweight, but old.”
This is good point. It’s like arguing that Windows 98 is more lightweight than Windows 7, it would be comparing apples to oranges, it doesn’t make any sense. First of all if modern operating system requires more resources is not because devs got lazy or they stopped caring about performance, it’s because hardware evolved, they have more resources at hand and they can do stuff that they couldn’t with old hardware. It doesn’t means it’s slower or less lightweight, it means that they are solving different set of problems and result of they work is evaluated using different scale.