KDE Windows/Meetings/Osnabrück Meeting Summer 2012

The KDE Windows community had a meeting in Osnabrück on the weekend of 3.- 5. August 2012 The meeting took place at the Intevation offices in Osnabrück.

The according Sprints page was: Sprint Page

Proposed Topics

• Qt5 --> Andy?
• KDE frameworks --> Patrick?
• Packaging / NSIS / MSI how to integrate in emerge even better.
• "Autoupdates" for Standalone software like Kontact / Amarok / Calligra
• Sandboxing
• Oxygen or a more Native look as the default?
• Sandboxing
• Tests / Unittests (Maybe more of a "to hack" on topic, but It would be cool if we could make better use of them)
• Keyword system to tagging unstable software:

Gentoos emerge uses "accept keywords" to categorize versions of software into either stable, testing or experimental.

I'd like to propose a similar (but simpler) system for emerge on Windows: Add a "keyword" parameter to installation targets. If empty / not existant (current situation) that means "safe" (stable). Potentially unstable packages could then be tagged as potentially dangerous by giving them a certain keyword (like "~").

An emerge configuration option would be needed that defines the keywords that the user accepts (per default, that'd be empty - accepting all current targets but not those marked as unstable).

Developers that want to run bleeding edge software could just add the "~" keyword to the list of accepted ones and instantly move up to all the latest releases (which also makes sense as they might depend on each other).

This simple approach would not have any regressions or require a large initial "tagging" effort but would allow developers in the future to mark potentially dangerous targets leading to a nicer experience for e.g. app developers that "just want a stable base to start from".

• cross compiling (OBS)
• system integration
• kdewin-installer

Things to hack on

• Update mingw-w64 to gcc 4.7 as 4.6 is required by Qt 5
• Patch Mysql to build with mingw
• Removing Version numbers from filenames in emerge
• Let's build the frameworks?
• kdewin-app-installer
• Website

Notes from the Sprint

Portage Version

To avoid renaming and improve the "mergability" we want to remove the portage Version from the package names. We want to archive this by adding a new subinfo field to a package: portage_revision. This number should default to 0 and should be increased when changes are made to a portage file that affect the build results, similar to that of a package-revision on Linux.

We then also want to modify the following information fields to the the InstallDB (or the text file)

+ Target (the target used for the build)
+ portage_revsion ( the earlier mentioned portage_revision )
+ isDefault

And remove the current Version field.

This should allow us to handle rebuilding more intelligent

Patrick Spendrin will be working on that.

Sandboxing

We've pretty much archived this over the last two years with ralfs dbus work after the last sprint and making sure that environment variables are respected correctly, now the question is to make it more convenient. To avoid conflicts beween seveal KDE Applications on the same system (e.g. Calligra / Kontact / Amarok) we need a mechanism to sandbox their environments without wrapper scripts and user interaction. To achieve this we want to have a global configuration file (kde.conf) that will contain the configuration that you usually set unter Linux with environment variables. Additionally to kdelibs (where we could patch this in readEnvPaths), this needs to be done in Akonadi and Soprano. Important is that we still keep it in a way that we don't have external settings in the registry or something.

Look & Feel

We won't have common ground here, so better improve the documentation so it is easy to change for everybody.

Implicit Dependencies

We want to have that, so we decide to make it default for 4.9 and master

Qt5 / Frameworks

Andreas Holzammer gave a talk about the the Qt-Project and the workflow for contributing to Qt. We still can't build Qt5 with emerge even with msvc, we started on the general framework for building this but with mingw-w64 it's a longer way to go. With mingw-w64 there was an error that bootstrapping configure failed.

Patrick Spendrin talked about packaging Frameworks putting the Tier* libraries into single packages. With everything else in some kind of kde4-leftovers package. We have a Frameworks branch in emerge but there is also a frameworks target in emerge master. At the moment we can only build it with Qt4 and this is recommended currently to start working on Frameworks from a Windows perspective. Talking about daemons and which will go away. Making d-bus go away would be a good thing for Windows and Android with a different IPC mechanism, there is a kdelibs branch by boud that makes dbus optional but just cuts down a lot of features. Basically consensus was that we would like something like a libdbus-fat that offers different ipc mechanisms depending on the platform with the same interface but that would be a lot of work.

Packaging

We would like to have some update notifications, tomahawk uses qtsparkle we have to check that out. Calligra already has some manual mechanism coded into. But this would just mean downloading a new package and reinstalling it over the old version. Amaraok and Kdepim packages are in Emerge, we would always be happy to get new maintainers for more packages especially with sandboxing. The calligra packaging is available at: https://git.gitorious.org/calligra-installer-for-windows/c2winstaller.git

Parallelism

Someone needs to step up and integrate parallel.py with emerge.py so that they offer the same options and interface. Andre will work on that.

Test / Unittest

We should make more use of them to detect when the linux guys break things for us but that would mean that we have a working base, as a state where all unittests are working so that we can actually get useful information when changes break them. Someone needs to do this,..

Get more new developers

We've found some very outdated wiki pages that give wrong information to new developers, those should be either updated or deleted. But the state is not that bad as we have a few up to date pages that can serve as an entry point. We need to clearly communicate that emerge is the Source distritbution and if you want to build KDE Software on Windows you should use emerge. The KDE-Windows installer is for users. The default settings for emerge were improved to actually reflect what most of the developers are using and should use. It also needs to be underlinded that even as a developer if you want to start developing on your software you should probably not use emerge master. Emerge Master is for building the master branches of everything and is very often broken. We also really need some tutorials:

* How to develop on Windows with Emerge
* How to create a new Portage File
* How to modify a portage file so that it does what you want ( modfiy configure options etc. )

Promote Emerge as a generic Windows build tool

Emerge works great as a generic build tool for windows, with the huge base of over 70 individual libraries buildable from source with MSVC and MinGW. This is not only useful for KDE software and we should advertise that more and also underline that we accept portage files for other not KDE related software.

System integration

There was talk about jumplists (the things that jump up if you right click over the task window in Windows 7) and thumb buttons. With a newer version of the mingw-w64 compiler we can even do this with mingw. There was a question of where to put this as a library, it might end up in Frameworks/Kdelibs so far its not really published by patrick. We are thinking about putting plasma widgets into ActiveX controls, to integrate them with the Windows desktop, Fabian showed a demo of the Elastic Nodes Qt demo inside of ActiveQt. The idea is not to implement all the Windows drag and drop and desktop integration from Windows to plasma, but instead to replace important parts of the Windows Explorer by plasma (The start menu or parts of the taskbar). Fabian also has written a start menu converter ( KBuildSycola ) that converts Windows start menu entries and registry entries to desktop files, so that they can be used together with KDE / Klauncher. The code for all this will (He promised ;) ) be placed in a scratch repo in the next week.

Cross Compiling

Dominik Schmidt demonstrated how to build windows packages with the Open Suse build service. (Including some live fixing of a Toolchan file)

The example of Tomahawk is documented at: http://wiki.tomahawk-player.org/mediawiki/index.php/Building_Windows_Binary_on_openSUSE_11.4

Link to the Windows project site in OBS: https://build.opensuse.org/project/subprojects?project=windows%3Amingw

Example Toolchain file: https://github.com/tomahawk-player/tomahawk/blob/master/admin/win/Toolchain-mingw32-openSUSE.cmake