The original UTC support in GWeather piggy-backed on the existing API, but
as "country" or "city" don't make sense in the context of UTC or AoE, the
concept of "named timezones" was introduced. Handle those explicitly to get
back labels for those locations.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/150
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
If there are locations unknown to the libgweather version gnome-shell is
using, don't crash.
JS ERROR: TypeError: b.location is null
WorldClocksSection<._clocksChanged/<@resource:///org/gnome/shell/ui/dateMenu.js:141:1
WorldClocksSection<._clocksChanged@resource:///org/gnome/shell/ui/dateMenu.js:139:9
https://bugzilla.gnome.org/show_bug.cgi?id=791148
Using a unicode character here means it may look quite different
from the intended style (for instance with emoji fonts). Avoid
this by providing a custom icon and use that instead.
https://bugzilla.gnome.org/show_bug.cgi?id=766368
It's not exactly clear what changed - gobject-introspection, gjs - but
the newly added gweather_condition_to_string_full() API no longer works
like it used to. The replacement code does look more idiomatic anyway,
so just fix the code without investigating the reason of the breakage.
https://bugzilla.gnome.org/show_bug.cgi?id=787423
GWeather now provides us with API to request strings that don't
use sentence capitalization, so we can use it for summaries that
don't start a sentence to make for more natural phrases.
https://bugzilla.gnome.org/show_bug.cgi?id=779873
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
PopupMenu needs special-treatment of certain types of menu items,
which it determines via children's _delegate property. However as
the calendar drop-down is very unmenu-ish, we use regular actors
rather than PopupMenuItems and the missing _delegate property
triggers a warning. Just add it as the bare minimum to make
PopupMenu happy.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
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
Similar to the Clocks integration we've had in the date+time drop-down for
a while, the designs have called for a similar section that integrates
GNOME weather as well. Use the WeatherClient added in the previous commit
to implement that section and add it to the popover.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
In order to avoid distracting popup size changes while browsing
other dates, we freeze the size to the last size request. However
in case of more complex size negotiations - wrapping or ellipsizing
labels, scrollable elements etc. - there's a chance of stray calls
to get_preferred_width/height() that are not used for the actual
allocation. If such a call happens to be the last size request
before the layout is frozen, the saved size will be wrong. To fix
this, save the allocated size rather than the requested one.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
We want the width of the calendar column to be determined by the
calendar, other elements should adjust their allocation accordingly.
However neither ellipsization nor wrapping will kick in unless the
parent's width is restricted, so use a small custom layout manager
that enforces the desired behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
When gnome-clocks is installed, there is currently a race between the
GSettings schema being added to the database and the world clocks
session trying to use it. The prize if we win that race is an abort
in GIO, so use the newly added AppSettingsMonitor skip the race
altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=766410
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
Currently both the base classes for messages/sections and the message
list itself that instantiates the available sections are located in
the same module. As a result, it isn't possible to define sections
in a different module without introducing circular dependencies. The
Calendar module is already unwieldily large, so split it up a bit to
avoid it growing even bigger in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=756491
We currently block banners while the time+date menu is open, as it
would obscure the notification. However it is not necessarily the
only menu for which this is the case, so generalize the behavior
to all menus that would overlap banners when open.
https://bugzilla.gnome.org/show_bug.cgi?id=745910
Ideally we would allow navigating into the button in the screen
reader case, so the configured clocks are read out properly.
However we can still do better than nothing short-term by pointing
to the section header as the button's label_actor.
https://bugzilla.gnome.org/show_bug.cgi?id=745393
We currently show the world clocks section unconditionally, even when
the session mode disallows launching the Clocks app to configure the
displayed clocks. This does not make sense, so hide the entire section
when the session mode disallows settings.
https://bugzilla.gnome.org/show_bug.cgi?id=745494
Make sure the message list section is set to the current date
when opening the menu, otherwise the calendar might skip
the selected-date-changed event (because the day did not change)
which would leave the message list with an uninitialized date.
https://bugzilla.gnome.org/show_bug.cgi?id=745412
The message indicator conveys that the message list contains unseen
messages that will not be shown as banner. So its visibility depends
on two factors: the number of unseen messages, and the number of
messages waiting in the queue to be shown as banner. As we currently
only update the visibility on changes to the former, the indicator is
not always accurate - for instance sources notify count changes before
passing on a notification to the message tray for display.
To fix, add a signal to the message tray to notify when the queue
changes and use it to update the indicator's visibility.
https://bugzilla.gnome.org/show_bug.cgi?id=744880
The summary may contain notifications that have not been seen by the user
and won't be shown as banner. Currently this is only the case for resident
notifications that are emitted by the focused app, but it will become more
common as we will start limiting the number of queued notifications.
Indicate to the user that more notifications are available by displaying a
small dot in the top bar button.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
As the popup's height depends on its content, which itself varies
depending on the selected day, browsing the calendar can result
in distracting size changes. To avoid this, the design calls for
the height to be frozen to the previous one in that case.
As the popup will always open with the current day selected, we
don't have to be very sophisticated and can just lock the popup
to the height corresponding to that day.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
The message list is not only a replacement for the calendar events
list, it will also take over the notification summary from the
message tray. As we start drawing events from other sources than
calendars, hiding it based on whether or not any calendars have
been set up is no longer appropriate, so always include it in the
calendar drop-down now.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Turn the existing EventsList into a MessageListSection and add the
message list to the calendar drop-down. The new events list only
displays events for the currently selected day, but in a more
structured and friendlier way than the old one.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Menu items are on their way out of the calendar drop down, so let's
start with the easy one. This one is removed without replacement,
but then the Date & Time panel should be a one-time stop for most
users anyway, so not having a direct shortcut should not be much of
a problem. It is also the last remaining Settings item outside the
system menu ...
https://bugzilla.gnome.org/show_bug.cgi?id=744817
The new design has the events list on the left and the calendar on the
right, so swap them around and remove the vertical separator between
them in favor of some additional whitespace as in the mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Commit 1291bcd0c8 implemented it for dateMenu, but the function
is already used in screenShield as well. Just add it globally as
we do for other standard gettext "macros".
Splits instantiation of the event source into a separate method,
allowing extensions to subclass the DateMenuButton and provide its
own calendar source.
https://bugzilla.gnome.org/show_bug.cgi?id=672500
We commonly mark strftime format strings for translation to account
for date/time representations without an existing strftime shortcut
("Yesterday %H%p"). As those translations are looked up according to
the locale defined by LC_MESSAGES, while the conversion characters
themselves are resolved according to LC_TIME, the result can be
rather odd when mixing locales ("Den 27. January"). The correct
solution would be to install translations for format strings in
the LC_TIME catalogue and look them up with dcgettext(), but we
don't have the infrastructure to do that easily. Work around this
by adding a helper method that looks up a string in LC_MESSAGES
using the locale defined by LC_TIME and use that to translate
format strings, which has the same result.
https://bugzilla.gnome.org/show_bug.cgi?id=738640
Instead of waking up the JS every second to set the clock and update a
date label the user will rarely see, simply use property binding to
bypass JS string handling, and update the date in the menu when the menu
is opened.
Commit 14ceb10555 changed the "Open Calendar" item to open the
"recommended" calendar application rather than the default one to
avoid problems with MIME subclassing (namely falling back to the
default text editor when no calendar app is installed).
With this change however, the application launched does no longer
necessarily match the one configured in Settings, which is unexpected.
To avoid both problems, use the default calendar application again,
but only if it is in the list of recommended applications.
https://bugzilla.gnome.org/show_bug.cgi?id=722333
Having the ability to go to the current date if the user is already
on the current date can be confusing. So don't make the button reactive
until the selected date changes.
https://bugzilla.gnome.org/show_bug.cgi?id=726724
