summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Update Occitan translationgnome-3-10Cédric Valmary2016-10-101-1219/+999
|
* Updated Portuguese translationPedro Albuquerque2015-10-061-581/+589
|
* Updated Occitan translationCédric Valmary2015-05-211-414/+2579
|
* remote-display: Initialise ->cancellableBastien Nocera2014-09-251-0/+1
| | | | | | At least once, right? https://bugzilla.redhat.com/show_bug.cgi?id=1145144
* remote-display: Stop plugin when exitingBastien Nocera2014-09-251-0/+21
| | | | | | Make sure that the plugin is stopped when it's disposed of. https://bugzilla.redhat.com/show_bug.cgi?id=1145144
* remote-display: Stop watching the D-Bus name on stopBastien Nocera2014-09-251-0/+5
| | | | | | So that we don't get called out when the plugin is stopped. https://bugzilla.redhat.com/show_bug.cgi?id=1145144
* power: '0' keyboard backlight is a valid valueBastien Nocera2014-09-041-1/+1
| | | | | | | | | | It's not the screen where you can't see anything if the backlight isn't on, it's a keyboard. Make sure to only reset the keyboard backlight to the maximum when there's an error reading that value. https://bugzilla.gnome.org/show_bug.cgi?id=734074
* wacom: add missing config.h includeBenjamin Tissoires2014-08-281-0/+2
| | | | | | | | | Without this, HAVE_GUDEV is not defined, and set_oled terminates abruptely, leaving out the possibility to set the OLEDs on the Intuos 4. As Bastien said "Not sure how we all missed that". https://bugzilla.gnome.org/show_bug.cgi?id=731977
* orientation: Fix plugin on MS Surface devicesBastien Nocera2014-08-121-21/+48
| | | | | | | | When plugging in the type/touch cover on a Microsoft Surface, the IIO sensor is unplugged, and plugged in again with a different sysfs path. As the accelerometer comes and goes, we need to handle this in the orientation plugin, and not bail out if we can't find the accelerometer on startup, and handle devices coming and going.
* orientation: Unset source ID on idle callbackCarlos Garnacho2014-08-121-0/+1
| | | | | | | The idle was being removed, but the source ID was left != 0, so on shutdown it'd cause warnings. https://bugzilla.gnome.org/show_bug.cgi?id=719973
* orientation: Use the G_SOURCE_REMOVE defineCarlos Garnacho2014-08-121-2/+2
| | | | Instead of just FALSE, this is a cosmetic change.
* orientation: Unown the D-Bus name on StopBastien Nocera2014-08-121-3/+3
| | | | | Instead of when finalizing the plugin, so that stop and starting the plugin again works as expected.
* housekeeping: fix deletion of files in the trashCosimo Cecchi2014-07-221-8/+8
| | | | | | | Fixes a regression from dd2477bf74510237310d41974ba3e342e6c95da1 where regular files would never get deleted from the trash. https://bugzilla.gnome.org/show_bug.cgi?id=733419
* updates: Avoid warning when on ACBastien Nocera2014-07-021-0/+2
| | | | | When on AC, we wouldn't be resetting the timeout ID, and throwing a warning later on, when the network state changed.
* 3.10.3GNOME_SETTINGS_DAEMON_3_10_3Rui Matos2014-06-032-1/+37
|
* main: Unown our DBus name when gnome-session says "Stop"Rui Matos2014-06-031-0/+24
| | | | | | | | | | | | We don't want to quit yet because if we do, gnome-shell and still mapped windows lose their theme and icons. But we have to unown our DBus name otherwise gnome-session will hang waiting for us. This only works due to a bug in gnome-session where it handles any client name being unowned as if the client has disconnected. Will need to be revisited when that bug is fixed in gnome-session. https://bugzilla.gnome.org/show_bug.cgi?id=727049
* housekeeping: Add missing debug for g_file_delete() callBastien Nocera2014-05-191-0/+1
| | | | To match the other g_file_delete() calls.
* housekeeping: Don't follow symlinks to subdirectoriesBastien Nocera2014-05-191-8/+45
| | | | | | | | | | | Check whether a leaf node is a symlink before processing it, and if it is, check whether we should delete the link itself. This works around a possible bug in GIO where GFileEnumerators will get the filetype of the linked-to item, instead of detecting that it is a symlink. https://bugzilla.gnome.org/show_bug.cgi?id=730223
* housekeeping: Fix warnings when info cannot be gatheredBastien Nocera2014-05-191-0/+2
|
* housekeeping: Make some functions public to allow debuggingBastien Nocera2014-05-192-16/+23
|
* power: Cancelling a temporary unidle shouldn't set an idle modeRui Matos2014-05-051-2/+3
| | | | | | | | | | | | | | | | | The caller already knows which idle mode it wants us to move to. Automatically going back to the previous idle mode here would at best cause a quick spurious idle mode switch which would be immediately overriden by the caller or, at worst, we could go into suspend if the previously saved mode was SLEEP. The latter could happen on resume from suspend because there's a race between idle_became_active_cb() and handle_wake_up_screen(). If the second wins the race then we'd set a teporary unidle with the previous mode being SLEEP, meaning that when idle_became_active_cb() cancels the temporary unidle afterwards we'd immediately move to SLEEP again. https://bugzilla.gnome.org/show_bug.cgi?id=729024
* power: Fix restarting of the lid inhibitor check timerRui Matos2014-05-051-25/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We were trying to restart the timer when randr events tell us that there are no longer any external monitors connected. But we were only actually restarting if there was a timer scheduled already, i.e. in case that there was no previous timer we wouldn't start a new one either and thus we'd never clear the inhibitor. This would happen when closing the lid, since we'd stop the timer on do_lid_closed_action(). This commit simplifies the logic and makes the timer be one shot again as was intended in 1e14c67 . The logic now is: 1. Only take the inhibitor and start the timer on randr events, unconditionally. If there was a timer running from a previous randr event we stop it and start a new one so that the "grace period" is always counted since the last randr event. 2. On the timer callback we check whether we should keep the inhibitor and thus we either suspend at that point or don't. In any case, we stop checking until we have further randr events. 3. When the lid closes, we only have to check if we should lock the session. If the timer has elapsed already and we should suspend, then the inhibitor is already gone and logind starts suspending right away. Otherwise we suspend when the timer elapses and we remove the inhibitor, unless we see an external monitor at that point. https://bugzilla.gnome.org/show_bug.cgi?id=729331
* power: Fix what seems to be a c&p typoCarlos Garnacho2014-05-051-1/+1
| | | | | | | The check to inhibit the lid close action when there's external monitors was quitting after the first run, even though it announces it will check again later. https://bugzilla.gnome.org/show_bug.cgi?id=719975
* power: Fix wakeup with some keymapsBastien Nocera2014-05-051-10/+8
| | | | | | | | | | When trying to wake up the screen, try to use XF86WakeUp in preference to the left Alt. Don't use the right Alt key as it might be set as the Compose key which would eat the event without resetting the idle. Also make sure to initialise the keycode only once. https://bugzilla.gnome.org/show_bug.cgi?id=729375
* common: Check the exit status of hotplug scripts correctlyBastien Nocera2014-04-251-4/+15
| | | | | | | Instead of comparing the shell's exit code by hand, use g_spawn_check_exit_status() to get the script's exit code. https://bugzilla.gnome.org/show_bug.cgi?id=710791
* common: Fix documentation for hotplug scriptBastien Nocera2014-04-251-1/+1
| | | | | | | The code at the bottom says we'll ignore further configuration if "1" is returned, but the top said if "0" is returned. Make both say "1".
* xsettings: remove check for native resolution when determining hi-dpiOwen W. Taylor2014-03-141-22/+0
| | | | | | | | | A non-native resolution, can still be hi-dpi - e.g., on my laptop, gnome-settings-daemon lists a resolution of 1920x1440 on my 2560x1440 display. The other checks we have in place should be sufficient to disable hi-dpi support if the user picks a small resolution. https://bugzilla.gnome.org/show_bug.cgi?id=709859
* xsettings: Never turn on hi-dpi support for small resolutionsOwen W. Taylor2014-03-141-0/+9
| | | | | | | | If the screen is less than 1200 pixels high, don't turn on hi-dpi support - GNOME isn't going to work with that little vertical real estate, and it's better just to be small. https://bugzilla.gnome.org/show_bug.cgi?id=709859
* xsettings: Don't mix GnomeRR and GDK informationOwen W. Taylor2014-03-141-16/+63
| | | | | | | | | | | | | If we don't mix information from GnomeRR and GDK, then the "changed" signal on GnomeRRScreen is all we need to properly know when the resolution of the system is changed - mixing them presents problems because GDK may not yet have updated it's information from X when the "changed" is triggered by a D-Bus signal. We still use GDK information before we have a GnomeRRScreen to minimize the chance of switching the window scale during startup. https://bugzilla.gnome.org/show_bug.cgi?id=709859
* xsettings: Use gnome_rr_screen_new_async()Owen W. Taylor2014-03-141-12/+55
| | | | | | | | Since gnome-settings-daemon starts before Mutter, we need to use gnome_rr_screen_new_async() to wait for Mutter to start and provide the screen information over D-Bus. https://bugzilla.gnome.org/show_bug.cgi?id=709859
* xsettings: Use correct flags for test applicationBastien Nocera2014-03-141-3/+3
| | | | | | | The other test app might not have the same requirements as the full plugin test app. https://bugzilla.gnome.org/show_bug.cgi?id=709859
* xsettings: Enable hidpi scaling on 4K monitorsBastien Nocera2014-03-141-2/+17
| | | | | | Even if HDMI is used. https://bugzilla.gnome.org/show_bug.cgi?id=709859
* xsettings: Disable scaling factor on HDMI outputsBastien Nocera2014-03-141-15/+38
| | | | | | | If the output is HDMI, it's likely that the output is a TV, so don't increase the scaling factor. https://bugzilla.gnome.org/show_bug.cgi?id=709859
* xsettings: Check native resolution for scaling factorBastien Nocera2014-03-142-1/+54
| | | | | | | | Check whether the panel is running at its native resolution before applying the scaling factor. We don't want hi-dpi screens running below native resolution to have a high scaling factor. https://bugzilla.gnome.org/show_bug.cgi?id=709859
* xsettings: Use primary monitor for scaling factorBastien Nocera2014-03-141-4/+7
| | | | | | Not screen 0. https://bugzilla.gnome.org/show_bug.cgi?id=709859
* common: provide a helper function to close an XDevice safelyPeter Hutterer2014-03-046-22/+31
| | | | | XCloseDevice may cause a BadDevice error if the device disappeared before we close it.
* mouse: wrap pointer acceleration changes into a gdk_error_trapPeter Hutterer2014-03-041-0/+5
|
* mouse: wrap device button mapping into gdk_error_trap_push/popPeter Hutterer2014-03-041-1/+2
| | | | | | The device may have disappeared by the time we get here, so make sure we catch BadDevice errors as well by moving the error trap push up before the first X call.
* wacom: Add OLED handling over BluetoothPrzemo Firszt2014-02-071-27/+70
| | | | | | For the Intuos4 Wireless tablets. https://bugzilla.gnome.org/show_bug.cgi?id=704167
* updated kn.poShankar Prasad2014-02-041-827/+135
|
* main: don't die when gnome-session says StopGiovanni Campagna2014-02-031-3/+0
| | | | | | | | | | | | gnome-session asks all registered clients to stop after the user confirms the poweroff/logout dialog, but we should ignore that request, because non registered applications are still mapped and they would lose their theme and icons if we die (and same for the shell). We will go away as soon as the X11 connection is closed or the session bus dies anyway. https://bugzilla.gnome.org/show_bug.cgi?id=707790
* main: modernize code for handling SIGTERMGiovanni Campagna2014-02-031-36/+3
| | | | | | | Let's use glib's builtin facilities for signals instead of our own pipe. https://bugzilla.gnome.org/show_bug.cgi?id=707790
* main: remove unused codeGiovanni Campagna2014-02-031-15/+0
| | | | | | | The SessionOver signal is legacy and is never emitted by gnome-session. https://bugzilla.gnome.org/show_bug.cgi?id=707790
* keyboard: Apply num-lock to newly connected keyboardsBastien Nocera2014-01-281-0/+1
| | | | | | | | | | | | | | | | before 34395459cc8f0da6f163736743bced441ef86390, apply_all_settings() and then apply_numlock() would sync up the numlock LED on a newly hotplugged device. 34395459cc8f0da6f163736743bced441ef86390 removed that call, so devices now come up with the numlock LED off even when the numlock is on, and a subsequent state change will wrongly toggle it, i.e. LED off when numlock is on, LED on when numlock is off. This should really be fixed in the xserver but it's unlikely to happen, restoring this patch in gnome-settings-daemon seems the simplest solution for now. https://bugzilla.gnome.org/show_bug.cgi?id=722753
* Revert "Revert "Adding shortcut for toggle screen reader""Bastien Nocera2014-01-281-1/+1
| | | | | | This reverts commit 11c0be5410caf47adaa968fb852f4a1f62210bde. Wrong keybinding.
* Updated Greek translationDimitris Spingos2014-01-031-462/+631
|
* Revert "Adding shortcut for toggle screen reader"Bastien Nocera2013-12-241-1/+1
| | | | | | | | Super+S conflicts with the "panel main menu" shortcut. See https://bugzilla.gnome.org/show_bug.cgi?id=720994 This reverts commit f20df9907933d24519a5e69d565cf25715349fda.
* Update Chinese simplified translation甘露(Gan Lu)2013-12-071-523/+625
|
* updates: Remove the unconditional clearing of the offline updates messageRichard Hughes2013-11-251-3/+0
| | | | | | The offline updates status file needs to be around for the failed text and also if we're using gnome-software to review the changed updates. We're already removing it in the callback even for the non-gnome-software case.
* Tamil Translations UpdatedShantha kumar2013-11-251-618/+871
|
View Lorry Controller Status