Skip to main content ↑ ↓
Topic: What's the plan with extension (Read 4444 times)

What's the plan with extension

There are some pros and some cons with extensions. In order to know if Otter's extensions will do it the good way or bad way it would be nice to see what the plan is. Is the plan to make Otter compatible with Chrome's extensions or will it be something more? Something less?


The Pro Side

- Extended functionality of the application
- More contributors to the application development, provided that the API's are easy enough to get

These pros are dubious in my opinion. Extensions don't really improve the application itself. The application has its own extensibility and the extensibility has to be decently documented, so the extension authors know how to do it.


The Con Side

- Breakage of the application when extensions are too intrusive
- Breakage of extensions at application updates

The application has to protect itself from too intrusive extensions. For example I don't like in Seamonkey/FF how a new extension may add its own menu item or button, instead of just showing up in about:addons and doing its thing thing.

The functionality of menu items and buttons should be left for the user to tweak and configure. Then I know that there are many Seamonkey/FF extensions that do just that - add a menu item or a button. This is intrusive. Users should be able to combine the available actions themselves in menu items and buttons, just like it was in Opera. Extensions should change the webpage elements or connect the browser to external applications. Or should it do something more? 

Actions related to keybinds, menu items and buttons are configured in the config files. When I have gone to great lengths to configure the application behaviour this way, I don't want an extension - or an update - to ruin this.

And then there's how extensions break when the application is updated. Just now I updated Seamonkey and again the GTK theme (an extension) gets disabled. Just plain annoying.

So, what's the plan?

Re: What's the plan with extension

Reply #1 –
@ersi, the plan was briefly described in own ticket:
https://github.com/OtterBrowser/otter-browser/issues/42#issuecomment-72354703

I also don't like that approach where extensions tend to litter menus or toolbars, this is why we decided to go for scriptlets first, which can be seen as evolution of idea of custom buttons, but using APIs compatible with Chromium (being gradually implemented on our side, with some custom additions when needed, placed in our namespace) and making them more powerful by tearing them like built-in actions.
Once defined these could be placed on toolbars, menus (global and context), triggered by gestures and keyboard shortcuts.

BTW, I don't like to share such details too early, as with our development speed and low marketing power some  other projects might get these features earlier than we. ;-)
Nadszedł już czas, najwyższy czas, nienawiść zniszczyć w sobie.
The time has come, the high time, to destroy hatred in oneself.

Re: What's the plan with extension

Reply #2 –
Thanks for the answer :) From ticket 42:

Quote
Each snippet will behave like actions right now, it will be possible to trigger it by shortcut, add to some menu or place as button on toolbar (although these two uses will require support for events which would allow to properly update their UI state, like icon or title).


So, you will start by implementing snippets in unknown language for something that worked in Opera's INI syntax out of the box. I remember we have discussed it before, but look again:

Otter INI
Code: [Select]

[Reload]
shortcuts=F5

[Stop]
shortcuts=Ctrl+.

[ReloadOrStop]
shortcuts=Ctrl+R


Opera INI
Code: [Select]

F5			= Reload
. ctrl			= Stop 
r ctrl			= Stop | Reload


See the simple but crucial difference? In Otter's syntax it's impossible to combine and sequence the actions, while in Opera's syntax it's intuitively present. This easy customisation is a feature that power users badly want and was easily achieved in Opera without any extensions. With the right choice of syntax, this ability would already be in Otter.

I never understood why you picked a different syntax for Otter. For every simple additional thing you have to create a new action and you can never combine and sequence them. In Otter it's impossible to even write simple toggles, to have a keypress to do something and the same keypress to undo it again. To Reload and Stop you have to have another action, while in Opera's INI everybody can think of Stop | Reload

Anyway, I hope the language for snippets will make sense and become usable.

Re: What's the plan with extension

Reply #3 –
@ersi, it's not an unknown language, it's JavaScript/ECMAScript using extension APIs. ;-)

Quote from: ersi – on
See the simple but crucial difference? In Otter's syntax it's impossible to combine and sequence the actions, while in Opera's syntax it's intuitively present.


It is possible to use this syntax that way (for example using some separator to group action identifiers in sections of INI file), but that is something invented and not flexible enough.
Nadszedł już czas, najwyższy czas, nienawiść zniszczyć w sobie.
The time has come, the high time, to destroy hatred in oneself.

Re: What's the plan with extension

Reply #4 –
Javascript is a very obscure language. It has a totally impenetrable syntax and is therefore extremely error-prone. I have been looking at it for at least a decade, but I still cannot create anything in it.

All I want is to sequence actions. Logically, all I should need for it is to know the names for the actions and how to connect them. In addition to the action names I should only need to know how to write "and" and "or". In Opera's INI these were & and | and everything worked seamlessly. Extremely simple and powerful, and the mistakes I could make were easily found and corrected.

In Javascript I have to write many completely unrelated things before I get to what I actually want to do. For example can you tell me how to write a keybind to toggle Stop and Reload? I have absolutely no idea how to do it, but I know that it involves several lines of nested JS-specific arguments, including meaningless brackets that have to be precise, otherwise the JS will not work. And somewhere in there perhaps I need to write Stop and Reload too, but I am not so sure of that. Compared to the INI examples above, JS is unnecessarily complicated and dangerously clumsy.

In INI, to write Stop and/or Reload, all I need to know is Stop and/or Reload. This is very easy and makes perfect sense. In JS I never know what I need to type, and when I try to find out what to type, the instructions don't make any sense.


Anyway, here's what I hope from those snippets/scriptlets.


  • Ability to write menu items, buttons and other things, such as sliders, fields, status items, checkmarks, toggles, and dialogues using the action names.

  • Ability to sequence and combine actions in keybinds, mouse gestures, and mouse buttons configuration, using the action names, key labels and mouse button numbers.

  • Ability to use everything mentioned in about:config using the names that occur in about:config, to use it for everything listed above - menus, buttons, dialogues, keybinds, mouse gestures, etc.

  • Ability to identify webpage elements (using the HTML names of the elements, e.g. h1, table, link rel, etc.) and do stuff with them, to use them for buttons and menus dynamically.

  • Ability to generate dynamic menus, e.g. an "Open with..." list so that it would be relevant to my own system. And the list items should work of course too.

  • Ability to connect to external programs. For example when I want to open a webpage textarea or a Notes item in an external editor, I should be able to do it.

  • The scriptlets should work even when JS is turned off. (This is where it's clearly evident that macros to simply sequence the available actions would be more secure.)

  • Common-sense location for the scriplets. The scriptlets that configure toolbars should sit in toolbars folder. Keyboard scriptlets in keyboard folder. Dialogue configuration should also have its own folder where to put the JSOn. And the scriptlets that configure webpage behaviour and do other things should be in the scriptlets folder.

  • Hopefully you will eventually implement native toggles to turn off and on ALL interface elements, e.g. scrollbars in fullscreen. If not, maybe scriptlets should do it, but this would be intrusive. Ability to add/remove interface things should be native, available in options dialogue and config files.



I am sure I am overlooking something, but this only because JS is indeed too obscure and unnecessarily complicated. It's an obstacle to straightforward thinking.

Re: What's the plan with extension

Reply #5 –
@ersi, most of that stuff belongs to extensions, scriptlets are supposed to be more like actions are, so stuff like adding them to menus and setting shortcuts would be done the same way as for actions.
Nadszedł już czas, najwyższy czas, nienawiść zniszczyć w sobie.
The time has come, the high time, to destroy hatred in oneself.

Re: What's the plan with extension

Reply #6 –
Quote from: Emdek – on

@ersi, most of that stuff belongs to extensions, scriptlets are supposed to be more like actions are, so stuff like adding them to menus and setting shortcuts would be done the same way as for actions.

I thought this was precisely what I was saying :) The scriptlets must be able to combine actions, to sequence and serialise them.

When I speak about generating a menu, I mean the menu should be ready-made in Otter, and there should be an action that has access to that menu, and the action should be possible to use in scriptlets, so that the menu could be put anywhere as a menu section, submenu, or button, and accessed via keybind or mouse gesture. As an example, Opera's Internal panels was the list of activated panel items. The list was in-built in Opera, not part of an extension or such, and the action Internal panels was the means to access the menu and use it in INI files.

When I speak about connecting to external program, I mean there should again be a simple single line of documented code that the user would be able to use in INI (or JSON) files. For example in Opera the kind of action I am talking about was Execute program. And for example in DWB I can

  • Open textareas in external editor by typing into the right place xterm -e nano dwb_uri

  • Define an external downloader by typing into the right place xterm -e wget dwb_uri -O

In this example, "the right place" must obviously be part of Otter, not part of the extension or scriptlet. And the equivalent of dwb_uri also has to be a documented part of Otter.

And I remembered one more aspect regarding Opera's buttons/menus/keybind/mouse-gesture configs that made it awesome: shareability. It was possible to type a definition for a button into a webpage, announce to other users that you have an awesome button on your website, so that other users could come to give it a click and try.

Menu config could be zipped to a file so that other users could download it. Opera would recognise it and add it to the list of "setups" so that the user could switch to it to try it and switch away from it when got tired of it. Same with keybinds.

When Otter could implement this, a compact geek cult following would be guaranteed forever.