why kdelibs?

[Robert Knight]

Hello,

> The other issue is platform portability, stick with Qt and you know it works
> on every platform with no extra effort, even if the tools fall short in some
> areas.

The 'no extra effort' part is only true if you are aiming for a 'it
technically works'
level of compatibility with the platform.  In a more demanding
scenario where you
have professional designers on board who care about details such as
spacing, fonts,
use of distinctive control features/styling from the platform etc.
then expect to spend
a fair amount of additional effort.

Regards,
Rob.


On 29 October 2010 17:17, John Layt <johnlayt at googlemail.com> wrote:
> On Friday 29 October 2010 06:08:35 Stephen Kelly wrote:
>> I didn't get a "Qt is all you need" vibe at DevDays, but the Qt developers
>> there are completely unaware that the kde libraries are available and
>> usable. Most still think that KDE is a monolithic desktop environment, and
>> set of applications. Nothing independently useful or usable.
>>
>> So awareness is one issue, and one which I'm trying to address. Another is
>> interdependence in kde libraries, and what I think of as upside-down-ness
>> in parts of the stack and modules. kdelibs is mixture of two things: a set
>> of libraries, and a platform. KJob is in the libraries conceptually, as is
>> KIMAP, whereas KStandardAction, which someone mentioned, KStandardDirs,
>> KSyCoCa, KGlobal etc are platformy because 1) They provide benefit to well
>> integrated KDE applications, and 2) They provide no benefit to Qt
>> developers who are not creating 'KDE integrated' applications. Qt
>> developers often have control over distribution of their own dependencies
>> and can be more specific in code about data directories etc than KDE
>> applications.
>>
>> Because of interdependence though, a developer who wants to use KIMAP must
>> also use KStandardDirs, KComponentData, KGlobal and everything else they
>> come with. It should be possible to use a an IMAP library without depending
>> on the entire 'integration platform', so I think of kdelibs as upside-down.
>>
>> Even if communication about the separate KDE Development Platform had
>> reached the Qt developers at DevDays, I don't know if they would care,
>> because they would want libraries, not a 'platform' with all the buy-in
>> baggage that entails.
>>
>> The result for the Joe the plumbers^W^W^W Gregory Schlomoffs of this world
>> is privately managed ifdefs and hacked target_link_libraries lines.
>>
>> http://dot.kde.org/2010/10/15/gregory-schlomoff-betterinbox-kde-development
>> - platform
>>
>> Thinking of the kde libraries in terms of how people like Gregory and other
>> software vendors which create and deploy (and self-manage the deployment,
>> paths, dependencies etc) could see and use them could be a good way to make
>> kdelibs more modular and independently and make the 'platform integration
>> pieces' appear much higher in the stack.
>>
>> Anyway, making a list of (mostly-)independent libraries which are
>> potentially interesting to a Qt developer is easy:
>>
>> KLocale: More powerful i18n than QObject::tr and friends. Based on gettext.
>> KConfig: More powerful settings management than QSettings.
>> KJob:    Asynchronous APIs for executing tasks. Includes progress
>> reporting. Kross:   Cross-language script interpretation
>> Threadweaver: Threading APIs to suit practical needs of applications.
>> KDEUI/ItemViews: Add-ons to the Qt itemviews API.
>> KMime :  Qt based library for handling emails
>> KIMAP :  Qt based library for asynchronous IMAP communication
>>
>> I've only included things which I have some familiarity with. The list
>> could be made longer of course.
>>
>> All of those could be useful to 'Qt applications', and they only depend on
>> Qt for the most part, or other libraries in the list (KIMAP depends on
>> KMIME and KJob, but Qt has no equivalents for those). Conceptually there's
>> no reason for them to depend on 'the platform'.
>>
>> The fact that they can't be used independently out of the box makes
>> communicating about them difficult. "If you're using Qt ItemViews for
>> serious business, you want to use the stuff in kdeui/itemviews, but it
>> depends on klocale, kconfig, kfile etc etc at shipping time, none of which
>> are used." Actually kconfig is used in one place, but that's removable.
>>
>> Hopefully there's some coherence in all that. I had intended this email to
>> be much shorter.
>>
>> All the best,
>>
>> Steve.
>
> Some excellent points, and it makes clear the sort of areas we need to be
> working on.  Currently choosing to use kdelibs or any other KDE library just
> as an extra Qt module usually means more pain, not less, which really should
> be our selling point.
>
> Do we have a wiki page were 'what can be fixed now' and 'what needs fixing in
> KDE5' has been/can be written down?  Perhaps a version of
> http://techbase.kde.org/Projects/Mobile/PlatformModifications but with a
> little more detail?
>
> While a lot of the dependency fixing would break BC and so can't be done in
> the KDE4 SC, I suspect a lot of 3rd parties would actually ship their own copy
> of of what they use anyway, rather than using shared libraries?  In which case
> we can do compile time switches for them to just get what they need without
> all the other stuff?  Of course there would be a lot of work providing the
> alternative paths, but it would be in preparation for KDE5 and thus less work
> to do then?
>
> For example, KLocale needs KConfig on KDE platform to load the format
> settings, but a Qt program would not want those settings so a QLocale backend
> could be used instead and thus remove the need for KConfig.  In fact, KLocale
> is a problem as if you don't have kdebase/runtime/l10n installed you get the C
> locale, and even if you do have the files there's no guarantee they will be
> the same as what QLocale will return for the rest of your app, or what your
> Win/Mac/MeeGo/Gnome system settings are. I'm working on that.
>
> For those libraries like KIMAP and the itemview stuff that don't really need
> kdecore/kdelibs stuff at all perhaps kdesupport is the right place for them?
> Perhaps the 'K' name is also an issue, if they don't need K stuff, then just
> call them QSomething or a funky non-K name?  From a promo point of view, we
> could then advertise libraries as being 'By KDE', 'Using the KDE Platform',
> and 'For the KDE Desktop'.
>
> The other issue is platform portability, stick with Qt and you know it works
> on every platform with no extra effort, even if the tools fall short in some
> areas.  Use kdelibs and you will have problems on Win and Mac trying to decide
> how to package and distribute.  Work is ongoing on Win to make it happen, but
> Mac appears to have stalled somewhat?
>
> Of course, once the splitting work is done, and it's easily portable, then
> eternal vigilance is needed to make sure it stays that way, which probably
> means more stringent rules around kdelibs.
>
> John.
>