Where is EventGhost going?

[stottle]

Since nearly half a year I observe my decreasing joy to work on this project. There are many reasons for it, but I won't comment on this now.

This is also the reason why I currently won't give new plugin developers SVN write-access. Most plugins will be removed from the trunk anyway.

Bitmonster posted this several weeks ago.

I don't know what Bitmonster is going through. It is obvious that EventGhost is a labor of love, and is a pretty amazing piece of software. I appreciate all of the hard work and I'm sorry it is no longer fun for him (and I would like to know if there is anything we, the users, can do to help).

I am also one of the users that requested write access to the SVN who isn't going to get it. While I empathize with what Bitmonster is going through, I'm also frustrated with the new releases of the core of EventGhost that have no documentation or release notes. It feels like Bitmonster has his own path for EventGhost that everyone else just has to live with.

I'm not bitching, just stating facts:

• It sucks that Bitmonster is not enjoying working on EventGhost. It sucks that this has resulted in less involvement on the forums and little or no communication on what changes are being made or will be made to EventGhost.
• Without Bitmonster's support, it is up to the user community to keep EventGhost going, by being active on the forums, helping new users, and developing (as much as we can) new capabilities for EventGhost.
• That core part of the user community that is able to help new users and develop new capabilities is getting disenfranchised. We end up as Beta testers (or trying to provide support for) new versions of EventGhost, where the only way to try to tell what changed is to manually dig through the source code.

I don't think going down this path ends well.

This isn't a plea for a changelog. I would guess that a changelog would not make Bitmonster any happier, and it would only make the user community feel better for a little while. I think the root of the problem is that Bitmonster is driving the ship, and the users are on deck trying to figure out where the ship is going. The lack of changelogs just makes us more aware that we are just along for the ride. And of course I love hearing the Captains not happy....

I'm not sure what we (all of us, including Bitmonster) can do. I know that I personally don't like having EventGhost run from a "black box." I've taken a recent SVN copy and created a local SVN were I can make my own cool changes. But that's obviously not a very good answer either.

I'm hoping an open discussion might bring up some ideas that will help get us off this path.

Brett

[jsonnabend]

I agree with pretty much everything you said, Brett. Bitmonster doesn't owe anyone anything. He has already given a tremendous amount -- both the code and the community setup -- and for that we should all thank him.

However, I think brief change notes for various versions would be very helpful. Nothing fancy or formal, but a brief note like, "hey, I messed around with this code" could help. At the very least, it would let us know what is changing and what we might focus on instead.

Also, posting a "standard" development environment setup would go a long way to allowing others to take on some real development. I have very limited time to play, and have been able to run EG from the SVN code (i.e., not using eventghost.exe), but still can't get it running in any IDE. Without breakpoints, code tracing, etc., development is real hard.

- Jeff

[stottle]

I think if you already understand how EG works and only need a little more capability from plugins, then everything is grand (except changelogs would be nice ). Jeff, you sound like you are in that camp.

I'm not. I think EG has the potential to appeal to a ton of new users, but it needs to be simpler to use and set up. I don't see any reason it can't be easier to use and set up, either, but the changes need to be made to the core, not as plugins.

[Note, I'm not making this up. I've tried to implement some functionality in plugins, and it doesn't work because of the threading model. Only the mainThread can add new actions, macros or events, so you either add new functionality to the core, or you change the core to allow the functionality in plugins. You have to change the core no matter what]

So I'm stuck, given that I'm not allowed to change the core. I'm trying to do something that the user community could really benefit from. I was hoping to get SVN access and make a separate branch to test my ideas out. I am hoping to get a sense of whether the user community and Bitmonster want these changes, or any other changes to the core by anyone besides Bitmonster. Best case, Bitmonster likes the ideas and supports the effort. But Bitmonster hasn't replied to any posts or PMs from me, so I'm guessing that isn't going to happen. Bitmonster is free to choose to develop EG or not. He's free to choose to support the user community or not. But if he chooses (and it looks like he already has) to not support the user community and to "surprise" us with changes, what then?

Anyone else think this is worth talking about?

[BTW, I agree an IDE would be great, everything I'm doing is with notepad++ and PyCrust within EG. But that's a topic for another thread.]

Brett

[jsonnabend]

To be clear, I'm not talking about plugins, I'm talking about the core. We don't really need SVN access, as we can do what you did, but publicly.

- Jeff

[Livin]

As I've said several times in the past, I also would like to see EG grow from good to great. Not to make this a bitch session but I agree, and have said before, Bit does not seem to care - he ignores posts and PM completely 99% of the time. I don't think that there is any hope that he will become more responsive to the community.

I think that trying to build on the core, with a separate SVN may be the only choice at this point and I suggest that we try to recruit other developers - the most likely starting with the XBMC and other media app communities.

If we are all in agreement on this we should start by compiling a list of features (core functionality) that we think EG would be good for and then advertise it to the media app communities and start recruiting.

[stottle]

I'm going to work on my own enhancements and see what I can come up with. Getting a little farther out of alignment with Bitmonster's SVN isn't a big deal for now.

I think until there's at least beta code that improves on EG, talking about an alternate SVN is a moot point. But if thats the only option, its the only option.

Anyone else want to chime in?

Brett

[Livin]

Brett,
As always, I'm happy to help with the testing

[stottle]

So I'm close to having a prototype working that I think works well for remotes. The idea is rather than manually creating macros to match events to program actions, let the software do as much of that as possible for you. This is obviously a departure from the way EG works right now. It doesn't break any of EG's functionality, just adds new processing for remotes.

I will certainly post more details, but for right now I'm wondering how much work I need to do to allow people to try it out. Case in point, you can't install a 2nd version of EG. It is hardcoded to look in a particular directory for config files. Those config files point to the xml configuration, wherever you saved it. If you install a prototype on a machine with EG already installed, it will use your existing config and any changes you make for the prototype will impact your existing version. Not very convenient. I could have my prototype point to a completely different set of files, but that will take extra time and doesn't provide any inherent value.

So I'm wondering if the people that are willing to try it out have a test system they can use that won't impact their working configs (either a test machine or a vm). Is that the case, or is it not worth letting people try a prototype until it can run on the same machine as an already configured EG?

I'm obviously talking to Livin and jsonnabend. If anyone else is interested, feel free to reply.

Thanks,
Brett

[Livin]

When I've tested new versions I always ZIP the existing EventGhost folder and then install the newest over the folder... to revert I delete the folder and unzip the previous version.

I guess what I'm saying is it should not be a big deal, I think?

[stottle]

I think there are two (possibly three) locations you need to worry about. First, you have the directory EG gets installed in, probably "C:\Program Files\EventGhost". There's also the directory EG puts config info, which is "C:\Documents and Settings\<USER>\Application Data\EventGhost" on XP. You also need to backup your xml configuration, which is the third location, unless you save the file to one of the first two directories.

When you say you zip up the existing EventGhost folder, I'm guessing you mean "C:\Program Files\EventGhost"? I think you can mess things up if you don't backup the Application Data folder as well. I think configuration settings are stored there in binary format, and I would guess they can get messed up if you mess with a prototype and then go back to an older version. The registry could potentially be a problem, but the only thing I'm aware of that touches the registry is the MCE plugin, which I don't think matters.

Brett

[Livin]

I've never messed with my "C:\Documents and Settings\<USER>\Application Data\EventGhost" and it has never been a problem.

[kingtd]

I think a lot of stress comes in from people expecting the software to do a lot of things "automatically", rather than treating it as a very flexible framework. I've been using eventghost for a long time now, coming over from the Girder community, and I have to say that Eventghost is better in every way. If you want to work with some hardheaded opaque devs, spend some time running Girder. So Bitmonster doesn't respond to your IM's on the free software he wrote for you? So he doesn't respond to your complicated idea that would most likely take days or weeks of work to implement on his part?

If you want it to do something, write it yourself as a plugin. That's the power of eventghost. Not getting one guy to do the heavy lifting for you, but to share the load and build something useful, then share it with the community.

For example - with remote handling, does that really require core changes that can't be done in plugins? If you make core changes, will it work with all of the crazy remote control plugin variations there already are?

Sure, I agree that we should have better access to the changes that are made to the core code, and there are some limitations to what the current thread model can do in some very complex circumstances. The hardcoded configuration opens are annoying sometimes, but not terrible to work with, and a silent automated installation mechanism would be pretty sweet. But there's got to be some less aggro approach than just straight up forking. If you're not successful you could just as easily destroy the community instead of improving it. And are you committed enough to babysit your own changes and take PM's and less-than-friendly posts when it doesn't do what someone wants?

It's a tough call but I'd just say consider carefully what can be done inside plugins, and what must be done with minimal core changes, before rebuilding something that we obviously all love to use.

~K

[jsonnabend]

King, your post is by and large correct, but misses the point. Those who can't develop (remember, we're not all coders) rely on those who can. And those of us who can are a bit frustrated by the inability to contribute to the core project directly.

No one, in this thread at least, expects anything from Bitmonster. He has been completely generous and provided a great program free of charge and open source. We just want to jump in and help move things along.

- Jeff

[stottle]

But there's got to be some less aggro approach than just straight up forking.

If you've got another approach in mind, I'd love to hear it. It would have been great if I showed up back in the day when Bitmonster was involved in the community, let others support development and enjoyed working on EventGhost. But I didn't show up then, and Bitmonster isn't involved now.

If you're not successful you could just as easily destroy the community instead of improving it.

HTPC is a hobby for die-hards. That's less true than it was a few years ago, but still true. And those die-hards will learn whatever complicated setup is necessary to get the results they want, with EG being a case in point. It works really well, has a good plugin system, but takes a fair amount of time and effort to learn and set up. But I think the landscape is changing. 95% of new users will probably be interested in using EG with the MCE remote. It is too inexpensive and too easy to install, so there isn't much reason to use anything else (or at least start with anything else). I think with Hulu and Netflix coming to HTPC, we could get a ton of new users. But the masses won't be interested in all the work that goes with trailblazing, they want something simple that works. And if they show up, HTPC won't be a die-hard hobby anymore.

And I think EG needs to be upgraded just to be viable software - unless there's a trick I haven't learned, I need to run the MCE remote in Win7 as an administrator and with UAC off.

Do you get any sense that Bitmonster is going to update EG to work for Win7/MCE? I don't. So I guess I disagree with your hypothesis that EG works and will keep working into the future and I should just "not rock the boat".

Worst case, I spend a lot of time and effort building something that doesn't work. That doesn't impact you, and doesn't impact Bitmonster. The die-hards that have spent the time to learn EG aren't going to go away until better software shows up or something comes along that it doesn't work with and no one provides a fix. I would be a lot more worried about the latter than having me want to make the software easier to use....

It's a tough call but I'd just say consider carefully what can be done inside plugins, and what must be done with minimal core changes, before rebuilding something that we obviously all love to use.

I'm admittedly new to this forum. I feel a bit like an outsider looking in and from my point of view, EG is on a path to being forgotten - for all the reasons put into this thread. I'm glad you don't feel that way.

I'm creating my own version of parts of EG to work better for me and my family, and I hope that some of this community is willing to try it as well so I know whether I'm making something that is worth sharing or not. I have no desire to hurt this community, so if you can help me share without doing harm - and let Jeff and anyone else share code as well - I'd love the input.

Thanks,
Brett

[kingtd]

Oh I'm certainly not saying not to rock the boat. If you search back through the forums, I'm sure you'll find several places where Bitmonster and I disagreed on the direction things were taking. I even asked for core changes a few times that I thought were important at the moment. But instead - and in both cases - I was able to get things working in my plugins without those core changes, and I think it made my plugins better.

Short of some very deep changes around the threading model that were pointed out earlier (which arguably apply to a very small minority of this already very small niche of users) there is very little that can't be done in a plugin. Take a look at my bluetooth hackery as an example of this type of thing. I'd just hate to see cool functionality get added in a fork and then get abandoned when it could almost certainly stay inside the existing framework.

To your point: HTPC and home automation is most certainly for hardcore people willing to spend a lot of time on minor details because we're always fighting with the scraps of incomplete interfaces and are often lucky to even get that much. There is some barrier to entry here that says "if you're not willing to roll up your sleeves and troubleshoot, this is probably not for you". Sure, adding MCE remote support would get past this hurdle for a few folks, but then what will they do? Most likely they'll shrug when it doesn't work because their HP or Dell has a ton of interfering crapware and they'll go back to just using the default stuff that it came with. I certainly wouldn't mind the extra Eventghost users, and there's lots of good stuff here for them, but those users are 99% going to be happy with just using the MCE remote with MCE and call it a day.

As a side note: I haven't been following your MCE Remote issues too closely, but I do personally run Windows 7 Media center as well. I use a Harmony remote programmed like an MCE remote, but I use it with a USB-UIRT receiver. This setup works fine logged as a standard user and with UAC enabled. It does not surprise me that the base MCE remote functionality doesn't like being intercepted by some non-Microsoft entity, as everything MCE has always been very blackbox integrated. It's one of the few plugins that requires a DLL in order to make it work. That's a little harder for some of us plugin writers to fix when it breaks. =)

Glad this conversation has come up, and I'm in favor of doing anything that makes the software better. Eventghost is a core working part of my configuration as it stands today. It talks to my Insteon system over ethernet. It talks to my HK receiver over serial. The blinds and projector with IR. MCe via the VMCcontroller software. All my other PC's with various broadcasts. Bluetooth to tell whether I'm in the building or not. With the new webserver it's got a robust way to display output to a browser.

Just don't break my baby. =)

~K