"Cornelius's grand plan" - Merging KDElibs into Qt

[Sean Harmer]

Hi,

I hope you don't mind a non-core dev adding in a few thoughts...

On Monday 01 November 2010 07:45:00 Aaron J. Seigo wrote:
> On Sunday, October 31, 2010, Mark Kretschmann wrote:
> > What do you think about it?
<snip>
> but looking at the idea squarley, the first question i think of is: What
> does "merge with Qt" mean, exactly? 

I would perhaps like to take a step back even further than this and ask, "What 
problem is the proposed merge with Qt trying to solve?"

>From reading these two threads it is my understanding that the core problem is 
trying to get more pure Qt app developers to make use of the excellent KDE 
libraries and finding ways to make them more attractive for use.

Cornelius' plan of merging with Qt is one possible way to go about making the 
KDE libraries (and services) more accessible to Qt developers. However, as 
Aaron and others have pointed out this does come with a number of additional 
obligations and hurdles.

>From my own perspective as someone who uses Qt to write commercial software, I 
would absolutely love to be able to recommend for our company to use the 
facilities provided by KDE in our applications. Although some in our company 
do run Linux/X11/KDE, the vast majority are still Windows users. As other have 
mentioned, the biggest problem for us then becomes one of getting KDE and its 
dependencies deployed on the developer and target machines.

I applaud the efforts of the KDE on Windows team they are doing amazing work, 
but they are trying to catch up with many many years of work that has already 
gone into *nix package management systems. To get a functioning runtime or 
development environment on Linux is a simple case of 
rpm/aptitude/yast/emerge'ing a few packages. On Windows, you can either use 
the KDE on Windows installer which although good - still scares typical 
windows users. Or if deploying a single application make a huge package like 
amarok does. I cannot comment on the Mac support as I do not own or have 
access any Apple produced tin at present.

So one major point limiting the uptake of KDE for us is the ease of getting a 
working development platform and then of deployment to end users on non-X11 
platforms. Solving this problem and marketing the fact that it had been solved 
would go a long way to attracting more developers to the KDE development 
platform. I would love to use things like KIO in our applications if it was 
easier to deploy across multiple platforms.

A couple of simple ideas (simple to think of, not necessarily simple to 
implement) to ease deployment for developers/packagers could be to:

1). Provide some qmake feature files *.prf that can be installed by the KDE 
Windows installer. This will allow Qt developers using qmake to have easy 
access to KDE libs at build time by simply adding FEATURES += kdeui kdecore 
for example.

NB I know that this is easy to do with CMake, but many qt apps and libraries 
that I see still use qmake so this just reduces yet another barrier to entry 
for using the KDE libraries.

2). Provide some simple way for packagers to ensure that their installer will 
provide the needed KDE libs and dependencies. Perhaps a macro for NSIS (or 
similar) that can be executed by the built installer such that when executed 
it checks to see if the target machine has the minimum KDE version installed. 
If it does then great. If not, then it goes off and downloads a KDE runtime 
environmentthat is shared between all installed applications that make use of 
the KDE libs/services.

I really do like the ideas that have been presented by Stephen et al about 
refactoring the KDE libraries into tiers that provide varying levels of 
services/integration (if my understanding is correct - forgive me if I am 
wrong). This approach coupled with a well thought out deployment mechanism for 
Windows/Mac/MeeGo/whatever would be a significant step forwards. 

I won't rehash these ideas here as others have already presented them, but I 
agree that there are some places where the K* classes provide extra/better 
functionality than the Q* equivalents. Where possible it would be good if 
these examples could be merged into Qt. However, I do not really see the 
benefit outweighing the downsides of merging the rest of KDE into the official 
Qt tree. I do see the benefit of refactoring as if we *were* going to merge 
but then stopping short of performing a merge as this will focus our thinking 
into making the platform easier to use and deploy.

One other thing that I have found that could be prohibiting wider adoption of 
KDE as a development platform is the lack of coherent documentation. Please do 
not take this as a criticism, techbase/userbase/api docs are all excellent 
resources and are constantly improving. From experience of trying to get some 
colleagues to utilise the KDE libraries who had not been exposed to them 
before, a large hurdle was discoverability of the APIs. A lot of the 
information is there it's just a question of finding it. If information is 
difficult or time consuming to find this discourages developers from coming 
back again or from branching out and using other facilities in the future. I 
do not pretend to have the answers here. KDE is a huge project and for the 
most part developed by volunteers and godo documentation is very difficult and 
hugely expensive in terms of time/blood/sweat/tears to write. Kudos to all the 
documentation writers (and devs/artists/testers etc).

Anyway, just a few random thoughts for food. I am very excited to see where 
this discussion goes and am even more excited to think of the possibilities of 
using KDE in places that were too onerous in the past.

Kind regards,

Sean

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.