1. 29 May, 2017 1 commit
  2. 25 May, 2017 1 commit
  3. 22 Nov, 2016 1 commit
  4. 08 Nov, 2016 1 commit
  5. 24 Oct, 2016 1 commit
  6. 12 Oct, 2016 1 commit
  7. 07 Jun, 2016 1 commit
  8. 04 Jun, 2016 1 commit
  9. 13 Apr, 2016 1 commit
  10. 12 Apr, 2016 1 commit
  11. 18 Feb, 2016 1 commit
  12. 02 Feb, 2016 1 commit
  13. 22 Dec, 2015 1 commit
    • Chun-wei Fan's avatar
      g_application_run(): Fix on Windows When Using Bindings · bec6a9a3
      Chun-wei Fan authored
      As g_win32_get_command_line() calls CommandLineToArgvW() to acquire the
      arguments passed into a GApplication program, it actually returns the
      whole command line which is used to invoke the program, including the
      script interpreter and its flags when a script using GNOME bindings
      (e.g. PyGObject and so on) is being invoked.
      
      The issue here is that g_application_run() would most probably have
      trouble in the scripts scenario on Windows as it is likely unable to
      "recognize" the script interpreter, causing such scripts to fail to run.
      
      Largely based on the patch by Ray Donnelly <mingw.android@gmail.com>.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=734095
      bec6a9a3
  14. 16 Dec, 2015 3 commits
  15. 01 Dec, 2015 1 commit
  16. 26 Nov, 2015 1 commit
    • Matthias Clasen's avatar
      GApplication: improve docs · 97877904
      Matthias Clasen authored
      Spell out which GVariant format strings to use for which
      commandline option types. I just wasted some time debugging
      this in an application.
      97877904
  17. 12 Sep, 2015 1 commit
  18. 27 Jul, 2015 2 commits
    • Christophe Fergeau's avatar
      gapplication: Stop handle-local-options emission on errors · 243d740c
      Christophe Fergeau authored
      A signal accumulator can return TRUE to continue signal emission, and
      FALSE to stop signal emission. handle-local-options callbacks can return
      « return a non-negative option if you have handled your options and
      want to exit the process ».
      
      Currently, g_application_handle_local_options_accumulator (the
      accumulator for the handle-local-options signal) returns TRUE on
      non-negative return value (ie continue signal emission), and returns
      FALSE on negative return values (ie when the default option processing
      should continue).
      This return value seems backward as on >= 0 values, subsequent
      handle-local-options callbacks could overwrite the 'exit request' from
      the handler, while on < 0 values, the handle-local-options processing
      could end up early if several callbacks are listening for this signal.
      In particular, the default handler for this signal
      (g_application_real_handle_local_options) always returns -1 and will
      overwrite >= 0 return values from other handlers.
      
      This commit inverts the check so that signal emission stops early when
      one of the handle-local-options callbacks indicates it wants processing
      to stop and the process to exit.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=751598
      243d740c
    • Christophe Fergeau's avatar
      gapplication: Fix typos in handle-local-options API doc · 2551685c
      Christophe Fergeau authored
      The @options parameter was missing an 's', and the name of
      g_application_command_line_get_options_dict() was not correct.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=751598
      2551685c
  19. 23 Jun, 2015 1 commit
  20. 09 Jun, 2015 1 commit
    • Christophe Fergeau's avatar
      gapplication: Make sure --help output is translated · f45ceb83
      Christophe Fergeau authored
      Currently, applications using g_application_add_main_option_entries()
      won't get translated entries in --help output. We need to call
      g_option_group_set_translation_domain() with a NULL domain to ensure that the
      default application gettext domain (ie the one passed to the
      textdomain() call) will be used for the main entries passed by the
      application.
      
      If we want to allow more flexibility on which gettext domain should be
      used for these entries, new API will be needed.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=750322
      f45ceb83
  21. 02 Mar, 2015 1 commit
  22. 01 Mar, 2015 1 commit
  23. 23 Feb, 2015 1 commit
  24. 19 Feb, 2015 1 commit
  25. 18 Feb, 2015 2 commits
  26. 17 Feb, 2015 1 commit
    • Lars Uebernickel's avatar
      gapplication: never set the prgname to the app id · fcb30409
      Lars Uebernickel authored
      GApplication set the prgname to the application's id when it was running
      in service mode. This broke with the addition of new --app-id option,
      because g_set_prgname() was called before parsing the options. Calling
      it after option parsing doesn't work, because GOptionContext sets
      prgname to argv[0] unconditionally.
      
      Instead of changing the semantics of GOptionContext, simply remove this
      functionality from GApplication. It is very unusual to have the prgname
      set to the app id instead of the binary's name and might confuse people
      when looking at logs etc.
      
      When overriding local_command_line() from a subclass,
      g_option_context_parse() might never be invokded. Thus, continue setting
      the prgname to argv[0] in GApplication.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=743933
      fcb30409
  27. 16 Feb, 2015 1 commit
  28. 05 Feb, 2015 1 commit
  29. 15 Nov, 2014 1 commit
  30. 20 Oct, 2014 1 commit
  31. 15 Oct, 2014 1 commit
  32. 16 Sep, 2014 3 commits
  33. 20 Aug, 2014 1 commit
  34. 07 Jul, 2014 1 commit