Plugin manager for EG

[kgschlosser]

awesome thing about the plugin being able to be installed on the fly. and as fr as updating all you should need do is replace the files and run a reload on the sys.modules for the plugin. or i think doing a re scan of all of the plugins will also force an update.

I do have a question though. have you put any thought into just running the plugins directly from the .egplugin file and having python add the .pyc files to the zip. or a temp directory

doing this package manager could really change how EG deals with plugins. and in a really good way. because the need for the eg.RegisterPlugin could go bye bye. because all of the information that would be needed to register the plugin would now be located in the info.py file. this would be a much better way instead of having EG load every single plugin and generate every single plugin icon at run time. in the altered version of eg i made i changed how it loads the icons because of the massive number of conversions it slowed my plugin scan time from .1 seconds to 1.5 seconds. and i am on an extremely fast computer. so that's one hell of a performance hit. but i really don't see the need to have EG load all of that data if it's not even being used. I don't remember if during the scan is when it actually sets the sys.modules for the plugin or not or if it's only on installation. but by using the .egplugin file this would be a much better way any way you look at it.

i do like it dynamically loading things as they are used and not at run time. for instance the context menus. not everyone does do a right click on items. so if they don't use it why have it loaded. i don't even know why the plugins are even scanned when you start EG. it really only needs to be done when you want to bring up the plugin dialog.

[topix]

I do have a question though. have you put any thought into just running the plugins directly from the .egplugin file and having python add the .pyc files to the zip. or a temp directory

No, i didn't. What would be the benefits of that? And what if a plugin has additional files it need to access?

[kgschlosser]

it all works fine the way EG has python all zipped up and it causes no issues. the benefit would be that when the pluginmanager scans plugins, it doesn't actually have to load the plugin. it only has to open the zip and read the info.py. none of the craziness of it having to raise an exception after the call of the eg.RegisterPlugin. and it would only need to load whatever data it needs at any given point. for instance. currently it loads all the data for every single plugin that is in the plugins directory. at load time. whether or not it's actually installed. when the only thing that uses that data is one dialog. the add plugin dialog. and how often do you go into that in all honesty? so does that information need to be in memory and do all the plugins have to be loaded even tho they are not technically installed??. not really. just a way to trim some proverbial fat. and it is also a much better way of handling the plugins in general. and it keeps the plugin folder nice and tidy instead of having nested folders. and i would imagine it would make the install and upgrade of a plugin easier. only one file to deal with. the big reason why i mention this is because of all of 1080P and higher monitors today a 16x16 doesn't really cut it. and bumping the size up to something viewable on that resolution which is between 32x32 and 64x64 is a huge performance hit with manipulating the thing but also has a pretty decent memory impact as well.

[dequi]

making some headway on a plugin database from all plugins on the forum viewtopic.php?f=5&t=7382&p=43567#p43567

so if I get it correctly the plugin manager will use only the .egplugin version of the plugin (there are not many out there)

• sign in as a plugin developer or register
• manage your plugins or upload a new .egplugin
• info gets extracted from the .egplugin into a database

The manager will then use this database to serve the .egplugin files to the eventghost clients?
should it be possible for users to browse this plugin database like: plugins.eventghost.net? just like the google play store with a link : "click here to install this plugin"?

[topix]

making some headway on a plugin database from all plugins on the forum viewtopic.php?f=5&t=7382&p=43567#p43567

so if I get it correctly the plugin manager will use only the .egplugin version of the plugin (there are not many out there)

Yes, but every plugin can be exported to .egplugin (even with latest 0.4).

• sign in as a plugin developer or register
• manage your plugins or upload a new .egplugin
• info gets extracted from the .egplugin into a database

The manager will then use this database to serve the .egplugin files to the eventghost clients?

Yes, that's the way i thought of. I even found an interesting extension for phpBB: A download addon with sections, new files for download can/must be approved and even automatic thread creation for issues/support. (see it in action)

should it be possible for users to browse this plugin database like: plugins.eventghost.net? just like the google play store with a link : "click here to install this plugin"?

If possible, yes, why not. IMO would be plus for the user experience.

[dequi]

OK here it goes...

at this point I have a php script that can run a directory of .egplugin files, extract the available data and put it in a javascript array stored in a .js file
at this point you can use jquery and https://datatables.net/ to create a browsable and searchable repository hosted at GitHub for example
have a look at https://dequi.github.io/test/ and search for Pako's plugins or for the weather plugin
if you choose download and open it shows the install plugin dialog box (if you have eventghost installed and have it running)

check source at: http://github.com/dequi/dequi.github.io

current issues with this setup are:

• in the .egplugin file you don't have any reference to where the source is located, I'd like that in the list
• no indication of what type the plugin is: program;external;remote;other
• the help argument is tacked onto the description and so the description gets large (now cleaned and trimmed to 100 characters)

[topix]

looks promising :thumbs-up:

if you choose download and open it shows the install plugin dialog box (if you have eventghost installed and have it running)

With latest 0.5 EG doesn't need to be running, just choose "open with...".

in the .egplugin file you don't have any reference to where the source is located, I'd like that in the list

me too (can be added to info.py in new betas [but needs to be filled by authors])

no indication of what type the plugin is: program;external;remote;other

In the info.py there should be kind=.

[dequi]

With latest 0.5 EG doesn't need to be running, just choose "open with...".

... it' very much browser dependent in Vivaldi I get the option to Open, Chome just downloads it, Internet Explorer even renames to .zip
but this is not the problem I'm currently trying to solve

me too (can be added to info.py in new betas [but needs to be filled by authors])

that would be nice. also try to separate the description and the help text. The help could be then located in in a popup or something

In the info.py there should be kind

have not seen it, checked multiple by hand. I'll check again tomorrow.

[topix]

... it' very much browser dependent

Uh, ok, only using Firefox, so didn't noticed that.

have not seen it, checked multiple by hand. I'll check again tomorrow.

No need to check again. It's not in there, only in my version. Sorry, my fault.

that would be nice. also try to separate the description and the help text.

I will look into that, but it has to wait a few days (could be a week).

[kgschlosser]

hey I have a means to get all of the plugins that have been put into the forum. as attachments. i have the database as a text file. and the files are actually stored as files. but they have been renamed. i have to make up a python script to parse the database file to filter out anything that is not a zip, rar, or __init__.py and have it grab the description from the same database file to make a directory by that name and put the file in it... i will have to do some weeding out but i should have a complete list by tomorrow. possibly even tonight. i am going to hop to it writing that code

[kgschlosser]

well it's doing it's thing. and it's converting all of the plugins to .egplugin as well

it's going to be running for a while. the easiest way was for me to beat the snot outta the web server and i am sure there will be a laundry list of ones that didn't convert properly.

it is making an egplugin file for each version that is attached... gonna take a long while


forgot to mention. there are 3900 ish file attachments it has to sift through

[kgschlosser]

doah! stupid error i didn't handle.

here are the stats so far

attachments scanned - 1586
attachments that are rar files - 34
attachments that have been converted to egplugin files - 346
attachments that did not get sucessfully converted - 209
HTTP errors - 21

now i am only looking for files that end with .py .zip and .rar so all the rest are just counted and then passed by

[kgschlosser]

ok so the final tally is in

number of attachments - 3902
number of rar files - 49
number of plugins converted - 777
number of errors - 40


lucky number 7's


w00t

now who needs all this data???

[pearbear]

What about licensing issues? Luckily many of the plugins have the standard EventGhost GPL v2 but the 3rd one I checked was all rights reserved so any use of that plugin is a copyright violation. My quick survey indicates this might be a problem with a significant number of plugins. I think most plugin authors have created them in the spirit of free open source but I've seen that assumption backfire terribly in the past. It's possible that some plugin authors would be upset if their plugin files are added to the manager without their permission. I think it would be a different situation if the plugin files were left in their current location and the URL to that file was saved in the database but there are issues with that due to different packaging of the plugin files.

[kgschlosser]

well if that is the case...

point 1... the plugin should not be housed on the eventghost servers for free mind you for the purpose of private gain. and without the express permission of the EventGhost Administrator(s)
point 2... we can look in the plugin file and if there is a GNU header then it's fair game...
point 3... if you have it so that it can be downloaded for free then that is the same thing as getting it from a plugin manager... it's still downloading it for free...

this is how i see the facts... if someone wants to add to it. or disagree with it. then fore away..

because the plugin is being posted in the manager with proper identification of who made the plugin there shouldn't be any kind of issue.

and if someone does have an issue then they will state they do have it.. and the plugin can be very easily removed.