Office/ and Utilities/ menu reorganization
lofi at freebsd.org
Tue Aug 9 01:02:15 BST 2005
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
> > > 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
Size: 187 bytes
Desc: not available
More information about the kde-core-devel