Re: GNOME Online Accounts 3.34 won't have documents support

[Debarshi Ray <rishi is lostca se>]

On Sun, Jan 27, 2019 at 12:13:26PM +0000, Emmanuele Bassi wrote:
> Again, not a huge deal; sure, Documents is actually useful to navigate
> through the Google Drive contents???the Drive web UX has become shockingly
> bad over the years, unsurprisingly since its a fate that befalls every
> Google application???but we can live without it, and it seems it's a niche
> usage to begin with.

GTK3 and GTK4 don't have a credible list or grid widget. We literally
don't have anything to implement 90% of the GNOME Documents UI. There's
no way Google's web UI can be worse than that.

Also, porting GNOME Documents to GTK4 involves LibreOffice work.

> Again: maybe Documents isn't used. Maybe Photos, Music, and whatever else
> aren't used either.

Whether it's used or not is only a part of the story. It's death by a
thousand paper cuts.

I already provided a list of issues GNOME Documents elsewhere.

> Who knows, we don't have metrics, right?

We have metrics, yes.

We have enough metrics to gauge if:
(a) an application has more than an infinitesimally small number of users 
(b) an application has an active enough contributor community

Both (a) and (b) were coming out false for an extended period of time for
GNOME Documents.

Sitting behind multiple bug trackers (in my case GNOME, Fedora and RHEL)
provides enough indication about (a). Insights into the RHEL customer and
user base is another. RHEL 8 dropped GNOME Documents around the same time
as both Fedora and RHEL 8 adopted GNOME Photos. You might not believe it,
but I played almost no role there.

Then there are Andrew Hayzen's scripts to gather data from Flathub:
https://gitlab.com/ahayzen/flathub-api-stats-generator

We do not have an exact measure of the number of active human users from
Flathub, but we do have the number of times an application has been
downloaded. Those numbers are influenced by the number of people who
bothered to install the application or had it offered by their distributor,
that's (a), and the frequency of updates to the Flatpak, that's (b).

Here are the figures from 4th January 2019:
https://pippin.gimp.org/tmp/flathub-download-stats-20190104.txt

Here are the figures from 26th October 2018:
https://pippin.gimp.org/tmp/flathub-download-stats.txt

The numbers for org.gnome.Documents are 1734 and 1279 respectively.

In comparison:
* org.gnome.Books is at 2226 and 2067
* org.gnome.Music is at 3137 and 2632
* org.gnome.Photos is at 9704 and 8591

Some others:
* org.gnome.Gnote is at 53299 and 43951
* org.gimp.GIMP is at 287177 and 214634

Those numbers inform our conclusion that both (a) and (b) were coming
out false for GNOME Documents.

>  - we told people to use Flatpak for core applications; Flatpak doesn't
> really like it when session services change, because session services are
> part of the system API that cannot be sandboxed. Sure, GOA is almost an
> outlier, but we have a bunch of services that are more than cavalier in
> attitude when it comes to changing their features; how do we deal with that
> happening?

Except there were no API changes. Neither the D-Bus nor the C API changed.
What changed is the metadata advertised by the accounts, something that
applications introspect at run-time anyway.

Flatpak in this context is a red herring. It only guarantees stuff
that's directly linked as ELF binaries, build flags, icons, etc.. It
doesn't even enforce the theme.

If you have an application that requires a D-Bus service, Flatpak
makes no guarantees at all. Every Tracker based app out there is used
to handling such errors.

If you have an application that hard codes X support, then it won't
run unless the host offers an X server; and the same way around for
Wayland.

If you have an application that needs a certain Linux kernel system
call, you need to introspect /proc/kallsyms at run-time.

Etc..

>  - we do have a user base, and we need to communicate changes effectively
> so that we don't spend cycles constantly defending our decisions; that
> stuff is exhausting.
>  - we have a software development platform, and we'd like for app
> developers to use it; we need to have processes in place to communicate our
> expectations with second/third parties.

Except, all that you accomplished in this thread is to scare the Deja
Dup community into believing GNOME or GOA or whatever is actively
harmful or hostile to them.