A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins)
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #61
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #62
Posted 18 September 2011 - 13:02
-- "cfg" for all configuration files
Configuration files (if they are modified by the user's action) should be stored in /etc/enigma2/. They should be recognizable as belonging to a plugin though, so name them after your plugin.
The reason is that they automatically go into a settings backup. Don't want people to go hunting for all the things they need to backup in dozens of locations.
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #63
Posted 18 September 2011 - 13:55
-- "cfg" for all configuration files
Configuration files (if they are modified by the user's action) should be stored in /etc/enigma2/. They should be recognizable as belonging to a plugin though, so name them after your plugin.
The reason is that they automatically go into a settings backup. Don't want people to go hunting for all the things they need to backup in dozens of locations.
I don't agree. This is true for linux applications. But in my opinion plugins are only e2 additions that have to be independent to be easly installed or removed.
I don't like plugins that go out of their tree without reason.
But it is only an opinion. I understand that the post you quoted can cause misunderstanding, so forget it.
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #64
Posted 20 September 2011 - 18:56
I'm thinking about restructuring the plugins to individual bb files. That needs some work and some discussion.
Basicly the questions plnick came up with.
It seems to me that the plnick question was about to push in main repo.
But this seems to be not a problem if we will have write access to it.
About the idea to create individual .bb files and avoid DYNAMIC_PACKAGES i am not sure to have the skill to understand.
In my poor knowledge i was thinking that we can start using one .bb file only (enigma2-open-plugins.bb) and change later when/if we will have a better solution.
Or maybe there are other problems ?
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #65
Posted 20 September 2011 - 19:37
-merge plugins from different repositories into the shared repository
-pick a selection of plugins to be used in a certain image (or feed)
By using lots of stand-alone subdirs, we can probably make life easier, for developers and users.
(especially if every plugin/subdir would contain its own example bb file for instance, so everybody knows how to 'build' the plugin)
Looking at elitedvb for instance, where all plugins are built from a single shared makefile, imagine you would want to:
-leave out a certain plugin, because you already provide the functionality in your base image
You would have to apply a patch to the central makefile, to realise that
-add a certain file (e.g. customized default config or icon) to a plugin
You would have to write some custom code in the dynamic package grabbing code
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #66
Posted 20 September 2011 - 21:55
I like too the idea to add the example bb file for every plugin.
And this should be extremely logic and easy to implement in my experience using a single git for each plugin.
But how to do using a single git repository with stand-alone subdirs for each plugin ?
In this case if we use the git url in the source of bb file we will have for each plugin the process of the entire repository and source tree.
And this is not good.
Or am i wrong ?
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #67
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #68
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #69
Posted 20 September 2011 - 23:41
DM500,DM600,DM800HD,VU+ Duo
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #70
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #71
Posted 21 September 2011 - 10:04
another advantage for one-repos-per-plugin will be that we will get a nice incremental version per plugin.
Instead of one combined version for 100 plugins.
So when a new version is available, that actually means something has changed.
If you think this is the better solution it is ok for me.
Maybe we can setup a mailman mailing-list and use for each repo the "service hooks" email pointed to our ml to inform in real time all subscribers about all the commits.
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #72
Posted 21 September 2011 - 10:17
[lupomeo/testplugins] 16b036: Update readme
From:
noreply@github.com
To:
xxx@gmail.com
Data:
Today 11:00:26
Branch: refs/heads/master
Home: https://github.com/lupomeo/testplugins
Commit: 16b036b3ff59f0bf5d11a7c7116161628bdff3bc
https://github.com/l...16161628bdff3bc
Author: meo <xxx@gmail.com>
Date: 2011-09-21 (Wed, 21 Sep 2011)
Changed paths:
M README
Log Message:
-----------
Update readme
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #73
Posted 26 September 2011 - 14:09
I also agree with bacicciosat when he speak about define some "coding guidelines".
I've only one request. Some plugins (in my case i'm speaking about crossepg) already exist. Probabilly it doesn't follow the guidelines but change it now (when around internet there are many scripts/tools/guides) it may make many problems to the final user.
So, if possibile, i'm asking to do some exceptions about existings plugins. And apply the guidelines only with new plugins.
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #74
Posted 26 September 2011 - 14:10
I have tested now @github and it seems to work.
[lupomeo/testplugins] 16b036: Update readme
From:
noreply@github.com
To:
xxx@gmail.com
Data:
Today 11:00:26
Branch: refs/heads/master
Home: https://github.com/lupomeo/testplugins
Commit: 16b036b3ff59f0bf5d11a7c7116161628bdff3bc
https://github.com/l...16161628bdff3bc
Author: meo <xxx@gmail.com>
Date: 2011-09-21 (Wed, 21 Sep 2011)
Changed paths:
M README
Log Message:
-----------
Update readme
This is really usefull. I like it
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #75
Posted 26 September 2011 - 22:18
I've only one request. Some plugins (in my case i'm speaking about crossepg) already exist. Probabilly it doesn't follow the guidelines but change it now (when around internet there are many scripts/tools/guides) it may make many problems to the final user.
So, if possibile, i'm asking to do some exceptions about existings plugins. And apply the guidelines only with new plugins.
Dear skaman i think my post about guidelines was a stupid idea because everyone have his own style and opinion, so it is better to forget it.
Off course i was not talking about crossepg or other important plugins that need special configurations or background functions.
I am sorry for misunderstanding about that post.
But it seems to me that this project is not started and is going to lose interest.
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #76
Posted 26 September 2011 - 22:28
I've put 4 repo's online to get some feedback at https://github.com/Sjaaky
The idea is to start one repository for one plugin. For most plugins the easy to use distutils will be used. For more complicated plugins (which use extra standalone c binaries) autotools is used. There is 1 repository with all bitbake recipes. This can be used as an example and be copied into openembedded. Or be integrated into openembedded/recipes as a submodule.
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #77
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #78
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #79
Re: A suggestion: Common Public E2 Plugin Repository (E2 OpenPlugins) #80
Posted 27 September 2011 - 15:17
It seem ok ... good work
When organization E2 openplugins will be created i'm ready to move crossepg (i hope to find some tool to convert actual svn repo to git without loose commits descriptions).
For any kind of help with startup.. simply ask.. i'm here!
@bacicciosat
For ML with crossepg i used google groups. I created a group for crossepg where every user can register/unregister his mail. And from google code (actual home of crossepg) i setted the main mail of the group as diff recipient.
5 user(s) are reading this topic
0 members, 5 guests, 0 anonymous users