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
