"Cornelius's grand plan" - Merging KDElibs into Qt
sh at theharmers.co.uk
Mon Nov 1 10:53:01 GMT 2010
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?
> 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
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.
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
More information about the kde-core-devel