edward.81 wrote:I,m sorry but i have to say that satory is a fail paragoned to eventghost.
The interface concept that u trying to build is really confusing and in certain aspect are a limitation for the user.
With eventGhost u can use to anything and u can stack unlimited number of action in every macro. in satory i can see...4 group action ?
U can drag and drop the event from log to the tree...here you have to write down the event.
Thanks for the try anyway.
My feeling on EG is that it is an interface only developers can love. The tree is effective and very flexible, but you have to configure everything. For example, adding a new application to control requires pushing every button on your remote and drag and dropping the events to the correct macro. For every application! And then dealing with exclusion macros, and jumpIf, etc is confusing to many as well.
Obviously SatoriHub is confusing to you. Hopefully that can be fixed with some adjustments to the UI and more documentation.
I believe most users
start with EG/SatoriHub because they want to control their computer with an IR remote. So I took the fundamental task - associating events to actions - and broke that into three groups. There are Remote events, Autonomous events and Generic events. In EG everything is a generic event, where you need to define the trigger event (drag and drop from the log), then assign the actions under the macro. SatoriHub provides this functionality as Generic events, but I expect it not to be used very often - the other ways to configure event handling (Remote and Autonomous) are intended to help with most use cases and be easier to use.
How's how it is intended to work. The goal for remotes is to be able to assign actions to every button and every application based on the button name, without worrying about events at all. Just double-click on the icon in the button's row and the application's column and assign the action(s) you want. And if plugins use the standard button names for actions, those actions will already be associated with the buttons without any configuration from the user.
Autonomous actions are ones that are generated without user interaction (System.Idle, DirectoryWatcher type stuff). The idea is for the plugin to define these, so instead of waiting for the event to occur so you can drag and drop, you just find the event in the list on that tab and define the action there. You can certainly create these a Generic events, but I thought it would be easier to select the event from the list of events produced by the plugin rather than waiting for the event so you could drag and drop. Unfortunately, there are probably quite a few events that should be listed as autonomous that haven't been set up that way yet. I think this is more growing pains than a flaw in the design, though.
The goal is to make the most common tasks easiest, while still allowing all of the functionality you can achieve with EG.
With the above in mind, SatoriHub still may not do what you want (hopefully it makes more sense why it was designed the way it is, though). No problem, thanks for giving it a try and providing feedback. If you don't mind, though, I would appreciate more detail on what you are trying to do that SatoriHub doesn't support. The Group function's limit to 5 actions is only in the UI, adding more comma separated actions in the text box is certainly not convenient but is possible. This is something that has been in the back of my mind to enhance, but I thought the need for it would be extremely rare.
SatoriHub is also adding more functionality to the plugins. For instance, I've added a StartOrBringToFront action for program plugins like TheaterTek and JRMC. In addition, I've combined the StartOrBringToFront with a LongPress action that starts/brings to foreground on short press and exits the app on longpress. So this common functionality is a single action instead of several. The idea being to have one person (the plugin developer) do the work, so that all the end users get more functionality with less configuration.
Brett
