[GSOC 2013] Easy plugins with a website

Bhaskar Kandiyal bkandiyal at gmail.com
Sat Apr 13 14:46:58 EDT 2013


On Saturday 13 April 2013 06:23 PM, Tomasz Wasilczyk wrote:
> 2013/4/13 Bhaskar Kandiyal <bkandiyal at gmail.com>:
>> I have created a few mockups [1] for the plugins window and I'm hoping
>> for some feedback on them. Here's a short description:
> 
> I think, these mockups shows too simple interface, which have less
> functionality than the current one (there is no details for selected
> plugin).

My apologies, I should have mentioned that these are just the rough
mockups. As for the details of selected plugins, I wanted to make each
plugin item of the list an expander-like view that would expand on click
and show the details (similar to the current one where the user has to
explicitly show the plugin details expander), but I couldn't find any
widget like this in Pencil (the UI design tool I used), so I left it
like this :P

> I will try to provide some mockups later, to show how it should look
> in my opinion.
> 

That would be great :)

>> * Get New Plugins Tab: Here we have two options, either we download a
>> list of available plugins and show them in a list view or open up the
>> plugins website in a web view and handle the (pidgin:// ?) protocol for
>> installing new plugins. The mockup currently shows a list view.
> 
> I think embedding gtkwebview will be more flexible. I also think,
> there is no need for registering pidgin:// handle - there could be
> just hardcoded url prefix for installable plugins.

+1 for gtkwebview. As for the pidgin:// handler, I think if we need the
functionality of installing plugins from, say, Firefox or Chromium etc.
then we need to have a handler, but if that functionality is not needed
then it would be good to have hardcoded url prefixes.

>> * Support for uploading new versions of the plugin
> 
> Support for autoupdate/checking for updates would also be handy here.
> 
Yes, I'm planning to add an autoupdate for plugins as well.

Also, we would require a specific format for the plugins, maybe a zip
file with some metadata that would identify the plugin's version etc.
Any ideas on this?

PS: I'm planning a bit ahead here, but is there any specific server-side
language that you would want me to develop the plugins website in? I'm
pretty familiar with PHP+MySQL, Python and basics of Ruby but I don't
have any problems if we decide to use a CMS.

Cheers,
Bhaskar Kandiyal




More information about the Devel mailing list