To avoid the burden of maintaining multiple build systems, autotools
support has been removed.
GitLab CI configuration has also been updated to use meson.
The GNOME Shell search results are forwarded from the results of
GLib's g_desktop_app_info_search() function, which matches the
Name, Exec, Keywords, GenericName, X_GNOME_FullName, and Comment
keys from desktop files[0].
Since Evince is now named "Document Viewer", a query for "evince"
would match the "Exec" key and present the application in the search
results as expected. Unfortunately that doesn't happen for Flaptaked
Evince, which would get its desktop file "Exec" key overwritten to
something such as Exec=/usr/bin/flatpak run --branch=stable
--arch=x86_64 --command=evince org.gnome.Evince --new-document
This way, searching for "evince" when only the Flatpaked version
of it is installed returns no results. Searching for "Document
Viewer" presents the application as expected.
Its been proposed in GLib to parse the "Exec" key for searches
but that was rejected[1] because it would imply establishing an
API which assumes that the command line behavior of Flatpak would
be stable/never-change.
A fix was proposed in Flatpak directly[2] but it was rejected,
leaving us with the only option of adding the historical/legacy
application names to the "Keywords" key in their desktop files.
Many users, such as myself, have the "muscle memory" of search
for the old application's name, such as "evince", "totem", "gedit".
Although I agree that the new names should be presented to new
users and that the old ones shouldn't be visible in UI, it makes
sense and little effort to support the search for the old names IMO.
I proposed the same changes in "gedit"[3].
[0] https://gitlab.gnome.org/GNOME/glib/blob/master/gio/gdesktopappinfo.c#L378
[1] https://gitlab.gnome.org/GNOME/glib/issues/1706
[2] https://github.com/flatpak/flatpak/issues/2749
[3] https://gitlab.gnome.org/GNOME/gedit/merge_requests/44
When document type does not support 'find', Evince disables the
find feature. Previously, we added a tooltip explaining the reason.
However, a straightforward visual cue is more desirable, especially
for touchpad users.
Aside the tooltip, we now also provide an icon that mimic other
icons in GNOME when a service is unavailable, that is, an 'x' on
the icon for mute or wifi.
Fixes#105
Regardless we renamed the app-id to org.gnome.Evince, and desktop
files, icons, etc. to match the name; we keep the D-Bus services
in lowercase for backward compatibility.
* Set application id lowercase
* Make the daemon and application names match
* Make the icons and desktop files match the
application id
* Keep the D-BUS interfaces backwards compatible,
and enable
the flatpak version to launch the daemon.
* Take care of translations after renaming files.
This commit also changes the application id for flatpak,
which is a compromise.
Many of used paths are using relative paths, which makes some
libraries/executables not to be found.
This has been changed to use absolute paths that fixes these issues.
It doesn't get exported outside the sandbox, so the session systemd
doesn't know how to start it. The information in the systemd .service
file should be enough for systemd to correlate the two when running
outside the sandbox.
Recent versions of Gettext are able to translate several formats
that are used in GNOME applications.
Both autotools and meson have been migrated from Intltool to
Gettext.
Meson is a build system focused on speed and ease of use, which
helps speed up software development. This patch adds Meson support
alongside Autotools.
It seems the action icons are not found inside
symbolic/actions, but they are found in scalable/actions.
Moved the -symbolic icons to scalable to solve temporarily
the issue.
Fixes#961
* Take format-justify-left and make it as the outline icon.
* Make a copy of the icon as the purpose in the theme is
different and it may change in the future.
See #947
This reverts commit 1dad69e1ba.
As per comment in MR #44:
"It pains me to ask you to postpone the merge until after 3.30.
Because we rolled out the initiative too late, it's been decided
to aim for 3.32 with the actual icons."
evince-previewer is not supposed to be used directly by the users and
then shouldn't be added to the list of available applications when
opening files.
On debian it causes issues as the .desktop file are automatically
registered in the /etc/mailcap file and applications using this
mechanism will prefer evince-previewer over evince itself, see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825418https://bugzilla.gnome.org/show_bug.cgi?id=744893
I've implemented this by adding a --with[out]-systemduserunitdir
configure option, because that seems to be what's conventional
in projects where user units are configurable at all. If a user or
distribution wants to disable these units, it's easier if they can
pass --without-systemduserunitdir to everything, rather than checking
whether it's spelled --disable-systemd-user-units in this particular
project. Also, a binary enable/disable option wouldn't be noticeably
less code.
If the systemd user unit is disabled at configure time, the
SystemdService line in the installed D-Bus service file is commented
out. This addresses the corner-case situation where a user configures
Evince --without-systemduserunitdir, but enables systemd activation
for their session dbus-daemon (perhaps later). In that situation,
we presumably want Evince to continue to use traditional activation,
rather than trying to launch a nonexistent systemd unit.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=755897
Reviewed-by: Carlos Garcia Campos
EvView CSS used to be shared in adwaita theme, but now that adwaita has
been merged into GTK+ and app specific CSS has been removed, we need to
add the EvView CSS to all of its users.
The NoDisplay=true made sense in a document centric system model but in
the app centric GNOME 3, we want it to show up in the menu and in app
search.
https://bugzilla.gnome.org/show_bug.cgi?id=634245
