Need Help

Do you have questions about writing plugins or scripts in Python? Meet the coders here.
Post Reply
User avatar
kgschlosser
Site Admin
Posts: 4652
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Need Help

Post by kgschlosser » Tue Nov 01, 2016 6:24 pm

This is getting a little overwhelming for me. and I would love to have a hand working on it.

I need a couple of people wiling to help. I need someone who can read Python code and turn geek into normal persons verbage. Could use a hand writing Docs for an EG build I am working on.

I also could use someone that is pretty knowledgeable about threading. specifically the object locking bits. I need to convert the current EG Dialog over to wx.Panes. problem is they have stackless intertwined and that just needs to be gotten rid of. because how it is coded it loops through stackless for the Modal Results and since there will be no more modal results gotta pitch stackless. the thing is I am trying to do it in a way that if there are plugins that are made that use any of the code in the Dialogs they won't get all broken LOL.

would also like someone willing to on take the challenge of adding a bunch of convince methods to the PluginManager/PluginBaseClass/PluginInstanceInfo/PluginItem. this needs to be done for several reasons. the way i did it works but I changed a bunch of other crap about so it needs to be done differently. I have set everything up to reply on "Managers " this is done to make doing different things in EG very simple. but also to allow EG to track the different things that have been done that way if the plugin gets removed so does all of the things that it has added. The PluginManager needs to be expanded in such a way to allow for setting attribute names to the plugin name attached to an instance of the plugin. this is how I have worked everything so it makes it super simple to say install a Plugin for example. if the attribute doesn't exist when you try to access it. it will install the thing and create the proper attribute name attached to the PluginManager I think having to do somehting like. eg.plugins.EventGhost.info.plugin to access the actual plugin class is kinda NUTZ I have done everything up so that you would do something like this eg.PluginManager.EventGhost

POW there is the plugin instance

or for example

eg.SettingsManager.EventLog.BackgroundColour
to do whatever you want to the background color

this becomes useful in such a way that if someone wants to add a Setting FoldPanelBar for their plugin. it can be done like so.

foldPanel = self.SettingsManager('caption text to be displayed')

and then they can add whatever config garbage they want via foldPanel.AddWindow() this would be a convenient way to add a small number of config items or a button can be added to open a full on panel that has loads of settings. so instead of having to click the plugin tree item. this would be in a nice Folding Bar displaying ell of the plugins that are available and if the settings need to be accessed from an external source it will be done via the PluginManager.PluginName.Settings. this will also create an entry in the eg.PersistantData and deep six all the args being stored in the xml file. this will then allow for keyword use for actions and plugins.
If you like the work I have been doing then feel free to Image

pearbear
Experienced User
Posts: 150
Joined: Mon Apr 02, 2012 10:28 pm
Contact:

Re: Need Help

Post by pearbear » Wed Nov 02, 2016 10:48 am

My advice is to push your work to your GitHub repository. GitHub is really an excellent tool for collaboration once you get past the initial learning curve. This will improve the chances of getting people involved in contributing to your fork. Even if they don't have a GitHub account and are not interested in working on that platform it still allows you to make the up-to-date code publicly available for anyone to review and give you input here on the forum or via other means of interaction.

User avatar
kgschlosser
Site Admin
Posts: 4652
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Need Help

Post by kgschlosser » Thu Nov 03, 2016 12:07 am

Yeah I know. I am trying to get to the point where the thing is running again. I am so close to being there. hopefully tonight if i manage to redo the config settings and get through all of the dumb coding mistakes we will see
If you like the work I have been doing then feel free to Image

User avatar
kgschlosser
Site Admin
Posts: 4652
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Need Help

Post by kgschlosser » Thu Nov 03, 2016 3:51 pm

well I didn't manage to get it up on git last night. I was finishing up something that needed the use of eg.Persistant data. and I wanted to make a method that would allow for dynamically creating one and also deleting entries from it. so i didn't want to have to recode what i was working on at a later point to work with such a feature. so i ended up writing a basic way of handling it.
If you like the work I have been doing then feel free to Image

User avatar
kgschlosser
Site Admin
Posts: 4652
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Need Help

Post by kgschlosser » Tue Nov 08, 2016 1:23 am

well i manager to get a somewhat running version up on github. There are a lot of things that do not work properly. but make sure you read the Github description. this is really more for a sneak and peek at what I have been doing. I am working on fixing the things that are not working properly. I will be generating a list of what's broken. and systematically going through that list. this is a major overhaul i don't even really know how much of the original code is left LOL.. I just spent the last 2 days chasing a phantom bug through my code. it was crazy. i would fix one thing and then the problem would move. it drove me bonkers. it turned out to be something really really really stupid. but it was strange how it would move around when i changed something completely unrelated.

but here is the link. if you need instructions on how to build the thing i can help ya out just PM me. please do not install this on your main computer. this is a test version. and i am not responsible if you install it over a running version of EG and things get a little messed up. I have not had a problem as of yet running this next to another version. but we all know how things like this go. so don't be yelling at me if your working" copy of eg don't work anymore because you installed this over it.

here is the link

https://github.com/kdschlosser/EventGhost
If you like the work I have been doing then feel free to Image

pearbear
Experienced User
Posts: 150
Joined: Mon Apr 02, 2012 10:28 pm
Contact:

Re: Need Help

Post by pearbear » Tue Nov 08, 2016 4:14 am

Putting the Auto in Automation! :D

I'm really grateful that you've been working so hard on this project to improve EventGhost. Thanks! I don't have enough familiarity with the programming side of what you're doing to be able to give much input but I do have a bit of experience with git and so would like to give some feedback on that topic.

I suggest that you read the two articles linked from the Commits count! section of the CONTRIBUTING.md file in your repository. It may seem uptight to be picky about commit discipline when what matters is the code but it's really important to maintain sanity when many people are collaborating over the course of decades on a large project such as EG. By making the effort to properly document your work you will make the project more likely to attract contributors. You need to consider the other people who will be working with the code and their various skill levels, good documentation really helps accessibility. Good commits make it easy to review the development history and troubleshoot bugs. I have found that being forced to break my programming work into logical, self-contained pieces has led to me being a better programmer and experiencing less frustration. I used to tend to get sidetracked from my current task when I'd notice some unrelated change I wanted to make, then when I finally got things to the point where I could do some testing and encountered a bug it was a lot more work to figure out which of those changes was the cause.

Here are a couple examples of what I'm talking about:
In your commit "Reorganized file structure" you are moving files around and that may be a good thing(though it does mess up file history and makes merges from the main repo more difficult) but you threw in a bunch of unrelated changes at the same time such as changing eventghost.net to eventghost.org. That has nothing to do with reorganizing the file structure and could have easily been done in a separate commit(which would have been a global, rather than partial, replacement of all occurrences) without affecting the atomicity of the "Reorganized file structure" commit. Large changes in commits are sometimes necessary but they make it much more difficult to review. For example in that commit GitHub says:
Sorry, we could not display the entire diff because too many files (390) changed.
If I encounter a bug it's very useful to be able to back up one commit at a time until the bug goes away. This requires commit atomicity to work, each commit must result in working code so the changes must be self contained. This does require some big changes sometimes when you are making changes to the fundamental code infrastructure but if you throw in a bunch of unrelated changes at the same time it's much more work to determine which part of the change actually caused the issue. I would expect a commit named "Reorganized file structure" to consist solely of moving files and any necessary edits to the code to account for the new file locations.

Imagine you're looking back through the commit history in 5 years. "Major changes" is not going to be a terribly helpful commit title, especially for such an important commit.

If I'm working on a big commit it may be helpful to break the work into multiple temporary commits to allow me to keep track of my changes and easily revert any of them. Then, once I've completed the changes, I'll do a rebase and squash all those temporary commits into a single commit before pushing it to the public repository. If you're working on that commit with multiple people then it might be useful to make a public development branch and then merge the finished commit to the main branch

I see that your repo is just a bit outdated:
This branch is 7 commits ahead, 149 commits behind EventGhost:master.
I'm not sure if the idea is to merge your changes to the main repository or if you are going to maintain a separate fork but either way this is an issue. Have you taken a look at those missing commits? Maybe some of them have been made obsolete by your major overhaul but I'm sure some of them are worth keeping. How difficult do you think it will be to merge?

Well I'm looking forward to seeing this project progress!

User avatar
kgschlosser
Site Admin
Posts: 4652
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Need Help

Post by kgschlosser » Tue Nov 08, 2016 5:59 am

ok. I would have loved to do commits. but the thing is that it was an entire reorganization/rewrite of the code. not something that could be done in steps. it was an all or none deal. LOL

and i wanted to keep a semi working version up. but from this ponit forward i also set up my IDE to deal with git directly. so if i break something (which i do quite often) it will be broken on github also. down side to that is that if someone wants to download the thing they will download a broken version. it is better to use git and commit very often. but when you completely toos away the GUI and just about rewrite the thing from scratch. going commits all the time isn't something that is first and foremost. I wanted to get it to a point of actually loading and running. and now i can deal with any issues that arize. most of them will only take 10 minutes to fix. but the thing is when i get into it. i will change something because i don't like how i did it. or i thought of a better way to code it. the dumbass settings panel that thing started out at 2000 lines. and 4 times of rewriting it i got it down to about 1400. LOL but i still have to add in the Event Log, and the Tree, and the Toolbar (now that i found a crafty way to set the colours) the menubar and popups i can do as well. but that is going to require a lot more effort. and in the process of doing all of this. it really aggravated me about how storing settings worked using eg.persistant data. and i added a ConfigManager that you can simply call with whatever you want to name it and supply it the class that houses your settings. and it deals with it from there. and sending out a notification if the setting has changed. the cool thing is it doesn't actually set anything to your config class until you tell it to. kinda like a save feature.

nice thing about this is you have the means to add temporary data if you want have have it available globally inside of EG. you can set any class into it you like actually. it doesn't really matter. i don't have it checking to make sure that it's a subclass of eg.persistantdata. I have already added the bits to it to handle the removal of an eg.persistantData class so for instance if a plugin gets removed from the tree the avilibility is there to have it also delete any config data that was stored. it wasn't set up to do that before. I still have to add it to the plugininstance class so it will have a settings "database" on hand. I am actually going to try to gear this to be a preferred method for storing plugin startup args and also storing action args. because of the use of keywords. and the only argument you would pass would be the actual identifier to locate the data inside the configmanager.

any of the managers i made they all operate the same way. as an example. if you want a set wx ID that will always be the same during that EG session. you simply do eg.IdManager.SOME_NAME
and it will return the wx Id and the id will be the same eacy and every time you call it. the first time you access it if the attribute SOME_NAME doesn't exist it will create a new id and set that new id to the SOME_NAME

so if you want to use the ConfigManager it would be eg.ConfigManager.SOME_NAME(config_to_manage)

and then from there you would eg.ConfigManager.SOME_NAME.SOME_SETTING() or eg.ConfigManager.SOME_NAME.SOME_SETTING.Get() to get the setting and eg.ConfigManager.SOME_NAME.SOME_SETTING(new_setting) or eg.ConfigManager.SOME_NAME.SOME_SETTING.Set(new_setting) to set a new setting. and you have to call Save() to actually save the data. otherwise it is just help in a temporary storage. but if you delete an attribute del(eg.ConfigManager.SOME_NAME.SOME_SETTING) it will remove it from the config.py or delete the configmanager del(eg.ConfigManager.SOME_NAME) it will delete the whole eg.persistantData class from the config.py

the ToolBarManager works in the same way except that the first time you call it
eg.ToolBarManager.BlahToolBar(caption, size, row=3, show=True, pos='Top', binder='ToolBar.SetSize', maxButton=True, minButton=True, closeButton=True, destroyOnClose=False, notify=False)
is for the creation of the toolbar and the addition of it to the PaneManager

every call to it there after
eg.ToolBarManager.BlahToolBar(iD, ident, label, icon, dispatchCommand, drop=None, check=False)

if to add an actual tool and because of the complexities in dealing with AUI Panes and Toolbars and the actual tools. trying to nail down who pressed what and when is bonkers. so i added a really nice little spiffy dispatchcommand. which is a callback if the button is pressed.

and i added a nice little feature to the PaneManager. called SetSpouse and GetSpouse. so you can marry 2 panes together (I am planning on making it more then just 2. so that way if one gets closed. it will close any other pane that is set as a spouse. no additional code needed on the user or plugin dev end except a one liner to add the spouse.

I have really worked at making EG easier to use from a programming standpoint. for instance. when you supply a widget to be added to the AUI it will automatically reparent the widget to a scrolled window and push the scrolled window to the AUI instead. so the person programming doesn't have to worry about a crap ton of extra lines of code to handle the scroll bars and the re sizing. I have already taken care of all of that. just like the settings panel. You want to add to it. works just like all of the rest. supply an attribute name and pass a caption to it. and presto you have a new bar and you can populate it with whatever you wish. I am working on a way to have it handle any settings changes automatically using the ConfigManager. I am thinking if you set the name of a specific item in the settings panel to be the attribute name in the config then when an event occurs. i can have it automatically grab the name from the event object and go a getattr on the configmanager with that name to get the instance and set the value. I have to do more reading to see how many of the wx widgets have the availability of PyData if most or all of them do then you would just set the config instance to the PyData instead. I am thinking if we add a widget to the bar via the SettingsManager. then you can just pass the instance of the config along with the widget. but I have a one up kinda idea. is to handle all the BS behind the scenes. example


eg.SettingsManager.SOME_BAR.SpinIntCtrl(eg.ConfigManager.SOME_CONFIG.SOME_ATTRIBUTE, blah blah blah)


and oh the nice thing i did with the ConfigManager is when you set a new value it will return an instance of it's self so you can do this

eg.ConfigManager.SOME_CONFIG.SOME_SETTING.Set(newValue).Save()

that that's long winded enough...

more to come....
If you like the work I have been doing then feel free to Image

User avatar
kgschlosser
Site Admin
Posts: 4652
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Need Help

Post by kgschlosser » Tue Nov 08, 2016 6:02 am

I am not planning on a merge. and this is the latest copy of EG that I have modified. you couldn't merge with what I have done. I am really interested in hearing peoples takes on it. and see what could be added to EG not really this becoming a main version. to see what works and what doesn't
If you like the work I have been doing then feel free to Image

pearbear
Experienced User
Posts: 150
Joined: Mon Apr 02, 2012 10:28 pm
Contact:

Re: Need Help

Post by pearbear » Tue Nov 08, 2016 9:48 am

kgschlosser wrote: from this ponit forward i also set up my IDE to deal with git directly. so if i break something (which i do quite often) it will be broken on github also. down side to that is that if someone wants to download the thing they will download a broken version.
That doesn't sound right. I have a local clone of all the repositories I work on. I commit to the local repository first and then when it's ready to go public I push to the remote on GitHub. If you need to push changes that haven't been thoroughly tested to GitHub then use a development branch(es) and then only merge to master once it's been tested. That way people know that the version in the development branch is for the brave and the master branch is more likely to be stable.
kgschlosser wrote:I am not planning on a merge. and this is the latest copy of EG that I have modified. you couldn't merge with what I have done. I am really interested in hearing peoples takes on it. and see what could be added to EG not really this becoming a main version. to see what works and what doesn't
I still think it's worth taking a look through those 149 missing commits to see if there's anything useful.

User avatar
kgschlosser
Site Admin
Posts: 4652
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: Need Help

Post by kgschlosser » Tue Nov 08, 2016 4:01 pm

ok i will make a backup and then merge the thing and see what happens
If you like the work I have been doing then feel free to Image

Post Reply