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.
