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: