New version 0.5.0-beta5 is out

[topix]

0.5.0-beta5 (2016-12-24)

Enhancements:

• Finish the new "Add Event..." dialog #110 (topic2k)
• Documentation improvements #114 (per1234)
• Bring back the -debug command line argument #118 (topic2k)
• Popup menu and hotkey for "Select All" in LogCtrl #124 (topic2k)
• Adds GUID to treeItems #133 (kdschlosser)
• [Webserver] plugin updates (with commit for each version) #134 (per1234)
• [EventGhost] add skin selection to ShowOSD #136 (topic2k)

Fixed bugs:

• [Broadcaster] fix Unicode encoding and decoding #122 (david-mark)
• Fix typo in build warning message #135 (per1234)

[pearbear]

Thanks topix! I really appreciate the work you do on administration of the GitHub repository and the improvements to EventGhost. And just a note to everyone about the Webserver plugin updates: Pako, Sem;colon, m19brandon, and davidmark deserve all the credit on that work and their names are on the individual commits but because of the way the automatic changelog generation works it put my name on it because I submitted the PR.

[kgschlosser]

I would like to give a description on how the GUID on the tree items works. Hopefully this at some point be a replacement for the XmlIdLink that is used when manipulating a tree item from an action.

In case you have not seen this but if you add the action to Disable a folder/macro/action/plugin then you copy the action as python and paste it into a script you will see the following

Code: Select all

eg.plugins.EventGhost.DisableItem(XmlIdLink(4))

the above line cannot be executed from a python script or command. this is due to the fact that XMLIdLink is a string representation of a class that really does not exist. it is a pointer to a dynamically created TreeLink object and that object is not callable and XMLIdLink as a name has no reference to TreeLink in any way and is also not in the __builtin__ module.

so what I have done is created a new eg class called eg.GUID. and what this class does is issues out unique GUID's to tree items if it doesn't have one. it will create GUID's for all existing tree items as well as any newly created ones so you will experience a save eventghost even if you didn't change a thing. this is because it has added all of the GUID's and wants to save them in the EG save file. so this is not a bug it's by design.

if you have a need to use any of the actions that utilize the XmlIdLink and would like to have the ability to run those from a script you will have to open the EG save file and locate the item you wish to control via an action. if you have an extensive tree then it would be easiest to add an action dealing with that item copy the action as python. paste it into a script and get the number from it. then search you EG save file for id="THE_NUMBER" and you should be able to locate the GUID for that item it will be XML_GUID="{SOME_GUID}". copy only the quoted GUID (braces and quotes also) then go back to your script and delete the XmlIdLink() and put in it place eg.GUID(PASTE_HERE) in it's place. paste the copied GUID into the PASTE_HERE and you can now run the script "blacklisted" actions from a script.

Code: Select all

eg.plugins.EventGhost.DisableItem(eg.GUID("{AA41EA4C-A3B0-4480-A230-C471107BF597}"))

this is the first step so I want to make sure issuing the GUID's works 100% and that those of you that use the GUID's in a script do not have any kind of a problem. the TreeLink class in EG is extremely nested into the code. and is going to take some time to alter or remove. and that is also if it is decided that the XmlIdLink is going to be depreciated

[blaher]

When I minimise EG, it clears the log. Hopefully this isn't by design.

[pearbear]

When I minimise EG, it clears the log. Hopefully this isn't by design.

This issue has been reported at:
https://github.com/EventGhost/EventGhost/issues/138

[kgschlosser]

don't know about the log. I will tinker with it tomorrow to see what's going on with it.

[kgschlosser]

and Oh

beta version bug reports go here

viewforum.php?f=15

[rdgerken]

I would like to give a description on how the GUID on the tree items works. Hopefully this at some point be a replacement for the XmlIdLink that is used when manipulating a tree item from an action.

In case you have not seen this but if you add the action to Disable a folder/macro/action/plugin then you copy the action as python and paste it into a script you will see the following

Code: Select all

eg.plugins.EventGhost.DisableItem(XmlIdLink(4))

the above line cannot be executed from a python script or command. this is due to the fact that XMLIdLink is a string representation of a class that really does not exist. it is a pointer to a dynamically created TreeLink object and that object is not callable and XMLIdLink as a name has no reference to TreeLink in any way and is also not in the __builtin__ module.

so what I have done is created a new eg class called eg.GUID. and what this class does is issues out unique GUID's to tree items if it doesn't have one. it will create GUID's for all existing tree items as well as any newly created ones so you will experience a save eventghost even if you didn't change a thing. this is because it has added all of the GUID's and wants to save them in the EG save file. so this is not a bug it's by design.

if you have a need to use any of the actions that utilize the XmlIdLink and would like to have the ability to run those from a script you will have to open the EG save file and locate the item you wish to control via an action. if you have an extensive tree then it would be easiest to add an action dealing with that item copy the action as python. paste it into a script and get the number from it. then search you EG save file for id="THE_NUMBER" and you should be able to locate the GUID for that item it will be XML_GUID="{SOME_GUID}". copy only the quoted GUID (braces and quotes also) then go back to your script and delete the XmlIdLink() and put in it place eg.GUID(PASTE_HERE) in it's place. paste the copied GUID into the PASTE_HERE and you can now run the script "blacklisted" actions from a script.

Code: Select all

eg.plugins.EventGhost.DisableItem(eg.GUID("{AA41EA4C-A3B0-4480-A230-C471107BF597}"))

this is the first step so I want to make sure issuing the GUID's works 100% and that those of you that use the GUID's in a script do not have any kind of a problem. the TreeLink class in EG is extremely nested into the code. and is going to take some time to alter or remove. and that is also if it is decided that the XmlIdLink is going to be depreciated

Thank you for this!!

[kgschlosser]

You are welcome. Something I thought would be useful. I do know I like being able to enable or disable macros programmatically. Reduced my tree size by quite a bit.

If you experience and issues with it. Or have any questions feel free.

Enjoy

K

[pearbear]

if it is decided that the XmlIdLink is going to be depreciated

I use Git for version control of my tree file. Half the time when I make a change to the tree the value of a whole bunch of unrelated ids and any references to those ids are automatically changed. This makes it a real hassle to see the meaningful changes from looking at the diff. I end up doing one commit for the actual change and another for the id changes but that's really time consuming to look through hundreds of changes to separate them out every time I make a simple change. It seems like replacing the id with the guid would have the benefit of preventing unnecessary changes to the tree source.

[kgschlosser]

@pearbear

you completely lost me. LOL

EDIT

never mind. i got ya. and the id is not a unique number and if unused will come up again. GUID's are some crazy odds of that happening.

[kgschlosser]

the plugin GUID cannot be used because of things like multiloading. so if a user has the same plugin loaded 2 times and then you go and disable the plugin programmatically it would disable both LOL.. well it wouldn't because the GUID's and tree items are stored in a dict so the last to load would overwrite.

[pearbear]

the plugin GUID cannot be used because of things like multiloading. so if a user has the same plugin loaded 2 times and then you go and disable the plugin programmatically it would disable both LOL

Sorry, I'm talking about the XML_Guid property, not Guid. I thought that was clear from the context. Multiloaded plugins get unique values of XML_Guid:

Code: Select all

        <Plugin XML_Guid="{9C838741-6C85-4142-B538-EE6EEE74C7A5}" Identifier="DesktopRemote" Guid="{5DFFBD61-7582-4D6F-8EA9-9CB36284C9CF}" File="DesktopRemote">
            gAIpLg==
        </Plugin>
        <Plugin XML_Guid="{F23858BF-9027-49BB-9D31-A0BCDA95F8C3}" Identifier="DesktopRemote2" Guid="{5DFFBD61-7582-4D6F-8EA9-9CB36284C9CF}" File="DesktopRemote">

What I'm saying is that now that you've added an XML_Guid to every item in the tree there's no reason for macros to have an id property(id="1884" in the example below), it's redundant to have two ids.

Code: Select all

<Macro Name="eventLogSilent" id="1884" XML_Guid="{F0E32474-9AED-4656-A3DD-491C7378BD6C}">

The problem with the change is it would break tree files backwards compatibility with previous versions of EG but if you get rid of XmlIdLink that would happen anyway.

[kgschlosser]

I know about the xmlguid. I made it. What I was saying was it's unfortunate I am unable to use the plugin GUID. But this is due to multiloading. Because the plugin if installed 2 times shares the same GUID. But if you want to programmatically disable one. You would only be able to do the one that appeared last in the plugin list.

And it is redundant but code has to stay the way it is and everything needs to keep on using the xmlID for now. But... Just because you only see an ID for some items doesn't mean there isn't one issued for every item. There is. And it is heavily used in the back end of EG. And to shift from this ID to the GUID is no small undertaking. And I also have to make sure the old I'd method gets converted over to the new. When eg launches.

If you look in the code any time you see a reference to Tree link or an attribute that ends in a .target is a call to a tree link attribute. And slot of times if there is a call to .parent it could be one as well. And with the voodoo magic code EG has it is no small task to track the whereabouts of a single treelink instance.
I would have e to have a __get__ set into a specific item. And have it print who got it and what thread it was in when it was gotten. And I would have to look into this but to find out what the attribute name it was set to. Kind of like a GPS tracker but for the inside of EG code. I wonder if they make something like that to map the path showing the code that has been run.

[kgschlosser]

Any changes would have to be made in such a way to be able to phase out the use of the ID so it would still create the IDs and write them in the file if needed. But the core of any EventGhost versions moving forward would not use it. It would be there for pure backwards compatibility. And after a decimal version jump or so. To remove even entering an ID. So phase it out. With the rate that EG progresses in versions it could be a decade to get to 0.6

Lol

It's a joke but not. I truly hope EG keeps moving forward