Projects/Mobile/Meetings/Akademy2010

    From KDE TechBase
    Revision as of 12:23, 16 July 2010 by Svuorela (talk | contribs)
    (diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

    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 (Kevin for IMAP)
      • 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
    • 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 (Kevin)
      • 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 (David, Kevin)
      • 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


    Afterthoughts

    Other issues that people thought about after the meeting, but wasn't actually discussed there.

    KDE as a guest

    • Kill kded, knotify and kdeinit after last kde app exiting. This existed with dcop back in kde3 days.