EG & question about loose coupling

[gechu]

EDIT: As suggested by Livin, the initial question was fuzzy and needed further clarified. So here it is:

Goal:
"Application A" is running, but the user wants to start "application B". The transition should be seamless by involving as few button presses as possible. So a single press of a button should:

1. close the currently active application
2. change button layout
3. start new application


Eventghost tree design:
My design of the eventghost three basically consists of 3 different folders:

1. "Preset folder". Used to exclusively enable a folder which contains remote key buttons mapped to a unique application.
2. "Context folder". In this folder there are many different folders, one for each application that I want to control. Only one can be enabled at the same time. Each application has macros which functions like an API to the application in question.
3. Global macros. These are functions that does not have buttons mapped. Instead macros in this folder can be called directly by any of the macros in the "Context folder" or "preset folder".


Preferred solution:
In the context folder there are two application: applicationA and applicationB. Each of these applications have macros that correspond to the functions that I need to access using my remote.

ApplicationA implements a macro which is triggered by the event: CloseApplication (used to close the application in question, surprise!). A macro like that also exists in the context folder of ApplicationB. So when the event CloseApplication is trigged, even though it is implemented in each application´s folder located in the "context folder", it practise it will only result in that one macro gets triggeres since only once application folder can be enabled at a certain time in the context folder.

So to enable seamless switching from ApplicationA to ApplicationB the event called CloseApplication is triggered each time a new preset is set. The design of a preset folder may look like this:

Code: Select all

1. MyRemote.Button.X (event)
2. Trigger event: CloseApplication (implemented in the context folder belonging to ApplicationA)
3. Set exclusive folder to ApplicationB
4. Trigger event: ApplicationB.Start


The problem (I think) is that the CloseApplication event (step 2) does not reach the correct target (ApplicationA). The reason is that the macro which holds the CloseApplication event gets disabled by the "set exclusive folder" action (step 3) before the completion of the triggering of CloseApplication (step2).

The result is that the CloseApplication event actually triggers the CloseApplication implemented in ApplicationB, and in this case we want to start ApplicationB and not close it So I think that timing lies at the core of the problem. My understanding is that events are asynchroious in nature, and support loose coupling. Loose coupling in the sense that I don´t have to specify which CloseApplication event definition that I want to trigger.

Also, I think events are triggered at the end of a execution of macro event though they may be defined to be triggered early in a macro (haven´t checked the EG implementation for that, just my rather random observations). So what I need is a synchronious event, but I don´t think that is available. The closest I get is the "jump to macro action" which are synchroious but can only be used by specifying the exact macro that should be triggered, hence not loosly coupled. I´ve come up with a couple of workarounds:


Workaround 1:
Save the current preset´s macro that is used to exit the application in shared memory, and then execute it when a new preset is launched. Is that even possible?


Workaround 2:
Make all application macros globally available. Have the context folder which contain macros that map a remote button with an application function, and dynamically construct the event string that is used to close the current application. Example:

Code: Select all

Preset folder:
   ApplicationA
      close current application by constructing & triggering an event: TriggerEvent(CloseApplication + 'eg.globals.currentApplication')
      set global variable: eg.globals.currentApplication = ApplicationA
      start applicationA
      
   ApplicationA
      close current application by constructing & triggering an event: TriggerEvent(CloseApplication + 'eg.globals.currentApplication')
      set global variable: eg.globals.currentApplication = ApplicationB
      start applicationB

Context folder:
   ApplicationA
      myRemoteButton
      triggerEvent(ApplicationA.doSomething)
   ApplicationB
      myRemoteButton2
      triggerEvent(ApplicationB.doSomethingElse)

Global macros:
   ApplicationA
      ApplicationA.Close (event)
      ApplicationA.doSomething (event)
      ...
   ApplicationB
      ApplicationB.Close (event)
      ApplicationB.doSomethingElse
      ...

Workaround 3:
Store the current preset´s "close application macro" in a variable. Is it even possible?

Code: Select all

Preset folder:
   ApplicationB
      execute stored macro (ApplicationA)
      change preset to ApplicationB
      store ApplicationB´s "close application macro" in variable.
      start applicationB
   ..

[gechu]

EDIT: Completely rewritten question in the first post. Please see that one.

[Livin]

I read your posts and cannot decipher what you are trying to accomplish... dumb it down for me into "I want to do A, and I want B to happen"

I don't know of any way, other than using Python script, to set/read global variables... e.g. I don't think there is a plugin for it. But, you can use a plugin that writes a file to keep state data across reboots...
viewtopic.php?f=5&t=732&p=5349&hilit=variable#p5349

If you are simply trying to stop a macro from running, that is dead simple... set it to disable via another macro. There is also the Enable Exclusive which even makes that easier if you want to "toggle" one as enabled, while a set of others are disabled.

... but again, if you explain what (not how) you are trying to do there might be more options.

[gechu]

Livin, it was rude of me not to describe the question in sufficient details. Please read post #1 again.

[Livin]

Livin, it was rude of me not to describe the question in sufficient details. Please read post #1 again.

No worries, it was not rude at all. You were thinking "out loud" - we all do it.

OK, so I think you are doing, what I thought you might be doing

I do almost the same exact thing, I just separate into 2 different remote buttons - for 2 reasons...
1) It is easy to tell my wife/friends/etc... blue button is for XBMC, red button if for Live TV.
2) separate buttons allows me to 'restart' (due to my coding) an app if it hangs, does not start (IR did not get there), etc... simply by pressing that color button.


Using one button to "toggle" apps (which I was going to do initially) is easy too. Here's an example if the most simple, and straight, forward way to do it:

You need 2 sections

Context Controls <-- holds folders remote control command mapping, use this with Enable Exclusive
- App1
- App2

Context Switching <-- holds folders for launching/closing apps. Once of these
- macro: Start App1 <-- two of these, one for each app
--- Trigger <whatever you set your trigger as - in your case, your button>
--- Disable Macro (Start App1)
--- Enable Macro (Start App2)
--- Close App2
--- Enable Exclusive App1
--- Launch App1

... as you can see, you can Disable a Macro and it will still finish running.

There are a lot more things you can do, which also makes things more complex, but can add some redundancy and cool factor:
* automatically enable/disable Context Controls based on what EG detects is running
* automatically close some/all other apps when EG detects a specific app running

... I do some of this. I call them Activities. Basically, what 'happens' when a specific App is in use/launched. Example: I have a macro where EG detects when an app launches, it then closes other apps as specified. This allows me expand it easily in the future by adding, as needed, to that one Macro and not need to change it in several places. This method creates more folders and complexity at the beginning but allows more flexibility in several ways I have not mentioned. But, if you are not going to do anything complex with multiple apps, just use the first example I gave.

Hope that helps

[gechu]

Hi Livin and thanks for sharing your design.

Would you like to make your configuration available? Especially interested in the last example you gave.

[Livin]

Attached.

[gechu]

Hi all, thought I´d write a little update on my experiences with EventGhost. My configuration is still work in progress, but I hope it may be useful for others even in the state it is right now.

Features:
- Seamless switch between application regardless of the switch is between computer based app like XBMC and an external device like a PS3.
- Dynamic button configuraiton loading - if application is brought to front, then load the related button configuration (only valid for computer based apps)
- Start application on correct display (if projector available, then the output should be placed there)

Design ideas:
- Two layer triggering design. First layer connects a remote control event with a application event, and the second executes the actual command. Example: remote contro event "PS3.Button.Enter" triggers Application event "XBMC.Select", which in turn executes the actual command to XBMC. The reason I use this design is that when I start a new application, I want to close the "previous" one, I must be able to target the close comand for the "previous" application even though that application´s button configuration may not be active.
- "Jump action" is used where a synchronious call is required, useful when sequence and most importantly timing is required. If not, always do an asynchronious call by triggering an event.

Hardware:
- PS3 remote (late 2011 one)
- Twisted Melon's Manta TR1
- 4x2 HDMI Matrix Switcher from HDcable.co.uk

Configuration file: https://dl.dropbox.com/u/5227529/eventg ... _gechu.xml

EventGhost team, thanks for an excellent app!

EDIT: changed note about "two layer triggering design"

[Livin]

I like your monitor seletion and placement... I'll be trying out eg.plugins.Window.MoveTo(0, 0, 1) myself

Your label of "two layer triggering" confused me for a second... I thought it might be something "new"... but what you are doing is normal/standard for EG.

Also just an FYI... Closing an app does not require their buttons to be active... you can close XBMC simply by telling EG to close it - it does not require the native XBMC keystrokes or IR.

[gechu]

Your label of "two layer triggering" confused me for a second... I thought it might be something "new"... but what you are doing is normal/standard for EG.

Thanks for pointing it out, noticed that my explaination was wrong since I forgot the last step. I´ve updated my previous post with the fix. The triggering looks like this:
First layer: Remote control event triggers application event
Second layer: Application event triggers the executes an application command

Also just an FYI... Closing an app does not require their buttons to be active... you can close XBMC simply by telling EG to close it - it does not require the native XBMC keystrokes or IR.

Hope I haven´t fundamentally misunderstood something here. I use my remote to control many different applications, but not at the same time. So if app A is active, and I want to close app B, then I have no possibly to reach the "close" command for that application unless I change the context folder to app B. The way I solve that problem is as earlier mentioned by using the "two layer triggering" design in combination with a couple of variables to keep state. A global variable for keeping the name of the application to be closed (referred to as "PreviousApplication" in my configration), is used to dynamically construct the "close event". Example: if PreviousApplication = XBMC, then I make sure XBMC has an event defined which is named "XBMC.Close". So by combining a global variable PreviousApplication (value = XBMC) with ".Close" I can generate the event that is used to close the "previous" application (XBMC.Close).

My design should be easy to expand/scale since only stuff related to i.e. XBMC is kept in at the same place. So I don´t list all the other applications or external equipment´s "close commands" in the end of the XBMC.Start command even though that work in practise. Or in other words, I strive for low coupling and high cohesion.

Update:

To handle my display configurations I have to use an external tool to set primary display. Here is a batch command for setting up primary monitor in a single display configuration:
"C:\Program Files Portable\12noon Display Changer\dc64cmd.exe" -monitor="Dell U2312HM DVI" -apply -primary -width=1920 -height=1080

And here is is for extended screen:
"C:\Program Files Portable\12noon Display Changer\dc64cmd.exe" -monitor="Dell U2312HM DVI" -more -primary -width=1920 -height=1080
"C:\Program Files Portable\12noon Display Changer\dc64cmd.exe" -monitor="Generic PnP Monitor" -apply -secondary -lx=1920 -ty=0 -width=1920 -height=1080

[Livin]

Hope I haven´t fundamentally misunderstood something here. I use my remote to control many different applications, but not at the same time. So if app A is active, and I want to close app B, then I have no possibly to reach the "close" command for that application unless I change the context folder to app B. The way I solve that problem is as earlier mentioned by using the "two layer triggering" design in combination with a couple of variables to keep state. A global variable for keeping the name of the application to be closed (referred to as "PreviousApplication" in my configration), is used to dynamically construct the "close event". Example: if PreviousApplication = XBMC, then I make sure XBMC has an event defined which is named "XBMC.Close". So by combining a global variable PreviousApplication (value = XBMC) with ".Close" I can generate the event that is used to close the "previous" application (XBMC.Close).

Well, yes... you are not understanding what EG can do and over complicating your macros. You might want to spend more time looking around the Wiki and the Actions to see what they can do.

As I stated in the last post "Closing an app does not require their buttons to be active... you can close XBMC simply by telling EG to close it - it does not require the native XBMC keystrokes or IR." This is a built-in function of the Windows OS - EG is smart and uses Windows OS features... not just what the app itself provides. If EG only used what the app provided (and passed commands), EG would be nearly worthless.

EG has a 'Close' action... so the macro would have:

Find Window
Close


Also, in a previous post you stated using Jumps made macros Synchronous (definition: occurring at the same time) and Triggers made them Asynchronous. That is actually backwards. Jumps stop the current macro, this by definition your macros run Asynchronous - one after the other. A Trigger starts another macro while the current macro is still running... thus these are Synchronous.

[gechu]

Well, yes... you are not understanding what EG can do and over complicating your macros. You might want to spend more time looking around the Wiki and the Actions to see what they can do.

As I stated in the last post "Closing an app does not require their buttons to be active... you can close XBMC simply by telling EG to close it - it does not require the native XBMC keystrokes or IR." This is a built-in function of the Windows OS - EG is smart and uses Windows OS features... not just what the app itself provides. If EG only used what the app provided (and passed commands), EG would be nearly worthless.

EG has a 'Close' action... so the macro would have:

Find Window
Close

I am very well aware that it is possible to close an application in many different ways. This is not what the solution I present was about. It is rather about how to invoke the actual close command (and not how the command is carried out).

Also, in a previous post you stated using Jumps made macros Synchronous (definition: occurring at the same time) and Triggers made them Asynchronous. That is actually backwards. Jumps stop the current macro, this by definition your macros run Asynchronous - one after the other. A Trigger starts another macro while the current macro is still running... thus these are Synchronous.

I don´t agree with you, even though I haven´t read any EG docs about this My take is that a synchronous call will halt the current macro (A) and load the "jump to" macro (B), and it will wait and resume execution of macro A when the macro B is completed. If macro B instead would be called by an event (async), then both macro A and macro B could be executed in parallel, with no interdependence at all. That´s why async calls often is the preferred choice to avoid performance bottlenecks.

[Livin]

You posted your solution, like it was something "new". I assumed you being a noobie to EG were not aware of an easier way to do the things so I was giving you options to make things easier an utilize EG's powerful features. If you don't want to do it, that is fine.

enjoy EG

[gechu]

Hi again, of course I´d like to know if there is an easier solution to the problem. The solution is new in the sense that I´ve never seen anyone mention it before. And you still haven´t convinced me that you understand the problem behind the solution. Until you do, there is certainly no need to talk about what is an easy solution.