Projects/Mobile/Meetings/Akademy2010: Difference between revisions
| Line 63: | Line 63: | ||
* runtime time deps within the platform (plugins, dbus services) | * runtime time deps within the platform (plugins, dbus services) | ||
** creating the data, have the list of runtime bits, which ones do we need? | ** '''creating the data''', have the list of runtime bits, which ones do we need? | ||
** profiles should include runtime | ** profiles should include runtime | ||
** most cases are easy: associate a lib with its runtime | ** most cases are easy: associate a lib with its runtime | ||
| Line 71: | Line 71: | ||
** refactoring | ** refactoring | ||
** changed at runtime (QUiTools? platform plugin for KIO?) | ** changed at runtime (QUiTools? platform plugin for KIO?) | ||
** creating the data, we very likely have more than KIO | ** '''creating the data''', we very likely have more than KIO | ||
=== Packaging! === | === Packaging! === | ||
Revision as of 21:49, 6 July 2010
When? Where?
- Tuesday, July 6th, 16:00-18:00
- Akademy 2010, Demola, Area 4
Attendees
In alphabetical order, these are the people expected to attend the KDE Platform Mobile BoF at Akademy 2010:
- Kevin Ottens
- Boudewijn Rempt
- Artur Souza
Minutes
Definition: KDE Platform == kdesupport + kdelibs + kdebase-runtime
KDE as a guest not as the workspace
- Interacting with "foreign" components
- Tracker
- MeeGo Touch framework
- Notification service
- harvesting PIM data from the device
- solid with whatever there
- pulseaudio
- geoclue
- (Harmattan) kdeinit like trick
- kwallet
- (platform security / DRM)
- Not enforcing our settings
- Style (already fixed? check it!)
- Proxy/SSL/Network settings (let's Qt do it when possible)
Constraining the platform
- profiling, priorities: startup time, battery time <= easy!, memory profiling <= hard!
- timechart to log activity (Helio)
- for the rest ask Lubos ;)
- network bandwidth (not me)
- usual tools (wireshark, tcpdump...)
- ksycoca (David, packaging side: Dirk, Sune)
- Rejected solution (at least for now)
- libkok, hackish, shipping premade cache in the package
- rely on Qt? for a "system cache"
- Preferred solution
- running kbuildsycoca on install using package facilities, automatic behavior can be disabled (means kbuildsycoca enters with kdecore)
- remove user settings from sycoca?
- split the sycoca base? (mimetypes definitely)
- kbuildsycoca4 got profiled, some hashing function misbehaving? Thiago to the rescue
- Rejected solution (at least for now)
- total disk size (whole list of .so to run)
- remove anything marked deprecated
- icons, do we need to ship them? probably not!
- packagers should split
- spare the plugins for cryptic formats (packaging again)
- translations bringing only the right ones (package management service)
- shared libs deps within the platform
- hard cuts for integration features (transitional)
- "soft linking"
- profiles would be the list of what is built/install ("tested combinations", shouldn't overlap)
- runtime time deps within the platform (plugins, dbus services)
- creating the data, have the list of runtime bits, which ones do we need?
- profiles should include runtime
- most cases are easy: associate a lib with its runtime
- runtime needed only for scripts: goes in an extras profile
- GUI contained in the platform
- refactoring
- changed at runtime (QUiTools? platform plugin for KIO?)
- creating the data, we very likely have more than KIO
Packaging!
- Dealing with outdated, pushing newer versions of deps
- Influencing before release: take latest, greatest
- Need overview on their release process
- Not depend on the features of newest versions, longer support for older Qt versions for instance
- Splitting the packages (see with volker current state for kontact mobile)
- kontact mobile: kdelibs 1 lib == 1 package, kdebase-runtime around 20 packages, kdepimlibs 1 lib == 1 package, etc.
- Communicate about the profiles, reunite packaging efforts based on that
Target platforms
- MeeGo
- WinCE 6.5
- Anything running on high-end phones and bigger