When setting the key focus to `this._dialog`, the default button is not
automatically focused and no button has key focus.
Use the `initialKeyFocus` property of the dialog instead, and set focus
to the default button if the dialog is not already focused.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/786>
It sounds strange that buttons would admit Pango markup
in their label text. It sounds better to default to plain
text, and let users wanting markup to access the child
directly.
This also makes the first label being set consistent
with later text being assigned wrt markup usage, since
the non-markup ClutterText API is used if the child is
already present and of the expected type.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3149>
Small and well-defined feature requests can be very useful, but
unfortunately too many are neither small nor well-defined.
Try to improve on that by adding another README section that
explains that changes need design approval, and points to
appropriate places to have broader design discussions,
hopefully without being too off-putting.
While this is unlikely to stop all "bad" feature requests, it
at least gives us something to point to when closing requests.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3122>
We currently just link to the issue tracker without providing
any further guidance.
Improve on that by pointing to the appropriate handbook chapter,
point out extensions as a possible source of issues, and direct
users towards discourse/matrix for support/discussions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3122>
The link to the GNOME schedule was added because of some confusion
of which versions are supported upstream. Briefly outline the
policy of "last two stable + current main", so that the information
can also be deduced from tags etc. without scrolling through the
schedule calendar.
While at it, update the link to the schedule to point to the
future release.gnome.org page.
Death to the wiki!
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3122>
The current debugging page on the wiki is fairly outdated and
very X11-centric, so base the new page on the recently added
mutter documentation instead, but with a bigger focus on
Javascript debugging.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3122>
While we use the standard meson build steps, our dependencies
are non-trivial and running the shell can be tricky; it's
certainly worth documenting.
This is also a good opportunity for plugging out toolbox tooling.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3122>
We have a fair bit of C code, yet don't document the expected
coding style. This is not much of an issue for regular GNOME
contributors as we are following the conventions of the wider
project (glib, gtk, clutter, ...), but it's still better to
spell it out.
Do that by adapting the corresponding documentation from mutter.
Even if much of our C code doesn't match all the new guidelines,
it's good to consolidate the coding style between both projects.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3122>
Start consolidating project-wide documentation in the docs/ folder.
While at it, change the name `js-coding-style`, which is both less
ominous and allows for an accompanying `c-coding-style`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3122>
Mutter's documentation was extended recently, with files using a
pattern of `some-stuff.md`. There is no strong argument for using
camel case, so switch to the same pattern as mutter to remove some
unnecessary friction for people who contribute to both projects.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3122>
To avoid having the coding style get out of sync with the actual
coding style in the future, run eslint on the individual snippets
when either the guide or the linter config change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3146>
Now that StIcon updates its texture automatically on icon theme
changes, we only have to recreate icon actors that aren't StIcons.
(This probably only applies to the folder icon in the app grid
where the sub-icons do use St.Icon, but making that assumption
feels dodgy with an API as generic as `createIcon()`)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3141>
St.Icon is very commonly used for displaying themed icons, yet so
far updating the icon on icon theme changes is left to the caller.
Unsurprisingly, very few actually do that, with the result that
for most icons, icon theme changes only take effect after a delay
(say, a color change on hover) or not at all.
This is also inconsistent with GTK, where Gtk.Image will automatically
pick up icon theme changes.
Address this by tracking whether the current icon corresponds to
a themed icon, and update it automatically on theme changes if
it does.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3141>
Since commit c570011 dropped the `with` statement, this bit of
the test has only checked for writes to a specific variable
in the file.
There is no direct replacement for `with` here, the best we can
do (I think) is comparing property names on the global objects
before and after the `eval()` call.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3132>
