g-action-group, g-action-map, g-object, common-lisp:standard-object, common-lisp:t

The g-application class is the foundation of an application. The g-application class wraps some low-level platform-specific services and is intended to act as the foundation for higher-level application classes such as the gtk-application class. In general, you should not use this class outside of a higher level framework.

The g-application class provides convenient life cycle management by maintaining a "use count" for the primary application instance. The use count can be changed using the g-application-hold and g-application-release functions. If it drops to zero, the application exits. Higher-level classes such as the gtk-application class employ the use count to ensure that the application stays alive as long as it has any opened windows.

Another feature that the g-application class, optionally, provides is process uniqueness. Applications can make use of this functionality by providing a unique application ID. If given, only one application with this ID can be running at a time per session. The session concept is platform dependent, but corresponds roughly to a graphical desktop login. When your application is launched again, its arguments are passed through platform communication to the already running program. The already running instance of the program is called the "primary instance". For non-unique applications this is always the current instance. On Linux, the D-Bus session bus is used for communication.

The use of the g-application class differs from some other commonly used uniqueness libraries, such as the libunique library, in important ways. The application is not expected to manually register itself and check if it is the primary instance. Instead, the main function of a g-application instance should do very little more than instantiating the application instance, possibly connecting signal handlers, then calling the g-application-run function. All checks for uniqueness are done internally. If the application is the primary instance then the startup signal is emitted and the main loop runs. If the application is not the primary instance then a signal is sent to the primary instance and the g-application-run function promptly returns.

If used, the expected form of an application identifier is the same as that of of a D-Bus well-known bus name. Examples include: "com.example.MyApp", "org.example.apps.Calculator", "org._7_zip.Archiver". For details on valid application identifiers, see the g-application-id-is-valid function.

On Linux, the application identifier is claimed as a well-known bus name on the session bus of the user. This means that the uniqueness of the application is scoped to the current session. It also means that the application may provide additional services, through registration of other object paths, at that bus name. The registration of these object paths should be done with the shared GDBus session bus. Note that due to the internal architecture of GDBus, method calls can be dispatched at any time, even if a main loop is not running. For this reason, you must ensure that any object paths that you wish to register are registered before a g-application instance attempts to acquire the bus name of your application, which happens in the g-application-register function. Unfortunately, this means that you cannot use the g-application-is-remote function to decide if you want to register object paths.

The g-application class also implements the g-action-group and g-action-map interfaces and lets you easily export actions by adding them with the g-action-map-add-action function. When invoking an action by calling the g-action-group-activate-action function on the application, it is always invoked in the primary instance. The actions are also exported on the session bus, and GIO provides the GDBusActionGroup wrapper to conveniently access them remotely. GIO provides a GDBusMenuModel wrapper for remote access to exported g-menu-model objects.

There is a number of different entry points into a g-application instance:

• via 'Activate' (i.e. just starting the application)
• via 'Open' (i.e. opening some files)
• by handling a command-line
• via activating an action

The "startup" signal lets you handle the application initialization for all of these in a single place.

Regardless of which of these entry points is used to start the application, the g-application instance passes some platform data from the launching instance to the primary instance, in the form of a g-variant dictionary mapping strings to variants. To use platform data, override the before_emit or after_emit virtual functions in your g-application subclass. When dealing with g-application-command-line objects, the platform data is directly available via the g-application-command-line-cwd, g-application-command-line-environ and g-application-command-line-get-platform-data functions.

As the name indicates, the platform data may vary depending on the operating system, but it always includes the current directory, key "cwd", and optionally the environment, i.e. the set of environment variables and their values, of the calling process, key "environ". The environment is only added to the platform data if the :send-enviroment flag is set. A g-application subclass can add own platform data by overriding the add_platform_data virtual function. For instance, the gtk-application class adds startup notification data in this way.

To parse command line arguments you may handle the "command-line" signal or override the local_command_line() virtual function, to parse them in either the primary instance or the local instance, respectively. An example to show the use of the signals of an application.

(defun application-open (&rest argv)
  (let ((app (make-instance 'g-application
                            :application-id "com.crategus.application-open"
                            :flags :handles-open))
        (argv (if argv argv (uiop:command-line-arguments))))
    ;; Print information about the application
    (format t "Start application~%")
    (format t "      arg : ~a~%" argv)
    (format t "  prgname : ~a~%" (g-prgname))
    ;; Signal handler "startup"
    (g-signal-connect app "startup"
                      (lambda (application)
                        (declare (ignore application))
                        (format t "The application is in STARTUP~%")))
    ;; Signal handler "activate"
    (g-signal-connect app "activate"
                      (lambda (application)
                        (declare (ignore application))
                        (format t "The application is in ACTIVATE~%")
                        ;; Note: when doing a longer-lasting action here that
                        ;; returns to the main loop, you should use
                        ;; g-application-hold and g-application-release to
                        ;; keep the application alive until the action is
                        ;; completed.
                      ))
    ;; Signal handler "open"
    (g-signal-connect app "open"
                      (lambda (application files n-files hint)
                        (declare (ignore application))
                          (format t "The application is in OPEN~%")
                          (format t "  n-files : ~A~%" n-files)
                          (format t "     hint : ~A~%" hint)
                          ;; The argument FILES is a C pointer to an array of
                          ;; GFile objects. We list the pathnames of the files.
                          (dotimes (i n-files)
                            (let ((file (mem-aref files '(g-object g-file) i)))
                              (format t " ~a~%" (g-file-path file))))))
    ;; Signal handler "shutdown"
    (g-signal-connect app "shutdown"
                      (lambda (application)
                        (declare (ignore application))
                        (format t "The application is in SHUTDOWN~%")))
    ;; Run the application
    (g-application-run app argv)))    

An example to show the implementation of actions for an application.

(defun activate-action (app name)
  (let ((ptype (g-action-group-action-parameter-type app name))
        (state (g-action-group-action-state app name))
        (enabled (g-action-group-action-enabled app name)))
    ;; Print information about the action
    (format t "     action name : ~A~%" name)
    (format t "  parameter type : ~A~%" ptype)
    (unless (null-pointer-p state)
      (format t "      state type : ~A~%" (g-variant-type-string state)))
    (format t "           state : ~A~%" state)
    (format t "         enabled : ~A~%" enabled)
    ;; Activate the action
    (g-action-group-activate-action app name state)))


(defun application-action (&rest argv)
  (let ((app (make-instance 'g-application
                            :application-id "com.crategus.application-action"
                            :flags :none)))
    ;; Create the "simple-action" action
    (let ((action (g-simple-action-new "simple-action" nil)))
      ;; Connect a handler to the "activate" signal
      (g-signal-connect action "activate"
          (lambda (action parameter)
            (declare (ignore parameter))
            (format t "Action ~A is activated.~%" (g-action-name action))))
      ;; Add the action to the action map of the application
      (g-action-map-add-action app action))
    ;; Create the "toggle-action" action
    (let ((action (g-simple-action-new-stateful "toggle-action"
                                                "b"
                                                (g-variant-new-boolean nil))))
      ;; Connect a handler to the "activate" signal
      (g-signal-connect action "activate"
          (lambda (action parameter)
            (declare (ignore parameter))
            (format t "Action ~A is activated.~%" (g-action-name action))
            (let ((state (g-variant-boolean (g-action-state action))))
              (if state
                  (setf (g-action-state action) (g-variant-new-boolean nil))
                  (setf (g-action-state action) (g-variant-new-boolean t)))
              (format t "The state changed from ~A to ~A.~%"
                        state
                        (not state)))))
      ;; Add the action to the action map of the application
      (g-action-map-add-action app action))
    ;; Signal handler "activate"
    (g-signal-connect app "activate"
                      (lambda (application)
                        (format t "The application is in activate.~%")
                        ;; Activate the actions and print information
                        (activate-action application "simple-action")
                        (activate-action application "toggle-action")))
    ;; Run the application
    (g-application-run app argv)))    

The "activate" signal

 lambda (application)    :run-last      

The signal is emitted on the primary instance when an activation occurs. See the g-application-activate function.

application

The g-application instance which received the signal.

The "command-line" signal

 lambda (application cmdline)    :run-last      

The signal is emitted on the primary instance when a command line is not handled locally. See the g-application-run function and the g-application-command-line documentation for more information.

application

The g-application instance which received the signal.

cmdline

A g-application-command-line object representing the passed command line.

Returns

An integer that is set as the exit status for the calling process.

The "handle-local-options" signal

 lambda (application options)    :run-last      

The signal is emitted on the local instance after the parsing of the command line options has occurred. You can add options to be recognised during command line option parsing using the g-application-add-main-option-entries and g-application-add-option-group functions.

Signal handlers can inspect options, along with values pointed to from the arg-data field of an installed option entry, in order to decide to perform certain actions, including direct local handling, which may be useful for options like --version.

In the event that the application is marked with the :handles-command-line flag the "normal processing" will send the options dictionary to the primary instance where it can be read with the g-application-command-line-options-dict function. The signal handler can modify the dictionary before returning, and the modified dictionary will be sent.

In the event that the :handles-command-line flag is not set, "normal processing" will treat the remaining uncollected command line arguments as filenames or URIs. If there are no arguments, the application is activated by the g-application-activate function. One or more arguments results in a call to the g-application-open function.

If you want to handle the local command line arguments for yourself by converting them to calls to the g-application-open or g-action-group-activate-action functions then you must be sure to register the application first. You should probably not call the g-application-activate function for yourself, however, just return -1 and allow the default handler to do it for you. This will ensure that the --gapplication-service switch works properly, i.e. no activation in that case.

Note that this signal is emitted from the default implementation of the local_command_line() virtual function. If you override that function and do not chain up then this signal will never be emitted.

You can override the local_command_line() virtual function if you need more powerful capabilities than what is provided here, but this should not normally be required.

application

The g-application instance which received the signal.

options

The options dictionary of type g-variant-dict.

Returns

An exit code. If you have handled your options and want to exit the process, return a non-negative option, 0 for success, and a positive value for failure. Return -1 to let the default option processing continue.

The "name-lost" signal

 lambda (application)    :run-last      

The signal is emitted only on the registered primary instance when a new instance has taken over. This can only happen if the application is using the :allow-replacement flag. The default handler for this signal calls the g-application-quit function. Since 2.60.

application

The g-application instance which received the signal.

Returns

True if the signal has been handled.

The "open" signal

 lambda (application files n-files hint)    :run-last      

The signal is emitted on the primary instance when there are files to open. See the g-application-open function for more information.

application

The g-application instance which received the signal.

files

A C array of g-file objects.

n-files

An integer with the length of files.

hint

A string with a hint provided by the calling instance.

The "shutdown" signal

 lambda (application)    :run-last      

The signal is emitted only on the registered primary instance immediately after the main loop terminates.

application

The g-application instance which received the signal.

The "startup" signal

 lambda (application)    :run-first      

The signal is emitted on the primary instance immediately after registration. See the g-application-register function.

application

The g-application instance which received the signal.