-
Carlos Soriano Sánchez authored
So, this came trying to fix a little issue. Christian Hegert pointed to me that nautilus -s was not working all the times. It was working only when the application was already running. That's because there was a race condition in the dbus. We were starting nautilus, owning the FileManager1 dbus path and inside application_select we were calling the dbus method to select the items. Then that instance died and the dbus path became unown by Nautilus again, but we were in the middle of a call to the dbus method. So that created a race somewhere and Nautilus was not responding to that call. When there was an instance already alive this was working fine since the dbus path was owned by Nautilus already. So one solution was to instead of calling nautilus by a dbus call for that use case, directly do the need operations there. But then it was happening the opposite, it was working for the first instance, since the startup is called an everything is in place, but when created a second instance with the -s option it was crashing because the second instance was not initialized and nothing was set up for it. So finally, the solution I though is better for this is always handle the command line options on the main instance. A way to do this is connecting to the command-line signal of GApplication and drop handle_local_options and application_open. Doing this actually make things easier for everything, like the problem we had some months ago about nautilus creating one window when icons on desktop was activated. That was happening because depending on the return value on handle_local_options it called the activate signal or not. Now instead we manage everything as we want in the handler of the command-line signal, so we don't have to worry about those things anymore and the code becomes clearer and simpler.
aedc98cf