https://community.kde.org/api.php?action=feedcontributions&user=OpenIDUser14&feedformat=atomKDE Community Wiki - User contributions [en]2024-03-29T06:07:21ZUser contributionsMediaWiki 1.40.2https://community.kde.org/index.php?title=Akademy/2012/QtQuick&diff=21653Akademy/2012/QtQuick2012-06-13T01:13:20Z<p>OpenIDUser14: </p>
<hr />
<div>'''Qt Quick 2 Training'''<br />
<br />
This free training will covering the basic concepts of Qt Quick 2. KDAB will be conducting this training, which is sponsored by Nokia in addition to their Platinum sponsorship. Nokia and KDAB are committed to Qt and KDE, and are offering this training to support that commitment. The training includes:<br />
* Concepts and composing user interfaces<br />
* Interactive discussion<br />
* Animations, states and transitions<br />
* C++ Integration<br />
<br />
Coaches: Volker Krause and Kévin Ottens<br />
----<br />
<br />
'''Registration is required.'''<br />
<br />
The workshop is suitable for beginners and advanced developers. Please add your name and information below if you want to attend.<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Number<br />
! Name/IRC nick/email<br />
! Level of Qt expertise<br />
|-<br />
| width="10%" | 1<br />
| width="45%" | Ima Hotshot<br />
| width="45%" | I can do cute with one hand behind my back.<br />
|-<br />
| 2<br />
| Helio Chissini de Castro<br />
| Some Qt but need learn new tricks<br />
|-<br />
| 3<br />
| <br />
| <br />
|-<br />
| 4<br />
| <br />
| <br />
|-<br />
| 5<br />
| <br />
| <br />
|-<br />
| 6<br />
| <br />
| <br />
|-<br />
| 7<br />
| <br />
| <br />
|-<br />
| 8<br />
| <br />
| <br />
|-<br />
| 9<br />
| <br />
| <br />
|-<br />
| 10<br />
| <br />
| <br />
|-<br />
| 11<br />
| <br />
| <br />
|-<br />
| 12<br />
| <br />
| <br />
|-<br />
| 13<br />
| <br />
| <br />
|-<br />
| 14<br />
| <br />
| <br />
|-<br />
| 15<br />
| <br />
| <br />
|-<br />
| 16<br />
| <br />
| <br />
|-<br />
| 17<br />
| <br />
| <br />
|-<br />
| 18<br />
| <br />
| <br />
|-<br />
| 19<br />
| <br />
| <br />
|-<br />
| 20<br />
| <br />
| <br />
|-<br />
| 21<br />
| <br />
| <br />
|-<br />
| 22<br />
| <br />
| <br />
|-<br />
| 23<br />
| <br />
| <br />
|-<br />
| 24<br />
| <br />
| <br />
|-<br />
| 25<br />
| <br />
| <br />
|-<br />
| 26<br />
| <br />
| <br />
|-<br />
| 27<br />
| <br />
| <br />
|-<br />
| 28<br />
| <br />
| <br />
|-<br />
| 29<br />
| <br />
| <br />
|-<br />
| 30<br />
| <br />
|<br />
|-<br />
| 31<br />
| <br />
| <br />
|-<br />
| 32<br />
| <br />
| <br />
|-<br />
| 33<br />
| <br />
| <br />
|-<br />
| 34<br />
| <br />
| <br />
|-<br />
| 35<br />
| <br />
| <br />
|-<br />
| 36<br />
| <br />
| <br />
|-<br />
| 37<br />
| <br />
| <br />
|-<br />
| 38<br />
| <br />
| <br />
|-<br />
| 39<br />
| <br />
| <br />
|-<br />
| 40<br />
| <br />
| <br />
|}</div>OpenIDUser14https://community.kde.org/index.php?title=KDE_Core/Platform_11/Settings&diff=16537KDE Core/Platform 11/Settings2011-12-05T13:26:50Z<p>OpenIDUser14: /* General */</p>
<hr />
<div>{{warning|This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made. Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.}}<br />
<br />
= KConfig x New config as a library support =<br />
<br />
Replace KConfig with a Qt only based config library, with native backends for target operational systems. This new library will be suitable for even Qt only apps.<br />
It will be a solid/phonon like library for backends<br />
<br />
Among cited characteristics desired<br />
<br />
* Remove all global config usage ( as <KDEDIR>/share/config in Linux ). All configs are user based and Kiosk is of course respected, so no user or distro will be afflicted<br />
<br />
* kcfg and defaults not deployed anymore by a separated file. Defaults can be included in binary through headers for example, and are generated on the fly on first run from user. Distros still can have their tree with configs. Maybe a description generated by a tool to provide automatically which configs are available on the app to help distros.<br />
<br />
* New library would be wrote from scratch and a kconfig new code will be as the direct glue to make kde compile it without change current implementations. In future, apps can use directly the new library as kconfig wrapper will not be needed anymore. KConfig will be a transitory stage<br />
<br />
Helio wants to try to implement it.<br />
<br />
= Current pointed implementation issues open questions =<br />
<br />
* Multiple instances of same app and concurrent write/read<br />
<br />
* Desire of config change notification related to backends, not all can have this available. Since we're not look deep on other platforms config systems, we assume that dconf is the only one that has it.<br />
<br />
* Migration from kde4 configs. Proposal of a tool to make the process. This is feasible, only will relies on create a parser or use kconfig to read ini files, and will take some time to write. Using kconfig itself will create an undesirable dependency.<br />
<br />
= Configuration systems =<br />
<br />
== DConf ==<br />
DConf as a backend for KConfig would offer some nice features.<br />
<br />
Unlike the current .ini files it creates one or multiple binary settings files that is used by all applications. A shell tool exists as well as a gtk settings editor. This multiple files can be used in a form of list, with the benefits of locks as well, making a must for kiosk or at least not breaking the functionality.<br />
<br />
Reading of settings is done via one mmaped file (read only). Therefor reading is fast. Writing happens via dbus.<br />
<br />
There are notifications for changes of settings.<br />
<br />
It features a hierarchy of settings like KConfig where user settings take precedence compared to system settings.<br />
The concept of locking is very similar to Kiosk immutable settings.<br />
In addition there are notifications if the locked state changes - that means activating a Kiosk immutable on a setting could immediately reflected in the UI.<br />
<br />
There is an existing Qt library:<br />
https://gitorious.org/dconf-qt/dconf-qt<br />
<br />
See also:<br />
http://live.gnome.org/dconf/SystemAdministrators<br />
<br />
<br />
Problems could be:<br />
There is no win/mac support. This requires keeping the old way with ini files a live or some investment to make dconf work or write other kconfig backends.<br />
<br />
We can't use change notifications as that would assume use of dconf as a backend which makes an application unportable to windows/mac (currently).<br />
<br />
DConf stores its config in xdg dirs (.config).<br />
<br />
=== Current state to compile ===<br />
Core dconf It requires quite new version of glib and vala, the visual registry editor requires Gtk 3 ( not needed for us now ) and dconf-qt made by Canonical requires a new vendor patch for Qt, included only in Qt 4.8<br />
<br />
== Windows Native ==<br />
<br />
TBD<br />
<br />
== OSX Native ==<br />
<br />
TBD<br />
<br />
= QDesktopServices =<br />
<br />
It may make sense to split between application state and actual configuration settings.<br />
DConf and other backends could then handle the real settings whereas application state (unread mails in kmail) could be handled by the traditional ini files.<br />
<br />
<br />
= General =<br />
<br />
* Having a dconf backend to KConfig is nice but doesn't mean a huge change. For application developers nothing would change due to this. ''The implementation of a current KConfig backend is far from simple, and banging on current implementation add more code will not help in any thew goals of a new modern configuration system.''<br />
<br />
* What about QSettings? big problems with settings-groups, not power full enough for KDE. Can KConfig be merged with this ? '' The short answer is no, most the fact that even Trolls decided not support it anymore, and current KConfig architecture is way to different and for sure we don't want create an Unmaintainable Frankenstein. ''</div>OpenIDUser14https://community.kde.org/index.php?title=KDE_Core/Platform_11/Settings&diff=16536KDE Core/Platform 11/Settings2011-12-05T13:26:04Z<p>OpenIDUser14: /* General */</p>
<hr />
<div>{{warning|This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made. Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.}}<br />
<br />
= KConfig x New config as a library support =<br />
<br />
Replace KConfig with a Qt only based config library, with native backends for target operational systems. This new library will be suitable for even Qt only apps.<br />
It will be a solid/phonon like library for backends<br />
<br />
Among cited characteristics desired<br />
<br />
* Remove all global config usage ( as <KDEDIR>/share/config in Linux ). All configs are user based and Kiosk is of course respected, so no user or distro will be afflicted<br />
<br />
* kcfg and defaults not deployed anymore by a separated file. Defaults can be included in binary through headers for example, and are generated on the fly on first run from user. Distros still can have their tree with configs. Maybe a description generated by a tool to provide automatically which configs are available on the app to help distros.<br />
<br />
* New library would be wrote from scratch and a kconfig new code will be as the direct glue to make kde compile it without change current implementations. In future, apps can use directly the new library as kconfig wrapper will not be needed anymore. KConfig will be a transitory stage<br />
<br />
Helio wants to try to implement it.<br />
<br />
= Current pointed implementation issues open questions =<br />
<br />
* Multiple instances of same app and concurrent write/read<br />
<br />
* Desire of config change notification related to backends, not all can have this available. Since we're not look deep on other platforms config systems, we assume that dconf is the only one that has it.<br />
<br />
* Migration from kde4 configs. Proposal of a tool to make the process. This is feasible, only will relies on create a parser or use kconfig to read ini files, and will take some time to write. Using kconfig itself will create an undesirable dependency.<br />
<br />
= Configuration systems =<br />
<br />
== DConf ==<br />
DConf as a backend for KConfig would offer some nice features.<br />
<br />
Unlike the current .ini files it creates one or multiple binary settings files that is used by all applications. A shell tool exists as well as a gtk settings editor. This multiple files can be used in a form of list, with the benefits of locks as well, making a must for kiosk or at least not breaking the functionality.<br />
<br />
Reading of settings is done via one mmaped file (read only). Therefor reading is fast. Writing happens via dbus.<br />
<br />
There are notifications for changes of settings.<br />
<br />
It features a hierarchy of settings like KConfig where user settings take precedence compared to system settings.<br />
The concept of locking is very similar to Kiosk immutable settings.<br />
In addition there are notifications if the locked state changes - that means activating a Kiosk immutable on a setting could immediately reflected in the UI.<br />
<br />
There is an existing Qt library:<br />
https://gitorious.org/dconf-qt/dconf-qt<br />
<br />
See also:<br />
http://live.gnome.org/dconf/SystemAdministrators<br />
<br />
<br />
Problems could be:<br />
There is no win/mac support. This requires keeping the old way with ini files a live or some investment to make dconf work or write other kconfig backends.<br />
<br />
We can't use change notifications as that would assume use of dconf as a backend which makes an application unportable to windows/mac (currently).<br />
<br />
DConf stores its config in xdg dirs (.config).<br />
<br />
=== Current state to compile ===<br />
Core dconf It requires quite new version of glib and vala, the visual registry editor requires Gtk 3 ( not needed for us now ) and dconf-qt made by Canonical requires a new vendor patch for Qt, included only in Qt 4.8<br />
<br />
== Windows Native ==<br />
<br />
TBD<br />
<br />
== OSX Native ==<br />
<br />
TBD<br />
<br />
= QDesktopServices =<br />
<br />
It may make sense to split between application state and actual configuration settings.<br />
DConf and other backends could then handle the real settings whereas application state (unread mails in kmail) could be handled by the traditional ini files.<br />
<br />
<br />
= General =<br />
<br />
* Having a dconf backend to KConfig is nice but doesn't mean a huge change. For application developers nothing would change due to this.<br />
'''The implementation of a current KConfig backend is far from simple, and banging on current implementation add more code will not help in any thew goals of a new modern configuration system.'''<br />
<br />
* What about QSettings? big problems with settings-groups, not power full enough for KDE. Can KConfig be merged with this? ''' The short answer is no, most the fact that even Trolls decided not support it anymore, and current KConfig architecture is way to different and for sure we don't want create an Unmaintainable Frankenstein.</div>OpenIDUser14https://community.kde.org/index.php?title=KDE_Core/Platform_11/Settings&diff=16535KDE Core/Platform 11/Settings2011-12-05T12:42:15Z<p>OpenIDUser14: </p>
<hr />
<div>{{warning|This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made. Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.}}<br />
<br />
= KConfig x New config as a library support =<br />
<br />
Replace KConfig with a Qt only based config library, with native backends for target operational systems. This new library will be suitable for even Qt only apps.<br />
It will be a solid/phonon like library for backends<br />
<br />
Among cited characteristics desired<br />
<br />
* Remove all global config usage ( as <KDEDIR>/share/config in Linux ). All configs are user based and Kiosk is of course respected, so no user or distro will be afflicted<br />
<br />
* kcfg and defaults not deployed anymore by a separated file. Defaults can be included in binary through headers for example, and are generated on the fly on first run from user. Distros still can have their tree with configs. Maybe a description generated by a tool to provide automatically which configs are available on the app to help distros.<br />
<br />
* New library would be wrote from scratch and a kconfig new code will be as the direct glue to make kde compile it without change current implementations. In future, apps can use directly the new library as kconfig wrapper will not be needed anymore. KConfig will be a transitory stage<br />
<br />
Helio wants to try to implement it.<br />
<br />
= Current pointed implementation issues open questions =<br />
<br />
* Multiple instances of same app and concurrent write/read<br />
<br />
* Desire of config change notification related to backends, not all can have this available. Since we're not look deep on other platforms config systems, we assume that dconf is the only one that has it.<br />
<br />
* Migration from kde4 configs. Proposal of a tool to make the process. This is feasible, only will relies on create a parser or use kconfig to read ini files, and will take some time to write. Using kconfig itself will create an undesirable dependency.<br />
<br />
= Configuration systems =<br />
<br />
== DConf ==<br />
DConf as a backend for KConfig would offer some nice features.<br />
<br />
Unlike the current .ini files it creates one or multiple binary settings files that is used by all applications. A shell tool exists as well as a gtk settings editor. This multiple files can be used in a form of list, with the benefits of locks as well, making a must for kiosk or at least not breaking the functionality.<br />
<br />
Reading of settings is done via one mmaped file (read only). Therefor reading is fast. Writing happens via dbus.<br />
<br />
There are notifications for changes of settings.<br />
<br />
It features a hierarchy of settings like KConfig where user settings take precedence compared to system settings.<br />
The concept of locking is very similar to Kiosk immutable settings.<br />
In addition there are notifications if the locked state changes - that means activating a Kiosk immutable on a setting could immediately reflected in the UI.<br />
<br />
There is an existing Qt library:<br />
https://gitorious.org/dconf-qt/dconf-qt<br />
<br />
See also:<br />
http://live.gnome.org/dconf/SystemAdministrators<br />
<br />
<br />
Problems could be:<br />
There is no win/mac support. This requires keeping the old way with ini files a live or some investment to make dconf work or write other kconfig backends.<br />
<br />
We can't use change notifications as that would assume use of dconf as a backend which makes an application unportable to windows/mac (currently).<br />
<br />
DConf stores its config in xdg dirs (.config).<br />
<br />
=== Current state to compile ===<br />
Core dconf It requires quite new version of glib and vala, the visual registry editor requires Gtk 3 ( not needed for us now ) and dconf-qt made by Canonical requires a new vendor patch for Qt, included only in Qt 4.8<br />
<br />
== Windows Native ==<br />
<br />
TBD<br />
<br />
== OSX Native ==<br />
<br />
TBD<br />
<br />
= QDesktopServices =<br />
<br />
It may make sense to split between application state and actual configuration settings.<br />
DConf and other backends could then handle the real settings whereas application state (unread mails in kmail) could be handled by the traditional ini files.<br />
<br />
<br />
= General =<br />
<br />
Having a dconf backend to KConfig is nice but doesn't mean a huge change. For application developers nothing would change due to this.<br />
<br />
What about QSettings? big problems with settings-groups, not power full enough for KDE. Can KConfig be merged with this?</div>OpenIDUser14https://community.kde.org/index.php?title=KDE_Core/Platform_11/Settings&diff=16534KDE Core/Platform 11/Settings2011-12-05T12:40:48Z<p>OpenIDUser14: </p>
<hr />
<div>{{warning|This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made. Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.}}<br />
<br />
= KConfig x New config as a library support =<br />
<br />
Replace KConfig with a Qt only based config library, with native backends for target operational systems. This new library will be suitable for even Qt only apps.<br />
It will be a solid/phonon like library for backends<br />
<br />
Among cited characteristics desired<br />
<br />
* Remove all global config usage ( as <KDEDIR>/share/config in Linux ). All configs are user based and Kiosk is of course respected, so no user or distro will be afflicted<br />
<br />
* kcfg and defaults not deployed anymore by a separated file. Defaults can be included in binary through headers for example, and are generated on the fly on first run from user. Distros still can have their tree with configs. Maybe a description generated by a tool to provide automatically which configs are available on the app to help distros.<br />
<br />
* New library would be wrote from scratch and a kconfig new code will be as the direct glue to make kde compile it without change current implementations. In future, apps can use directly the new library as kconfig wrapper will not be needed anymore. KConfig will be a transitory stage<br />
<br />
Helio wants to try to implement it.<br />
<br />
= Current pointed implementation issues open questions =<br />
<br />
* Multiple instances of same app and concurrent write/read<br />
<br />
* Desire of config change notification related to backends, not all can have this available. Since we're not look deep on other platforms config systems, we assume that dconf is the only one that has it.<br />
<br />
* Migration from kde4 configs. Proposal of a tool to make the process. This is feasible, only will relies on create a parser or use kconfig to read ini files, and will take some time to write. Using kconfig itself will create an undesirable dependency.<br />
<br />
= Configuration systems =<br />
<br />
== DConf ==<br />
DConf as a backend for KConfig would offer some nice features.<br />
<br />
Unlike the current .ini files it creates one or multiple binary settings files that is used by all applications. A shell tool exists as well as a gtk settings editor. This multiple files can be used in a form of list, with the benefits of locks as well, making a must for kiosk or at least not breaking the functionality.<br />
<br />
Reading of settings is done via one mmaped file (read only). Therefor reading is fast. Writing happens via dbus.<br />
<br />
There are notifications for changes of settings.<br />
<br />
It features a hierarchy of settings like KConfig where user settings take precedence compared to system settings.<br />
The concept of locking is very similar to Kiosk immutable settings.<br />
In addition there are notifications if the locked state changes - that means activating a Kiosk immutable on a setting could immediately reflected in the UI.<br />
<br />
There is an existing Qt library:<br />
https://gitorious.org/dconf-qt/dconf-qt<br />
<br />
See also:<br />
http://live.gnome.org/dconf/SystemAdministrators<br />
<br />
<br />
Problems could be:<br />
There is no win/mac support. This requires keeping the old way with ini files a live or some investment to make dconf work or write other kconfig backends.<br />
<br />
We can't use change notifications as that would assume use of dconf as a backend which makes an application unportable to windows/mac (currently).<br />
<br />
DConf stores its config in xdg dirs (.config).<br />
<br />
=== Current state to compile ===<br />
Core dconf It requires quite new version of glib and vala, the visual registry editor requires Gtk 3 ( not needed for us now ) and dconf-qt made by Canonical requires a new vendor patch for Qt, included only in Qt 4.8<br />
<br />
== Windows Native ==<br />
<br />
TBD<br />
<br />
== OSX Native<br />
<br />
TBD<br />
<br />
= QDesktopServices =<br />
<br />
It may make sense to split between application state and actual configuration settings.<br />
DConf and other backends could then handle the real settings whereas application state (unread mails in kmail) could be handled by the traditional ini files.<br />
<br />
<br />
= General =<br />
<br />
Having a dconf backend to KConfig is nice but doesn't mean a huge change. For application developers nothing would change due to this.<br />
<br />
What about QSettings? big problems with settings-groups, not power full enough for KDE. Can KConfig be merged with this?</div>OpenIDUser14https://community.kde.org/index.php?title=Qt_Contributors_Day&diff=15338Qt Contributors Day2011-10-11T10:45:24Z<p>OpenIDUser14: </p>
<hr />
<div>The Qt Contributors Day is an event hosted by Nokia at the Qt Developer Days. There are two of these events - one in Munich and one in San Francisco. This page pertains to the Munich event.<br />
<br />
The event follows the Unconference format, which means that the attendees are presented with a number of empty time slots, and that they bring their own event topics to fill the time slots.<br />
<br />
== Registered Attendees ==<br />
<br />
We have space for an absolute maximum of 50 attendees for this event. If you wish to take part, please do /not/ simply add yourself to this list: Email admin@leinir.dk and say you wish to attend (sorry for the bureocracy, we need to control the event a bit due to the relatively small number of available spaces). <br />
<br />
# Dan Leinir Turthra Jensen - admin (at) leinir.dk<br />
# Cornelius Shuhmacher - schumacher (at) kde.org<br />
# Mirko Boehm - mirko (at) kde.org<br />
# Claudia Rauch - claudiar (at) kde.org<br />
# Stefan Derkits - stefan (at) derkits.at<br />
# Stuart Dickson - stuart (at) furkinfantastic.net<br />
# Laszlo Papp - lpapp (at) kde.org<br />
# Andreas Hartmetz - ahartmetz (at) gmail.com<br />
# Richard Moore - rich (at) kde.org<br />
# Frank Karlitschek - karlitschek (at) kde.org<br />
# Sune Vuorela - sune (at) vuorela.dk<br />
# Thiago Macieira - thiago (at) kde.org<br />
# Kevin Funk - krf (at) gmx.de<br />
# Till Adam - adam (at) kde.org<br />
# Oliver Goffart - ogoffart (at) kde.org<br />
# Markus Goetz - markus (at) woboq.com<br />
# Olaf Schmidt-Wischhöfer - olaf (at) amen-online.de<br />
# Martin Konold - konold (at) kde.org<br />
# Hanna Skott - hanna.skott (at) kogmbh.com<br />
# Christian Muehlhaeuser - muesli (at) gmail.com<br />
# Boudewijn Rempt - boud (at) valdyas.org<br />
# Inge Wallin - inge (at) lysator.liu.se<br />
# Mark Kretschmann - kretschmann (at) kde.org<br />
# Anne-Marie Mahfouf - annma (at) kde.org<br />
# Helio Chissini de Castro - helio (at) kde.org<br />
# Manuel Nickschas - sputnick (at) quassel-irc.org<br />
# Arjen Hiemstra - djfreestyler (at) gmail.com<br />
<br />
Potential:<br />
<br />
# Volker Krause - vkrause (at) kde.org<br />
<br />
== FAQ ==<br />
<br />
==== Do I have to be member of the KDE e.V.? ====<br />
Short version: No! :O<br />
<br />
Lon version: It has come to my attention that some people believe they must be a member of the KDE e.V. to take part in this event: This is by no means the case! If you think you have something to add to this, you should not be stopped by some simple detail as not being part of the e.V.! If you think you've something to add - email me at admin@leinir.dk so we can get you invited.<br />
<br />
==== Why is there no schedule? ====<br />
==== aka What is an unconference? ====<br />
<br />
The basic idea of an unconference is that the participants of such an event make their own schedule. Upon arrival you will be presented with a set of empty time slots on a calendar, and some post-it notes. You write your session ideas on those post-it notes, grab a bunch of people, and put that post-it note on an empty time slot.<br />
<br />
Tip: You should consider beforehand what sort of sessions you wish to host or take part in, and try and grab a few people ahead of time - especially if you are going for the early time slots.</div>OpenIDUser14https://community.kde.org/index.php?title=Qt_Contributors_Day&diff=15337Qt Contributors Day2011-10-11T10:44:56Z<p>OpenIDUser14: </p>
<hr />
<div>The Qt Contributors Day is an event hosted by Nokia at the Qt Developer Days. There are two of these events - one in Munich and one in San Francisco. This page pertains to the Munich event.<br />
<br />
The event follows the Unconference format, which means that the attendees are presented with a number of empty time slots, and that they bring their own event topics to fill the time slots.<br />
<br />
== Registered Attendees ==<br />
<br />
We have space for an absolute maximum of 50 attendees for this event. If you wish to take part, please do /not/ simply add yourself to this list: Email admin@leinir.dk and say you wish to attend (sorry for the bureocracy, we need to control the event a bit due to the relatively small number of available spaces). <br />
<br />
# Dan Leinir Turthra Jensen - admin (at) leinir.dk<br />
# Cornelius Shuhmacher - schumacher (at) kde.org<br />
# Mirko Boehm - mirko (at) kde.org<br />
# Claudia Rauch - claudiar (at) kde.org<br />
# Stefan Derkits - stefan (at) derkits.at<br />
# Stuart Dickson - stuart (at) furkinfantastic.net<br />
# Laszlo Papp - lpapp (at) kde.org<br />
# Andreas Hartmetz - ahartmetz (at) gmail.com<br />
# Richard Moore - rich (at) kde.org<br />
# Frank Karlitschek - karlitschek (at) kde.org<br />
# Sune Vuorela - sune (at) vuorela.dk<br />
# Thiago Macieira - thiago (at) kde.org<br />
# Kevin Funk - krf (at) gmx.de<br />
# Till Adam - adam (at) kde.org<br />
# Oliver Goffart - ogoffart (at) kde.org<br />
# Markus Goetz - markus (at) woboq.com<br />
# Olaf Schmidt-Wischhöfer - olaf (at) amen-online.de<br />
# Martin Konold - konold (at) kde.org<br />
# Hanna Skott - hanna.skott (at) kogmbh.com<br />
# Christian Muehlhaeuser - muesli (at) gmail.com<br />
# Boudewijn Rempt - boud (at) valdyas.org<br />
# Inge Wallin - inge (at) lysator.liu.se<br />
# Mark Kretschmann - kretschmann (at) kde.org<br />
# Anne-Marie Mahfouf - annma (at) kde.org<br />
# Helio Chissini de Castro - helio (at) kde.org<br />
# Manuel Nickschas - sputnick (at) quassel-irc.org<br />
# Arjen Hiemstra - djfreestyler (at) gmail.com<br />
# Helio Chissini de Castro - helio (at) kde.org<br />
<br />
Potential:<br />
<br />
# Volker Krause - vkrause (at) kde.org<br />
<br />
== FAQ ==<br />
<br />
==== Do I have to be member of the KDE e.V.? ====<br />
Short version: No! :O<br />
<br />
Lon version: It has come to my attention that some people believe they must be a member of the KDE e.V. to take part in this event: This is by no means the case! If you think you have something to add to this, you should not be stopped by some simple detail as not being part of the e.V.! If you think you've something to add - email me at admin@leinir.dk so we can get you invited.<br />
<br />
==== Why is there no schedule? ====<br />
==== aka What is an unconference? ====<br />
<br />
The basic idea of an unconference is that the participants of such an event make their own schedule. Upon arrival you will be presented with a set of empty time slots on a calendar, and some post-it notes. You write your session ideas on those post-it notes, grab a bunch of people, and put that post-it note on an empty time slot.<br />
<br />
Tip: You should consider beforehand what sort of sessions you wish to host or take part in, and try and grab a few people ahead of time - especially if you are going for the early time slots.</div>OpenIDUser14https://community.kde.org/index.php?title=KDE_Core/Platform_11/Settings&diff=12623KDE Core/Platform 11/Settings2011-06-03T18:06:02Z<p>OpenIDUser14: </p>
<hr />
<div>= Configuration systems =<br />
<br />
== DConf ==<br />
DConf as a backend for KConfig would offer some nice features.<br />
Helio wants to try to implement it.<br />
<br />
Unlike the current .ini files it creates one or multiple binary settings files that is used by all applications. A shell tool exists as well as a gtk settings editor. This multiple files can be used in a form of list, with the benefits of locks as well, making a must for kiosk or at least not breaking the functionality.<br />
<br />
Reading of settings is done via one mmaped file (read only). Therefor reading is fast. Writing happens via dbus.<br />
<br />
There are notifications for changes of settings.<br />
<br />
It features a hierarchy of settings like KConfig where user settings take precedence compared to system settings.<br />
The concept of locking is very similar to Kiosk immutable settings.<br />
In addition there are notifications if the locked state changes - that means activating a Kiosk immutable on a setting could immediately reflected in the UI.<br />
<br />
There is an existing Qt library:<br />
https://gitorious.org/dconf-qt/dconf-qt<br />
<br />
See also:<br />
http://live.gnome.org/dconf/SystemAdministrators<br />
<br />
<br />
Problems could be:<br />
There is no win/mac support. This requires keeping the old way with ini files a live or some investment to make dconf work or write other kconfig backends.<br />
<br />
DConf stores its config in xdg dirs (.config).<br />
<br />
QDesktopServices<br />
<br />
It may make sense to split between application state and actual configuration settings.<br />
DConf could then handle the real settings whereas application state (unread mails in kmail) could be handled by the traditional ini files.<br />
<br />
== Current state to compile ==<br />
Core dconf It requires quite new version of glib and vala, the visual registry editor requires Gtk 3 ( not needed for us now ) and dconf-qt made by Canonical requires a new vendor patch for Qt, included only in Qt 4.8<br />
<br />
== General ==<br />
<br />
Having a dconf backend to KConfig is nice but doesn't mean a huge change. For application developers nothing would change due to this.<br />
<br />
What about QSettings? big problems with settings-groups, not power full enough for KDE. Can KConfig be merged with this?</div>OpenIDUser14https://community.kde.org/index.php?title=KDE_Core/Platform_11&diff=12050KDE Core/Platform 112011-05-03T10:53:58Z<p>OpenIDUser14: </p>
<hr />
<div>== Insert logo here ==<br />
making it now (Nuno)<br />
<br />
[[File:Coreproposal.png]] <br />
<br />
[[User:Saleel]]'s Proposal. SVG:[[Media:Coreproposal.svg]]<br />
<br />
== Purpose of the Sprint ==<br />
To examine the current state and near future of the KDE Platform (kdelibs and kdebase-runtime), particularly as it relates to the growing usage of it in new contexts such as mobile or on Windows and MacOS and its traditional usage as a set of conveniences and consistency creators for KDE application development.<br />
<br />
The sprint will aim to create an actionable, multi-year roadmap for kdelibs and kdebase-runtime and will examine issues of modularity, topicality and the inherent dichotomy between the KDE Platform as an application development framework (similar to Qt) and as a stand-alone platform to target (similar to, e.g. Windows, MacOS, etc.)<br />
<br />
== Participants ==<br />
<br />
This sprint will aim to bring together developers who contribute to the KDE Platform directly, who use it in sophisticated applications, packagers of it and those involved in setting similar policies for Qt.<br />
<br />
The proposed break down of attendees:<br />
<br />
* 12-15 kdelibs and kdebase-runtime commiters<br />
* 3-5 KDE application developers<br />
* 2-3 packagers<br />
* 1-2 people from the KDE Release Team<br />
* 1-2 Qt representatives<br />
<br />
making for a total of 19-27 people.<br />
<br />
If you would like to attend, please record your name below. Date organization will occur at a later point.<br />
<br />
{| class="wikitable" border="1"<br />
!Name<br />
!Email<br />
!Role / Work<br />
!Arrival<br />
!Depart<br />
!Est. Cost<br />
!Need Sponsor?<br />
!Need Hotel?<br />
!Food Req.<br />
!Airport<br />
!Flights<br />
|-<br />
|Aaron&nbsp;Seigo<br />
|aseigo@kde.org<br />
|Meeting facilitation, libplasma<br />
|<br />
|<br />
|~170 Euro (could be 1/2)<br />
|yes<br />
|yes<br />
|vegetarian<br />
|<br />
|<br />
|-<br />
|John Layt<br />
|john@layt.org<br />
|Localization, Printing, Geolocation<br />
|Wed 1 June <br />
|Tues 7 June<br />
|€200<br />
|Yes<br />
|Yes<br />
|Yes<br />
|Zurich<br />
|EZY5113 arrives 9:50, EZY5118 departs 21:20<br />
|-<br />
|Marijn Kruisselbrink<br />
|mek@kogmbh.com<br />
|kdelibs mobile, meego packaging, koffice<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|vegetarian<br />
|<br />
|<br />
|-<br />
|Thiago Macieira<br />
|thiago@kde.org<br />
|Qt, used to work in kdelibs<br />
|<br />
|<br />
|<br />
|no<br />
|no<br />
|any<br />
|<br />
|<br />
|-<br />
|Andreas Hartmetz<br />
|ahartmetz@gmail.com<br />
|kdelibs - mostly KIO and some kdeui<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|yes<br />
|<br />
|<br />
|- <br />
|Dario Freddi<br />
|drf@kde.org<br />
|Authorization Framework, Solid, Possibly all things KCM* <br />
| <br />
| <br />
| <br />
|yes <br />
|yes <br />
|any<br />
|LIN/BGY/MXP<br />
|<br />
|-<br />
|Kevin Ottens<br />
|ervin@kde.org<br />
|KDE Platform+Frameworks modularity, interaction with Qt<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|no seafood<br />
|coming by train from Toulouse via Avignon<br />
|<br />
|-<br />
|David Faure<br />
|faure@kde.org<br />
|kdelibs, interaction with Qt<br />
|<br />
|<br />
|<br />
|no<br />
|yes<br />
|<br />
|coming by train from Avignon<br />
|<br />
|-<br />
|Alexander Neundorf<br />
|neundorf@kde.org<br />
|buildsystem (kdesupport +kdelibs +kdepimlibs +kdebaselibs) modularization<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|any<br />
|<br />
|<br />
|-<br />
|Raphael Kubo da Costa<br />
|kubito@gmail.com<br />
|Mostly kdecore and kio. KDE/Qt on FreeBSD.<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|any<br />
|<br />
|<br />
|-<br />
|George Kiagiadakis<br />
|kiagiadakis.george@gmail.com<br />
|drkonqi, small contributions to kdelibs, debian packaging<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|any<br />
|<br />
|<br />
|-<br />
|Olivier Goffart (not sure)<br />
|ogoffart@kde.org<br />
|Qt, former kdelibs contributor (port to Qt4, knotify)<br />
|<br />
|<br />
|<br />
|maybe<br />
|maybe<br />
|2500 kcal/day<br />
|<br />
|<br />
|-<br />
|Till Adam<br />
|adam@kde.org<br />
|kdepim, kdelibs, KDE/Mac, KDE/Windows, KDE/Maemo, KDE/WinCE, KDE/MeeGo<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|if you don't want it eaten, don't keep it around me<br />
|<br />
|<br />
|-<br />
|Sebastian Kügler<br />
|sebas@kde.org<br />
|release team<br />
|<br />
|<br />
|<br />
|probably<br />
|probably<br />
|omnivore<br />
|AMS<br />
|<br />
|-<br />
|Frederik Gladhorn<br />
|gladhorn@kde.org<br />
|Qt, knewstuff<br />
|<br />
|<br />
|<br />
|maybe<br />
|probably<br />
|any<br />
|Oslo<br />
|<br />
|-<br />
|Albert Astals Cid<br />
|aacid@kde.org<br />
|l10n, misc<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|almost any<br />
|Dublin<br />
|<br />
|-<br />
|Sune Vuorela<br />
|sune@vuorela.dk<br />
|Packaging and weirdness<br />
|<br />
|<br />
|<br />
|most likely<br />
|most likely<br />
|yes<br />
|cph; prefers train.<br />
|<br />
|-<br />
|Stephen Kelly<br />
|skelly@kde.org<br />
|kdelibs, modularisation, Qt interfacing<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|Anything but sushi<br />
|TXL/SXF<br />
|<br />
|-<br />
|Volker Krause<br />
|vkrause@kde.org<br />
|kdepimlibs, kdepim, KDE on MeeGo/Maemo5/WinCE<br />
|<br />
|<br />
|<br />
|<br />
|yes<br />
|anything<br />
|TXL/SXF<br />
|<br />
|-<br />
|Ivan Čukić<br />
|ivan.cukic@kde.org<br />
|libplasma, activities<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|anything<br />
|<br />
|<br />
|-<br />
|Teo Mrnjavac<br />
|teo@kde.org<br />
|Social desktop<br />
|<br />
|<br />
|<br />
|yes please<br />
|yes<br />
|vegan<br />
|coming by car<br />
|<br />
|-<br />
|Marco Martin<br />
|mart@kde.org<br />
|libplasma, mobile profiles, activities<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|anything<br />
|<br />
|-<br />
|Cornelius Schumacher<br />
|schumacher@kde.org<br />
|Used to work on kdelibs, kdebase-runtime, and KDE PIM, these days mostly 3rd party applications. Would love to pitch the idea of merging Qt and the KDE platform to this group to trigger some productive discussion and some out-of-the box thinking<br />
|<br />
|<br />
|<br />
|maybe<br />
|yes<br />
|any<br />
|<br />
|<br />
|-<br />
|Valentin Rusu<br />
|kde@rusu.info<br />
|Authorization Framework, KCM*<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|any<br />
|coming by car from Lyon<br />
|<br />
|-<br />
|Helio Castro<br />
|helio@kde.org<br />
|KDE Platform, integration, mobile<br />
|01.06<br />
|07.06<br />
|<br />
|no<br />
|yes<br />
|any<br />
|FLN<br />
|<br />
|-<br />
|Mario Fux<br />
|fux@kde.org<br />
|Sonnet (NLP framework), Nepomuk<br />
|01.06.<br />
|07.06.<br />
|0 CHF<br />
|no<br />
|no<br />
|any<br />
|<br />
|<br />
|-<br />
|Alex Fiestas<br />
|afiestas@kde.org<br />
|libsolid, BlueDevil, Kamoso<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|vegetarian (eggs+milk)<br />
|<br />
|<br />
|-<br />
|Will Stephenson<br />
|wstephenson@kde.org<br />
|kdelibs, kdepim, packaging<br />
|01.06.<br />
|03.06.<br />
|? CHF<br />
|no<br />
|yes<br />
|any<br />
|<br />
|<br />
|-<br />
|Gregory Schlomoff<br />
|gregory.schlomoff@gmail.com<br />
|Developer of a non-KDE app that uses kdelibs and kdepimlibs. Small contributor to kdepimlibs. Wants to help making it easier for Qt devs to use relevant kde libraries.<br />
|<br />
|<br />
|<br />
|yes, if possible.<br />
|yes<br />
|any<br />
|looking for some cheap way to come from Paris. Car pooling?<br />
|<br />
|-<br />
|Davide Bettio<br />
|davide.bettio -at- kdemail.net<br />
|libplasma and mobile developer<br />
| On friday<br />
| I'll leave few days after the arrival<br />
| ~150 €<br />
|yes<br />
|yes<br />
|any except fish<br />
|<br />
|I'll take a train<br />
|-<br />
|Ryan Lortie<br />
|desrt@desrt.ca<br />
|dconf<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|any<br />
|Zurich, probably<br />
|<br />
|}<br />
<br />
== Topics ==<br />
<br />
<br />
Note: these are simply sample topics, not final direction on what will actually be discussed. Actual topics will be generated at a pre-sprint meeting online as well as through group authorship of this section.<br />
<br />
=== Modularization of KDE libraries ===<br />
<br />
Alex: should IMO include not only kdelibs, but also kdesupport, kdepimlibs and kdebase libs<br />
<br />
=== Framework vs Platform ===<br />
* Qt OpenGov<br />
* Policy towards QtMobility<br />
* Geolocation<br />
<br />
=== Redundancies ===<br />
KLocale & co vs QLocale & co: How to act local everywhere while retaining configurability.<br />
<br />
=== Build Profiles ===<br />
<br />
=== Build system ===<br />
<br />
What level modularity do we want/need here ?<br />
Chances of CMake becoming the buildsystem for Qt.<br />
<br />
=== QML and Javascript ===<br />
<br />
== Logistics ==<br />
<br />
=== Dates ===<br />
<br />
June 1/2 - 6/7<br />
<br />
=== Location ===<br />
<br />
[http://community.kde.org/Sprints/Randa Randa], Switzerland<br />
<br />
=== Travel and Accommodations ===<br />
<br />
See at the general [http://community.kde.org/Sprints/Randa Randa] page.<br />
<br />
=== Food, Drink and Shopping ===<br />
<br />
See at the general [http://community.kde.org/Sprints/Randa Randa] page.</div>OpenIDUser14https://community.kde.org/index.php?title=KDE_Core/Platform_11&diff=8386KDE Core/Platform 112011-01-12T13:52:14Z<p>OpenIDUser14: /* Participants */</p>
<hr />
<div>== Purpose of the Sprint ==<br />
<br />
To examine the current state and near future of the KDE Platform (kdelibs and kdebase-runtime), particularly as it relates to the growing usage of it in new contexts such as mobile or on Windows and MacOS and its traditional usage as a set of conveniences and consistency creators for KDE application development.<br />
<br />
The sprint will aim to create an actionable, multi-year roadmap for kdelibs and kdebase-runtime and will examine issues of modularity, topicality and the inherent dichotomy between the KDE Platform as an application development framework (similar to Qt) and as a stand-alone platform to target (similar to, e.g. Windows, MacOS, etc.)<br />
<br />
== Participants ==<br />
<br />
This sprint will aim to bring together developers who contribute to the KDE Platform directly, who use it in sophisticated applications, packagers of it and those involved in setting similar policies for Qt.<br />
<br />
The proposed break down of attendees:<br />
<br />
* 12-15 kdelibs and kdebase-runtime commiters<br />
* 3-5 KDE application developers<br />
* 2-3 packagers<br />
* 1-2 people from the KDE Release Team<br />
* 1-2 Qt representatives<br />
<br />
making for a total of 19-27 people.<br />
<br />
If you would like to attend, please record your name below. Date organization will occur at a later point.<br />
<br />
{| class="wikitable" border="1"<br />
!Name<br />
!Email<br />
!Role / Work<br />
!Arrival<br />
!Depart<br />
!Est. Cost<br />
!Need Sponsor?<br />
!Need Hotel?<br />
!Food Req.<br />
!Airport<br />
!Flights<br />
|-<br />
|Aaron&nbsp;Seigo<br />
|aseigo@kde.org<br />
|Meeting facilitation, libplasma<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|vegetarian<br />
|<br />
|<br />
|-<br />
|John Layt<br />
|john@layt.org<br />
|KLocale & co<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|<br />
|<br />
|<br />
|-<br />
|Marijn Kruisselbrink<br />
|mek@kogmbh.com<br />
|kdelibs mobile, meego packaging, koffice<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|vegetarian<br />
|<br />
|<br />
|-<br />
|Jeremy Whiting<br />
|jpwhiting@kde.org<br />
|knewstuff, accessibility<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|any<br />
|<br />
|<br />
|-<br />
|Thiago Macieira<br />
|thiago@kde.org<br />
|Qt, used to work in kdelibs<br />
|<br />
|<br />
|<br />
|no<br />
|no<br />
|any<br />
|<br />
|<br />
|-<br />
|Andreas Hartmetz<br />
|ahartmetz@gmail.com<br />
|kdelibs - mostly KIO and some kdeui<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|yes<br />
|<br />
|<br />
|-<br />
|Kevin Ottens<br />
|ervin@kde.org<br />
|KDE Platform+Frameworks modularity, interaction with Qt<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|no seafood<br />
|<br />
|<br />
|-<br />
|David Faure<br />
|faure@kde.org<br />
|kdelibs, interaction with Qt<br />
|<br />
|<br />
|<br />
|no<br />
|yes<br />
|<br />
|MRS/LYS<br />
|<br />
|-<br />
|Artur Souza<br />
|asouza@kde.org<br />
|KDE UI/Core + QML/JS<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|any<br />
|<br />
|<br />
|-<br />
|Dario Freddi<br />
|drf@kde.org<br />
|Authorization Framework, Solid, Possibly all things KCM*<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|any<br />
|LIN/BGY/MXP<br />
|<br />
|-<br />
|Alexander Neundorf<br />
|neundorf@kde.org<br />
|buildsystem (kdesupport +kdelibs +kdepimlibs +kdebaselibs) modularization<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|any<br />
|<br />
|<br />
|-<br />
|Raphael Kubo da Costa<br />
|kubito@gmail.com<br />
|Mostly kdecore and kio. KDE/Qt on FreeBSD.<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|any<br />
|<br />
|<br />
|-<br />
|George Kiagiadakis<br />
|kiagiadakis.george@gmail.com<br />
|drkonqi, small contributions to kdelibs, debian packaging<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|any<br />
|<br />
|<br />
|-<br />
|Olivier Goffart (not sure)<br />
|ogoffart@kde.org<br />
|Qt, former kdelibs contributor (port to Qt4, knotify)<br />
|<br />
|<br />
|<br />
|maybe<br />
|maybe<br />
|2500 kcal/day<br />
|<br />
|<br />
|-<br />
|Till Adam<br />
|adam@kde.org<br />
|kdepim, kdelibs, KDE/Mac, KDE/Windows, KDE/Maemo, KDE/WinCE, KDE/MeeGo<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|if you don't want it eaten, don't keep it around me<br />
|<br />
|<br />
|-<br />
|Sebastian Kügler<br />
|sebas@kde.org<br />
|release team<br />
|<br />
|<br />
|<br />
|probably<br />
|probably<br />
|omnivore<br />
|AMS<br />
|<br />
|-<br />
|Frederik Gladhorn<br />
|gladhorn@kde.org<br />
|Qt, knewstuff<br />
|<br />
|<br />
|<br />
|maybe<br />
|probably<br />
|any<br />
|Oslo<br />
|<br />
|-<br />
|Albert Astals Cid<br />
|aacid@kde.org<br />
|l10n, misc<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|almost any<br />
|Dublin<br />
|<br />
|-<br />
|Sune Vuorela<br />
|sune@vuorela.dk<br />
|Packaging and weirdness<br />
|<br />
|<br />
|<br />
|most likely<br />
|most likely<br />
|yes<br />
|cph; prefers train.<br />
|<br />
|-<br />
|Stephen Kelly<br />
|skelly@kde.org<br />
|kdelibs, modularisation, Qt interfacing<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|Anything but sushi<br />
|<br />
|<br />
|-<br />
|Volker Krause<br />
|vkrause@kde.org<br />
|kdepimlibs, kdepim, KDE on MeeGo/Maemo5/WinCE<br />
|<br />
|<br />
|<br />
|<br />
|yes<br />
|anything<br />
|TXL/SXF<br />
|<br />
|-<br />
|Ivan Čukić<br />
|ivan.cukic@kde.org<br />
|libplasma, activities<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|anything<br />
|<br />
|<br />
|-<br />
|Teo Mrnjavac<br />
|teo@kde.org<br />
|Social desktop<br />
|<br />
|<br />
|<br />
|yes please<br />
|yes<br />
|vegan<br />
|coming by car<br />
|<br />
|-<br />
|Marco Martin<br />
|mart@kde.org<br />
|libplasma, mobile profiles, activities<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|anything<br />
|<br />
|-<br />
|Cornelius Schumacher<br />
|schumacher@kde.org<br />
|Used to work on kdelibs, kdebase-runtime, and KDE PIM, these days mostly 3rd party applications. Would love to pitch the idea of merging Qt and the KDE platform to this group to trigger some productive discussion and some out-of-the box thinking<br />
|<br />
|<br />
|<br />
|maybe<br />
|yes<br />
|any<br />
|<br />
|<br />
|-<br />
|Valentin Rusu<br />
|kde@rusu.info<br />
|Authorization Framework, KCM*<br />
|<br />
|<br />
|<br />
|yes<br />
|yes<br />
|any<br />
|coming by car from Lyon<br />
|<br />
|-<br />
|Helio Castro<br />
|helio@kde.org<br />
|KDE Platform, integration, mobile<br />
|<br />
|<br />
|<br />
|no<br />
|yes<br />
|any<br />
|FLN<br />
|<br />
|}<br />
<br />
== Topics ==<br />
<br />
<br />
Note: these are simply sample topics, not final direction on what will actually be discussed. Actual topics will be generated at a pre-sprint meeting online as well as through group authorship of this section.<br />
<br />
=== Modularization of KDE libraries ===<br />
<br />
Alex: should IMO include not only kdelibs, but also kdesupport, kdepimlibs and kdebase libs<br />
<br />
=== Framework vs Platform ===<br />
<br />
=== Redundancies ===<br />
KLocale & co vs QLocale & co: How to act local everywhere while retaining configurability.<br />
<br />
=== Build Profiles ===<br />
<br />
=== Build system ===<br />
<br />
What level modularity do we want/need here ?<br />
Chances of CMake becoming the buildsystem for Qt.<br />
<br />
=== QML and Javascript ===<br />
<br />
== Logistics ==<br />
<br />
=== Dates ===<br />
<br />
Tentatively: June 1/2 - 6/7<br />
<br />
=== Location ===<br />
<br />
Tentatively: Randa, Switzerland<br />
<br />
=== Travel and Accommodations ===<br />
<br />
=== Food, Drink and Shopping ===</div>OpenIDUser14