Consider Libpeas for addons

Bug #1196002 reported by 982c80311320c1b on 2013-06-29
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Midori Web Browser
Fix Released
Christian Dywan

Bug Description

I think kalikiana aleady mentioned this on IRC

Related branches

tags: added: extensions
Changed in midori:
assignee: nobody → Christian Dywan (kalikiana)
milestone: none → 0.5.6
Christian Dywan (kalikiana) wrote :

Recommended reading:
I just realized a ton of problems we're facing would be solved by moving to libPeas and it's actually not painful because we're not forced to port everything at once. So it's not a goodie, but we can avoid re-inventing a number of wheels here.

  Support external extensions
  Separate interfaces for Midori.View/ Browser/ App/ Completion/ SpeedDial
    - The core would provide entry points; extensions no longer need to manually connect to all signals and manage lifetime of objects, a huge source for bugs at the moment
    - The same interfaces can be used internally to make
    - Support external/ third-party extensions first class, with a libmidori etc.
    - Allow other languages to be used, such as Javascript and Python
    - Based on the previous two assumptions, a website for extensions à la Firefox would become feasible
    - include WebKit2 WebExtension support in the new API

    - extension_init can remain the existing entry point; the new API would use peas_register_types (see example above)
    - we have no final concept for WebKit2 yet - this is a good chance to introduce it

André Stösel (ivaldi) on 2013-08-03
Changed in midori:
importance: Undecided → Wishlist
status: New → Confirmed
gue5t gue5t (gue5t) wrote :

+1 if we can rearchitect extensions to do things like "once per tab: foo()" rather than having. I recall having worked on a "base extension" but it took the opposite approach of trying to build hooks from our current "you get signals and the public functions" rather than the guts of midori having hooks built in, and my attempts ended up complex and ugly. It would also be nice to see people able to use other languages for extensions--though I prefer /running/ things in Vala or C because of runtime efficiency, Javascript or Python support will likely lead to extensions that would never have been written otherwise.

The only concern I have w/r/t the new architecture is versioning and updates for third-party extensions. By shipping almost all extensions with Midori at present we have a lot of wins via relying on the system package manager--but if we begin supporting external/third-party extensions in a more meaningful way it becomes more important to think about versioning, updates, etc. for those extensions.

Christian Dywan (kalikiana) wrote :

With cmake (bug 1211909) having landed I'll soon push a branch to enable libpeas. See bug 1211899 with regard to stricter versioning of the API.

tags: added: libpeas
Donte Greene (flykidd) on 2013-09-28
Changed in midori:
status: Confirmed → In Progress
Changed in midori:
milestone: 0.5.6 → 0.5.7
Changed in midori:
milestone: 0.5.7 → garage
Changed in midori:
importance: Wishlist → High
milestone: garage → 0.6.0
Christian Dywan (kalikiana) wrote :

People seem to be very excited by bringing in libpeas with WebKit2 support, which would save us some porting hassles if we can avoid ever introducing custom API for that, so I'm looking into that now.

Changed in midori:
milestone: 0.6.0 → 0.5.12
Changed in midori:
milestone: 0.5.12 → 0.6.0
Christian Dywan (kalikiana) wrote :

Peas plugins for the GUI, web process and even Private Browsing working in the latest stable version.

Changed in midori:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers