App duplication again (Re: new project in kdemultimedia)

Christoph Cullmann crossfire at babylon2k.de
Sat May 4 20:59:11 BST 2002


On Saturday 04 May 2002 21:06, Andreas Pour wrote:
> Neil Stevens wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Saturday May 04, 2002 07:17, Hetz Ben Hamo wrote:
> > > > > OK, meanwhile I was told that this new CD burner (k3b) in
> > > > > kdemultimedia adds another 700+ strings which means that we now
> > > > > have something like 2000 strings for CD burning apps alone for each
> > > > > and every of our 50+ translation teams. Even if we can re-use a lot
> > > > > of these strings I think the situation is getting absurd. And I'm
> > > > > not only talking CD burners here.
> > > >
> > > > If translators don't wish to translate the new app, nobody's forcing
> > > > them to do so.
> > > >
> > > > Why should translators get a double super veto over what goes into
> > > > KDE?
> > >
> > > And why not finally have a vote page for the following applications:
> >
> > Because KDE isn't a democracy.
>
> To some extent it is, and has to be.  You need to go back to the basic
> purpose of putting something into KDE's CVS.  And when you do that, bear
> in mind that "sophisticated" people can get their apps from the
> Internet, compile themselves, decide which they like most, etc.  The
> "core" distribution should instead be targeted at the unsophisticated
> user, the one that will be confused by multiple applications, that wants
> to be able to use the machine at the office or at a friend's and have
> the same tools as the machine at home.
>
> To get a good grasp on it, compare the user API to a developer's API.
> Learning to use an application, for a user, is much like learning to use
> a class, for a developer.  Do we have 4 classes in KDE to open a file,
> combined with a situation that as a developer you do not know in advance
> which class is installed on a a target machine?  No, that is an
> impossible situation.  It leads to fragmentation, and if MS has proven
> anything with its market domination, it is that having a single
> "standard" desktop is *highly* desirable for people.
>
> The job of the "release coordination" is to find the best apps for the
> job and put them in as default.  The others should be optional and
> should not be part of a "core" package.  This is not an easy job, for
> sure, but I think we are capable of doing a good job at it.
>
> > Developers are under no obligation to. That is, KDE has no leverage to
> > force the developers if the result doesn't go the way they want.  KDE can
> > only enforce a negative - removing apps and reverting commits.  It can't
> > force developers to "team up," or force a developer to move into CVS and
> > comply with KDE CVS rules.  It can't force developers to add features and
> > redesign UIs.
>
> No, but it can encourage it, by rewarding developers who do that.
> Having an app in KDE CVS is a privilege which carries responsibilities;
> if you do not like these responsibilities, develop your app outside KDE
> CVS.  One of the responsibilities is to reuse code and avoid duplication
> of effort.
>
> KDE is growing up, it's time to realize that and act accordingly.
>
> > This is a good thing.  User feedback is important, but to have users make
> > decisions is to ask them to take over some of the developer
> > responsibility.
>
> The point of packaging is to create something useful for users (if
> nobody used the app, there wouldn't be much point of putting it in KDE's
> CVS).  Hence their opinions do matter.
>
> > The average user is not necessarily inclined nor
> > qualified to make release decisions in a way that is in line with KDE's
> > goals and previous success.
>
> The "average" user does not read the dot or vote on applications.
> People who read the dot are typically people who are involved in KDE and
> care about it, so I think their views deserve consideration.
>
> > Further, to put these up for a vote assumes that the options in each vote
> > are interchangable.  They are not.  Hetz, you and I clashed at least
> > twice on whether CD Bake Oven or KreateCD would be better for KDE.  We
> > both argued that one was better for a particular group of users.  So,
> > just as we have KWrite and Kate for different kinds of users, why not
> > have CD Bake Oven and KreateCD for different kinds of users?
>
> KWrite is a subset of Kate.  I don't have an issue with having a "quick"
> frontend to *the* KDE CD-burning app which has limited options (using
> mainly defaults) - it's still essentially the same app and same
> codebase.
And for Neil: KWrite has around 20 kb of source code and only a few i18n 
strings, which seems to be nothing in compare to any of these cd writer apps. 
(just to point out why your comparison is completly wrong here)


>
> In the long run it is better to have one default application, and let
> people download everything else separately.  Part of the responsibility
> of having a distribution (even if in the case of KDE it is source code
> only) is to make some of the difficult decisions for the user.  Letting
> other users be involved in this process is smart.
>
> > Lastly, any online vote would just hand the results to whoever has access
> > to the most IP addresses to vote from.
>
> No decision-making is perfect, yet we still have to make decisions.
> Generally the goal is to obtain the best information available, even if
> it is not perfect.
>
> As it stands now, how should the decision be made, depending on who
> sends the most emails on the topic to this list?  What makes *you*
> better qualified to judge the CD-burning apps than the "average" user?
>
> Ciao,
>
> Dre

-- 
Christoph "Crossfire" Cullmann
Kate/KDE developer
cullmann at kde.org
http://kate.kde.org




More information about the kde-core-devel mailing list