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

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:

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:

Here are the figures from 26th October 2018:

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

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

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


 - 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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]