If we're started by systemd, we won't be in the user's display session.
However, this is still the session that will get locked & unlocked. Ask
logind what the 'display' or 'greeter' session is, and watch for the
Unlock signal for that session to know when to unlock.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/137
And stop using FocusCaretTracker for caret position purposes. This
new object uses 1) the text-input protocol in wayland and 2) Info
from IBusPanelService for X11 (which is meant to work for XIM too).
This drops the usage of AtspiEventListener for OSK purposes, which
is best to avoid.
commit 642107a2 attempts to avoid resetting the current keymap on
spurious input source changes.
It does this by checking if the current layout id is found in
the new list of layouts and resetting the current layout to the
associated match in the list. By not nullifying the current
layout, it won't get subsequently reset.
Unfortunately, if the order of the list changes, resetting the
current keymap is still necessary, since the order corresponds
with the index of the activated group.
This commit changes the code to nullify the current layout if
its group index changes.
https://bugzilla.redhat.com/show_bug.cgi?id=1573923
The IM can pretty much update the input sources anytime (even if
to set the same ones). That ends up triggering rebuilding all user
defined keymaps, and losing modifier state if we are unfortunate
enough that this caught us while pressing one.
One common situation seems to be password entries, resulting in
the wrong character being printed if the first character happens
to require the shift key.
If the current keymap is not found in the newly loaded list,
this._current will end up null, with the same behavior as we get
currently (immediate keymap reload).
https://bugzilla.redhat.com/show_bug.cgi?id=1569211https://gitlab.gnome.org/GNOME/gnome-shell/issues/240Closes: #240
The author of the original URL-matching regex warns[0] that the pattern may
cause certain regex engines to lock up with certain input, namely patterns
that contain parentheses. It turns out SpiderMonkey is affected, but rather
than switching to the author's improved version (that is still crazy), sim-
plify the pattern a bit by removing support for nested parentheses in URLs.
Even a single pair of parentheses is extremely rare, so this is unlikely to
make a noticeable difference (other than not locking up SpiderMonkey of
course) ...
[0] http://daringfireball.net/2010/07/improved_regex_for_matching_urls
Even though we are using an "xkb" source, it still makes sense to
pass the event through the IBus simple engine, in order to let it
handle compose keys and ctrl+shift+[u|e].
https://gitlab.gnome.org/GNOME/gnome-shell/issues/115Closes: #115
When not using arrow notation with anonymous functions, we use Lang.bind()
to bind `this` to named callbacks. However since ES5, this functionality
is already provided by Function.prototype.bind() - in fact, Lang.bind()
itself uses it when no extra arguments are specified. Just use the built-in
function directly where possible, and use arrow notation in the few places
where we pass additional arguments.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
IBus was initially made optional as gnome-shell depended on too
recent API. This API is now old enough and gnome-shell is committing
further to IBus by implementing a ClutterInputMethod through it.
Let's just make IBus a mandatory dependency, instead of making code
paths trickier to cater for situations where it's missing.
This is a ClutterInputMethod implementation using IBus underneath. The
input method will interact with the currently focused ClutterInputFocus,
be it shell chrome or wayland clients through the text_input protocol.
It turns out that NetworkManager does export the directory as pkg-config
variable after all, so use that instead of building the path ourselves
from the prefix.
https://bugzilla.gnome.org/show_bug.cgi?id=789811
Every action has specific associated terms that
identify that action and show it in the search
results. Methods to match the actions as well
as getting properties of specific actions are
needed in order to provide a way of using the
actions.
https://bugzilla.gnome.org/show_bug.cgi?id=691900
We want to be able to search for available system actions, so
rather than tracking each action in a separate property, store
them in a single map that can be searched in a generic and clean
way.
https://bugzilla.gnome.org/show_bug.cgi?id=691900
In anticipation of showing the system actions in
the search results, it is fit to move action
specific code to its own module in order to
reuse it.
https://bugzilla.gnome.org/show_bug.cgi?id=691900
Meson is on track to replace autotools as the build system of choice,
so support it in addition to autotools. If all goes well, we'll
eventually be able to drop the latter ...
https://bugzilla.gnome.org/show_bug.cgi?id=783229
Any symbols (including class properties) that should be visible
outside the module it's defined in need to be defined as global.
For now gjs still allows the access for 'const', but get rid of
the warnings spill now by changing it.
https://bugzilla.gnome.org/show_bug.cgi?id=785084
Commit 39a840e2c3 added an additional parameter to shell_app_launch().
When adjusting callers, the parameter was also added accidentally to
calls of the confusingly similar g_app_info_launch() ...
Remove those to fix some warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
Don't try to access a non-existent engine - it probably makes sense to
use Map() instead of a plain object to track engines in the future, but
for now just add an additional check to shut up a warning.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
We only use lastItem() to reset the history index to the end, so
nobody noticed the utter nonsense in the return value until gjs
started to warn about it. As we don't actually use the value
anywhere, we could just remove it, but the function name implies
that an item is returned, so fix it to behave as advertised.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
While the string returned by formatTime() should follow the locale's
text direction as a whole, the actual time part is always expected
to put hours on the left and minutes to the right. It is possible to
enforce that by inserting a left-to-right mark, but so far this is
only done by the Hebrew translation. So in order to not require all
other RTL translations to be fixed individually, just insert the
mark into the returned string ourselves like gnome-desktop's WallClock
code does[0].
[0] https://git.gnome.org/browse/gnome-desktop/tree/libgnome-desktop/gnome-wall-clock.c?h=gnome-3-24#n267https://bugzilla.gnome.org/show_bug.cgi?id=784130
Ever since commit b8e29ae8c7
(I think), start up is littered with this message:
Gjs-WARNING **: JS ERROR: could not get remote objects for service
org.gnome.SettingsDaemon.Smartcard path
since gnome-shell is now started before gnome-settings-daemon.
This commit addresses the problem by making the object manager code
not try to autostart its proxy, and instead wait for it to appear.
https://bugzilla.gnome.org/show_bug.cgi?id=772589
So far, the GWeatherInfo was given the enabled weather providers
as a parameter, at construction time. Because of the way in
which libgweather was designed, setting the providers right from
the beginning enabled libgweather to use them internally in order
to update its state. Updating the internal state is only relevant
when there is a valid location set, which is not guaranteed at the
time when the GWeatherInfo object is constructed.
In order to fix this, enable no providers at construction time and
only set valid providers after setting a valid location.
https://bugzilla.gnome.org/show_bug.cgi?id=780404
Our weather integration should follow GNOME Weather as closely as
possible, which means that we should respect its location permission
rather than using our own or none at all (which we can as a "system"
component and as geoclue's authorization agent).
https://bugzilla.gnome.org/show_bug.cgi?id=780252
It doesn't make sense to tie the proxy code for flatpak's permission
store to the location indicator, just because that was the first
component to use it, so split it into a separate module.
https://bugzilla.gnome.org/show_bug.cgi?id=780252
The setting to globally disable location settings altogether isn't
handled by the geoclue service itself, but by the authorization
agent. This means that:
- it doesn't apply to system components
(which gnome-shell is now considered[0])
- it doesn't apply once the geoclue connection
has been authorized
However users can reasonably expect that we won't use location services
after they disabled them, so handle the setting explicitly.
[0] https://cgit.freedesktop.org/geoclue/commit/?id=a4cef6c0ad08https://bugzilla.gnome.org/show_bug.cgi?id=780252
We currently use automatic location for weather forecasts if the
corresponding Weather setting is set, however we should take other
factors into account as well:
- whether location services are enabled at all
- whether Weather has been authorized to use them
In preparation of these changes, track the setting's value in a
separate property and make _useAutoLocation a getter, so we can
extend it with additional conditions easily.
https://bugzilla.gnome.org/show_bug.cgi?id=780252
Setting GWeatherInfo:location to null helpfully doesn't mean
"no location", but "NYC". This obviously isn't what we want
to show users, so track the location validity separately and
consider it when updating the label shown to users.
https://bugzilla.gnome.org/show_bug.cgi?id=780252
If GeoClue is not responding for some reason, the callback of
Geoclue.Simple.new would not get called, meaning that _gclueFailed
remains false. This is preventing the fallback to the most recently
used location in gnome-weather, because it requires _gclueFailed to be
true (or auto-location to be disabled). So neither code path sets a
location and the libgweather default (New York City) is being used
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=779898
For notifications in the message list, it is usually less relevant
when exactly it occurred, but how long ago. So rather than showing
the exact time and expecting the user to figuring out the timespan
themselves, change the format to something human readable.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
Weather conditions - at least as far as online services are
concerned - don't usually change in a couple of minutes.
So when updating shortly after a previous update, assume
the current conditions are still valid and trigger an
update without showing a loading indication. This should
help a bit with not getting stuck permanently in loading
state when on a shitty network.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
In preparation of integrating GNOME Weather, add a helper class that
retrieves weather information according to Weather's configuration
if the application is installed.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
When integrating with optional components like Clocks, it is not safe
to access their GSettings right after the application became visible
to the AppSystem:
Installation is usually not atomic, so the .desktop file may appear
before the settings schema, in which case Gio will abort due to an
"invalid" schema ID.
To address this, add a small helper class that wraps the settings
access in a safe way.
https://bugzilla.gnome.org/show_bug.cgi?id=766410
Mutter now provides versioned libraries and pkg-config files, meaning
an application using libmutter and friends need to depend on a specific
version of the API.
https://bugzilla.gnome.org/show_bug.cgi?id=777317
The following code is a syntax error in ES6:
let a = 'something';
let a = 'other thing';
Previously GJS would silently accept this code, but in the next release the
SpiderMonkey JS engine will be more ES6-compliant.
https://bugzilla.gnome.org/show_bug.cgi?id=778425
Per ES6, a variable declared const should only be valid inside its lexical
scope. Previously, GJS would accept this code, but that will change in the
SpiderMonkey JS engine in the next release of GJS.
https://bugzilla.gnome.org/show_bug.cgi?id=778425
Ever since commit b8e29ae8c7
(I think), start up is littered with this message:
Gjs-WARNING **: JS ERROR: could not get remote objects for service
org.gnome.SettingsDaemon.Smartcard path
since gnome-shell is now started before gnome-settings-daemon.
This commit addresses the problem by making the object manager code
not try to autostart its proxy, and instead wait for it to appear.
https://bugzilla.gnome.org/show_bug.cgi?id=772589
And adapt existing callers to the new API. This will allow us to
implement a way to launch applications on the discrete GPU for systems
where an "Optimus" system exists.
https://bugzilla.gnome.org/show_bug.cgi?id=773117
Apparently importers for the 'same' path are shared, even when the
relative paths resolve to different absolute ones. Until this bug
is fixed properly, we can work around this by expressing the current
extension path as the UUID relative to the parent directory.
https://bugzilla.gnome.org/show_bug.cgi?id=772386
You can define a new importer object by importing a subdirectory in GJS.
This is undocumented, but it is likely to at least hold until the whole
thing moves to ES6 modules, after which we'll be able to do this purely
in JS with Reflect.Loader.
Since this was the only thing the ShellJS library did, we can remove it
altogether.
This allows us to discontinue use of the gjs-internals-1.0 embedder API.
https://bugzilla.gnome.org/show_bug.cgi?id=772386
Currently it's assumed only an extension can call this method. However
it can be useful if any part of the shell want to know if it was invoked
by an extension.
https://bugzilla.gnome.org/show_bug.cgi?id=770717
The underlying logind API does not only indicate whether suspend is
available, but also whether the user is eligible for executing the
operation without further authentication. This information can be
relevant, so pass it to the callback.
https://bugzilla.gnome.org/show_bug.cgi?id=725960
Logind recently got support for a hint property in Session Object to
inform if session is Locked or not. It is up to desktop environments
to keep this property up to date.
https://bugzilla.gnome.org/show_bug.cgi?id=764773
According to systemd logind's documentation, the CanSuspend() method
"returns 'na' in case "the operation is not available because hardware,
kernel or drivers do not support it", while "'no' is returned if the
operation is available but the user is not allowed to execute it".
See http://www.freedesktop.org/wiki/Software/systemd/logind
Thus, we need to return true here when the reply for the CanSuspend
method is neither 'no' nor 'na', or we would providing false positives
in cases where suspension is simply unsupported.
https://bugzilla.gnome.org/show_bug.cgi?id=748338
On locales that support it, time formats should follow the 12-hour/24-hour
preference, which implies that they should be updated when the setting
changes. So add another utility method which creates a label for a specific
time and keeps it in sync with the format setting.
https://bugzilla.gnome.org/show_bug.cgi?id=745111
The world clock uses GLib.DateTime instead of the built-in Date type
because of the much superior timezone support, and therefore cannot
use the new formatTime() helper. To make this possible, modify the
method to support a parameter of either type.
https://bugzilla.gnome.org/show_bug.cgi?id=745111
Displaying a time is more complex than it appears at first glance:
it should respect the user's choice regarding 12- our 24-hour format (but
only when supported by the locale) and follow the LC_TIME rather than the
LC_MESSAGES setting.
So rather than getting it more or less right in various places, it makes
sense to defer to a helper method which hopefully does the right thing. The
method added by this patch is based on _formatTimestamp in telepathyClient
with some minor tweaks:
- there's an additional params parameter which allows enforcing
a time-only format, even on dates other than the current one
- only a single desktop settings object is created and shared between
invocations
https://bugzilla.gnome.org/show_bug.cgi?id=745111
Input method preedit text needs to be disabled on password entries
for security and usability reasons.
IBus 1.5.7 provides the signal set-content-type so that panel UIs can
handle these special purpose input entries:
https://github.com/ibus/ibus/commit/6ca5ddb302c9
Unfortunately IBus versions older than 1.5.10 have a bug which causes
spurious set-content-type emissions when switching input focus that
temporarily lose purpose and hints defeating its intended semantics
and confusing users. We thus don't use it in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=730628
Normally users switch xkb input sources and ibus input sources.
But currently the first input source only is running. It's also good
to preload all ibus engines in the logging session so that users switch
input sources quickly without the launching time of input sources.
The following is the ibus change:
https://github.com/ibus/ibus/commit/cff35929a9https://bugzilla.gnome.org/show_bug.cgi?id=695428
Instead of calling out to gnome-settings-daemon we'll just implement
the switching logic ourselves and use mutter APIs that allow this
functionality to work both in X sessions and when we're a Wayland
compositor.
Switching IBus engines is done transparently as well just like g-s-d
used to do.
https://bugzilla.gnome.org/show_bug.cgi?id=736435
gnome-settings-daemon doesn't this for us anymore. Note that
ibus-daemon isn't DBus activatable but just spawning it is fine
because it does its own single instance management. The library
notifies us when it shows up and goes away through the connected and
disconnected signals.
https://bugzilla.gnome.org/show_bug.cgi?id=736435
The code path is completely unmaintained and untested (and probably
unused as well, considering that nobody has complained about accessing
the session object's Active property which does not exist in the
ConsoleKit case).
Most of our ConsoleKit code is already a dummy anyway, just do the
same for the remaining functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=686626
When a user logs in to a wayland session, we keep the login screen
running on the X server with the login screen running in a deactivated mode.
This commit makes sure it get reactivated when the user comes back to
the VT (from user switching, logout or just ctrl-alt-f1).
https://bugzilla.gnome.org/show_bug.cgi?id=726989
The asynchronous nature of extension loading, session loading, and more,
makes the code racy as to what is initialized first, and hard to debug.
Additionally, since gjs is single-threaded, the only code we're running
in a thread anyway is readdir, which is going to be I/O bound, so the
code here is actually likely to be faster.
Drop this in favor of some good old fashioned synchronous loading.
It's important to compare the version components as integers,
not strings, so "10" evaulates as greater than "5"
This fixes the login screen in gnome 3.10.
https://bugzilla.gnome.org/show_bug.cgi?id=708691
We need to adjust the offset of close buttons, in case the box
pointer has the arrow at the top. To do so, extend close buttons
to hook into a boxpointer (since that's the common use for them)
and automatically adjust their position.
https://bugzilla.gnome.org/show_bug.cgi?id=707842
These don't go through gnome-session, so they don't properly update
its state machine. We should use these in the future when we want to
use logind user sessions, but for now, they're just a trap.
https://bugzilla.gnome.org/show_bug.cgi?id=706612
A D-Bus service can export more supported interfaces than the
shell cares about. In those cases, we avoid creating proxies,
but neglect to finish things up so the object manager class
knows it can mark itself loaded.
This commit makes sure we do the proper finishing, so the object
manager still loads in the face of unsupported interfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=706542
gnome-settings-daemon monitors smartcard insertion and removal
events on the system and then exports a model of the current
smartcard topology over the bus using the D-Bus ObjectManager interface.
This commit adds the support code needed in gnome-shell to talk to
the gnome-settings-daemon service.
A future commit will use this code to inform the login screen
when a user inserts a smartcard (so it can react appropriately)
https://bugzilla.gnome.org/show_bug.cgi?id=683437
The D-Bus ObjectManager interface is fairly recent addition to the
D-Bus specification. Its purpose is to provide a standardized way
to track objects dynamically coming and going for a service, and
to track capabilities dynamically coming and going for those objects
(by means of interfaces).
This commit adds the requisite code needed to make use of the
ObjectManager interface.
It will ultimately be needed to implement smartcard support in the
login screen.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
Before the fix, the message tray highlighted all urls containing "://", even
invalid ones. This change fixes this by have the message tray highlight only
the urls with http, https, ftp schemes.
Credit goes to: Phuong Vu, Liye Fu, Monica Chelliah, Owen Taylor
https://bugzilla.gnome.org/show_bug.cgi?id=661225
With fallback mode dropped, we can no longer rely on gnome-screensaver
to be installed, so we'll have cases where we are unable to lock the
screen. The user menu should not show the "Lock" item in this case,
but as UnlockDialog includes UserMenu, we cannot use the existing check
without creating a circular dependency; move the function to a more
generic place to fix.
https://bugzilla.gnome.org/show_bug.cgi?id=693403
If screen locking is enabled, the screen shield should drop down
on suspend. Currently this is achieved by either explicitly locking
the screen (when selecting "Suspend" from the user menu) or by
relying on g-s-d delaying the suspension enough time for the shield
to get into place (lid close, power button).
Systemd inhibitors offer a safer way to ensure that the screen is
locked before going to sleep, so add a small abstraction for them
in the loginManager - with inhibitors being a systemd-only feature,
the ConsoleKit path only has a dummy implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=686482
This commit removes all the code in charge of playing with the database of
mobile providers, which was originally included in order to perform
MCCMNC->OperatorName and SID->OperatorName conversions.
This logic is now exposed by libnm-gtk.
https://bugzilla.gnome.org/show_bug.cgi?id=688943
ModemManager >= 0.7 comes with a new DBus interface. This patch makes the shell
work with the new interface if the modem is detected as being exposed by the new
ModemManager (based on the device.udi string reported by NM).
https://bugzilla.gnome.org/show_bug.cgi?id=687359.
Gnome session started to track the session's active state a while
ago, so use that instead of our own ConsoleKit/logind abstraction
in LoginManager.
https://bugzilla.gnome.org/show_bug.cgi?id=693161
A simple implementation of the ES6 Map proposal, internally
done as a hash table, using System.addressOf() to support keys that
are arbitrary objects.
Should help replacing linear searches in various places around the shell.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
Remove section titles for ethernet and mobile broadband, and replace
them with device status items that recognize if multiple devices are
installed in the same section, and if so automatically disambiguate.
https://bugzilla.gnome.org/show_bug.cgi?id=677142
shell_mobile_providers_parse() was returning the country information split
into a hash table with providers and a hash table with country names. This
patch merges both outputs into a single per-country object, so the parse()
method now returns a GHashTable with the following element-type:
(element-type utf8 ShellCountryMobileProvider>)
This also avoids more complex setups like returning lists inside of hash tables,
which was actually breaking either g-i or gtk-doc.
shell_mobile_providers_parse() was also modified to allow inputting the paths
of the country codes and provider list files to use. If paths are not given, the
default ones will be used. This helps us to provide test files during unit
tests.
Both the findProviderForMCCMNC() and findProviderForSid() methods are exported
out of the GSM and CDMA specific classes, and new unit tests for them are
implemented. Tests can be run manually with:
$> ./tests/run-test.sh tests/unit/mobileProviders.js
https://bugzilla.gnome.org/show_bug.cgi?id=687356.
Logind provides a Suspend method, which we should use instead of
the UPower API when available. Expose this in loginManager, using
the UPower API for the ConsoleKit implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=686482
A missing extension directory isn't worth debug spew, so check
if the error when reading the extension directory is NOT_FOUND,
and if so, suppress output.
https://bugzilla.gnome.org/show_bug.cgi?id=685466
Currently the HistoryManager consumes all arrow up/down key presses
unconditionally. Change this to only consume the event if the entry
text was actually changed, e.g. not when trying to move past the
first/last item.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
Various code around had different paths for ConsoleKit and
logind. Consolidate it by making an abstract class that all
callers can use, which hides the implementation details of the
two daemons.
https://bugzilla.gnome.org/show_bug.cgi?id=682096
In preparation for accessing it in the screenshield, factor out
common code for ConsoleKit and Systemd.
Also, clean up ConsoleKit manager, as the daemon is required in
a non systemd installation. In particular:
- We allow it to be autostarted at session startup (or really,
we expect it to be already there, started by GDM during session
opening).
- We no longer silently assume that the session is active if
it can't start.
https://bugzilla.gnome.org/show_bug.cgi?id=682096
This is a bare-bones copy/replace. It does not implement ChangeLog
support. If we cannot get System Updates integration, I will implement
notification support.
https://bugzilla.gnome.org/show_bug.cgi?id=679099
When PackageKit signals that it prepared an update, offer an option
to reboot and apply it, using a helper that will setup the next
reboot and then calling to gnome-session.
https://bugzilla.gnome.org/show_bug.cgi?id=677394
When connecting to virtual machines with usb-device redirection, such as Spice
enabled vms, automount may get in the way. Specifically if auto-usbredir is
enabled in the vm-viewer, then the usbredir code and the automount code race
for who gets to the device first.
If the automount code wins the race this is a problem, since usbredir causes a
device-disconnect (iow the usb mass storage driver sees an unplug), so in the
end usbredir always wins, and we end up with a non clean potentially corrupt
filesystem. Also see:
https://bugzilla.redhat.com/show_bug.cgi?id=812972
There for the need exists to be able to inhibit gnome-shell's automounting,
since all other inhibits run through gnome-session, I've chosen to do the same
for the automount-inhibiting. I've also submitted a patch to gnome-session to
reserve flag value 16 for this, see bug 678595.
This patch adds support to gnome-shell to honor this new inhibit flag.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=678597
The dependency chain spirals out from folks->zeitgeist->xapian...and
I'm really not interested in pulling in all of that into the core
shell.
There is work on splitting out contact search into gnome-contacts; I'd
add a bug link but Bugzilla is down.
This allows us to move to a file-monitor based approach in the future.
Since we need signals, we convert the current set of functions to an
object we attach signals too, leading to the new ExtensionFinder object.
https://bugzilla.gnome.org/show_bug.cgi?id=677586
This is seldomly used, and isn't checked in SweetTooth. Just remove
this inconsistency here rather than adding infrastructure to manage
and check it elsewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=677586
Some extensions may have complex layouts with multiple subdirectories.
Currently, getCurrentExtension doesn't support this, as it uses a regex
and assume's that the last path's component's parent is all that's needed.
Fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=677001
gnome-shell-extension-prefs uses format(), but can't pull in Shell
(which is a dependency for the module), since that in turn would pull in
Meta. Fix this by moving the introspected int format function to ShellJS
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=673106
gnome-session moved away from using properties over DBus in 2008, which
means that the code in GNOME 3.0 never should have worked -- but it did,
which makes me suspect that it was a quirk of the GJS DBus implementation.
Switch over to the proper inhibitor API, which is based on methods. If
gnome-session eventually gets ported to GDBus, then we can switch back
to properties.
https://bugzilla.gnome.org/show_bug.cgi?id=672270
Although not all "Finding and reminding" applications are ready
yet, the integration with gnome-documents' search results overlaps
enough with the "Recent Items" provider to justify its removal.
https://bugzilla.gnome.org/show_bug.cgi?id=670150
Substitutions generated by configure don't resolve prefixes, so
cannot be used for paths. Config already had localedir, and next
commit will need libexecdir and sysconfdir, so just bite the bullet
and move to sed.
https://bugzilla.gnome.org/show_bug.cgi?id=658484
Gsm.GetRegistrationInfo and Cdma.GetServingSystem return a single argument
consisting of a tuple, not three separate arguments. This is
a regression from the GDBus port.
https://bugzilla.gnome.org/show_bug.cgi?id=670005
The "extension" object is what I previously called the "helper" object.
It contains the extension importer object as well as the metadata object.
Things that were previously added on to the metadata (state, path, dir, etc.)
are now part of this new "extension" object.
With the new importer changes brought on by the extension prefs tool,
extensions are left without a way to import submodules at the global scope,
which would make them rely on techniques like:
var MySubModule;
function init(meta) {
MySubModule = meta.importer.mySubModule;
}
That is, there's now a lot more meaningless boilerplate that nobody wants
to write and nobody wants to reivew.
Let's solve this with a few clever hacks.
Allow extensions to get their current extension object with:
let extension = imports.misc.extensionUtils.getCurrentExtension();
As such, extensions can now get their own extension object before the
'init' method is called, so they can import submodules or do other things
at the module scope:
const MySubModule = extension.imports.mySubModule;
const dataPath = GLib.build_filenamev([extension.path, 'awesome-data.json']);
https://bugzilla.gnome.org/show_bug.cgi?id=668429
Add two new APIs, "launchExtensionPrefs" to let SweetTooth let the user
launch the extension preferences tool directly from the browser. To allow
SweetTooth to check if an extension can be configured, add a new key to
the 'metadata', 'hasPrefs', which is returned by the GetExtensionInfo/
ListExtensions DBus methods.
https://bugzilla.gnome.org/show_bug.cgi?id=668429
A new tool, 'gnome-shell-extension-prefs' can load a new entry point from
extensions, 'prefs.js', which has an entry point to return a GTK+ widget.
This allows extensions to have their own preferences dialog, without each
extension needing to ship its own Python script and .desktop file.
https://bugzilla.gnome.org/show_bug.cgi?id=668429
