EventGhost

Similarly to the EG and Stackless discussion (viewtopic.php?f=10&t=9083), I think it might be time to replace or upgrade our current wxWidgets library.

I've been working on a few eg extensions the last few weeks and the current wx version is pretty horrible to work with. Additionally, there are still some annoying bugs which have been open for a long time (8 years) such as this one which I bumped into: http://trac.wxwidgets.org/ticket/9165

The easiest option is probably to upgrade to Phoenix (the new and future wxPython release): https://github.com/wxWidgets/Phoenix
But I don't think we should forget about alternatives such as PyQt5 or GTK or Kivy.

What do you guys think?

You are able to run pyQT if you want. EG 0.5 will add the Python site-packages folder to sys upon startup if you have Python installed. And we are also wanting to change to Phoenix but it's still a beta. And we would rather have a non beta release due to API changes possibly happening and causing more work on the back end. But I do not know if Phoenix will ever graduate to a full release. Lol they have been working on the beta for 10 years now.

That's true, you can run nearly anything but bundling PyQt is a bit too heavy for an EventGhost plugin. It should be bundled or it would be too heavy imho.

As for Phoenix, so far Phoenix has been working better for me than the old version is but both suck... the methods are illogical and window management is strange to say the least. With proper docs that could still be ok but the docs are not too great either

I still think it would be good to consider for the next major EventGhost release. If/when we switch to Python 3 and break nearly everything anyhow, why not switch to a properly supported GUI library?
My personal preference goes to PyQt5 since Qt has an amazing GUI designer but all toolkits have pros and cons. The PyQt5 docs are not as good as you'd hope either. In that regard Kivy really shines but it seems to be focussed towards touch (mobile) interfaces.

you can't add PyQT by just dropping the files. it has to be a local install with a local install of python as well.

I have already tried that. a lot of packages you can just copy the files and bundle them with the plugin. but not with PyQT

Now I made that package installer that can do the task. but the issue is that it is apart of the compile process and cannot be added after the fact.

and as far as the python 3 thing goes. outside of the main EG code. most plugins the code could be fixed using regex when the plugin gets installed. it wuold have to make the proper changes to the code for things like print, and del, and change any iterator calls to something like dict.keys() which no longer returns a list it returns an iterator. it would have to be changed to list(dict.keys())

I know that in pycharm when i do a code inspection and set it to use 3.x code it will tell me where the problems are and fix them if i tell it to do so. I am not sure how that engine runs. but somehting like that if it exists in a package might help. i know it wouldn't be perfect. but at least if it works not as many things would be "broken"

True, in most cases it will just work by using 2to3.py.
I am just being hopeful about a major new release with a completely new plugin system design ("while Affirmed()" should not be part of it) which can be tested outside of EventGhost with relative ease as well.

Thinking about it though... using a web interface as a plugin configuration gui might not be a bad idea either. That would be far lighter to incorporate and give the additional advantage of being available through the network if desired.

that exact kind of thing i would love to do. because i wanted to have EG be more of like a client/server type of interface. because of how eg revolves around the gui i am not yet knowledgeable enough to separate the 2. even if you run EG in hidden mode the GUI is still created just not shown. and I know from how it makes an invisible window to receive win32 messages it cannot be run as a service. if there is a way to receive those messages without creating an invisible window that would solve the service issue, and every day i am becoming more and more familiar with how eg uses the xml to create the separate "tree items" and i think i can separate it from using the treectrl to to be the storage of this data. once that is done it would be very simple to pass the data to where ever it needs to go to be displayed. whether it's a web portal or a client eg

i am redesigning the eg.Icons at the moment to handle a couple of things like different sized icons for one. but the ability to change the size of the icons so that if you run EG on these new super high res monitors the icons aren't so tiny you can't tell what they are. so adding the ability to zoom in out out on the gui on the fly.

and the core portion of it does a memoization but only for the indexed information of the wxIcon. so i am making it so that it will also look at arguments passed and store those arguments in a cache dict using a tuple of the arguments for the key so if the same arguments are passed it will grab the stored result instead of having to resize and convert the icons each and every time. for something like expanding a tree item. because the tree items icons are dynamic based on things like if they are disabled or not. right now EG has to remake the icon each and every single time it changes. and that's costly. so i want to cache it so if it's made once it won't have to do it again.

and I have added icons to all of the menu items. as well as separated the tool bar into file, view, tree, log, edit toolbars

i created a full icon set for the core eg icons. and with how i have redesigned it is you will have the ability to add different icon sets or even edit the icons on the fly without the need to restart EG for the changes to take place. this is essential for doing something like themes for the gui.

A few weeks ago i converted EG to wxPhoenix. There were much changes, but finally i got it working. But only with the core plugins.
Because of the lot of changes i thought it would be better to wait with it until the jump to Python 3.x. (if not completly drop in favour of a web based gui as WoLpH also mentioned).

topix wrote:A few weeks ago i converted EG to wxPhoenix. There were much changes, but finally i got it working. But only with the core plugins.
Because of the lot of changes i thought it would be better to wait with it until the jump to Python 3.x. (if not completly drop in favour of a web based gui as WoLpH also mentioned).

is there a web based gui package that is already made, or would something have to be made from the ground up?

It depends what you're looking for really.

I'm guessing that forms are enough for most cases and those are easy enough to generate using WTForms: http://wtforms.readthedocs.io/en/latest ... ourse.html

If you're looking for an example of a project that did something similar, take a look at PgAdmin4: https://www.pgadmin.org/
It switched from a pure C++ based interface to a Python based webinterface with a C++ backend.

the issue is you can't really drop wx. because it's used to receive windows messages via some kind of a hidden window (not 100% sure how it works) i believe it is. that is one piece of eg i have yet to mess with and figure out. I for one would love to see EG have the ability to run true gui less but because of the use of the wx.TreeCtrl to house all of the xml node data i am unsure of how you would go about storing the data in a some other container. i am still trying to wrap my head around how the xml data is turned into a class and then stored inside of the tree item. i don't see how there is enough information in the xml file to populate the information that is housed within one of the core classes. one day i am sure the light bulb will go on when i am tinkering with it.