trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: August 2012

Re: Re: Re: Re: [trinity-devel] kbugbuster

From: Martin Gräßlin <mgraesslin@...>
Date: Fri, 24 Aug 2012 10:17:13 +0200
On Thursday 23 August 2012 15:47:35 Timothy Pearson wrote:
> An extra dependency is
> still an extra dependency, and it still consumes disk space (and RAM when
> the application is running).
I think I asked in my previous mail why that is a problem. Let me check:
"And even if what is so bad about an extra dependency? Can someone explain 
that please? And if you try to do so, please also think about the current cost 
of disk space (according to Wikipedia 3.5¢/GB in 2011) and RAM doesn't matter 
as an app only pulls in what it really links anyway."

So could you please elaborate on that. I really want to understand it.
> 
> > right, like not seeing any difference between GTK2, GTK3 and KDE
> > applications
> > [1]. What a surprise: KDE is the only environment having matching GTK2 and
> > GTK3 styles.
> 
> If you like the (IMHO ugly) Oxygen style, yes.  This is sort of like the
> old Model T argument: you can buy it in any color you want, so long as
> that color is black.
*sigh* it was you telling that it looks different if used two toolkits and 
that this is a reason to have a fork. Now I showed you that you can have a 
style which looks exactly the same on three different toolkits. Basically I 
prooved your argument being wrong.

What's your reply: it's ugly. Seriously? What's that for an argument? First of 
all it's completely irrelevant in the discussion and second of all it's highly 
subjective. Who cares what you think a style looks like?
> 
> > Oh and then there is the Plastique widget style shipped by Qt which is
> > just
> > the same as the one used in KDE 3. And there's of course qtcurve [2]
> > offering
> > matching styles for KDE 3, 4 and GTK.
> 
> QtCurve doesn't work on GTK3 and there are no plans to add support at this
> time AFAIK.
and what has that to do with the discussion? You said that two toolkits (KDE 3 
and 4) are bad because they look different. I show you a toolkit supporting 
KDE 3, 4 and GTK and your answer is it does not support GTK3. Seriously? 
What's that for an argument?

Is KBugBuster nowadays written in GTK 3 that it matters? And even if I 
consider that this would be a valid argument, where is the Trinity GTK 3 
style? (I can play as badly as you and twisting arguments, that's fun isn't 
it?)
> 
> > I find it a really, really sad thing to bring look as a justification of a
> > fork. It just illustrates how ridiculous this whole thing is. Please think
> > about it.
> 
> This is NOT justification of a fork.  Rather, it is a group of software
> developers deciding to work on a platform that is more comfortable for
> them to use.  Think about this: with KDE4's vastly superior developer
> resources and larger userbase, why is the KDE4 version of kbugbuster not
> being worked on and fixed, whereas TDE is considering fixing its version
> of the same application?  Could it have something to do with the differing
> styles of computing favored by TDE versus KDE users?.
yeah the old "KDE doesn't care about its users argument". Easy to repeat and 
hardly to contradict because you have thousands of examples where KDE does not 
care about the users.

So you asked me to think about it. And the first thing I noticed is that you 
obviously did not think about it, because then you would have realized that 
the targeted usergroup of kbugbuster are not users but KDE developers. You can 
realize that by the fact that it lives in kdesdk for one thing, then that it 
is a tool to manage bugs, but not to report bugs and so on.

So the targeted user groups the KDE developers do not care about is 
themselves.

Now what could be reasons that the KDE developers do no longer care about 
KBugBuster? Most likely because nobody sees a motivating factor to work on it. 
Maybe it is because web-applications are more common today for usage than when 
KBugBuster was initially written (think about Facebook and co). Maybe the 
Internet connections are nowadays better, so that you don't need an offline 
application to work with a bugtracker (IIRC KBugBuster still uses the email 
interface to bugzilla instead of xml/json web client). Maybe it's because 
bugzilla's webinterface is nowadays really good and does not suck badly 
requiring a desktop application.

I really think and hope that KDE and Trinity could collaborate. To make it 
quite clear only Trinity would benefit from a closer collaboration. From a KDE 
standpoint I could as well relax and wait till the annoyance of the fork has 
died away.

But to get to a closer collaboration the Trinity developers have to start to 
improve their relationship with KDE. Don't assume everything KDE does is bad. 
Just look at your users argument above and how ridiculous it is in the given 
context. It doesn't need me to realize that this has been a ridiculous 
argument, you could have done as well while writing it.

As long as Trinity developers bring up ridiculous justifications for their 
fork there cannot be a collaboration. As long as Trinity bring in arguments 
which are clearly wrong and harmful to the KDE community by spreading FUD 
(nothing else the users argument is) the fork while be perceived as an enemy 
and that is nothing the Trinity developers can want. 

So I kindly ask you to take a step back from what you do and think about it. 
It's not pure chance that I chimed in the thread about KBugBuster to ask for 
the reason to work on the fork instead of working upstream.

Best Regards
Martin Gräßlin

Attachments: