EventGhost

Posted: **Thu Nov 17, 2016 10:45 pm**

Sem;colon wrote:You know what the problem with the wiki was/is? No one has access to it!

Exactly, and that's why I'm very excited about the work dequi is doing. However, if the wiki content is moved to a GitHub repository anyone can submit a pull request but if nobody with the privileges to merge the pull request bothers to do so then it's not going to be much of an improvement over the current system. If there is someone actively managing the website repository then it will work fine but if you take the EventGhost application repository as an example you'll see we can't just take for granted that there will always be someone willing to do this and even if there is someone willing that won't help if nobody will give them administrative rights over the repository. So if it is going that direction I think there should be some sort of a plan in place for managing the repository. This is why I've been asking that the alternative of a true wiki that can be freely edited by anyone be considered as an option. I noticed that dequi did create a wiki in the EventGhost/EventGhost repository today: https://github.com/EventGhost/EventGhost/wiki. dequi, what are your intentions for that wiki?

Sem;colon wrote:I can only speak for me of course, but if there was a centralized place to put/list plugins I would so going to use it. (If I have the possibility to, of course)

There is one already, the Plugin Support section of the forum. Unfortunately it's a big mess because it's not just a single topic per plugin. If all those topics were merged or moved it would be much easier to look through it for useful plugins. It still could be much improved by organizing the plugins according to category. topix has been doing a lot of work towards a plugin manager for the EventGhost application. If that gets done then it will be another centralized list of plugins. So why spend a bunch of time trying to make and maintain a plugin list for the website when we already have one and likely will have another in the future? I think that effort would be better spent on cleaning up the Plugin Support forum section(which I'm willing to help as much as possible with), this would also benefit the process of populating the plugin manager database.

Sem;colon wrote: btw. Not all plugins are stored in the Forum, krambriw for example, uses his own webspace to host plugins and just linked it in the forum.

Yes, I think that will be an issue for the current attempts to automatically generate a list by scraping the forum database for plugin attachments. The only way I could see to automatically generate a full list would be if the Plugin Support section topics followed a strict format, which would require someone to go through and edit all the old topics.

Posted: **Fri Nov 18, 2016 2:02 am**

well i have all of the plugins that are attachments already converted to egplugin files... all 777 of them. there is an egplugin file for each version of each plugin that has been attached.

i am going to have to take a look see at parsing messages to look for keywords and links to possibly get the rest. but i feel that this is a great start thus far

****edit 798. with 120 or so that need to be gone through, plus another 40 from connection errors...

i converted all the ones that were compressed with rar also

Posted: **Fri Nov 18, 2016 8:53 am**

pearbear wrote:
Sem;colon wrote:You know what the problem with the wiki was/is? No one has access to it!
Exactly, and that's why I'm very excited about the work dequi is doing. However, if the wiki content is moved to a GitHub repository anyone can submit a pull request but if nobody with the privileges to merge the pull request bothers to do so then it's not going to be much of an improvement over the current system.

pearbear wrote:I noticed that dequi did create a wiki in the EventGhost/EventGhost repository today: https://github.com/EventGhost/EventGhost/wiki. dequi, what are your intentions for that wiki?

Aha, would have told... but some one broke the forum

so in the spirit of better to ask for forgiveness, then waiting for permission (doesn't really happen here I've noticed). I just went for it.

The goal was to see how far can I go without needing any sort of administration rights. Well here it is: pretty far, the only limitation I had was not being able to add images directly to the wiki repository when adding a tutorial (I could have used image links but in the long run could just break stuff if the image sources disappear)

So I've set up a basic framework that I think could replace the complete website and old wiki. https://github.com/EventGhost/EventGhost/wiki

To bypass the 'image upload problem' when porting the tutorial 'getting started' from the old wiki, I've created my own repository https://github.com/dequi/EventGhostWiki/wiki used the wiki from that, mirrored the footer, sidebar and breadcrumb trail and added the tutorial with the images as I have full rights on my own repository, and just added a link to the https://github.com/EventGhost/EventGhost/wiki/Tutorials = this ensures a smooth user experience, but in theory anybody can host their tutorials anywhere and add a link to it on the GitHub Wiki. We could even add links to youtube videos. In practice anybody could also come in and edit my tutorial and fix mistakes (well it's not actually my tutorial but you get the gist). If links break anybody can fix them.

go have a look: https://github.com/EventGhost/EventGhost/wiki. The 'Getting Started' tutorial is on my repository, the rest is on the EventGhost repository (in my opinion the official documentation should be only text and in the Eventghost repository) but you shouldn't notice.

I think this way solves practically all problems, nobody needs to be merging pull requests, nothing needs to be build, anybody can start their own repository with tutorials, anybody can update the GitHub Wiki and add links to their own tutorials/documentation/plugins. nobody needs to be actively involved for the long haul. The website can just be a landing page that links to the GitHub Wiki or parts of the GitHub Wiki or just be the GitHub Wiki itself.

Sem;colon wrote:I can only speak for me of course, but if there was a centralized place to put/list plugins I would so going to use it. (If I have the possibility to, of course)

Feel free and go add them on https://github.com/EventGhost/EventGhost/wiki/plugins - but be responsible

pearbear wrote:So why spend a bunch of time trying to make and maintain a plugin list for the website when we already have one and likely will have another in the future?

1. the one(s) we have is outdated and messy, nobody can update.
2. Topix needs a updated organised place to start from.

pearbear wrote:The only way I could see to automatically generate a full list would be if the Plugin Support section topics followed a strict format, which would require someone to go through and edit all the old topics.

Sem;colon wrote:btw. Not all plugins are stored in the Forum, krambriw for example, uses his own webspace to host plugins and just linked it in the forum.

Isn't it easier just to start a organised list? don't need no forum admin rights for that.

big issue is we need to be able to clean up after ourselves when were done moving.

Posted: **Fri Nov 18, 2016 10:05 am**

dequi wrote:I just went for it.

Reminds me of the Wikipedia motto, which I really like: Be Bold!

dequi wrote:So I've set up a basic framework that I think could replace the complete website and old wiki. https://github.com/EventGhost/EventGhost/wiki

I like the idea. It's not so pretty as your eventghost.github.io but what's important to me is information presented in an organized manner and I think that can be achieved within the constraints of the GitHub wiki system. I find GitHub Flavored Markdown to be really easy to work with and I think this option will be the most friendly to allowing anyone to easily contribute. I also like that the wiki and the EventGhost application source code are both accessible from the same repository, makes things less confusing.

dequi wrote:the only limitation I had was not being able to add images directly to the wiki repository when adding a tutorial (I could have used image links but in the long run could just break stuff if the image sources disappear)

How about a separate repository used to store images used on the wiki, something like EventGhost/WikiFiles? This would still require pull requests to add images but if that was a slow process the person wanting to add the image could always use the image in their fork of the WikiFiles repository until the pull request was merged and then change the image URL in the wiki after the merge.

There will also need to be some changes in how the documentation is generated for the EventGhost application during the build. I had brought this up in the "How you can help" thread and topix replied:

topix wrote:the idea would be to put the docs in the wiki and import them from there when building. Then they would only need to be edited in one place.

Currently the EventGhost website has Documentation and Wiki sections. The Documentation section is part of the EventGhost application source and generated during a build into the website pages and the built-in application documentation, the wiki content is not. With the move of the documentation content to the wiki it seems the two categories may want to merge together. This makes some sense because half the pages in the eventghost.net wiki are duplicated in the documentation but I'm wondering if it would be a good idea to have a specific section(s) of the GitHub wiki for the documentation that will be built into the EventGhost application rather than putting the whole wiki in there?

dequi wrote:big issue is we need to be able to clean up after ourselves when were done moving.

Here's the road map for the move as I see it:

Create a demonstration implementation. I think what dequi has already done gives a reasonable preview of the wiki so this step is pretty much finished.
Get approval for the move from the people able to make things happen on eventghost.net and the EventGhost/EventGhost repository. I think that would be zian(or maybe kgschlosser?) for the website and topix for the repository. This is necessary to make sure it will be worth doing the work of the full content migration since without their cooperation it will be all for nothing.
Add all content to the wiki. I'm willing to work on this, just let me know what you want me to do.
Link or redirect from eventghost.net to the wiki and delete all moved content from eventghost.net.
Update the EventGhost application build script to get the documentation from the wiki and remove all documentation files from the EventGhost application source. This should be done before the next EventGhost release so that the application documentation won't be different from the wiki documentation.

I'd like to propose that my version of the documentation files(https://github.com/per1234/EventGhost/t ... /data/docs) be used in the import, I fixed a lot of typos/grammar/broken links and they are up to date with the latest versions from the EventGhost/EventGhost repository.
EDIT: My updates to the documentation have now been merged to the EventGhost/EventGhost repository.

Posted: **Fri Nov 18, 2016 2:45 pm**

pearbear wrote:I like the idea. It's not so pretty as your eventghost.github.io but what's important to me is information presented in an organized manner

Yes, it is less slick but someone, not naming names but, you know who you are,

raised some concerns about update-ability, contribution-ability, lack of long term commitments. This is somewhat the best solution I can come up with, that addresses most points. I prefer function before form.

pearbear wrote:There will also need to be some changes in how the documentation is generated for the EventGhost application during the build. I had brought this up in the "How you can help" thread and topix replied:
topix wrote: the idea would be to put the docs in the wiki and import them from there when building. Then they would only need to be edited in one place.

Let me propose something wild: don't build the documentation into the application anymore

remove the Help -> Home Page / Help -> Support Forum / Help -> Wiki links from the application
change Help -> Help Contents to point to the GitHub Wiki https://github.com/EventGhost/EventGhost/wiki
generate the documentation for the eg.module from source to (one) page in the GitHub Wiki under documentation. The rest are mostly an import of static .rst files that can easily be ported to the wiki.
no .hlp/.chm file anymore

Why?

.hlp/.chm files are on their way out. Personally I don't use them. More and more applications are just providing a webpage.
By pointing to the wiki, The user gets direct access to all tutorials as well in stead of a limited view.
Documentation will always be up to date for all previous/new releases (that work this way) when updated.
You don't have to take into account anymore that sphinx and Github Flavored Markdown don't get along.
This way you can move practically everything without the application help getting broken, well except for the GitHub repository and wiki.

just my two cents

pearbear wrote:4. Link or redirect from eventghost.net to the wiki and delete all moved content from eventghost.net.

Don't forget to put a redirect on http://www.eventghost.net/mediawiki as well, not to break the old versions

Posted: **Fri Nov 18, 2016 7:08 pm**

Sem;colon wrote:You know what the problem with the wiki was/is? No one has access to it!

Well, i once had and i'm still the 'leader'

of the wiki group, but as i tried to login a few minutes ago, i got an error:

Code: Select all

Unexpected non-MediaWiki exception encountered, of type "Exception"
exception 'Exception' with message 'There was a problem when connecting to the phpBB database.<br />Check your Host, Username, and Password settings.<br /><br />MySQL Error Number: 0<br />MySQL Error Message: <br /><br />' in /home/content/79/7358079/html/mediawiki/extensions/Auth_phpBB.php:699
Stack trace:
#0 /home/content/79/7358079/html/mediawiki/extensions/Auth_phpBB.php(428): Auth_phpBB->mySQLError('There was a pro...')
#1 /home/content/79/7358079/html/mediawiki/extensions/Auth_phpBB.php(491): Auth_phpBB->connect()
#2 /home/content/79/7358079/html/mediawiki/includes/User.php(716): Auth_phpBB->getCanonicalName('Topix')
#3 /home/content/79/7358079/html/mediawiki/includes/User.php(357): User::getCanonicalName('topix', 'valid')
#4 /home/content/79/7358079/html/mediawiki/includes/specials/SpecialUserlogin.php(475): User::newFromName('topix')
#5 /home/content/79/7358079/html/mediawiki/includes/specials/SpecialUserlogin.php(611): LoginForm->authenticateUserData()
#6 /home/content/79/7358079/html/mediawiki/includes/specials/SpecialUserlogin.php(118): LoginForm->processLogin()
#7 /home/content/79/7358079/html/mediawiki/includes/specials/SpecialUserlogin.php(17): LoginForm->execute()
#8 [internal function]: wfSpecialUserlogin(NULL, Object(SpecialPage))
#9 /home/content/79/7358079/html/mediawiki/includes/SpecialPage.php(791): call_user_func('wfSpecialUserlo...', NULL, Object(SpecialPage))
#10 /home/content/79/7358079/html/mediawiki/includes/SpecialPage.php(559): SpecialPage->execute(NULL)
#11 /home/content/79/7358079/html/mediawiki/includes/Wiki.php(254): SpecialPage::executePath(Object(Title))
#12 /home/content/79/7358079/html/mediawiki/includes/Wiki.php(64): MediaWiki->handleSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
#13 /home/content/79/7358079/html/mediawiki/index.php(117): MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
#14 {main}

dequi wrote:remove the Help -> Home Page / Help -> Support Forum / Help -> Wiki links from the application

At least 'Home Page' i would leave.

dequi wrote:change Help -> Help Contents to point to the GitHub Wiki https://github.com/EventGhost/EventGhost/wiki

Agree with that.

dequi wrote:generate the documentation for the eg.module from source to (one) page in the GitHub Wiki under documentation. The rest are mostly an import of static .rst files that can easily be ported to the wiki.

Will/can you change that code (if we go that way)?

dequi wrote:no .hlp/.chm file anymore

Yeah, i too don't use them (or very very very seldom).

Posted: **Fri Nov 18, 2016 7:39 pm**

ok i have a really dumb question...

well maybe not..

there is the use of docstrings in python and the purpose of it is to explain a function/method/class/module and you mainly see it's use in IDE's or something like the python shell where you can key in a function/method/class/module name and from that you can bring up the "help" for that item...

how come we are not using that mechanism?? as there is already a whole bunch of these docstrings already done...

it keeps everything nice and tidy and in one place.... in the source code of EG

and it makes it super simple to dynamically update things like webpages. or help files... because you just have to have it scan the source for these.. an example of how to do this would be the python shell..

so if for instance someone is running version 0.4 and then go to the help menu if it loads a webpage then the version is passed so only help on that version is displayed. and the webpage just reads the information from the actual source files for the version that has been passed... or even if it is local the same thing applies. it will just read from the local source files so there relly only needs to be one bit of code written and not one for each version

Posted: **Fri Nov 18, 2016 8:28 pm**

kgschlosser wrote:how come we are not using that mechanism?? as there is already a whole bunch of these docstrings already done...

We are already using it. If you look in the help file: Developer documentation - The eg module. This section is build from source while building the setup file.

Posted: **Fri Nov 18, 2016 8:44 pm**

dequi wrote:Yes, it is less slick but someone, not naming names but, you know who you are, raised some concerns about update-ability, contribution-ability, lack of long term commitments. This is somewhat the best solution I can come up with, that addresses most points. I prefer function before form.

Well I'm just putting in my $0.02 and that's about all it's worth. You certainly shouldn't feel that it's required to make me happy because it's certainly not. More important is to make sure that the person who can change the website is happy since the move won't happen without them. I just wanted the full implications of all the options to be considered. But yeah, function before form. I actually really like the simplicity of the current website layout.

dequi wrote: Let me propose something wild: don't build the documentation into the application anymore

That would really simplify things. The only problem I see is that the documentation will not be available offline but it seems like everyone has access to the internet all the time these days.

The thing that's nice about the current system of putting the documentation files in the application source and then only updating the website documentation content on each release is lets say I make a change to EventGhost that requires a change in the documentation. I will update the documentation in the same commit as the changes to the application code. If the pull request for that change doesn't get merged then the documentation doesn't get changed either. If it is merged then the documentation change doesn't hit the website until the next application release, which has the change. So that all works exactly as you would want it to, though it means any other changes to the documentation have to wait for a release before they update the website. Moving the documentation to the wiki complicates things. Ideally you would want to wait for the application release before updating the wiki to reflect my change but this won't happen automatically so either I would update the wiki at the time of the merge of my pull request, which would make the wiki content incorrect for the current application version or I need to remember to document the change when the release happens, which could be months after the merge happens. This makes it easy to forget or just not make the effort and thus leads to undocumented features, etc. A workaround for this issue could be to require that an issue be submitted to the EventGhost/EventGhost repository with the necessary documentation changes either at the time of submitting the pull request or at the merge. These issues would be used as a to-do list for updating the documentation at the time of the release.

topix wrote:i tried to login a few minutes ago, i got an error

Yes, same here and I'm a member of the wiki group. I think that issue has been the main motivation for moving the website content.

Posted: **Fri Nov 18, 2016 9:04 pm**

topix wrote:
kgschlosser wrote:how come we are not using that mechanism?? as there is already a whole bunch of these docstrings already done...
We are already using it. If you look in the help file: Developer documentation - The eg module. This section is build from source while building the setup file.

i can swear there are a whole lot more docstrings compared to what help there is in the developer section. but i could be mistaken

Posted: **Fri Nov 18, 2016 9:13 pm**

i just went and looked... there sure is a whole lot more then is in the help files... well between that and the lack of parameter descriptions and use examples... but it's a good framework to use and should be expanded upon.

but also. i never really poked around with the media wiki. but it seems more like a "tutorial page" then anything. and the lack of ability to add things to it makes it kind of pointless and useless.

and also with that i do like the idea of doing video tutorials more so then typed out tutorials. only because it can eliminate any user confusion. for example.

if i say.... go into the context menu for tree item blah

there are people who would be like.... what the hell is a tree item.. and where is this context menu thing.... LOL

video tutorials will eliminate any misunderstanding due to verbage

Posted: **Fri Nov 18, 2016 9:15 pm**

and one other thing. i believe the mediawiki is not functioning properly is due to the fact that the hosting package does not support it..

could be a good reason.. i guess.... which means getting it to work properly is most likley a for not...

Posted: **Fri Nov 18, 2016 9:26 pm**

kgschlosser wrote:i can swear there are a whole lot more docstrings compared to what help there is in the developer section.

Aah, you might be right, not all, only selected items.

Posted: **Fri Nov 18, 2016 10:13 pm**

i do have yet another question. but it will post it into the plugins topic. but it really has to deal with both

Posted: **Sat Nov 19, 2016 4:11 am**

dequi wrote:[*] change Help -> Help Contents to point to the GitHub Wiki https://github.com/EventGhost/EventGhost/wiki

So a year ago I lost my internet for a month, so because you don't use local help, I don't get any help for EventGhost for a month, really nice. (It was a dark time in my life so this hits a nerve)
So I hate when programs has a nice button/menu with help or something and when I press it, it suddenly opens my web-browser, the thing is I am crazzzzzzzzy I have about a million tabs open so it takes a while to open. So at least indicate that the help button will open a webbrowser.

[*] .hlp/.chm files are on their way out. Personally I don't use them. More and more applications are just providing a webpage.

If it wasn't clear I would highly recommend having local help available, maybe have an option to choose offline or online help.

jonib

EventGhost

Website update

Re: Website update

Re: Website update

Re: Website update

Re: Website update

Re: Website update

Re: Website update

Re: Website update

Re: Website update

Re: Website update

Re: Website update

Re: Website update

Re: Website update

Re: Website update

Re: Website update

Re: Website update