Goddamn dude. All this EG drama aside, that sounds painful and terrifying and I'm glad to hear you're OK.zian wrote:Roger that...dequi wrote: On a side-note you should consider sharing access, no-one is immortal...
I nearly died Sunday up in Michigan in a lake messing with a water pump. Power off. Bad Ground. Still hot. Couldn't move as my whole body was juiced. But I did. Burned a little hole in my arm. Still feel it in my back.
Side note... Bought lottery scratch off today.
would it be cheaper to solely use github or any similar portal like that?
This way perhaps some monies can be shaved off the budget. As long as the site has bug request capabilities and discussion boards (and download links, but that's a given).
I am invested in this project because most of my automation setup is based on EG. But I do not know if there is anything I can personally do to support this project.
- Site Admin
- Posts: 3470
- Joined: Fri Jun 05, 2015 5:43 am
- Location: Rocky Mountains, Colorado USA
the machine is an 8 core 3.2 64 gigs ram, 120 gig (expandable) SSD RAID0 with write caching turned on. dual intel IOP1.2 Ghz Raid controllers capable of handling 128 HDD's Each with 1/2 a gig ram on each. all Noctua Magnetic Suspended Oil Bearing fans.
I'll post some Pics.
I had it out of the Rack about 2 years ago for a cleaning and Hardware Upgrades. I have photos from then
You can see the 2 RAID Controllers to the left and that dusty ass fan. LOL that thing is 8 years old. and been on 24/7 for those 8 years
I believe when i got that heatsink and Fan it was like 160 USD (I didn't pay that but that was the normal price)
Top Shot, You can see the HDD Backplanes the drives are connected VIA a SFF Cable. so one cable for 4 Drives With this case. There is a riser card that can be gotten to allow for external Drive Banks Shot of the HDD Controllers. those little 40mm Noctua fans were ridiculous in price same price as the big brother 120MM
Now the Original fans were not designed to come off the original heatsink. and the heatsink didn't want to come off the card. took me a long while to get those buggers off and come up with a way to mount them properly Here you can see the front of the chassis on the right. yup, count em 5 rows of 4. it's a tremendous amount of heat. I actually use it to heat the Media Room where the Server is located. I run what is called a "Hot Isle" 1/2 of my basement is finished and the wall the Rack is in was an old closet. so what i did was on the back wall. I cut a hole through, a big hole enough to climb through. and that leads into the unfinished side of my basement. which is always a beautiful 60 degrees F. so i bout 2 crazy Furnace Filters and make a way to slide them in over the opening i cut. and the rack pushes into the wall and all of the fans in every piece of equipment i flipped 180 so it draws air from the rear. sucking the cool air through the filters through the machines exhausting the heat into my Media Room. I closed off all the Heating vents and it's always about 72 in that room now. and the room is 15 wide my 30 deep. it's a big space. the air coming out of the front of the rack is about 115 degrees
The website pays for itself and more:skribb wrote: would it be cheaper to solely use github or any similar portal like that?
This way perhaps some monies can be shaved off the budget.
zian wrote: Once we got Google AdSence here at the forum that income covers all the website expenses. Plus sum.
GitHub is great for issue tracking but it would not be appropriate to use for support requests, general discussion/chit chat, 3rd party plugin support, etc. GitHub does provide decent wiki capability(https://github.com/EventGhost/EventGhost/wiki). I like other wiki software better but it would be a huge improvement over the completely broken wiki that EventGhost currently has.skribb wrote:As long as the site has bug request capabilities and discussion boards
I'm in the same position. I was very happy to see development move to GitHub because it makes it very easy for anyone to participate in development but now it's unclear if that repository will continue to be active as Blackwind was managing it. I guess the only way to find out is to submit a pull request.skribb wrote:I am invested in this project because most of my automation setup is based on EG. But I do not know if there is anything I can personally do to support this project.
There are certainly quite a few ways that anyone can support the project. Some are listed here:
these are a few more I came up with:
Yes, but not functional. Github doesn't offer a proper forum which is an important part of the EventGhost community. Besides that, yes I believe it would be good enoughskribb wrote: would it be cheaper to solely use github or any similar portal like that?
45 days and counting: https://github.com/EventGhost/EventGhost/pull/111pearbear wrote: I'm in the same position. I was very happy to see development move to GitHub because it makes it very easy for anyone to participate in development but now it's unclear if that repository will continue to be active as Blackwind was managing it. I guess the only way to find out is to submit a pull request.
So far I'm not impressed
Who has access to the backups? That should be part of the inventory.WoLpH wrote:Bummer! I'd really like to see something like that be implemented.skribb wrote: 45 days and counting: https://github.com/EventGhost/EventGhost/pull/111
So this thread got derailed by some stupid drama, now that's sorted itself lets get back to the important stuff:
Is Pako going to maintain the GitHub repository? I'm not talking about necessarily putting tons of work in but just the willingness to do basic management tasks like merge or close PRs, close issues, etc. Code review of PRs and discussion of issue reports can be done by anyone.
How about making topic2k a collaborator in the GitHub Repository?
Did blackwind turn over control of the Slack and appveyor accounts?
What about all the other resources that only a single person has control over? I know this is a difficult subject but it needs to be resolved. Why not just add Pako to all of them? I don't think anyone here would disagree with that except maybe Pako.
What about the one here:zian wrote: I would remove ALL of those existing PayPal buttons.
https://raw.githubusercontent.com/Event ... buting.rst
dequi wrote: A full offline backup of all files and databases is now sorted. We can restore if needed.
Also, enough with this beta BS. Eventghost has been around for over 11 years and has thousands of users depending on it. It's not beta anymore and the version number should be 1.0.0+. The only possible reason for staying in beta is so the developers won't look bad when the major version gets high because they broke backwards API compatibility a bunch of times. That's just childish. I'd much rather end up at EventGhost 42.0.0 than have a version number that doesn't convey useful information because of someone's ego.
What?!, whether a release is a beta or not has nothing to do with how long it's been in development. A beta release is for testing so any bugs can be found and fixed before a proper release can be made that don't burn down someones house.pearbear wrote:Also, enough with this beta BS. Eventghost has been around for over 11 years and has thousands of users depending on it. It's not beta anymore and the version number should be 1.0.0+. The only possible reason for staying in beta is so the developers won't look bad when the major version gets high because they broke backwards API compatibility a bunch of times. That's just childish. I'd much rather end up at EventGhost 42.0.0 than have a version number that doesn't convey useful information because of someone's ego.
From http://semver.org/#spec-item-4 :
Sorry, but you don't get to stay in "initial development" for 11 years. That sends a clear message to the users that EventGhost isn't reliable, which we know is not the case. Sure there will always be some issues but it's definitely long past time for 1.0.0.Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
That's actually not too unusual, the famous VLC Media Player for example has been version 0.x for about 15 years.pearbear wrote:Sorry, but you don't get to stay in "initial development" for 11 years.
Anyway, I think we make progress with 0.5.0 over 0.4.1 that we had for many years
Also, there are Milestones set in GitHub for a version 1.0, what brings be to my next and more important question: Is anyone able to accept pull requests on GitHub and can build a new release, if required???
Edit: Sorry, I used the wrong tense; I mean had been version 0.x for about 15 years.
Latest VLC release is 2.2.4Sem;colon wrote:the famous VLC Media Player for example has been version 0.x for about 15 years.
If the information in the resource inventory post is correct then Pako has the permissions to do so but it would be nice to get an update from them on what level of participation in the the repository can be expected so that others will know if it's worth submitting pull requests, issue reports, or working on the existing ones.Sem;colon wrote:Is anyone able to accept pull requests on GitHub and can build a new release, if required???
I'm also curious why CarsonF is the only "People" listedin the EventGhost organization on GitHub. Does this mean that he is the only Owner in that organization? Again, I think Pako should be added to all these resources(assuming they're cool with that). The inventory would indicate that Pako is the only one with control over EventGhost/EventGhost repository which is definitely not a good thing but maybe CarsonF also has control over it?
- Site Admin
- Posts: 3470
- Joined: Fri Jun 05, 2015 5:43 am
- Location: Rocky Mountains, Colorado USA
Sem;colon wrote: Also, there are Milestones set in GitHub for a version 1.0, what brings be to my next and more important question: Is anyone able to accept pull requests on GitHub and can build a new release, if required???
I have the knowledge, but not the permissions to do so. I have spent at least 100 hours so far retooling the eventghost UI in hopes that progress will move forward. i did this in the event that someone ends up with the ability and want to move development forward. and the code I have written for the UI i also python 3 compatible. and I have been making changes to things that i come across that aren't so if by some chance version 1.0 is a possibility i have done all this up to put into a pull request to hopefully lessen the work. in my eyes we are still moving forward. and I am going to continue doing what i do and come up with ideas and try them out and see what happens. I have done some of the things on the milestone list as well. I added the GUID's to all the tree items and made sure that the whole way the xmlId() works still functions the same (for backwards compatibility). tho i would much rather just convert the old egtree upon install of a newer version of EG. but that would require someone who knows more about xml and could write some code to do such a conversion. I added the ability to install packages into EG. and I removed the way the current beta works with adding the python path because I found that has all sorts of issues on it's own due to the simple thing of my python development environment is just that. development. don't need to have my development environment mingling with my software. you can see where that might be an issue.
this is where I am at so far. things that have a YAY are things I found to be a personal bug up my ass and annoyed the crap out of me
the UI has been upgraded to use the wx.agw.aui
the ability to adjust things in the UI - caption bar size, active color, active gradient color, font, inactive color, inactive gradient color, gradient type (None, horizontal, vertical)
the dock controller style (standard, aero, whidbey)
size gripper (yes, no), color, size
item border color, size
button size (close, maximize, minimize, restore),
general UI background color and gradient color
move item gripper color, size
animate the docking and undocking of items
using smooth (pyQT style) style for the animation
previewing the item if it's minimized
making the item transparent when moving it when it's not docked
making the item act like a drop down menu if it's not docked and you make it active (auto minimize with some flare)
I added a debug log viewer that parses the data and puts it into a tree organized by date and time and has a table format for the item with a column for the entry type. whether it's an error, a call that returns or just a log entry and you also have the ability to clear the debug log from that viewer.
when closing EG instead the EG just sitting there blinking at you if something is open. now a dialog pops up and tells you what is open and asks you if you would like to close it. YAY!!!
this is more of a development thing. but if you are tinkering with making the config dialogs and it crashes it doesn't get stuck anymore requiring you to kill the process. YAY!!!
GUID to the tree items allowing for things like disabling an item to take place from code.
eg.IconManager - proper icon handler that allows for changing icon sets and adding new sets (without a restart of EG) changing the icon size. allowing for plugins to utilize the IconHandler for custom icons so that any changes in size from the UI can also carry into the plugins custom sets. you can now put in a file name, base64encoded string, path to a set, wx.Icon, wx.Bitmap, wx.Image, PIL.Image into the eg.RegisterPlugin for the icon keyword. the whole setup is auto sensing. Actions for a plugin can have their own icon by adding a class level variable actionIcon to the action and is processed in the same manner as the plugin or setting a path in the RegisterPlugin and naming the icon the same as the class name all lowercase. if a path is used the icon for the plugin needs to be named "plugin". I also added support for ico, bmp, jpg along side png. tho the png is the best because of alpha transparency and is the preferred method. the icon handler also takes care of cropping out any excess "alpha transparency" and re-sizing the icon properly. so need need to have a standard size only that if you don't use a square (ish) icon it may get a little stretched (or a lot), still working on that one.
eg.PackageManager - this was a beast to code. it cannot be overridden. it can only be accessed by a small number of things (register plugin, shell, python script, python command). the Package manager wraps every piece of pip and setuptools (easy-install) so that no access is allowed to it by anything except the package manager. it tracks and manages what is and is not installed and what files and directories are altered allowing for a complete clean uninstall of a package. if it is run from the register plugin it looks to see if the package is installed and if it is adds the plugin name to the list of that is using that package, if not makes a new list. this only happens if the plugin is added to the tree. and when it is removed from the tree if it is the last/only plugin using that package it will uninstall the package. if you want to manually upgrade the package it can be done from a python script, shell, command.
because i had to trace down the means to do something when a plugin is removed from the tree. i added a method to the plugin base class __remove __ that is called when a plugin is removed. this allows a plugin to do tasks if it is uninstalled like cleanup any files that are made. or popup a little friendly dialog stating "thank you for using my plugin", whatever you want
added PluginSettings to the plugin base class which is a means to store any configuration settings you want. this functions by calling self.PluginSettings.SETTINGNAME to get a setting or self.PluginSettings.SETTINGNAME = value to make a new settings if you try to read a setting that doesn't exist it will make the setting and return a class so it can be nested. only at the point in which you assign the value to it does it become that value and not a nested class so if you want to make a separate settings container for an action it would be self.PluginSettings.ACTIONNAME.SETTINGNAME. this was done because of looping imports when making a subclass of eg.PersistentData and having multiple files. you would not have the ability to import the subclass if it was located inside of the __init__.py because you could not import the secondary file and then have the secondary file import the subclass from the __init__. this does not work. . so if you want to place your actions into separate files this allows the means to access that class easily and doesn't require any additional code to use it other then calling the self.PluginSettings. if you have specific settings to be added as a default and don't want to key a whole crap load of code. there is a method __settings__ in which you can simply set variable = value and for nesting you would do class classname: and your settings for that nesting after it.
if the settings container is used and any data is saved into the config file. it will be removed upon removal of a plugin from the tree. YAY!!!!
eg.IdManager to handle all the issuing of wx Id's
eg.ToolBarManager for adding toolbars to the UI
eg.PaneManager for adding panels to the UI
eg.MenuBarManager for adding new dropdown menus and items
eg.PopupManager for adding popup menus
the addition of a plugin without the need to have EG restart (including upgrading a plugin) YAY!!!!
added the ability to clear all settings (kind of like a fresh start) this will only clear the config.py file and make a new one with the same data that would be there on a brand new install of EG and then it reloads the whole plugin list causing eg to refresh anything that is using it and create new variables with their defaults.
a lot of the above make adding and removal of things nice and simple. but also allows for linking of items. as an example. you can link a toolbar to a pane so that if the pane gets closed the toolbar gets closed also without the need for additional code to do so other then a one liner linking the 2 together.
there is more but this is already a long winded forum post. so take this so far as some brain gravy and i have been documenting every single piece as i make it. and I am sure i will think of better ways to do things and have to make some changes. but by doing this even if for my own use has made me figure out how the core of EG runs. and taught me a lot about Python. the only downside I have so far is because of the handling of the icons and allowing for any size has caused EG to take a couple of seconds longer to load. but because it caches the icons it's only a startup thing. I was thinking about doing up a nice startup splash screen anyways. as most apps now use them. need to find someone that is proficient at making those kinds of things
oh yeah, and i also reorganized all of the core files. and changed how the import system works in eg but all of the original names are in place as not to break the current API
I am about 1/2 way done with redesigning the dialog system to allow it to add the dialogs as panes instead of a dialog purpose for this is it will allow for the user to select if they want everything contained into one window or to undock a dialog. but will also allow for remembering if a specific dialog was open when they close EG and have it reopen it upon startup
I'm sure you already know this, but just to be certain, those changes should definitely be submitted as multiple self contained pull requests rather than grouping unrelated changes together which would make testing and review much more difficult.kgschlosser wrote: i have done all this up to put into a pull request
- Site Admin
- Posts: 3470
- Joined: Fri Jun 05, 2015 5:43 am
- Location: Rocky Mountains, Colorado USA
pearbear wrote: I'm sure you already know this, but just to be certain, those changes should definitely be submitted as multiple self contained pull requests rather than grouping unrelated changes together which would make testing and review much more difficult.
heh yeah I know. but sending something to a place where it's going to just sit there and do nothing is kind of pointless. I have put all of this into a version of EG I have and it runs. i am ironing out any things i can find wrong. then i will post the changes up on my fork of it. that way at least if someone wants it can be used. and tested. and if there is at some point in time when everything starts to move forward again if something is needed/wanted it has at least had some testing done to it. but there is also a small issue with doing multiple pull requests. this is kind of a whole rewrite of the EG GUI it's an all or none sort of thing. there are things that can be separated but the bulk of it has to go all as one. but at any rate this is giving me a much better understanding of how EG works. and thus far the way I have made everything is it has dramatically made it easier for say a plugin developer to use the agw.aui features of wx. because in all honesty it's kind of a pain in the ass.