Qt KDE relations

Us and Them

Respect should go both ways? Tone of messages should be friendly.

Offering KDE as playground - less strict, gets feedback, gets real app exposure

 -> more that a Qt labs project

Qt and KDE

Qt is cross platform, KDE is not there

KDE plan for QCS

Make KDE attractive Present KDE vision to Qt people

Sessions: KDE and Qt communities and working together, what can we learn from each other Code of conduct

Technical: The things that should be merged: KUrl and friends KLocale QLocale Printing Config systems Archive handling

3rd party libraries independent Qt libraries Libraries for Qt developers that are not part of Qt

- system how to get libraries ?!? ruby gems, cpan

The contributor agreement?

How do we handle improved KDE stuff that goes into Qt but has a different api?

Open Governance

App developers:

KDE is still a great public showcase and large resource of Qt example code. KDE is an early adopter, commercial customers are way behind. KDE is a good pool for people. KDE wants to contribute to Qt. KDE cares about Qt. High quality feedback and contributions.

Example for successful library: QJson

- modularization is great

Rekonq is interesting because it is a real world demo using qt webkit.

Git is a bonus

Can we convince people to do modularization and clean up for KDE? Can kdelibs benefit from Qt test infrastructure.

KDE attitude: complain about blog post

Buildsystem???

Can we put cmake projects into qt creator.

Get a foot into the door: go for qt creator What about QML designer