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. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
