Kevin Krammer posted on Sat, 31 Mar 2012 13:11:21 +0200 as excerpted:
> On Saturday, 2012-03-31, Duncan wrote:
>> >> Kevin Krammer posted on Sat, 31 Mar 2012:
>> >> > http://www.betterinbox.com/
> Btw, I believe that ksmtp is fully their work, so their contributions
> are more than just "a couple of changes here and there"!
=:^)
> One thing I forgot to write previously is that since they seem to use
> IMAP and SMTP, the client will likely also work with other mail service
> providers. Being a company they probably want their official
> documentation to only list ones they have tested with but not meaning
> that it doesn't work with others.
Makes sense. But if it doesn't have POP3, it won't work for me,
currently. But that doesn't take away from their contributions or that
it might work for others, or for me later.
>> I do like the idea as extended into (what I've read of) kde frameworks.
>> Between the greater kde modularization and the migration of some
>> current kdelibs functionality into qt5 (which is from what I read
>> itself tilting toward more modularization)
>
> Qt4 is already quite modular, i.e. its libraries usually don't depend on
> each other (each one depending usually just in QtCore) and application
> developers can easily decide which ones to explicitly use.
>
> My understanding is that on top of that Qt5 modularization is mainly
> changing how Qt is built, e.g. specialized libraries having their own
> repositories and not needing to be switched on or off when building Qt.
Of course being a gentoo user, that's the perspective I tend to see, and
gentoo is script-automated from-source package builds, so from here, "how
Qt is built" really IS end-user detail. =:^)
FWIW, gentoo already has qt-4 broken up into its split modules, and has
qt-based app dependencies set accordingly, but just as with kde's
formerly huge monolithic tarballs that are now being gradually split out,
having them actually shipped split-out from upstream, and having the
split modules dependencies specified explicitly as a result, is going to
reduce the work load (and bug-load when it turns out wrong) for distros
like gentoo that already split them up, TREMENDOUSLY.
As big as the kde project is and as many packages as it has, kde and its
underlying qt have been MAJOR operations at the distro level, and while
the split won't much affect the number of individual packages for distros
that were already splitting them, lifting that dependency-tracking
workload from the distros back to upstream (with I'm sure an occasional
distro fixup, as happens with every package) should be quite the
standardization and stability boon, lessening the distro work load and
end-user seen dependency bugs dramatically for those who already have it
split, while equally dramatically increasing flexibility for those are
still getting the monolithic packages.
So as you can see I'm very optimistic about the results of this at all
levels, qt and kde upstreams, distros, and end-users. =:^)
> I am not sure it will make a difference for users since dependencies are
> handled automatically already anyway, but my guess is that the added
> flexibility will incur some extra cost for developers and especially
> packagers.
The difference for users will be in flexibility if they're currently
using monolithic, and in number of bugs if their distros/packagers are
already splitting it up (as is gentoo), since much of the work will be
transferred to upstream, where it'll be common to all packagers instead
of each one having to develop their own solutions.
>> If the module releases are desynchronized as well, as I've read is
>> being discussed, letting the modules evolve at their own rate, it could
>> be a good thing.
>
> True, but I don't think this will be employed anytime soon, at least not
> for the traditional modules. Faster moving products like Plasma on the
> other hand might switch to separately released libraries sooner.
Makes sense.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
