Office/ and Utilities/ menu reorganization

[Michael Nottebrock]

On Tuesday, 9. August 2005 01:02, Christoph Cullmann wrote:
> On Monday 08 August 2005 21:21, Michael Nottebrock wrote:
> > I.e. create a tarball every once in a while and make it available for
> > download somewhere (and KDE could simply provide ktown-access/space to
> > keg-application developers for that purpose). That's hardly stressful
> > compared to developing and maintaining an application in the first place.
>
> For small apps, that is most stressful, small apps will perhaps only need
> few lines changes per kdelibs/qt release to keep the user happy (e.g. to
> fix regressions with the new versions, to adopt to some little new stuff,
> to fix bugs), than you have to made a tarball, notifiy the translators if a
> string change was done, ....

I don't buy any of that. Qt and Kdelibs are binary compatible over long 
periods of time, making a tarball is a matter of five minutes maximum and as 
far as string changes go, isn't it a rather good thing that you can work out 
your own deadlines with your project's translators rather than having to 
worry about squeezing in your code-changes before the KDE string-freeze (or 
annoying translators by forgetting and doing it *just* after the string 
freeze)?

> > > Users who build from sources would have to keep track of
> > > more packages,
> >
> > How so? Kdelibs would be a constant requirement, third party libraries or
> > similar stuff users need to keep track of no matter which configure
> > script looks for them. I can see how finding applications to download and
> > compile in the first place require a little extra effort from users, but
> > again this could be very much mitigated by allowing extragear developers
> > to host their distribution tarballs on KDE.org's mirrors and/or adding
> > them to konstruct (if konstruct doesn't already include extragear, I
> > don't use it so I don't know).
> >
> > > new dependencies
> >
> > See above.
>
> Kile need kdvi, kghostview, kpdf to be actually usable for example, atm,
> that means, compiling kdegraphics, if we would split, that would mean
> compile these three apps, just as an example ;)

... and it would mean that users only get kile, kdvi, kghostview and kpdf in 
the end - but not a bunch of very much TeX-unrelated, gratuitous stuff like 
kpovmodeller, kfax, kruler, kview, the X11 gamma correction kcm module ...  

And they would spend less time compiling overall.

> Why they eat away resources? No developer is forced to spend it's time
> there. And no translator is really forced to translate it, or I am wrong?
> It is the aim to provide as complete translations as possible, but some
> untranslated docu in kdeedu would be no showstopper there , or?

The same reasoning could be applied to the hypothetical small, independently 
released applications you're talking about above.

-- 
   ,_,   | Michael Nottebrock               | lofi at freebsd.org
 (/^ ^\) | FreeBSD - The Power to Serve     | http://www.freebsd.org
   \u/   | K Desktop Environment on FreeBSD | http://freebsd.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050809/999b5bdb/attachment.sig>