Review of attachment 198644 [details] [review]:

Thanks for your patch, it's quite interesting but could you use the autotools backend instead of the directory backend?

As it's written in javascript, there is no compilation step so there is few differences but installation and translation should work by example. I have looked at gnome-shell-extentions repository here (http://git.gnome.org/browse/gnome-shell-extensions/) and it is using autotools, you can use it as an example. I'm not completely sure that the autotools backend will get all source files correctly but if it doesn't I will fix the backend, I think this could be done for the next version.

Created attachment 198835 [details] [review]
Add template for Gnome Shell extensions.

I've modified it to work with autotools the best I could.  I don't know if I've violated the rules or not by overriding the default prefix to be ~/.local/share/gnome-shell/extensions (I don't know where global extensions are allowed to install...).  

My current concern is that this setup makes it somewhat un-intuitive to change the UUID of your extension after it is created, since it needs to be changed in the makefile and metadata.json.  I guess we could try and dynamically generate metadata.json like gnome-shell-extensions, but my autoconf skills are insufficient...

It would also be nice to have some place to suggest that while developing, one can symbolic link src/ to .local/share/gnome-shell/extensions/[+UUID+].  I think such a comment would be helpful to new devs.  Is there an appropriate place to put such a comment?  Should the template come with a HACKING file with this info by default?

Review of attachment 198835 [details] [review]:

Your patch is good but I would like to make two changes.

I would like to keep only the project name and use it as plugin name to limit the number of entries in the project wizard.

I would prefer to merge the option and the meta page. It's done like this in most other project wizard and I'm trying to limit the number of page. The second page is necessary because it uses some data from the first one. 

Do you agree with both changes? If yes I can do the changes myself or send me an updated patch. If no could you explain why?

(In reply to comment #3)
> I've modified it to work with autotools the best I could.  I don't know if I've
> violated the rules or not by overriding the default prefix to be
> ~/.local/share/gnome-shell/extensions (I don't know where global extensions are
> allowed to install...).  

I think it would be better to keep the prefix as it is and just install your data in $(datadir)/gnome-shell/extensions, as it's done in gnome-shell extension.


> My current concern is that this setup makes it somewhat un-intuitive to change
> the UUID of your extension after it is created, since it needs to be changed in
> the makefile and metadata.json.  I guess we could try and dynamically generate
> metadata.json like gnome-shell-extensions, but my autoconf skills are
> insufficient...

Well, I'm not sure it's better because we need to regenerate the metadata.json so the build will be a bit more complex. But if you think it's better I will take care of this.


> It would also be nice to have some place to suggest that while developing, one
> can symbolic link src/ to .local/share/gnome-shell/extensions/[+UUID+].  I
> think such a comment would be helpful to new devs.  Is there an appropriate
> place to put such a comment?  Should the template come with a HACKING file
> with this info by default?

Yes, I think it's a good idea to add a HACKING file.


There is another thing that looks a bit difficult to setup for a new user, it is the compatibility list. It is a list of version separated by commas but in fact, it is a list of quoted version separated by comma and surrounded by square bracket. I think it's not completely obvious but I don't know how do handle this in a better way.


One last missing thing is a nice icon for the project wizard, I think the current terminal icon is not the best one. But I haven't found a icon representing GNOME shell. If you find an icon it would be nice else perhaps I can try to do something here.

>I would like to keep only the project name and use it as plugin name to limit
>the number of entries in the project wizard.

That seems OK, although it will restrict plugin names to be names that don't contain spaces.

>I would prefer to merge the option and the meta page. It's done like this in
>most other project wizard and I'm trying to limit the number of page. The
>second page is necessary because it uses some data from the first one. 

Metadata and Project Options on the same page is a good idea.

>There is another thing that looks a bit difficult to setup for a new user, it
>is the compatibility list. It is a list of version separated by commas but in
>fact, it is a list of quoted version separated by comma and surrounded by
>square bracket. I think it's not completely obvious but I don't know how do
>handle this in a better way.

I am sure that a scheme macro in the template file could easily parse a comma separated list and add quotes around it.  Unfortunately string in scheme is not something I am good at...

>One last missing thing is a nice icon for the project wizard, I think the
>current terminal icon is not the best one. But I haven't found a icon
>representing GNOME shell. If you find an icon it would be nice else perhaps I
>can try to do something here.

Very good point.  There doesn't seem to be an established icon for gnome-shell.  Perhaps http://www.gnome.org/wp-content/uploads/2011/04/video_accessing-apps-quickly-thumb.png  as an icon.  Or maybe it would be better just to go with the gnome foot...

I have committed your patch and implement all the changes discussed above:
- Merge plugin and project name (I have create a new kind of restriction to allow space in project name)
- Merge metadata and project options page
- Add some schema code to automatically add quote and square bracket to version list
- Add a standard GNOME foot icon.

Thanks for your work.