On Sat, Dec 10, 2011 at 6:35 PM, Martin Gr��lin <mgraesslin@...> wrote:
> Hi Trinity developers,

> Therefore I suggest to you to discontinue the work on twin and instead switch
> to KWin 4 as provided, developed and maintained by the KDE community. We are

 martin,

 i was happy to accept - with reservations - what you were saying
right up until the point where you effectively ordered everyone to
quit.

 the gist of your message is as follows:

 a) you (twin developers) are making mistakes
 b) you cannot be trusted not to make mistakes
 c) it's a big responsibility and i believe that you're not up to the job
 d) therefore you should quit.

 i was prepared to accept that you are perfectly within your rights to
say that mistakes are being made, and it is very useful for you to do
so.  however you have absolutely NO right to suggest, recommend, tell
or otherwise imply that the twin developers should do something other
than what they are doing.

 now it's my turn to give you a reality-check.

 i've been following KDE for a long time, and loved it - it was my
default desktop that i put in front of average users, and i even wrote
an automated debian installer system http://lkcl.net/d-i which did
extensive customisation and package installation.  i've done quite a
few bugfixes, including in kdm for use with SE/Linux, and i've done
superkaramba development.

 then i heard about plasma, and was initially very enthusiastic (i'm
also a python developer)  but the more i learned about it, the more
alarmed i became.

 then i heard about the EU Framework funding, and was initially very
enthusiastic, but the more i learned about the direction being taken,
the more alarmed and concerned i became.

 then i heard that the KDE team wanted to adopt the entirety of QT4
into libkde and maintain it as part of libkde and i began to realise
that there was something deeply, deeply wrong with KDE's development
direction.

 KDE 4 came about at a time when windows vista had just been released.
 somewhere, someone decided that it would be a good idea to copy the
UI of windows vista.  if i had been consulted, i would have told
whoever who was prepared to listen that this would be a seriously bad
move.

 unfortunately, you didn't ask, and so didn't hear, and the
train-wreck just had to proceed.  basically, windows vista quickly
became the most hated version of the windows UI ever to hit the
planet... and KDE 4 copied it.

the problem is compounded by the fact that i'm hearing reports that
the key developer behind plasma is basically behaving like a fucking
idiot.  just looking at the plasma API and its verbosity makes me
throw up my arms and walk away, so i'm not even going to _remotely_
get involved with plasma or any plasma application development, even
though it would represent an opportunity to write a from-scratch
complete replacement for the existing KDE4 dog's dinner desktop
paradigm with something that i would find palatable.

 btw it's also worthwhile reiterating that i did an install of
debian-squeeze recently for a friend.  it installed KDE 4 without my
knowledge, and, because their network connection was so slow (15k/sec
- they live in a very remote area) i couldn't get them a replacement
desktop in time.  KDE4 was so bad that, *without* telling me they took
the machine to an incompetent who DESTROYED all the work that i'd done
and replaced it with vista.

 my friend is now no longer speaking to me because they believe that
it was "my fault" that the virus destroyed their windows partition in
the first place, and that i must have taken advantage of them somehow,
to try to peddle such a deeply-shit replacement desktop at them.

 example: we tried for 15 minutes to set the wallpaper.  there wasn't
even a menu option anywhere to do it.  everything that should have
been intuitive and obvious wasn't.  there wasn't a control panel
option to manage the desktop.  there wasn't a right-mouse context
option on the desktop itself to set the wallpaper.

 example: we tried to mount an NTFS partition (their old windows data
drive).  was there any obvious way to do it?  was there fuck.  did the
drives appear automatically on the desktop?  did they fuck.

 the whole exercise was a complete utter failure.  i couldn't even
tell them how to run applications.  i had to press ctrl-alt-f1 and go
and manually locate firefox.desktop in /usr/share/applications, and
copy it into their home directory.

 _everything_ about KDE4 was a complete utter failure - it was the
worst desktop "manager" i've ever encountered in my life, and i had to
find this out right in front of a friend who was trusting _me_ with
their precious documents that had not been backed up.

 i trusted _you_ - the KDE developers who had been funded to the tune
of $EUR 10 million - to do a decent job, and you completely and
utterly failed to do that.

 now in that context, you might now appreciate why i may be taking a
dim view of KDE developers telling the Trinity Desktop developers that
they should "quit".

 here's what i believe that _you_ should be doing, in a series of alternatives:

 * you should consider dropping - entirely - the KDE4 codebase and
return to KDE 3.5.  i am deadly serious.
 * you should make room for the Trinity Desktop developers to
accommodate the KDE 3.5 applications within the KDE4 infrastructure.
 * you should make room for the KDE codebase to be compiled
successfully with QT3 (so that the Trinity Developers don't have to do
it).
 * you should abandon the KDE codebase entirely and join the Trinity
Desktop team.
 * you should help the Trinity Desktop team by keeping an eye on them
and doing specific code-reviews and making useful bugreport comments
so that they don't make mistakes (that took you 2 years to learn
about).
 * you should add comprehensive (automated) unit tests to KDE so that
the Trinity Desktop team can pick those up and ensure that the code
that they develop has self-checking.

just one last thing: you have to bear in mind that i am an embedded
systems developer, as well as many other things.  i've compiled
pywebkitqt4 for a (very good) 400mhz ARM9 that had access to 800mhz
DDR2 RAM.  pywebkitqt4 ran so slowly that it put the entire project
into jeapordy.  qt4 itself consumed vast amounts of resources (over
128mb of RAM), and took over 90 seconds to start up.

 an analysis of the various options (pywebkitgtk and webkit for
enlightenment) wasn't much better, but it wasn't 256mb of RAM.  i then
had to help the directfb developers port webkit to directfb, and the
startup time was reduced to under 6 seconds, and the RAM used reduced
to about 128mb (GTK was about 130mb).

 the bottom line is that if you believe that qt4 or qt5 is going to be
suitable for low-memory usage you are due for yet another train wreck.
 qt3 - precisely because it has *not* had massive amounts of
development or interference - is still suitable for use on systems
even with as little as 64mb of RAM... with *no* swap space.  perhaps
running such large systems as KDE3 in only 64mb of RAM is too much to
hope for, but because qt3 was designed for such tiny resource usage
and does *not* have massive feature-bloat, it won't be far off.

 i'm sorry i had to break the request of the trinity developers not to
appear to be "adversarial", but, martin, the KDE team _really_ need a
serious, serious reality check.  you should, instead of asking the
trinity developers to quit, be encouraging them to explore their
chosen path (which you have absolutely no control over) with
enthusiasm, and offering to help guide them to success.

l.