Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

I have a legacy brew applet that I've updated to run under BrewMP. This applet normally gets launched in the background (ISHELL_StartBackgroundApplet hands me an EVT_APP_START_BACKGROUND) by a separate applet based on various conditions, but the user also the option of launching explicitly from an app menu icon.  I currently handle EVT_APP_START in this icon launch scenario, but that brings me to the foreground. Since my applet needs to be in the background (its configuration determines when and how to come to the foreground), it then does CloseApplet to move itself into the background.

The problem is that this foreground to background transition is accompanied by a white screen flash that looks bad. What I'd prefer to have happen is launch directly to background when user launches from the icon.

Ignoring philosopical ui questions about whether that's an appropriate thing to do, I see that if I handle EVT_APP_START_WINDOW instead of EVT_APP_START, my applet will launch directly to the background. So I (actually, someone I work with) tried a very quick test, and it seemed to produce the desired result. We start in the background, with no screen flash.

 

The question then is whether it's safe to make just that single change in my applet, or does handling EVT_APP_START_WINDOW mean my applet is declaring itself to be a 'Windowed Application' and so must change to support a different set of constraints? (e.g., with regard to event handling and memory management, as described in the 'Window Manager Technology Guide')

 

thanks.

-steve

 

Note that if you handle EVT_APP_START_WINDOW then your application will start in window mode. When an application is started, it is first sent an EVT_APP_WINDOW_START event. If the application handles this event, it is moved to the background and does not receive an EVT_APP_START event.
https://developer.brewmp.com/resources/tech-guides/window-manager-techno...
Also note that, There are a number of differences between non-windowed applications and windowed applications, which are described below.

Windowed applications do not receive EVT_APP_SUSPEND or EVT_APP_RESUME events.
Windowed applications receive user events (key events, pointer events, etc) through the IWidget used to create a window instead of through the IApplet_HandleEvent function.
Multiple windows can be shown on the screen at the same time. Only one non-windowed application can be shown at a time.
Windowed applications should handle the AVK_CLR event and take appropriate action. Non-windowed applications could simply ignore this event and use the default BREW handling.
Windowed applications do not need to enable touch. Window Manager does this.
Windowed applications should not access IDisplay or call functions that do implicit display updates such as IImage_Draw() and IControl_Redraw().
Windowed applications do not receive the EVT_SCR_ROTATE, EVT_FLIP, or EVT_KEYGUARD events. Windowed applications should use notifications instead.
Windowed applications get their extent from the Window Manager through IWidget_SetExtent() instead of through IDisplay as non-windowed applications do.
Windowed applications run in the background and are not listed in the application stack (IAppHistory).
Brew MP maintains separate stacks for non-windowed and windowed applications.

Note that if you handle EVT_APP_START_WINDOW then your application will start in window mode. When an application is started, it is first sent an EVT_APP_WINDOW_START event. If the application handles this event, it is moved to the background and does not receive an EVT_APP_START event.
https://developer.brewmp.com/resources/tech-guides/window-manager-techno...
Also note that, There are a number of differences between non-windowed applications and windowed applications, which are described below.

Windowed applications do not receive EVT_APP_SUSPEND or EVT_APP_RESUME events.
Windowed applications receive user events (key events, pointer events, etc) through the IWidget used to create a window instead of through the IApplet_HandleEvent function.
Multiple windows can be shown on the screen at the same time. Only one non-windowed application can be shown at a time.
Windowed applications should handle the AVK_CLR event and take appropriate action. Non-windowed applications could simply ignore this event and use the default BREW handling.
Windowed applications do not need to enable touch. Window Manager does this.
Windowed applications should not access IDisplay or call functions that do implicit display updates such as IImage_Draw() and IControl_Redraw().
Windowed applications do not receive the EVT_SCR_ROTATE, EVT_FLIP, or EVT_KEYGUARD events. Windowed applications should use notifications instead.
Windowed applications get their extent from the Window Manager through IWidget_SetExtent() instead of through IDisplay as non-windowed applications do.
Windowed applications run in the background and are not listed in the application stack (IAppHistory).
Brew MP maintains separate stacks for non-windowed and windowed applications.