Talk:FSO

From Openmoko

(Difference between revisions)
Jump to: navigation, search
m
m
Line 13: Line 13:
  
 
*[[User:Mickey|Mickey]]: Akonadi seems '''huge'''. It uses kdelibs, tries to integrate a lot (much more than we need) and I don't see any sign of a dbus API.
 
*[[User:Mickey|Mickey]]: Akonadi seems '''huge'''. It uses kdelibs, tries to integrate a lot (much more than we need) and I don't see any sign of a dbus API.
 +
 +
==== Using PolicyKit for the usage daemon ====
 +
 +
PolicyKit concerns authorisation of priviledged actions requested by an unprivileged user. This is independant of the actual functionality and APIs. Using PolicyKit may make sense later, when the functionality has been finished.

Revision as of 13:19, 9 May 2008

Sin: Would unified theming (something like qtcurve) belong here? How about another high-level service, a web browser element (webkit) that can be used from any application?

  • Mickey: Unified theming is an application level thing, the framework has no idea about UI. To put it to the extreme, the framework services should allow you to write a feature phone UI in ncurses, if you want :) Same goes for web browsing, while being super important nowadays, this is clearly application level framework, not services level.
    • Sin: So the framework will be used to make a user environment that could provide a native theme to Qt, GTK and EWL/ETK? I'm a bit worried about consistency of the UI since any toolkit can and will be used (which is great btw). As for the browser thing, it seems quite similar to the situation of telephony or PIM to me.

Elektrolott: How about using Akonadi?

Akonadi - The PIM Storage Service
Mission Statement
We intend to design an extensible cross-desktop storage service for PIM data and meta data
providing concurrent read,  write, and query access.
It will provide unique desktop wide object identification and retrieval.
  • Mickey: Akonadi seems huge. It uses kdelibs, tries to integrate a lot (much more than we need) and I don't see any sign of a dbus API.

Using PolicyKit for the usage daemon

PolicyKit concerns authorisation of priviledged actions requested by an unprivileged user. This is independant of the actual functionality and APIs. Using PolicyKit may make sense later, when the functionality has been finished.

Personal tools

Sin: Would unified theming (something like qtcurve) belong here? How about another high-level service, a web browser element (webkit) that can be used from any application?

  • Mickey: Unified theming is an application level thing, the framework has no idea about UI. To put it to the extreme, the framework services should allow you to write a feature phone UI in ncurses, if you want :) Same goes for web browsing, while being super important nowadays, this is clearly application level framework, not services level.
    • Sin: So the framework will be used to make a user environment that could provide a native theme to Qt, GTK and EWL/ETK? I'm a bit worried about consistency of the UI since any toolkit can and will be used (which is great btw). As for the browser thing, it seems quite similar to the situation of telephony or PIM to me.

Elektrolott: How about using Akonadi?

Akonadi - The PIM Storage Service
Mission Statement
We intend to design an extensible cross-desktop storage service for PIM data and meta data
providing concurrent read,  write, and query access.
It will provide unique desktop wide object identification and retrieval.
  • Mickey: Akonadi seems huge. It uses kdelibs, tries to integrate a lot (much more than we need) and I don't see any sign of a dbus API.