Midori: Webkit Web browser

Consider Libpeas for addons

Reported by Alexander Wilms on 2013-06-29
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Midori
Wishlist
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: https://wiki.gnome.org/Vala/Gedit3PluginSample
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.

Benefits:
  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

Concerns:
    - 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
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
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers