WO2016107852A1

WO2016107852A1 - Method for changing the z-order of windows on the graphical user interface of a portable device

Info

Publication number: WO2016107852A1
Application number: PCT/EP2015/081306
Authority: WO
Inventors: Jonas MIEBACH; Andreas ZEISER; Simon SCHWARZMEIER
Original assignee: Taptap Mobile Ug (haftungsbeschrankt)
Current assignee: Taptap Mobile Ug (haftungsbeschrankt)
Priority date: 2014-12-29
Filing date: 2015-12-28
Publication date: 2016-07-07
Anticipated expiration: 2017-06-29

Abstract

A method for rendering a view on a graphical user interface (200) is disclosed. The graphical user interface (200) has at least two windows (202, 204, 206) and a different window permission is associated with ones of the at least two windows (202, 204, 206). The method comprises receiving (402, 608) an input event, handling (610), according to the z-order, the input event by a plurality of views, processing (614) the input event by a lowermost one of the plurality of views, if none of the other ones of the plurality of views processes the input event, inaugurating (502, 620) in the lowermost one of the plurality of views an action based on the input event, the action including a display of a view in the graphical user interface (200), and assigning (622, 624) the action to the one of the at least two windows (202, 204, 206) having the topmost z-order, if the action has the corresponding window permission.

Description

Title

METHOD FOR CHANGING THE Z-ORDER OF WINDOWS ON THE GRAPHICAL USER INTERFACE OF A PORTABLE DEVICE

Description

Field of the Invention

[0001] The present invention relates to a method for rendering a view on the graphical user interface of a portable device initiated by a user input on a device wallpaper.

Background of the Invention

[0002] Over the years consumption of digital media has moved substantially away from sta- tionary devices to portable devices, such as but not limited to mobile phones, tablet computers and other kind of other wearable devices. A lot of effort has been taken to simplify a user interface to such portable devices in a manner to enable users to get faster access to relevant content of digital media accessible by the portable devices. [0003] One component in operating systems of the portable devices that has been used to date very rarely in order to simplify access to the content is the device wallpaper. The device wallpaper (alternatively termed background) is a digital image, which is used as a decorative background of the graphical user interface (GUI) on the screen of the portable device. The device wallpaper is typically a photo, a drawing or another form of graphical representation and it is usually used for the desktop on a computer, while on the portable device the device wallpaper is usually a background for a home screen. The operating system of the portable device will typically come with pre-installed images to set as the device wallpaper and will also allow users to install their own images to be used as the device wallpaper. [0004] In the GUI of the screen of the portable device, the device wallpaper is located "behind" other user interface elements, such as icons or widgets. From the user's point of view, the device wallpaper is the element of the GUI which is the farthest from the viewer. The user will see the other interface elements located in front of the device wallpaper. [0005] Previously the only functionality of the device wallpapers was the aesthetic embellishment of the portable device. In order to bring additional functionality to the device wallpaper, modern operating systems of the portable devices, such as the Android operating sys- tern, allow installment of wallpaper applications in addition to home screen applications. The wallpaper applications are those applications that manage the wallpaper of the portable device. The home screen applications are those applications that manage the home screen including the user interface elements on the home screen such as icons. [0006] Wallpaper applications are located below home screen applications on the display of the device. As a result, the user interface elements of the home screen application overlap some parts of the wallpaper application but do not fully obscure the device wallpaper.

[0007] One important functionality of a wallpaper application is to enable users to actively interact with the wallpaper i.e. by touching a spot on the device wallpaper, which is not overlapped by the home screen. The reaction to user input endows the device wallpaper with a new functionality and simplifies the way in which the users are able to navigate on the portable devices. [0008] The current operating systems of the portable devices, such as Android, iOS or Windows Phone hinder this type of the user interaction. For example, the Android operating system artificially delays the navigation from the device wallpaper to another content. This time delay leads to an unsatisfactory user experience. In order to ensure a satisfactory user experience, a method and system is required that allows the users to navigate to the required content upon the user input on the device wallpaper substantially instantaneously.

[0009] A number of patent documents are known that describe interaction with a view. For example, US patent application US 2012/0102428 Al describes systems and methods that allow interaction with a transparent view located on top of a desktop GUI.

[0010] The US '428 describes systems containing a system application maintaining a desktop GUI interface comprising elements such as the wallpaper image and icons for folders. The described systems are limited in a way that no other application can create a replacement for the system application maintaining the desktop GUI. For example, a user of the described systems of '428 is not able to install and run an application with an extended feature set as a replacement of the system application maintaining the desktop GUI having a default feature set.

[0011] Another limitation of the systems of '428 is that the system application maintaining the desktop GUI combines the wallpaper image as well as the icons. As described in the paragraphs above, in terms of good user experience a separation of the wallpaper image and the icons is desirable. For example, a system including separation of wallpaper image and icons would give the user the ability to change the application providing the wallpaper image without having to change the application providing the icons.

[0012] It should be noted that the term "window" or "application window" as used in US '428 has the same meaning to the term "view" used in the present disclosure. The term "window" as used in the present disclosure is defined as a container holding multiple ones of views assigned to the window. A term with a similar meaning to the term window defined in the present disclosure is not used in US '428.

[0013] The created views in US '428 are grouped into a single space and the system therefore lacks the ability to group views into logical units. Such logical units may be desirable for the systems in order add another hierarchy of views, such as units of views based on the importance of one of the views to the user. For example, it would be desirable for the system to group views showing system information in a first one of the logical units with a highest importance and other views, such as applications views, into a second logical unit with a normal importance. On the screen, the views inside the logic unit with the highest importance could then be displayed on top of the views inside the logic unit with the normal importance.

[0014] The methods described in US patent '428 allow a first set of applications to intercept any one of input events before the input events are passed to other ones of the applications located "behind" or in a lower z-order of the first set of applications intercepting the input events. To do so, the first set of applications creates a transparent view and places the transparent view on top of the views of the other ones of the applications. If the input events occur at the location of the transparent view, the first set of applications, i.e. the applications associ- ated with the transparent view, are able to handle the input events before the input events are passed to the other ones of the applications.

[0015] One example of the methods of US patent '428 is that one of the applications can in- tercept the input events targeted to the home screen application of the portable device. To do so, the application places the transparent view "above" (i.e. in higher z-order) the home screen of the portable device. If the user of the portable device generates the input events at the location of the home screen, the input events are passed to the application associated with the transparent view first so that the application associated with the transparent view can handle the input events before the input events are passed to the application associated with the home screen.

[0016] A second patent document is known that describes interaction with a view. US patent application US 2011/0179380 Al describes systems and methods that allow interaction with a hidden application.

[0017] US '380 describes systems running two or more applications at the same time with the interface element associated with one application being fully obscured by the interface element associated with another one of the applications. If the interface element for the applica- tion is obscured, the interface element is not visible to the user of the portable device. The interface element for one of the applications is fully obscured if the interface element of the other application is placed on the same coordinates of the screen and has a higher position in the GUI order than that of the the obscured application. [0018] Furthermore, US '380 describes methods for allowing at least two applications to receive input events at the same time and allowing the hidden application to handle the input event without allowing the application obscuring the hidden application to handle the input event.

Summary of the Invention [0019] This disclosure describes a system and a method for enabling users of portable devices to interact with the device wallpaper visible to the user of the portable device, the device wallpaper being located below the home screen of the portable device. [0020] This disclosure describes a process for portable devices enabling wallpaper applications to instantaneously open a view initialized by a user input on the device wallpaper visible to the user of the portable device, circumventing limitations set by the operating system.

[0021] The method and system of the current disclosure enables the users of the portable de- vices to interact with the device wallpaper visible to the user of the portable device in order to get faster access to relevant content of digital media.

Description of the Diagrams [0022] FIG 1A illustrates an exemplary process of requesting required permissions by an application during the installation of the application.

[0023] FIG IB illustrates an exemplary process of checking and requesting a required permission at runtime of an application.

[0024] FIG 2 is an illustration of an exemplary system of rendering a graphical user interface of a portable device respecting the z-order of GUI elements.

[0025] FIG 3 illustrates an exemplary process of classifying views in the z-order.

[0026] FIG 4 illustrates a flow chart of an exemplary system process of dispatching an input to the views of the graphical user interface on a portable device respecting the z-order.

[0027] FIG 5 is a flow chart, which represents an exemplary process of an application assign- ing a view to a window using the window manager and utilizing a permission.

[0028] FIG 6 is a flowchart of a specific process of creating and utilizing a permission to instantaneously assign a view to the system window upon an input on the wallpaper window circumventing a technical limitation set by the operating system when navigating from the wallpaper to a view.

[0029] FIGs 7, 8 and 9 illustrate an aspect of the invention on a device.

Description of the Embodiments of the Invention [0030] The term portable device used in this disclosure includes, but is not limited to, a smartphone, tablet computers or other portable devices, such as wearable devices.

[0031] One characteristic of operating systems of the portable devices is that the operating systems allow the users to install applications onto the portable device. The installed applications are computer programs or a set of software modules that the user perceives as a single entity as a tool for a well-defined purpose. The application software cannot run by itself but is dependent on the operating system to enable execution on the portable device. The operating system manages and integrates the portable device's capabilities but does not directly perform tasks that benefit the user. The operating system serves the application, which in turn serves the user.

[0032] The operating systems of the portable devices give users control over the access that the application has to resources, such as data, the user's contacts or hardware. The hardware includes an in-built microphone or a camera and may include other hardware such as an RFID chip. The operating systems provide interfaces for the user, either graphical interfaces or programmable interfaces, to grant or revoke specific permissions required by an application, i.e. during the installation of an application or at the runtime of an application after an application has been installed and started.

[0033] The user's decision whether a specific permission is either granted or revoked is stored by the operating system on the portable device. The operating systems may also provide additional programmable interfaces to applications to determine whether the user has granted a specific permission for the application.

[0034] Furthermore, the operating systems may also include programmable interfaces for applications to ask the user for granting a specific permission at the runtime of the application to access one of the resources. For example, one of the applications may include a feature for taking pictures and may ask the user to grant the permission for accessing the camera re- source, if the application determines at runtime that the user has not yet granted the application the permission for accessing the camera. [0035] FIGs 1A and IB represent two variants of exemplary operating systems. In FIG 1A the exemplary operating system is illustrated which asks the user during the installation of the application to grant required permissions by the application to be installed in step 110a. If the user in step 110a declines to grant the required permissions in step 120a, the installation pro- cess will be aborted by the operating system. In case the user grants the required permission in step 130a the installation process will be finished.

[0036] FIG IB illustrates an exemplary operating system which includes programmable interfaces for the applications to determine at runtime of the application whether the specific per- mission is granted by the user to the application and, if not, to ask the user to grant the required permission for the application at runtime. In contrast to the operating systems illustrated in FIG 1A, the operating system illustrated in FIG IB implementing such programmable interfaces may allow users to install the applications without the need to review and to grant the required permissions by the application during the installation process. After the applica- tion has been installed and started the application may check whether the specific permission has been granted by the user for the application in step 102. If the specific permission is granted in step 130b, the application can continue without asking for granting the specific permission. If on the other hand, the specific permission has not yet been granted by the user for the application in step 120b, the application may utilize the programming interface pro- vided by the operating system to ask the user to grant the specific permission for the application in step 110b. After the user has been asked to grant a specific permission for the application, the application can again check if the specific permission has been granted in step 102. If the specific permission has been granted by the user to the application in step 130b, the application can continue. If the user declined to grant a specific permission required by the applica- tion in step 120b, the application may ask again in step 110b or may exit the process.

[0037] The operating systems of the portable devices are equipped with a graphical user interface (GUI) for visualizing the contents of applications. FIG 2 illustrates an exemplary GUI rendering system 200 for rendering the GUI on a display of the portable device. The GUI comprises a plurality of virtual elements, which comprise graphical icons and visual indicators. The users can interact with the virtual elements on the display by direct manipulation, i.e. by touching one or more of the virtual elements on a touchscreen on the display of the porta- ble device. The rendering of the GUI on the display is a software process that transforms the virtual elements into visual elements shown on the display.

[0038] The visual elements of the GUI are termed "views". A view contains logical opera- tions in order to transform data into a visual image during the rendering process. An application typically consists of multiple views. The entirety of all views of the application yield the representation of the application visible to the user in order to visualize its contents.

[0039] Inside the GUI rendering system 200, each one of the views must be assigned to a window. The windows act as containers for all of the views assigned to the window. The window can hold and display multiple ones of the views. During the GUI rendering process, the window initializes and provides a canvas for the screen and the GUI rendering system 200 enables the assigned views to draw their visual image on the canvas. [0040] The exemplary illustration of the GUI rendering system 200 in FIG 2 comprises three windows. The wallpaper window 202 contains a single, but is not limited to, view responsible for rendering a background of the portable device. The application window 204 contains the views from the applications installed on the portable device and the system window 206 contains specific types of the views for use by the operating system along with the views of those applications which have been granted with the specific permission by the user in step 130a or in step 130b as described in conjunction with FIGs 1A and IB.

[0041] Since multiple views must be rendered by the GUI rendering system 200, a common characteristic of the GUI on the portable devices is that the views may overlap, so that one of the views hides part or all of another one of the views. This is why the GUI rendering system 200 renders all of the views assigned to the windows 202, 204 and 206 in a well-defined order, which is called z-order. When two of the views overlap, their z-order determines which one of the views appears on top of the other one of the views. [0042] The z-order is defined by two rules as illustrated by FIG 3. Firstly, one of the views falls into a specific one of the windows. Each one of the windows is allocated to a z-order within the GUI in step 302. Secondly, the final z-order position of the view is defined by the window in which the view resides in step 304. [0043] The GUI rendering system 200 is able to group multiple ones of the views into windows and to enforce rules on each of the windows. For example, the GUI rendering system 200 may force applications to fulfil a set of rules before the applications are allowed to assign views of the application to one of the windows. These rules may vary from the type of application, or the type of window, or the type of the view to be assigned, or a combination of all of them. In the prior art, such as the US patent application US '428, there was no provision to assign rules to the application. [0044] One non-limiting example of such a rule is described in the paragraphs above. In order to assign one of the views to the system window 206, the application needs to hold one of the specific permission granted by the user of the device. This permission is required because otherwise malicious applications ("malware") might assign the views associated with the malware to the window with the highest z-order, here the system window, in order to gain visibility and "encourage" the users to initiate the malicious application.

[0045] As mentioned in the introduction of the present disclosure, another example of such a rule is that the system may apply a time delay before the view is rendered on the screen for those applications navigating from the wallpaper window to the application window.

[0046] Another characteristic of graphical user interfaces is the ability to interact with views. For example, a button view may be pressed by the user of the portable device on the touch screen to perform an action, an equivalent to a push-button as found on mechanical or electronic instruments.

[0047] As described in conjunction with FIG 2, the GUI of the portable device may contain multiple views. The operating system of the portable device determines which ones of the multiple views is a target view of the user input. For example, let us suppose that one of the GUIs contains two views A and B and that the view A is a view with a higher z-order than the view B. This could result in the view A partially or fully overlapping the view B on the graphical display. If the user input occurs on a screen location in which the view A overlaps the view B, the operating system requires an input handling system to decide which one of the views (view A or view B) is eligible to handle the user input. This input handling system uses the z-order of the views to determine the input handling of the user input. First the view with the highest z-order is eligible to handle the user input. If this view cannot or does not want to handle the user input the input handling system hands the user input over to the view with second highest z-order, and so on. In this specific (non-limiting) example, if the user input occurs on the screen location in which the view A overlaps the view B, the input handling system must allow the view A to handle the user input because the z-order of the view A is higher than the z-order of the view B. If the view A does not handle the user input, the input handling system must then allow the view B to handle the user input. [0048] The view handling the user input means that the view is able to react to the user input, for example a button view may change its appearance if the button view clicked. If the view is not able to react to the user input or if the view is simply not interested in handling the user input, then the view must not handle the input. In such a case other ones of the views of the GUI will be able to handle this user input.

[0049] FIG 4 shows a flowchart of an exemplary system for dispatching an input to the views of the GUI. The dispatch of the input may be, but is not limited to, the input of touch commands on a touchscreen or by voice input through a microphone by the user. Other examples include the use of an external device, such as a Bluetooth-connected mouse or keyboard, sending an input command to the portable device. FIG 4 exemplarily illustrates the process of input handling in case of the touch input.

[0050] Dispatching the input is the process of passing on information about the input to the views of the GUI for further processing. The process is based upon the z-order of the views and follows the structure of a waterfall. If one of the views of the GUI reacts to the input and subsequently handles the input (as illustrated above), the process of dispatching the input to other ones of lower z-ordered views will be stopped. Hence, the view with the lowest z-order receives the user input only if all of the other views with higher z-orders did not or were not able to handle the user input.

[0051] The process illustrated in FIG 4 is distinct from the methods described in US patent application US 2011/0179380 Al. First, the methods of '380 allow multiple ones of the appli- cations to receive the same input. Second, the application with the lower z-order is allowed to process the input without allowing the application with the higher z-order to process the input.

[0052] The information about the user input is represented as a model. The flow chart of FIG 4 uses the term InputEvent as the name for the model. The InputEvent may consist of properties x, y and an action property. The properties x and y represent the coordinates on the touchscreen at which the input has been generated, i.e. where the finger touched the screen of the portable device of this example. The action property describes the type of the input. For example, the Android operating system uses multiple types of the action properties to describe the action of the touch input. Examples of the action properties include ACTION_DOWN that defines that the user pressing the touch screen with his or her finger, or ACTION_UP that defines that the user releases his or her finger from the touchscreen.

[0053] The flowchart illustrated in FIG 4 starts in step 402 in which the user generates the input. This input may be the touch of the finger on the touchscreen. In step 404, the operating system transforms the incoming input into an InputEvent in step 406 that contains the information about the input.

[0054] In step 408 the operating system starts to dispatch the InputEvent 406 to the views of the GUI. This input dispatching system is now in state 410 meaning that the dispatching process has started.

[0055] As previously explained, the input dispatching system 400 respects the z-order of the views when passing the InputEvent to the views. That means that the first view receiving the InputEvent is the view with highest z-order within the system window 206 through step 412 since the system window 206 is the window with the highest z-order. If one of the views inside the system window 206 can handle the InputEvent 406, as indicated in step 413, the handling view will hand the InputEvent 406 and the further dispatching of the InputEvent 406 to other ones of the views will be stopped in step 418. This results in the state 420 in which the system is halted. If as a result of step 412 the InputEvent 406 is not handled by one of the views inside of the system window 206, the InputEvent 406 will be passed further in step 414. [0056] The step 414 passes the InputEvent 406 to the subjacent window, which is the application window 204. If one of the views inside the application window 204 handles the InputEvent 406, as indicated in step 415 the dispatching of the InputEvent 406 is stopped in step 418 and the system switches to state 420 in which the system is halted. If none of the views inside the application window 204 handles InputEvent 406 the next step is 416.

[0057] In step 416, the InputEvent 406 is passed to the window with the lowest z-order, the wallpaper window 202. The wallpaper window 202 is the last window receiving the InputEvent 406. If one of the views inside the wallpaper window 202 handles the InputEvent 406 in step 417, the dispatching of the InputEvent 406 is stopped in step 418 and the system is halted in step 420. If none of the views inside the wallpaper window 202 handles the InputEvent 406, dispatching of the InputEvent 406 simply ends in state 422.

[0058] The previous paragraphs illustrated the system that the operating systems of the porta- ble devices use in order to regulate the order in which the existing views are displayed as well as the order in which the existing views are eligible to handle user input. The next paragraphs explain the view handling system with details on how the applications are able to insert the views into the GUI, especially on how applications may utilize specific permissions to insert views into specific areas of the GUI protected by the operating system.

[0059] FIG 5 is a flowchart of an exemplary process of the applications assigning the view to one of the windows 202, 204, 206. A system component fulfilling such a process is called a window manager 500. [0060] The window manager 500 includes an API (application programing interface). The API is a particular set of rules and specifications that the software programs running on the portable device must follow to communicate with each other. The applications installed on the portable devices use this API of the window manager 500 in order to assign the views to windows on the display.

[0061] Default behavior of the operating system is to assign automatically the views of the applications to the application window 204 in step 504. However, by using the API of the window manager 500, the operating system allows applications to circumvent the default be- havior and assign the views to the system window 206 instead of the application window in step 508. In order to do this assignation, the applications running on the portable device are required to have a specific permission, in the Android operating system for example the name of this specific permission is android.permission.SYSTEM_ALERT_WINDOW 510. The user must grant this specific permission in step 130a or in step 130b as explained in conjunction with FIGs 1A and IB. If the specific permission is not granted in step 120a or in step 120b, the window manager 500 declines the assignment of the view in step 512. Otherwise, if the specific permission is granted in step 130a or in step 130b, the view is assigned to the window in step 514. After the process of assigning a view to a window in step 514 is success- fully completed the window manager 500 requests the GUI rendering system 200 to render view in steps 516a/516b.

[0062] The present disclosure introduces a method that simplifies the GUI of the portable devices. The method allows the users to interact with the device wallpaper of the portable device in order to navigate to the content of the digital media. Implementing such navigation requires the wallpaper applications to create the view containing the content of the digital media.

[0063] Interaction in the case of the present disclosure means the handling of the user input on the device wallpaper visible to the user of the portable device, with the device wallpaper being located on the lowermost position in terms of the z-order inside the GUI, as described in conjunction with FIG 3. The process of handling the user input on the device wallpaper is different to the methods described by the US patent application US 2012/0102428 Al. The methods of US '428 rely on intercepting the input events, before the input events get passed onto the lowermost view of the GUI, by adding a transparent view on top of the lowermost view. By adding a transparent view on top of another element, the view's z-order is higher than the z-order of the lowermost element.

[0064] Navigation in this case means the creation of the view upon the input of the user, as- signing the view to one of the windows and rendering the view so that the contents of the view are made visible to the user. [0065] All of the views created by one of the applications are assigned to the application window 204 by default behavior, as described in conjunction with steps 502, 504 and 506 of FIG 4. However, in the default case that a wallpaper application assigns a view to the application window 204 the operating system delays the assignment of the assigned view by a noticeable amount, as explained in the introduction. In the case of the Android operating system, a delay of a few seconds occurs. Such delay results in a poor user experience (UX) for users using the wallpaper applications, which implement this type of navigation. It is a known fact that the users expect the applications to react substantially immediately to the input from the user. Hence, due to the poor UX of such navigation only a small number of the wallpaper applica- tions provide such navigation, as the users may be unsatisfied with the navigation.

[0066] Furthermore, the assignation of the created view to the application window 204 may result in a view created by another application overlapping the view containing the content of the digital media. The other application may have created its own view in the same location of the application window 204.

[0067] The present disclosure enables the wallpaper applications to react more quickly when navigating to a view by utilizing a specific permission to assign the view to the system window 206 as opposed to using the default behavior of assigning the view to the application window 204. The wallpaper applications using this process can provide a substantially instantaneous navigation, thus assuring a high level of user experience. This process consists of two primary steps.

[0068] The first step of the process is to analyze the incoming user input. Since the wallpaper window is the window with the lowest z-order as described in conjunction with FIG 3 this requires that none of the windows with a higher z-order handled the user input as illustrated in steps 413 and 415. The wallpaper applications may use various gesture recognition techniques to support gesture-based interaction on the wallpaper of the portable device. Gesture recognition is a topic in computer science with the goal of interpreting human gestures via mathemat- ical algorithms. These human gestures may range from simple taps/clicks to complex movements like handwriting. On detection of the valid user input the second step of the process will be invoked. [0069] In the second step the view is created and assigned explicitly to the system window 206, as opposed to using the default behavior of assigning the view to the application window 204. In this way the wallpaper applications avoid the delay and are able to assign the view substantially instantaneously. In terms of a good UX this is the desired behavior as the reac- tion to an input is instant to the user.

[0070] Furthermore, by assigning the view explicitly to the system window 206, as opposed to using the default behavior of assigning the view to the application window 204, the other applications using the default behavior of assigning a view to the application window 204 may not create and assign a view which overlaps the view containing the content of digital media.

[0071] FIG 6 illustrates a flow chart of the process of this disclosure. First of all, it is required that a wallpaper application is installed on the device (step 602). Furthermore, the installed wallpaper application must have granted the specific permission 604 by the user of the portable device. The wallpaper application may require the specific permission 604 using the described processes in conjunction with FIGs 1A and IB in step 110a or in step 110b. The operating system stores and manages the permission for the further usage of the application. As a result of step 110a and step 110b the wallpaper application is installed on the portable de- vice and contains the required specific permission 604.

[0072] After the installation of the wallpaper application and the grant of the required specific permission 604, the user may interact with the wallpaper visible on the mobile device in step 608, i.e. by using touch gestures. In step 610, the input dispatching system 500 processes the incoming user input. The input dispatching system transforms the user input into an In- putEvent 612. During the process of dispatching the input 610, the views of the application window 204 and the system window 206 actively decide not to handle the InputEvent 612. As a consequence, InputEvent 612 is received by the view of the installed wallpaper application in step 614 as described in conjunction with step 416 in FIG 4.

[0073] In contrast to prior art systems, the view of the wallpaper application having the lowest z-order is receiving the InputEvent 612 only if all of the other views, having a higher z- order than the view of the installed wallpaper application, actively decide not to handle the InputEvent 612.

[0074] On receiving the InputEvent 612 the wallpaper application must process the input in step 616, ie. the wallpaper application may use various gesture recognition techniques as described above. If InputEvent 612 does not contain a recognized one of the gestures required from the installed wallpaper application, the process is aborted in step 618. Otherwise, if the InputEvent 612 contains one of the recognized gestures, the wallpaper application navigates the user to content of the digital media by creating a view in step 620.

[0075] In step 624, the created view 622 is assigned to the system window 206 by using the window manager API as described in conjunction with step 514 in FIG 5. Because the user has granted the specific permission 604 in step 606, the wallpaper application is allowed to assign the view 622 to the system window 206. As described above, assigning the created view to the system window 206 results in a substantially instantaneous action as opposed to the default behavior in which the operating system assigns the view to the application window 204 with a noticeable delay.

[0076] Furthermore, by assigning the created view to the system window 206 prevents the overlapping of the created view by another view created by another application using the default behavior of assigning a view to the application window 204.

[0077] If the created view 622 has been assigned to the system window 206 in step 624, the GUI rendering system 200 will render the graphical user interface in step 626 in order to up- date the visual image on the screen of the portable device as described in conjunction with FIG 2 and FIG 3. When the GUI has been rendered, this process ends in step 628. Step 628 is the state in which the created view 622 containing content of the digital media is visible to the user as a response upon his input on the wallpaper.

[0078] Figures 7, 8 and 9 illustrate exemplary embodiments using the process that is subject of this disclosure. [0079] Figure 7 illustrates an exemplary embodiment when the user input in form of a finger touch is executed. When the user touches the display with his or her finger and moves this finger up (called swipe up gesture) in step 608 the wallpaper application detects this gesture in step 616 and initiates the rendering of the view in step 620. The view animates in from the bottom of the display and overlaps the other views visible to the user. In this case the initiated view may contain additional information about the wallpaper picture, i.e. location the picture was taken or a text with additional information about the picture.

[0080] In FIG 8 a device is represented with a display capable of receiving the input by either touching the display with a finger or with a touch screen stylus. In FIG 8 the home screen is rendered on top of the wallpaper application on the display of the device. The wallpaper application is showing an image as the background of the device. The image represents a single frame of a series of images i.e. a single frame of a video. By executing the input with the finger or a touch screen stylus on the wallpaper application, as described in step 608 in conjunction with FIG 6, the wallpaper application processes the input in step 616 and creates a view 622 in step 620 containing user interface elements for playing the video which contains the single frame represented by the image shown by the wallpaper application. The user interface elements may consist of, but are not limited to, a play button, a stop button, a previous and a next button or buttons for controlling the behavior of the video or the appearance of the view 622. By assigning the created view to System Window in step 624 using the specific permission 604 the GUI rendering system renders the view 622 in step 626 resulting in the view and the video being visible instantaneously to the user of the device.

[0081 ] Figure 9 illustrates another example for the usage of the process of this disclosure. In this other example, the user executes an input with a pen instead of a finger touch in step 608. The wallpaper application uses gesture recognition able to detect handwriting in step 616. In this case when the user writes "google" on the wallpaper the wallpaper application initiates the rendering of a view in step 620. The view animates in from the bottom of the display and overlaps the other views visible to the user. In this case the initiated view may contain the Google interface that allows users to search for a specific topic.

Claims

A method for rendering a view on a graphical user interface (200), the graphical user interface (200) having at least two windows (202, 204, 206), whereby a different window permission is associated with ones of the at least two windows (202, 204, 206), and whereby the method comprises:

receiving (402, 608) an input event;

handling (610), according to the z-order, the input event by a plurality of views;

processing (614) the input event by a lowermost one of the plurality of views, if none of the other ones of the plurality of views processes the input event;

inaugurating (502, 620) in the lowermost one of the plurality of views an action based on the input event, the action including a display of a view in the graphical user interface (200);

and

assigning (622, 624) the action to the one of the at least two windows (202, 204, 206) having the topmost z-order, if the action has the corresponding window permission.

The method of claim 1, whereby the at least two windows (202, 204, 206) comprise at least one or more views.

The method of claim 1 or 2, wherein the window permission is assigned (102, 103) on installation of an application for the display of a view in one of the at least two windows (202, 204, 206) requiring the window permission.

The method of any of the above claims, further comprising displaying the view in the lowest one of the windows (202), if none of the higher order windows has a permission corresponding to the window permission of the view.

The method of any one of the above claims, wherein the receiving (606) of the input event comprises at least one of a touch gesture on the graphical user interface (200), a pen input on the graphical user interface (200) or a voice input through a built-in microphone.

6. The method of claim 5, further comprising an association of an input event with a type of touch gesture

7. A graphical interface device comprising:

a graphical display for displaying a plurality of views in different windows;

a permissions database comprising a plurality of window permissions associated with the different windows;

a graphics processor for rendering a plurality of windows on the graphical display; an input device for entering an input event; and

a processor for accepting the input events from the input device, handling the input events by a plurality of views, processing the input event by a lowermost one of the plurality of views, if none of the other ones of the plurality of views process the input event,

inaugurating (502, 620) in the lowermost one of the plurality of views an action based on the input event, the action including a display of a view in one of the plurality of windows of the graphical user interface (200) requiring a window permission and interrogating the permissions database to obtain the window permission corresponding to the action and passing the obtained window permission to the graphical processor.

8. The graphical interface device of claim 7, wherein the graphics processor produces a hierarchical z-order of windows (202, 204, 206) displayed on the graphical display and wherein one of the plurality of windows has a window permission associated with the window.