summaryrefslogtreecommitdiff
path: root/gio/gapplication.c
Commit message (Collapse)AuthorAgeFilesLines
* g_application_run(): Fix on Windows When Using BindingsChun-wei Fan2015-12-221-1/+28
| | | | | | | | | | | | | | | | 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
* GApplication: Avoid getting the default context repeatidlyXavier Claessens2015-12-161-4/+6
| | | | | | This avoids getting a global lock on every main loop iteration. https://bugzilla.gnome.org/show_bug.cgi?id=759554
* gapplication: Acquire the main context before runningJasper St. Pierre2015-12-161-0/+9
| | | | | | | | | | | | | | | | Otherwise, we'll acquire it on every loop iteration, which can leave us vulnerable to racing another thread for the acquisition of the main context. This can break methods like g_main_context_invoke, which try to acquire a context to figure out if it can invoke the method synchronously or need to defer to an idle. In these cases, it isn't guaranteed that the invocation function will be invoked in the default main context, e.g. the one that GApplication is holding. This also matches what GMainLoop is doing. https://bugzilla.gnome.org/show_bug.cgi?id=752983
* GApplication: destroy the impl on shutdownAllison Ryan Lortie2015-12-161-1/+5
| | | | | | | | | | | It's theoretically possible (and see in the wild) for D-Bus messages to come in to the application after shutdown() has been called and while we're draining out the lingering events in the main context. Prevent this from happening by ensuring we unregister our objects on D-Bus during the shutdown process. https://bugzilla.gnome.org/show_bug.cgi?id=757372
* docs: Be more precise on the use of set_resource_base_path()Emmanuele Bassi2015-12-011-1/+6
| | | | | The current wording is a bit vague on when to call set_resource_base_path() in a GApplication implementation.
* GApplication: improve docsMatthias Clasen2015-11-251-0/+11
| | | | | | Spell out which GVariant format strings to use for which commandline option types. I just wasted some time debugging this in an application.
* gio: Intern all signal names beforehandMatthias Clasen2015-09-121-6/+6
| | | | This avoids pointless copying of static strings.
* gapplication: Stop handle-local-options emission on errorsChristophe Fergeau2015-07-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* gapplication: Fix typos in handle-local-options API docChristophe Fergeau2015-07-261-2/+2
| | | | | | | 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
* gapplication: Initialize backend before withdrawing notificationsKalev Lember2015-06-231-2/+4
| | | | | | | | | | | Make sure to initialize the notification backend in g_application_withdraw_notification() the same way as is done in g_application_send_notification(). This makes it possible for an app to withdraw notifications it has sent in a previous execution of the application. https://bugzilla.gnome.org/show_bug.cgi?id=750625
* gapplication: Make sure --help output is translatedChristophe Fergeau2015-06-091-1/+4
| | | | | | | | | | | | | | 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
* GApplication: don't iterate further on _quit()Ryan Lortie2015-03-021-2/+3
| | | | | | | | | If someone explicitly calls g_application_quit() then don't attempt to drain the mainloop of remaining sources. This allows applications with 100% CPU utilisation to quit reliably. https://bugzilla.gnome.org/show_bug.cgi?id=744876
* gio: Add some missing type annotations to object argumentsRico Tzschichholz2015-03-011-2/+2
| | | | Similar to https://bugzilla.gnome.org/show_bug.cgi?id=745239
* GApplication: let the main loop drain on shutdownRyan Lortie2015-02-221-0/+3
| | | | | | | | | | After ::shutdown, run the mainloop until all pending activity is handled, before returning from run(). Among other things, this gives a chance for destroyed windows to be properly withdrawn from the windowing system. https://bugzilla.gnome.org/show_bug.cgi?id=744876
* gapplication: add "is-busy"Lars Uebernickel2015-02-191-3/+47
| | | | | | A property to query the current busy state of an application. https://bugzilla.gnome.org/show_bug.cgi?id=744756
* gapplication: stop using deprecated APIRyan Lortie2015-02-181-2/+2
| | | | More fallout from the GOptionGroup binding patch.
* gapplication: tune busy-bindingLars Uebernickel2015-02-181-30/+59
| | | | | | | | | | g_application_bind_busy_property() had the restriction that only one property can be bound per object, so that NULL could be used to unbind. Even though this is enough for most uses, it is a weird API. Lift that restriction and add an explicit unbind function. https://bugzilla.gnome.org/show_bug.cgi?id=744565
* gapplication: never set the prgname to the app idLars Uebernickel2015-02-171-17/+6
| | | | | | | | | | | | | | | | | | | 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
* gapplication: add bind_busy_property()Lars Uebernickel2015-02-161-0/+104
| | | | | | | | | | Balancing g_application_{un,}mark_busy() is non-trivial in some cases. Make it a bit more convenient by allowing to bind multiple boolean properties (from different objects) to the busy state. As long as these properties are true, the application is marked as busy. https://bugzilla.gnome.org/show_bug.cgi?id=744565
* docs: fix up docs issues in gio/Xavier Claessens2015-02-051-0/+10
|
* gapplication: enable --help when app has optionsLars Uebernickel2014-11-151-14/+14
| | | | | | | | | | This should already work according to the documentation, but doesn't because main_options is consumed before the check in g_application_parse_command_line(). Fix by moving the check for main_options up. https://bugzilla.gnome.org/show_bug.cgi?id=740157
* GApplication: ignore --help if not handling argsRyan Lortie2014-10-201-1/+7
| | | | | | | If the user didn't register any arguments for parsing, also ignore --help. This fixes a regression in meld. https://bugzilla.gnome.org/show_bug.cgi?id=737869
* GApplication: Plug a memory leakMatthias Clasen2014-10-141-0/+2
| | | | We were not freeing resource_path.
* GApplication:handle-local-options: document return valueJasper St. Pierre2014-09-161-5/+5
| | | | | The return value for this signal was documented in the prose, but not properly in a Returns: stanza. Fix that.
* g_application_add_main_option: fix type signatureJasper St. Pierre2014-09-161-1/+1
| | | | The flags argument is a GOptionFlags so use that type instead of 'int'.
* Fix some introspection warningsJasper St. Pierre2014-09-161-1/+1
|
* GApplication: Add g_application_add_main_optionJonas Danielsson2014-08-201-2/+65
| | | | | | | | | | | | This function adds a single main option entry to be handeled by GApplication. The option entry has it arg_data field set to NULL and will be added to the applications packed_options. The rationale for this is that bindings will be able to add command line options even when they can't use the un-boxed struct GOptionEntry. https://bugzilla.gnome.org/show_bug.cgi?id=727455
* GApplication: add a "resource base path"Ryan Lortie2014-07-071-0/+104
| | | | | | | | | | | We don't use this for anything inside of GApplication yet, but Gtk is about to start using it to find various bits of the application (such as its menus, icons, etc.). By default, we form the base path from the application ID to end up with the familiar /org/example/app style. https://bugzilla.gnome.org/show_bug.cgi?id=722092
* GApplication: Don't decrease use_count below 0Marek Kasik2014-04-041-0/+1
| | | | | | | | Place an assert for use_count to be at least 1 in g_application_release() so we don't decrease it below 0. https://bugzilla.gnome.org/show_bug.cgi?id=727551
* Fix build of gio/gapplication.c on Visual C++Chun-wei Fan2014-02-231-1/+2
| | | | | | | | Visual C++ is quite zealous about checking against the types used in the initializing of array of structures, even up to Visual C++ 2013. Fix this by splitting up the initializing steps. https://bugzilla.gnome.org/show_bug.cgi?id=724609
* Annotate g_application_add_main_option_entriesPaolo Borelli2014-02-161-1/+2
|
* Another stray litrealMatthias Clasen2014-02-081-7/+7
|
* Convert more xincluded examples to external linksMatthias Clasen2014-02-081-23/+8
|
* Remove a new literal tag that has crept inMatthias Clasen2014-02-081-3/+2
|
* Eradicate links and xrefsMatthias Clasen2014-02-081-1/+2
| | | | These are all replaced by markdown ref links.
* Docs: use quotes instead of firsttermMatthias Clasen2014-02-061-22/+21
|
* GApplication: parse command line optionsRyan Lortie2014-02-061-146/+579
| | | | | | | | | | | | | | | | | | | | | Add support for parsing command line options with GApplication. You can add GOptionGroup and GOptionEntry using two new APIs: g_application_add_option_group() and g_application_add_main_option_entries(). Also add a "handle-local-options" signal that allows handling of commandline arguments in the local process without having to override local_command_line. As a special feature, you can have a %NULL @arg_data in a GOptionEntry which will cause the argument to be stored in a GVariantDict. This dictionary is available for inspection and modification by the "handle-local-options" signal and can be forwarded to the primary instance in cases of command line invocation (where it can be fetched using g_application_command_line_get_options()). https://bugzilla.gnome.org/show_bug.cgi?id=721977
* Convert external links to markdown syntaxMatthias Clasen2014-02-051-1/+1
|
* GApplication: Convert docs to markdownMatthias Clasen2014-02-011-14/+24
|
* Docs: Convert examples to |[ ]|Matthias Clasen2014-01-311-11/+11
|
* Updated FSF's addressDaniel Mustieles2014-01-311-3/+1
|
* Drop a no-longer-existing example from the docsMatthias Clasen2014-01-251-8/+0
| | | | | | | | gapplication-example-menu.c was dropped in 0c094d660769a00564ef33a775a387f62cf2ff41, two years ago. Time to remove its inclusion in the docs too. https://bugzilla.gnome.org/show_bug.cgi?id=722973
* GApplication: change commandline encoding policyRyan Lortie2014-01-171-11/+21
| | | | | | | | | | | | | | | | | | | | | | Clarify in the documentation that the commandline arguments passed around by GApplication (to local_command_line and returned via g_application_command_line_get_arguments()) are in the GLib filename encoding (ie: UTF-8) on Windows, not the system code page. Fix the mismatch that would result from having argv passed to g_application_run() in main() on Windows (where it is in the system code page) by ignoring argc/argv on Windows and calling g_win32_get_command_line() for ourselves. Document this. This might be a slight API break on Windows: we documented that it was possible to call g_application_run() with arguments other than argc/argv and now doing that will result in those arguments being ignored. It has always been recommended practice to only call g_application_run() from main() directly, however, and all of our code examples have shown only this. We will see if this causes any issues and consider reevaluating the situation if so. https://bugzilla.gnome.org/show_bug.cgi?id=722025
* GApplication: allow handles_commandline and serviceRyan Lortie2014-01-101-1/+2
| | | | | | | | | | The default local_command_line handler has a fast return path for the case that we handle the commandline by forwarding it to the primary instance, but this doesn't account for the fact that we may want to become a service. Allow for this by making sure we don't take the fast path of the service flag is set.
* GApplication: add --gapplication-service switchRyan Lortie2014-01-091-0/+40
| | | | | | | | | | | | | | | | | Add a --gapplication-service switch to the default implementation of local_command_line. This name is unlikely to clash with any option used by an existing application. When a normal application (neither service nor launcher) is launched with exactly this one argument, G_APPLICATION_IS_SERVICE will be set. The idea is that people will write their D-Bus service file with --gapplication-service on the Exec line. This provides a nice compromise for people who want the benefits of DBusActivatable applications but without losing the ability to easily run them directly (under the debugger or inside jhbuild, etc.) https://bugzilla.gnome.org/show_bug.cgi?id=710965
* Add includes to all gio docsMatthias Clasen2014-01-071-0/+1
|
* application: Use printerr for runtime errorsChristian Persch2013-11-231-2/+2
| | | | | | | g_critical can be fatal (with --g-fatal-warnings, or some env var set), so don't use it to print out runtime errors. Bug #676761.
* Clarify the g_application_withdraw_notification docsMatthias Clasen2013-10-211-0/+4
| | | | Mention that notifications are dismissed when activated.
* Add GNotificationLars Uebernickel2013-10-211-0/+99
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=688492
* GApplication: Stop using deprecated apiMatthias Clasen2013-08-171-6/+6
|
View Lorry Controller Status