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.