On Saturday, 2012-03-31, Duncan wrote: > Kevin Krammer posted on Sat, 31 Mar 2012 11:45:12 +0200 as excerpted: > > On Saturday, 2012-03-31, Duncan wrote: > >> Kevin Krammer posted on Sat, 31 Mar 2012 10:53:55 +0200 as excerpted: > >> > http://www.betterinbox.com/ > > > > Yeah, they are a pretty new startup and obviously need to prioritze. > > I was only aware of them because they are users of *and* contributors to > > email related KDE libraries. > > I saw mention of that on the webpage. That /is/ nice! =:^) Indeed :) 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. > > Something we will hopefully see more often when the frameworks effort > > makes individual components more visible as stand-alone entities (which > > they often already are, just not visible as such). > > FWIW, I don't believe I've mentioned it yet, but while I wasn't > particularly impressed with the kde sc rename Yes, a concession towards the media, they like to have one name that addresses the whole portfolio :-/ The SC name is not needed if one refers to the products individually but the impression was that news outlets would not do that for KDE while regularily doing it for other vendors. > 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. Not sure how much of a change in this direction we'll see from KDE Frameworks 5, but I am not following it that closely so that might be applicable as well. > , it sounds to me like a universally required kdelibs will > be much smaller, and that it's going to be a better deal for users, > distro-maintainers and kde devs all three, with more dependency > flexibility and a more explicitly specified dependency chain, which > should lead to fewer end-user visible bugs and less work trying to get > the splits right at the distro level. =:^) 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. Right now application developers already specify which "frameworks" their application is using, e.g. whether it needs KWallet. However it is not necessary to make the build system search for them individually, their presence is satisfied by just looking for "kdelibs". This then extends into the packaging realm, i.e. a kdelibs package satisfying the need for any application using whatever component. Increased granularity will very likely make that a bit more complex, though I don't know whether it will be used at all levels (i.e. whether packagers will create individual package for components or just create a kdelibs package as usual). > 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. > >> FWIW, there's also the still fairly new "trojita". Qt4-based, but > >> IMAP-only, unfortunately, which isn't going to help for users with > >> POP3 (and webmail, but ugh!) providers only. As I'm in that > >> category... But I'd be tempted if my providers did IMAP. > > > > You could use it with a local IMAP server and use system level agents > > for mail gathering, e.g. fetchmail. > > I actually did think about it. But decided that was biting off more than > I could chew at that point, especially as I wanted off kmail for 4.7.0, > which was fast approaching when I was doing my research. Still, learning > all about running my own mail servers, MTAs (mail transfer agents), etc, > has for years been on my list of things I'd eventually like to try. As > I've learned stuff like how to run and configure my own md/raid, ntpd, > dns, etc, and crossed it off that list, mail gets closer and closer to > the top... I can relate to that, I also never seem to find the time to look into these topics myself either ;) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
Attachment:
signature.asc
Description: This is a digitally signed message part.
___________________________________________________ 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.
