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

[Debarshi Ray]

On Thu, Jan 17, 2019 at 10:21:01AM -0500, Christopher Davis wrote:
> As asked on the fedora issue, will this mean that cloud documents will 
> no longer be available within the app?

If you want to keep the online accounts integration alive in Documents
then you'd need to do something like this while introspecting the
accounts over GOA API:
  * s/documents/files/g
  * s/Documents/Files/g
  * s/DOCUMENTS/FILES/g

Look in gnome-documents.git and gnome-online-miners.git.

Basically, you'd be looking for the "files" tag, instead of
"documents". Just like Deja Dup looks for "files", since we don't have
a "backup" tag.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Michael Gratton]

On Tue, 29 Jan, 2019 at 6:48 AM, mcatanz...@gnome.org wrote:
We'll be much more careful about adding apps in the future to ensure 
we have consensus and avoid backtracking on changes again. (I think 
Geary is still a very plausible candidate, though.)


As mentioned a long time ago, I think I'd be happy for this to happen. 
I haven't been pushing it from my end however because I just don't have 
the time at the moment.


//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Michael Gratton]

On Mon, 28 Jan, 2019 at 9:27 AM, Sriram Ramkrishna  
wrote:
A blog post was written and put out there because there was 
confusion/issues with 3rd party folks wanting to integrate with GOA. 
I'm not sure what more is required?


Documenting it in the API docs or on the GOA wiki would have probably 
been useful.


The wiki currently says:

GNOME Online Accounts Single sign-on framework for GNOME. It aims to 
provide a way for users to setup online accounts to be used by the 
core system and applications…


Which reads to me as being there to be used by "GNOME applications", of 
which I would count Geary, because that the desktop environment it is 
targeted at. If 3rd party developers were not supposed to use it then 
that should have been spelled out loud and clear everywhere app 
developers would see it. Including, as Michael Terry suggested, as a 
compiler error.


//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Adrian Perez de Castro]

Hello!

On Thu, 24 Jan 2019 22:03:01 +0100 (CET), Adrien Plazas via desktop-devel-list 
 wrote:

> Le jeu. 24 janv. 2019 à 19:32, mcatanz...@gnome.org a écrit :
>
> > It's been a while, but IIRC I wanted a reading list mode to not be
> > totally dependent on Pocket. We could sync it to Pocket though, since
> > that fits in nicely with our existing Firefox Sync support, but there
> > should be local storage too.
> 
> If support for a more ethical alternative to Pocket, e.g. Wallabag, was
> added using the same API (note, I don't know how GOA work and I am just
> assuming things) then the hard dependency on Pocket would be dropped,
> even though it's not a local solution.

I completely agree with Michael and Adrien here: I would rather have a
local reading list as well, and syncing would be an extra on top.

Personally I would favour Wallabag over Pocket, but I understand that
it can be useful and can be considered to fit well with the “we sync the
things Firefox can do as well” idea, and I wouldn't be against having support
for Pocket.

BTW, the reader mode currently available in Ephy is already one step in the
direction; I've found myself manually saving some thing to read later with
the “Save As...”, then loading the “.mhtml” and immediately switching the
reader mode. We would need some UI and automation over this manual process 
:-)

Cheers,

-Adrián


pgpDfC9XLGAHy.pgp
Description: PGP signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[mcatanzaro]

This is a tangent of a tangent, but:

On Mon, Jan 28, 2019 at 9:29 AM, Jeremy Bicha  wrote:

Thank you for your reply. Ubuntu includes GNOME To Do by default in
18.04 LTS and still does. I guess we need to discuss whether it should
be removed by default, but we try to limit the adding and removing of
apps because of the disruption it causes to upgrading users. We added
it because we try to follow GNOME Core (for many reasons we are unable
to follow it completely) and we found the app fairly useful. We
appreciate you developing and maintaining it.


This is kinda my fault. I added To Do to core without consulting with 
design team. (I think I had consulted Georges? But it was a while ago.) 
Based on input from design team and also Fedora Workstation, we wound 
up adopting more a restrictive approach to managing the core apps, and 
subsequently removed To Do after a year or so. I think To Do was there 
by default in just one Fedora release.


The current list of core apps is here:

https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/master/elements/core/meta-gnome-core-utilities.bst

We'll be much more careful about adding apps in the future to ensure we 
have consensus and avoid backtracking on changes again. (I think Geary 
is still a very plausible candidate, though.)


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Philip Chimento via desktop-devel-list]

On Mon, Jan 28, 2019, 00:00 Debarshi Ray,  wrote:

> On Sun, Jan 27, 2019 at 09:26:05PM -0800, philip.chime...@gmail.com wrote:
> > On Sun, Jan 27, 2019 at 1:04 PM Debarshi Ray  wrote:
> >
> > > On Sun, Jan 27, 2019 at 11:24:00AM -0800, philip.chime...@gmail.com
> wrote:
> > > > 2. It's not possible to discontinue support for services X, Y, and Z
> from
> > > > GOA, and yank the rug out from under apps that expected (even if that
> > > > expectation was wrong) it to be part of a stable platform.
> > >
> > > You mean like the time when GJS broke GNOME Documents?
> > >
> >
> > Sorry, I don't know what particular event you're referring to.
>
> https://bugzilla.gnome.org/show_bug.cgi?id=791613
>
> > GJS is even different from GOA because, as pointed out earlier
> > in the thread, GOA is not part of a Flatpak runtime but is still used by
> > Flatpak apps.
>
> One, Flatpak is still not the primary way users consume applications.
>
> Second, being part of the runtime is irrelevant for a session D-Bus
> service like GOA. The service is meant to live on the host. There were
> no D-Bus or C API breaks. What changed is the metadata associated with
> an account, which applications introspect at runtime anyway.
>
> Third, with Flatpak, a newer version of an application has to be ready
> to run on an old host anyway, and the old host might not have the GOA
> feature that your new application wants. Apps need to be resilient
> about that. Hence the introspection.
>
> > Are you seriously suggesting that because I committed some mistake, you
> > should insist on the right to make the same mistake with eyes wide open?
>
> And what mistake am I insisting on making?
>
> > Literally just a few messages before mine in the thread, we heard about
> > deja-dup.
>
> And what about Deja Dup? GOA screwed over Deja Dup?
>
> > For what it's worth, I don't appreciate the ad-hominem attack here. I
> > intended to *help* you by trying to break the cycle of people ignoring
> your
> > problem and yelling at you about theirs, and vice versa, but if you
> prefer
> > to continue yelling then suit yourself.
>
> You are trying to help me by making unsubstantiated innuendoes?
>
> You said:
>
> > PS. Yes, count me among the completely surprised that GOA is not an API
> > that apps should use. It was not communicated anywhere close to the level
> > it needed to be. That's on GNOME, not on those app developers. This is
> why
> > it's our problem.
>
> If nothing else, you are driving a wedge between "GNOME" and "those
> app developers".
>
> In the context of this thread, it also sounds as if there exists a
> whole bunch of application developers whose hard work was thrown away
> because of me.
>
> You talk about communication. The very first version of the GOA home
> page, created in August 2012, said:
>
> "The objective of GOA is to provide a central place where a set of
> online accounts (defined by the OS/distributor) can be configured
> for use with core applications. In UX terms, GOA provides a static
> list of online accounts that can be setup by users (through the
> Online Accounts panel in System Settings). These accounts will then
> be used by core GNOME applications.
>
> While third party applications can access the accounts set up
> through GOA, this is not its primary goal, nor does it set out to
> enable third party applications to add online accounts of their own.
> There are several reasons for this:
>   ...
>   ...
> "
>
> See:
>
> https://wiki.gnome.org/action/recall/Projects/GnomeOnlineAccounts?action=recall=1
>
> That text was recently improved and lives on its own page, linked
> multiple times from the main landing page:
> https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals
>
> The current landing page says:
> "GNOME Online Accounts Single sign-on framework for GNOME. It aims to
> provide a way for users to setup online accounts to be used by the
> core system and applications."
>
> See: https://wiki.gnome.org/Projects/GnomeOnlineAccounts
>
> We don't have an active PR team at our disposal to send out weekly
> press releases - it's not like the GNOME Engagement Team has a ton of
> resources. Blogs were written to address the most pressing issues of
> the day.
>
> There doesn't exist a single application developer whose work was
> thrown away without any prior notice or discussion.
>
> The Telepathy support was removed after multiple Empathy and Telepathy
> maintainers publicly and repeatedly asked people not to use the
> stack. The removal was publicly announced early in a development
> cycle. Not a single soul complained when this happened.
>
> Michael Catanzaro, Allan, Jakub and I have had multiple discussions,
> often over email, with Felipe Borges, author of GNOME's Pocket client
> [1], and Bastien over the years. The most recent discussion was about
> toggling the Autotools and Meson options to not build the Pocket
> extension by default, accompanied with a public announcement. That's
> supposed to happen after March. 

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

[Jeremy Bicha]

On Mon, Jan 28, 2019 at 8:47 AM Georges Basile Stavracas Neto
 wrote:
>  * It was never my intention to make GNOME To Do a core app, and I was
>glad to see it being dropped from the core set. For various reasons,
>both technical- and design-wise, I believe To Do wasn't a good fit.

Thank you for your reply. Ubuntu includes GNOME To Do by default in
18.04 LTS and still does. I guess we need to discuss whether it should
be removed by default, but we try to limit the adding and removing of
apps because of the disruption it causes to upgrading users. We added
it because we try to follow GNOME Core (for many reasons we are unable
to follow it completely) and we found the app fairly useful. We
appreciate you developing and maintaining it.

Jeremy
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Jeremy Bicha]

On Mon, Jan 28, 2019 at 8:28 AM Debarshi Ray  wrote:
> The Todoist provider was always disabled by default. So unless a
> distributor enabled it by default, I don't see how that can happen.

That's an important point that I didn't notice before. Fedora and SUSE
kept it disabled; Arch, Debian and Ubuntu enabled Todoist. (In this
particular context, I was Debian and Ubuntu and Debarshi was Fedora.)

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Alberto Mardegan via desktop-devel-list]

Hi,

On 21/01/19 19:32, mcatanz...@gnome.org wrote:
> We have a rule though: the account types exposed in
> gnome-online-accounts must be used by at least one core application.
> It's a good rule because it doesn't make sense to have settings in
> control-center for apps that aren't installed by default. So unless we
> reverse course and add gnome-documents back to core, the documents
> account configuration settings should move from control-center to
> gnome-documents itself.

I wrote most of the Ubuntu Online Accounts stuff which was used in the
Ubuntu Phones and is still used in Ubports. I hope that bringing my 2
cents will be of some help.

In Ubuntu Phone, we had the same rule that you wrote above: if no
application can use a certain account, it doesn't make sense for the
system settings to carry an option to create that account. But it
doesn't mean that the functionality needs to be removed: it can just be
hidden in the user interface. In fact, what we have been doing in Ubuntu
was to carry configurations for several online accounts, but show them
only if there was at least one application installed that could use
them. Since most of these authentication methods are either OAuth 1 or
OAuth 2, the "weight" of these configurations is minimal: just a small
JSON file.
As soon as the user installed an application supported by an online
accounts, the option to create the account would appear in the system
settings.


Second (as mentioned somewhere else in the thread), about applications
being able to ship their own keys: yes, we support it, and it is indeed
the recommended way of working. We still provide the whole
authentication component, so that the application doesn't need to worry
about OAuth, but only needs to tell us what are its authentication keys
and what OAuth scopes it needs.

The account is created by a system process, and if more applications are
using the same account the user doesn't need to login multiple times: we
set the user context directory in the webview to be per-account, meaning
that cookies are shared across all applications operating on the same
account. Given that the webview is not opened in the application's
process, and that we use apparmor to confine the applications, there's
no way that an application can read the cookies.


Last, but not least: some service providers (IIRC Twitter and Facebook),
explicitly state that using an umbrella application to provide access to
several distinct applications, like GNOME is doing, is a violation of
the terms of usage.
In Ubports, the approach that we try to follow is to let the platform
authenticate using a very "weak" (permission wise) set of keys, just
enough to perform the OAuth login and retrieve some unique ID for the
user (e-mail, typically), which we can then show in the account list so
that the user can tell his own accounts apart.

This has also other advantages:
- should some application (or even the very Ubports) get banned by some
  platform, all the other applications continue to work
- less risk of hitting the API limits


Ciao,
  Alberto

-- 
http://blog.mardy.it - Geek in un lingua international
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Georges Basile Stavracas Neto via desktop-devel-list]

Since GNOME To Do is being constantly cited in this thread, I'd like to
officially clarify a few things:

 * It was never my intention to make GNOME To Do a core app, and I was
   glad to see it being dropped from the core set. For various reasons,
   both technical- and design-wise, I believe To Do wasn't a good fit.

 * As such, To Do should be treated as part of the extended GNOME set. It
   was a courtesy of Debarshi to land the Todoist provider in GOA, given
   that we knew it wasn't the right place for it to be since the very
   beginning.

 * We agreed on making GNOME To Do responsible for its own authentication
   process regarging Todoist. Back in 2017, we had discussions about GOA,
   and how to allow applications to reuse its authentication code. We did
   not agree on anything regarding that IIRC.

 * Dropping the Todoist backend from GOA was a decision made in good terms,
   at least from my side. We knew that was going to happen sooner or later.
   There are pending merge requests for moving authentication to To Do, but
   they depend on WebKitGTK that is GTK3, so it's not in a mergeable state.

 * I try to follow the GNOME release *schedule*, but To Do is deviating from
   the release *number*. I'm aiming to a 4.0 release together with GTK4. I'd
   like to experiment with the new GTK4 APIs, and give feedback to the GTK
   team about all that is going well or not as an application developer.

Hopefully that clarifies any doubts or misunderstandings anyone may have
regarding GNOME To Do.

With respect,
Georges
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

On Mon, Jan 28, 2019 at 05:14:39AM -0500, Jeremy Bicha wrote:
> This feels like an awfully aggressive way of asking for a reply in a
> heated thread that's already getting close to 100 emails. I don't know
> if replying will help but since you seem to want a reply so badly and
> because I do want to keep acting in good faith and not have our
> relationship damaged over this, here's a reply.

Umm... maybe consider avoiding relatively strongly worded messages
about nitpicky details? That too devoid of context.

Maybe assume that when I write a commit message, especially a
sensitive one deleting code, that I have done some basic fact
checking?

Since your first message, this thread has gone haywire. Maybe you
could have clarified what you wanted to say without leaving it
hanging?

> > Select a recipe
> > -> Buy ingredients
> > -> View shopping list
> > -> Share
> > -> Add service
> > -> Todoist
> 
> Your test case was so minimal that I didn't understand that's what it
> was. Let me give a few more words. Step 0 is to build GOA with
> --disable-todoist (if like me you're still using the stable version of
> GOA). Then log out and log back in to make sure that you're using the
> correct GOA service. The final step where you click the word Todoist
> opens gnome-control-center to the Online Accounts page which does not
> have a Todoist provider since we removed it in Step 0.

The Todoist provider was always disabled by default. So unless a
distributor enabled it by default, I don't see how that can happen.

It was disabled because we had a long discussion with Recipes and Todo
about what to do with Todoist. The code was merged into GOA in the
first place to avoid perpetually blocking a student project while we
were having this discussion.

It was taken out 1.5 years later to avoid giving everybody the
impression that Todoist was meant to stay in GOA. I believe 1.5 years
is a fairly long grace period for something that was never enabled,
and was never intended to be there in the first place.

If anything, this was discussed at length and clearly conveyed to the
relevant applications.

> > https://download.gnome.org/sources/gnome-todo/3.91/
> 
> Wait, GNOME To Do has one experimental release targeting GTK4 using
> the same version number scheme as GTK4 and that's enough for you to
> say that they are not following GNOME's Release Schedule?

That both Todo and Recipes wants to stay loosely coupled from core GNOME
was made clear during our discussions. Georges literally said so a few
times. The release numbering is one of the indicators of that.

> I'm
> sorry that you feel so attacked in this thread and I apologize if my
> replies or lack of replying feels like I'm trying to hurt you more.
> That is not my intent at all.

Thanks. That's appreciated. :)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

On Mon, Jan 28, 2019 at 12:33:09PM +, Emmanuele Bassi wrote:
> Bug trackers are an awful metric, with a clear and demonstrable bias.

For an application that regularly released in an utterly broken state,
a bug tracker is a decent indication.

> Nevertheless, as I said: I don't *care* about Documents. I care about the
> fact that we've added and removed things from GOA without establishing even
> a scrap of a process.

And what was the process through which GTK broke GNOME Terminal by
dropping geometry hints?

> If you stopped from lashing out at everyone you think is questioning your
> ability to do your job for just *five minutes* you'd have realised that
> this thread could have ended 80 emails ago

No, I am only fending off bullshit Brexit/Trump level fake news, and I am
lashing out at people who think their time is worth more than others.

> you just needed to open a wiki
> page and write down what the process for adding a new service and removing
> an existing service in GOA works, and what are applications supposed to do
> in either case.

The Wiki already has that.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Emmanuele Bassi via desktop-devel-list]

On Mon, 28 Jan 2019 at 11:40, Debarshi Ray  wrote:

> On Sun, Jan 27, 2019 at 12:13:26PM +, 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.
>
>
Oh, trust me: it's worse.


> Also, porting GNOME Documents to GTK4 involves LibreOffice work.
>

Indeed, that is a problem that is not easy to solve without dropping
functionality from Documents. It's probably a justification alone from
dropping Documents from the release, and archiving it, assuming we ever
want to port Documents to GTK 4.


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

And I already told you that I'm not advocating for Documents to be kept on
life support, or that you should keep the Documents integration in GOA
because of reasons.

I told you that removing things is perfectly okay, as long as we
communicate this upfront.


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

No, we really don't, I'm sorry.


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

Bug trackers are an awful metric, with a clear and demonstrable bias.

Unless you have instrumented the session in RHEL to give you numbers on how
many people launch Documents and how much time they spend on it, then
looking at the installation numbers in RHEL paints only a very limited
picture.

Nevertheless, as I said: I don't *care* about Documents. I care about the
fact that we've added and removed things from GOA without establishing even
a scrap of a process.

If you stopped from lashing out at everyone you think is questioning your
ability to do your job for just *five minutes* you'd have realised that
this thread could have ended 80 emails ago; you just needed to open a wiki
page and write down what the process for adding a new service and removing
an existing service in GOA works, and what are applications supposed to do
in either case.

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

Again, those numbers do not give you an accurate representation of use.
Downloads are *one* metric, and one that's not even very good. Before 3.30
we didn't have automatic Flatpak updates, which means downloading manually
whenever you remember to do so; with 3.30 we have automatic updates, which
means unless people actively uninstall an app, it'll still appear in the
stats. We don't know how many people install an application once; how long
does a session last; what kind of interaction there is; if it's used for
remote work or not.


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

You must have read a very different thread from the one I read, because
every one of your emails is a demonstration that nobody should use GOA at
all, unless it's a system service like the Shell which has no UX for
authorising access to things like the Calendar.

Not only you have been lashing out at everyone in this thread that told you
something you didn't like to the point of throwing out wild accusations of
slander 

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

[Debarshi Ray]

On Sun, Jan 27, 2019 at 12:13:26PM +, 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

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

[Jeremy Bicha]

On Mon, Jan 28, 2019 at 1:26 AM Debarshi Ray  wrote:
> You already attempted to slander me once before in this thread:
> https://mail.gnome.org/archives/desktop-devel-list/2019-January/msg00027.html
>
> It's been one week since I produced evidence against that:
> https://mail.gnome.org/archives/desktop-devel-list/2019-January/msg00035.html
>
> You had enough time to clarify your original statement or recant it. I
> no longer consider anything you say to be in good faith.

This feels like an awfully aggressive way of asking for a reply in a
heated thread that's already getting close to 100 emails. I don't know
if replying will help but since you seem to want a reply so badly and
because I do want to keep acting in good faith and not have our
relationship damaged over this, here's a reply.

> Select a recipe
> -> Buy ingredients
> -> View shopping list
> -> Share
> -> Add service
> -> Todoist

Your test case was so minimal that I didn't understand that's what it
was. Let me give a few more words. Step 0 is to build GOA with
--disable-todoist (if like me you're still using the stable version of
GOA). Then log out and log back in to make sure that you're using the
correct GOA service. The final step where you click the word Todoist
opens gnome-control-center to the Online Accounts page which does not
have a Todoist provider since we removed it in Step 0.

I did the test case a month and a half ago and drafted an email to you
to let you know about the 2 things I saw as mistakes in your commit
message but I decided it was too much like nitpicking for me to send
that email then. Maybe it would have been better if I had sent it
then.

> https://download.gnome.org/sources/gnome-todo/3.91/

Wait, GNOME To Do has one experimental release targeting GTK4 using
the same version number scheme as GTK4 and that's enough for you to
say that they are not following GNOME's Release Schedule? I think it's
reasonable to interpret the release number as a mistake (although a
fairly easy one to make given how GTK and GNOME release schedules have
been aligned fairly closely since 2011 and that the developer wasn't
around for GTK2). That version obviously isn't intended for distros to
ship and I think it's a reasonable way to identify releases in an
experimental series so that they don't conflict with new major
releases in the ordinary stable track. If you object to the version
number used, I encourage you to talk to the developer politely about
it.

I don't see a need to recant anything in my short original email. I'm
sorry that you feel so attacked in this thread and I apologize if my
replies or lack of replying feels like I'm trying to hurt you more.
That is not my intent at all.

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

On Sun, Jan 27, 2019 at 09:26:05PM -0800, philip.chime...@gmail.com wrote:
> On Sun, Jan 27, 2019 at 1:04 PM Debarshi Ray  wrote:
> 
> > On Sun, Jan 27, 2019 at 11:24:00AM -0800, philip.chime...@gmail.com wrote:
> > > 2. It's not possible to discontinue support for services X, Y, and Z from
> > > GOA, and yank the rug out from under apps that expected (even if that
> > > expectation was wrong) it to be part of a stable platform.
> >
> > You mean like the time when GJS broke GNOME Documents?
> >
> 
> Sorry, I don't know what particular event you're referring to.

https://bugzilla.gnome.org/show_bug.cgi?id=791613

> GJS is even different from GOA because, as pointed out earlier
> in the thread, GOA is not part of a Flatpak runtime but is still used by
> Flatpak apps.

One, Flatpak is still not the primary way users consume applications.

Second, being part of the runtime is irrelevant for a session D-Bus
service like GOA. The service is meant to live on the host. There were
no D-Bus or C API breaks. What changed is the metadata associated with
an account, which applications introspect at runtime anyway.

Third, with Flatpak, a newer version of an application has to be ready
to run on an old host anyway, and the old host might not have the GOA
feature that your new application wants. Apps need to be resilient
about that. Hence the introspection.

> Are you seriously suggesting that because I committed some mistake, you
> should insist on the right to make the same mistake with eyes wide open?

And what mistake am I insisting on making?

> Literally just a few messages before mine in the thread, we heard about
> deja-dup.

And what about Deja Dup? GOA screwed over Deja Dup?

> For what it's worth, I don't appreciate the ad-hominem attack here. I
> intended to *help* you by trying to break the cycle of people ignoring your
> problem and yelling at you about theirs, and vice versa, but if you prefer
> to continue yelling then suit yourself.

You are trying to help me by making unsubstantiated innuendoes?

You said:

> PS. Yes, count me among the completely surprised that GOA is not an API
> that apps should use. It was not communicated anywhere close to the level
> it needed to be. That's on GNOME, not on those app developers. This is why
> it's our problem.

If nothing else, you are driving a wedge between "GNOME" and "those
app developers".

In the context of this thread, it also sounds as if there exists a
whole bunch of application developers whose hard work was thrown away
because of me.

You talk about communication. The very first version of the GOA home
page, created in August 2012, said:

"The objective of GOA is to provide a central place where a set of
online accounts (defined by the OS/distributor) can be configured
for use with core applications. In UX terms, GOA provides a static
list of online accounts that can be setup by users (through the
Online Accounts panel in System Settings). These accounts will then
be used by core GNOME applications.

While third party applications can access the accounts set up
through GOA, this is not its primary goal, nor does it set out to
enable third party applications to add online accounts of their own.
There are several reasons for this:
  ...
  ...
"

See:
https://wiki.gnome.org/action/recall/Projects/GnomeOnlineAccounts?action=recall=1

That text was recently improved and lives on its own page, linked
multiple times from the main landing page:
https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals

The current landing page says:
"GNOME Online Accounts Single sign-on framework for GNOME. It aims to
provide a way for users to setup online accounts to be used by the
core system and applications."

See: https://wiki.gnome.org/Projects/GnomeOnlineAccounts

We don't have an active PR team at our disposal to send out weekly
press releases - it's not like the GNOME Engagement Team has a ton of
resources. Blogs were written to address the most pressing issues of
the day.

There doesn't exist a single application developer whose work was
thrown away without any prior notice or discussion.

The Telepathy support was removed after multiple Empathy and Telepathy
maintainers publicly and repeatedly asked people not to use the
stack. The removal was publicly announced early in a development
cycle. Not a single soul complained when this happened.

Michael Catanzaro, Allan, Jakub and I have had multiple discussions,
often over email, with Felipe Borges, author of GNOME's Pocket client
[1], and Bastien over the years. The most recent discussion was about
toggling the Autotools and Meson options to not build the Pocket
extension by default, accompanied with a public announcement. That's
supposed to happen after March. No code was to removed until October.

Michael Catanzaro, Allan, Jakub and I had similarly discussed the
GNOME Documents situation with Cosimo.

You are tilting at windmills here. As if, I, the GOA maintainer,
screwed myself, the GNOME Documents maintainer. 

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

[Debarshi Ray]

Hey Michael,

On Sun, Jan 27, 2019 at 08:29:32PM -0500, Michael Terry wrote:
> I meant (1) keeping GNOME's API key valid, (2) maintaining
> libgdata, (3) maintaining the GVFS google backend (which only
> supports using GOA keys -- an app can't give it its own keys),
> and (4) maintaining the GOA google backend.

Ok.

Did anybody tell you that you need to contribute N patches a year to
libgdata, gnome-online-accounts and gvfs every year or you are out?
Honest question.

You're surely welcome to help, but I don't think it's ever been
mandatory. That'd be crazy.

The only thing I remember is trying to figure out why Deja Dup's
API calls were sometimes erroring out. Maybe somebody else gave
you some misinformation? I apologize if that's been the case.

> If GNOME lets their API key be revoked, all of the above will be
> dropped on the floor. Libgdata might live on independently, but
> GNOME wouldn't have a reason to put it into releases any more.
>
> ...
>
> (I assume you meant that deja-dup doesn't have much to worry about
> in the main context of this thread about Documents support etc being
> dropped from GNOME. And you're correct there. But Michael's comment
> about GNOME losing it's Google key in three weeks does have me spooked.)

As the primary maintainer of GNOME's Google API keys for the last
seven years, and the author of libgdata's Google Drive support, and a
co-author of the GVfs backend, I can assure you that GNOME won't just
"let their API key be revoked". :)

My understanding is that Google is still going through their list of
emails and sending out the notifications. I got my copy of their email
only yesterday. Michael Catanzaro and Philip Withnall got theirs some
days before that. I'd have had a better understanding of things by
now, but I am currently busy with desktop-devel-list duty.

Having to deal with the service providers is a part of life when we are
using their services.

For various unknown reasons, GNOME's Facebook API key had been flagged
multiple times over the past six or seven years. GNOME was twice
temporarily banned by Facebook, which was lifted once we answered
their questions and explained a few details.  It's possible that these
were temporary restrictions placed by some bot and not a human.

Twice we had to ask Google to increase GNOME's quota for two of their
API subsets. It needed an explanation of what GNOME is, how many users
we have, how we handle caching, etc. and Google gave us what we had
asked for.

Once we had to switch our Google key because a bug in
evolution-data-server had polluted the older key:
https://debarshiray.wordpress.com/2016/12/15/new-gnome-api-key-for-google-services/

I don't know how this present situation will be resolved, but we'll
see.  In the worse case, if Google does think that we are not meeting
their standards, then Deja Dup wouldn't be able to circumvent that
with a separate key on a sustained basis. If, hypothetically, Deja Dup
is the cause for GNOME loosing its access, then Google sooner or later
will catch up and shut it down one way or another.

Cheers,
Rishi
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Britt Yazel]

Folks,

I don't have anything technical to add to this discussion, so as someone
just following along with the thread I think we should take our emotions
down a couple notches. Calling each other out, playing the blame game, and
dredging up stuff from the past is not going to help us come up with a
clear path forward.

We're all friends and colleagues, let's not forget that first and foremost.
:-)

On Sun, Jan 27, 2019 at 10:26 PM Debarshi Ray  wrote:

> Jeremy,
>
> You already attempted to slander me once before in this thread:
>
> https://mail.gnome.org/archives/desktop-devel-list/2019-January/msg00027.html
>
> It's been one week since I produced evidence against that:
>
> https://mail.gnome.org/archives/desktop-devel-list/2019-January/msg00035.html
>
> You had enough time to clarify your original statement or recant it. I
> no longer consider anything you say to be in good faith.
>
> On Wed, Jan 23, 2019 at 03:21:57PM -0500, Jeremy Bicha wrote:
> > But you're talking about removing even more online accounts providers
> > even though apps that support them have not yet implemented a
> > replacement.
>
> Nice reversal of cause and effect there. Good job.
>
> The decision to retire GNOME Documents was the reason the integration
> point was dropped from GOA.
>
> > Interestingly, Ubuntu Online Accounts was ahead of its time here. What
> > it offers in Ubuntu 16.04 LTS sort of foreshadows how this could work.
>
> Oh, yeah, Ubuntu Online Accounts - the purveyor of shady downstream
> patches against applications (read: Shotwell) that replace upstream
> branding and reward with crashes.
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

On Thu, Jan 24, 2019 at 01:29:54PM +, Matthew Paul Thomas via 
desktop-devel-list wrote:
> *   For some reason that isn???t clear to me, GOA cares what you use each
> account for, rather than merely recording which apps the user has
> granted access to each account.

Because that's how Google, Facebook, and Microsoft's services work.

The program needs to explicitly say exactly which subset of services
it's going to use, and the user needs to sign off on that. The
technical term is "OAuth2 scope".

> Why was there such a thing as
> ???Documents support??? in GOA in the first place? This suggests that if
> Facebook or Google or Microsoft announced and released a new chat
> app XYZ tomorrow, which integrated with their usual account
> system, it couldn???t use your Facebook or Google or Microsoft account
> stored in GOA, because GOA wouldn???t include ???XYZ support???.

You cannot just go and use the chat API or services just because the
user had added a Facebook or Google or Microsoft account. It will very
likely fail to authenticate; or your program will get banned by the
service provider.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

Jeremy,

You already attempted to slander me once before in this thread:
https://mail.gnome.org/archives/desktop-devel-list/2019-January/msg00027.html

It's been one week since I produced evidence against that:
https://mail.gnome.org/archives/desktop-devel-list/2019-January/msg00035.html

You had enough time to clarify your original statement or recant it. I
no longer consider anything you say to be in good faith.

On Wed, Jan 23, 2019 at 03:21:57PM -0500, Jeremy Bicha wrote:
> But you're talking about removing even more online accounts providers
> even though apps that support them have not yet implemented a
> replacement.

Nice reversal of cause and effect there. Good job.

The decision to retire GNOME Documents was the reason the integration
point was dropped from GOA.

> Interestingly, Ubuntu Online Accounts was ahead of its time here. What
> it offers in Ubuntu 16.04 LTS sort of foreshadows how this could work.

Oh, yeah, Ubuntu Online Accounts - the purveyor of shady downstream
patches against applications (read: Shotwell) that replace upstream
branding and reward with crashes.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Philip Chimento via desktop-devel-list]

On Sun, Jan 27, 2019 at 1:04 PM Debarshi Ray  wrote:

> On Sun, Jan 27, 2019 at 11:24:00AM -0800, philip.chime...@gmail.com wrote:
> > 2. It's not possible to discontinue support for services X, Y, and Z from
> > GOA, and yank the rug out from under apps that expected (even if that
> > expectation was wrong) it to be part of a stable platform.
>
> You mean like the time when GJS broke GNOME Documents?
>

Sorry, I don't know what particular event you're referring to. Sometimes
GJS breaks things. When that happens, I spend actually quite a lot of my
maintainer time 1) writing about the breakage, so that app developers are
aware, and 2) writing about a migration plan, so that app developers know
what to do. GJS is even different from GOA because, as pointed out earlier
in the thread, GOA is not part of a Flatpak runtime but is still used by
Flatpak apps.

A migration plan could be the type of solution that addresses both
problems. Or some way to get a workalike service into existing Flatpak
runtimes so that apps on, for example, 3.24, don't break.

Nonetheless, I'm sure I make mistakes where GJS breaks things that I don't
communicate well enough.

Are you seriously suggesting that because I committed some mistake, you
should insist on the right to make the same mistake with eyes wide open?

> PS. Yes, count me among the completely surprised that GOA is not an API
> > that apps should use. It was not communicated anywhere close to the level
> > it needed to be. That's on GNOME, not on those app developers. This is
> why
> > it's our problem.
>
> Ah, "those app developers"? And who might those be?
>
> You better produce solid proof of a single case where "those app
> developers" were screwed over by GOA, or withdraw that comment.
>

Literally just a few messages before mine in the thread, we heard about
deja-dup. I also fell into the same trap at work while considering the
technology to use in a particular application, but luckily (?) we ended up
not using GOA for unrelated reasons.

For what it's worth, I don't appreciate the ad-hominem attack here. I
intended to *help* you by trying to break the cycle of people ignoring your
problem and yelling at you about theirs, and vice versa, but if you prefer
to continue yelling then suit yourself.

Philip C
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[mcatanzaro]

On Sun, Jan 27, 2019 at 6:32 PM, Nathan Graule via desktop-devel-list 
 wrote:
Given what I've read about the Google policy (and I don't know how 
much of that was added with the Jan. 15 revision), but it seems like 
the very concept of GOA as a centralized account repository goes 
against Google rules. Google wants to know by whom the OAuth key will 
be used, and how. Under an open system where any third-party can 
implement access to GOA, GNOME cannot be able to tell Google about 
the use of the key (which is part of what they're asking in their 
request, as the ansible issue presents <#2>).
Therefore GOA *needs* to change somewhat. At the very least, it 
cannot let third-party applications use the GNOME OAuth key to access 
Google APIs.


Question: the GNOME key is necessarily public, since it's open source 
and we don't have secret sauce in the build system. GNOME can't stop 
random apps from using it. Right? The g-o-a README says this is allowed:


https://gitlab.gnome.org/GNOME/gnome-online-accounts/blob/bf77325d847d2878159e8ba2677768b2fe6386a6/README#L58

So there's no way we can ever stop random applications from using the 
GNOME key and pretending to be us, right? It just works because nobody 
has decided to abuse it yet?


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[mcatanzaro]

On Sun, Jan 27, 2019 at 7:29 PM, Michael Terry  wrote:
You say deja-dup has nothing to worry about. But I very much have to 
solve the problem of many of my users losing access to their backups 
(through my app at least) in three weeks. Will not inspire 
confidence. Again, my fault I guess for using GOA in the first place.


There are multiple deadlines:

"""For projects that require action, you must submit apps for 
verification before Feb 15th, 2019. If you don't, access for new users 
will be disabled on February 22nd, 2019, and existing grants for 
consumer accounts will be revoked on March 31st, 2019."""


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Sriram Ramkrishna]

On Sun, Jan 27, 2019 at 8:29 PM Michael Terry  wrote:

> (I assume you meant that deja-dup doesn't have much to worry about in the 
> main context of this thread about Documents support etc being dropped from 
> GNOME. And you're correct there. But Michael's comment about GNOME losing 
> it's Google key in three weeks does have me spooked.)

I have someone who I think can help.  If not, I will find someone at
Google who can either delay it or help us with it.  The whole thing is
related to GDPR.  I'm hoping that we can get this resolved.

Cheers,
sri
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Michael Terry]

On Sun, Jan 27, 2019, at 16:16, Debarshi Ray wrote:
> "maintain GNOME's Google support" is bit misleading here. I'll try to
> explain.
> 
> "GNOME's Google support" is libgdata and the GNOME API key. Using
> libgdata is independent of using GOA, and that's where the
> overwhelming bulk of effort goes - keeping up with API changes and so
> on. As for the API key, we often have a hard time because we don't
> fall into one of the big buckets called: web application, iOS app,
> Android app, etc.. Since the Linux desktop is such a small portion of
> the user base, we always run into weird rough edges that don't affect
> the more popular platforms that much.
> 
> The one genuine case where you might have to do some work is when a
> bug in Deja Dup adversely affects the GNOME API key. Say, for example,
> if there's a bug in the code that DoSes the Google servers or causes
> data loss or something catastrophic like that.
> 
> But other than that I don't know what "maintain GNOME's Google
> support" would mean.

I meant (1) keeping GNOME's API key valid, (2) maintaining libgdata, (3) 
maintaining the GVFS google backend (which only supports using GOA keys -- an 
app can't give it its own keys), and (4) maintaining the GOA google backend.

If GNOME lets their API key be revoked, all of the above will be dropped on the 
floor. Libgdata might live on independently, but GNOME wouldn't have a reason 
to put it into releases any more.

You say deja-dup has nothing to worry about. But I very much have to solve the 
problem of many of my users losing access to their backups (through my app at 
least) in three weeks. Will not inspire confidence. Again, my fault I guess for 
using GOA in the first place.

(I assume you meant that deja-dup doesn't have much to worry about in the main 
context of this thread about Documents support etc being dropped from GNOME. 
And you're correct there. But Michael's comment about GNOME losing it's Google 
key in three weeks does have me spooked.)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Nathan Graule via desktop-devel-list]

Given what I've read about the Google policy (and I don't know how much 
of that was added with the Jan. 15 revision), but it seems like the 
very concept of GOA as a centralized account repository goes against 
Google rules. Google wants to know by whom the OAuth key will be used, 
and how. Under an open system where any third-party can implement 
access to GOA, GNOME cannot be able to tell Google about the use of the 
key (which is part of what they're asking in their request, as the 
ansible issue presents <#2>).
Therefore GOA *needs* to change somewhat. At the very least, it cannot 
let third-party applications use the GNOME OAuth key to access Google 
APIs. This would be fine, however I don't think having a conceptual 
exception for Google is particularly good.


I see two ways to approach a hypothetical re-design of GOA.
A first way would be to put GOA as the authentication backend of the 
system itself (considering core apps as part of the system), and close 
access to third-party. This effectively is a regression on usability 
since having a centralized authentication system does make life (ever 
so slightly) easier for both users and developpers.


A second way would be one pretty much inspired from Android. In 
Android, apps that want access to the users' Google account simply 
contact the backend with an authentication request. Since Android 
phones are almost always linked to a Google account, the user only sees 
an OAuth confirmation prompt (the prompt outlining which services will 
be granted access to the app) which links the application's key to the 
account.
In GOA, this could work in a similar way: If a Google account is 
already present, GOA presents an OAuth confirmation dialog that grants 
access to the application. At any point, GOA doesn't know about which 
apps have been granted, because in the case of OAuth applications the 
role of access control is left to the account.
For non-OAuth applications, the logging in and access control is left 
to GOA (a simple enable/disable access to this app should be sufficent, 
the same way it works for location and notificatio access), but the 
workflow is the same.


In the second case, on top of having a more flexible GOA, it would 
provide real value to users and developers by having GOA continue being 
an open service that both reduces boilerplate and provides a 
centralized place to manage accounts. The downside is that this 
implementation is going to need work and maintainship, which might be 
lacking*. This is what the first option answers directly: it strips 
down GOA so that maintaining it is less work.


Those are my 2cc on GOA as a whole, as I do see real value in keeping 
it there.


Nathan

* Yes, I realize I'm saying this while I'm all talk and no walk. 
However I am not confident in my ability to be part in such a complex 
project, even less writing code for it. I am however happy to help 
whenever and wherever I can.


Le dim. 27 janv. 2019 à 23:27, Sriram Ramkrishna  a 
écrit :

On Sun, Jan 27, 2019 at 2:24 PM Philip Chimento via desktop-devel-list
 wrote:

 PS. Yes, count me among the completely surprised that GOA is not an 
API that apps should use. It was not communicated anywhere close to 
the level it needed to be. That's on GNOME, not on those app 
developers. This is why it's our problem.


A blog post was written and put out there because there was
confusion/issues with 3rd party folks wanting to integrate with GOA.
I'm not sure what more is required?  As a project we tend to only
communicate when there is a fire.  Which given our lack of general
resources is not surprising.  I'm sure people want to better given
appropriate resources.

I want to add one comment: someone on the thread said: "we are a small
niche market".  No.. we're a growing niche market.  I can assure you
of that.  This market is supporting several companies who market
pre-installed machines with Linux based desktop and are thriving.  It
might be slow, but conversions are happening.

Given we are losing google services,  gnome-documents seems to lose a
lot of what would make it useful - managing cloud based documents.
The fact that we are losing this is much more alarming to me than this
discussion over single sign on.  Tens of thousands of people will no
longer be able to use google files through nautilus seems like a big
deal to me in three weeks and should in fact be communicated
immediately as an existential community issue.

GOA will figure itself out one way or another if we care about the
issue.  I wish people would ask me if they need help getting people to
help.  It's one of the things that engagement people are supposed to
help with rather than throwing your hands up in the air and say we
don't have resources.  They are out there.  You just have to attract
them.

sri
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Sriram Ramkrishna]

On Sun, Jan 27, 2019 at 2:24 PM Philip Chimento via desktop-devel-list
 wrote:

> PS. Yes, count me among the completely surprised that GOA is not an API that 
> apps should use. It was not communicated anywhere close to the level it 
> needed to be. That's on GNOME, not on those app developers. This is why it's 
> our problem.

A blog post was written and put out there because there was
confusion/issues with 3rd party folks wanting to integrate with GOA.
I'm not sure what more is required?  As a project we tend to only
communicate when there is a fire.  Which given our lack of general
resources is not surprising.  I'm sure people want to better given
appropriate resources.

I want to add one comment: someone on the thread said: "we are a small
niche market".  No.. we're a growing niche market.  I can assure you
of that.  This market is supporting several companies who market
pre-installed machines with Linux based desktop and are thriving.  It
might be slow, but conversions are happening.

Given we are losing google services,  gnome-documents seems to lose a
lot of what would make it useful - managing cloud based documents.
The fact that we are losing this is much more alarming to me than this
discussion over single sign on.  Tens of thousands of people will no
longer be able to use google files through nautilus seems like a big
deal to me in three weeks and should in fact be communicated
immediately as an existential community issue.

GOA will figure itself out one way or another if we care about the
issue.  I wish people would ask me if they need help getting people to
help.  It's one of the things that engagement people are supposed to
help with rather than throwing your hands up in the air and say we
don't have resources.  They are out there.  You just have to attract
them.

sri
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

On Sun, Jan 27, 2019 at 11:37:31AM +, Emmanuele Bassi wrote:
> On Sun, 27 Jan 2019 at 09:24, Debarshi Ray  wrote:
> 
> > On Thu, Jan 24, 2019 at 11:00:58AM +0100, Bastien Nocera wrote:
> > > I don't think that feature requests should be treated on the same level
> > > as existing, merged, features
> >
> > I can't change my theme, I can't change my fonts, no minimize button,
> > no wallpaper options, my laptop insists on suspending ...
> >
> > Can I have those back?
> >
> 
> Install Tweaks.

And you can install a web browser, nautilus and evince; but, hey,
guess what? You already have those!

> See, that's kind of the difference between removing infrastructure and
> removing UI for it.
> 
> Even if you're removing infrastructure, we do have mechanisms and policies
> for transitioning between the initial and final points: versioned
> interfaces, soname bumps, new dependencies, deprecations.

Oh, you mean like GTK dropping geometry support and breaking GNOME
Terminal one day: https://bugzilla.gnome.org/show_bug.cgi?id=760944

I wonder what mechanisms or policies were in play there.

I do know that some brave souls scurried to workaround that in GNOME
Terminal.

I'll let the reader guess how many people use GNOME Documents versus
those who use GNOME Terminal or care about themes or fonts or
minimize buttons or wallpapers or suspend?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

On Sun, Jan 27, 2019 at 02:48:12PM -0500, Michael Terry wrote:
> On Wed, Jan 23, 2019, at 21:39, Michael Gratton wrote:
> > If GOA Mail is going to be removed from Fedora can there at least be a 
> > method to programatically determine what is supported and what isn't, 
> > so Geary can avoid launching the control center when people want to add 
> > an account on Fedora?
> 
> A minor technical side note here. You actually might be able to
> programatically determine that: libgoa-backend will tell you what
> providers exist and what features they support.

Yes, that's correct.

That doesn't mean this thread has anything to do with email,
regardless of how much bullshit is being peddled on this thread.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

TL;DR:

I don't think Deja Dup has anything to worry about. I was pleasantly
surprised to know that Deja Dup even uses GOA. Having backups
integrated more closely in the OS seems like a good thing to me. I'd
encourage you to bring up the story of backups with the GNOME Design
Team.

On Sun, Jan 27, 2019 at 01:57:49PM -0500, Michael Terry wrote:
> I totally understand the difficulty GNOME is in here, and I'm
> not expecting you folks to do work that you don't have the time for.
> I don't have the time to maintain GNOME's Google support either, so
> no shade thrown by me. But it sure is a bummer. And a lesson to me
> about relying on GNOME's platform.

"maintain GNOME's Google support" is bit misleading here. I'll try to
explain.

"GNOME's Google support" is libgdata and the GNOME API key. Using
libgdata is independent of using GOA, and that's where the
overwhelming bulk of effort goes - keeping up with API changes and so
on. As for the API key, we often have a hard time because we don't
fall into one of the big buckets called: web application, iOS app,
Android app, etc.. Since the Linux desktop is such a small portion of
the user base, we always run into weird rough edges that don't affect
the more popular platforms that much.

The one genuine case where you might have to do some work is when a
bug in Deja Dup adversely affects the GNOME API key. Say, for example,
if there's a bug in the code that DoSes the Google servers or causes
data loss or something catastrophic like that.

But other than that I don't know what "maintain GNOME's Google
support" would mean.

Of course, you are always free to use your own API key and drop the
GOA support too.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

On Sun, Jan 27, 2019 at 11:24:00AM -0800, philip.chime...@gmail.com wrote:
> 2. It's not possible to discontinue support for services X, Y, and Z from
> GOA, and yank the rug out from under apps that expected (even if that
> expectation was wrong) it to be part of a stable platform.

You mean like the time when GJS broke GNOME Documents?

> PS. Yes, count me among the completely surprised that GOA is not an API
> that apps should use. It was not communicated anywhere close to the level
> it needed to be. That's on GNOME, not on those app developers. This is why
> it's our problem.

Ah, "those app developers"? And who might those be?

You better produce solid proof of a single case where "those app
developers" were screwed over by GOA, or withdraw that comment.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Michael Terry]

On Wed, Jan 23, 2019, at 21:39, Michael Gratton wrote:
> If GOA Mail is going to be removed from Fedora can there at least be a 
> method to programatically determine what is supported and what isn't, 
> so Geary can avoid launching the control center when people want to add 
> an account on Fedora?

A minor technical side note here. You actually might be able to programatically 
determine that: libgoa-backend will tell you what providers exist and what 
features they support.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Philip Chimento via desktop-devel-list]

On Sun, Jan 27, 2019 at 4:13 AM Emmanuele Bassi via desktop-devel-list <
desktop-devel-list@gnome.org> wrote:

> On Sun, 27 Jan 2019 at 10:27, Debarshi Ray  wrote:
>
> GNOME has various core applications that depend on the same mechanism. We
> actually made a point of integrating with remote services, because
> apparently that's a thing. We don't really have a policy for moving
> applications from second/third party to core, but if that policy existed,
> "integrating with the Online Accounts platform" would be on it. For
> applications that migrate from second/third parties to core, that would be
> an additional feature; for first party application, we would *only* have
> that kind of integration.
>
> The "political" issue I'm trying to raise is that not only we lack the
> "how do we move an app into core" policy, but we also lack the "how do we
> move an app out of core" one, especially when it comes to services
> integration. Second/third party apps that integrate with web services can
> be moved out of core by ripping the GOA integration, and falling back to
> their own—if they still have it. First party applications that never had
> anything else don't have that fallback path in place.
>
> Again: maybe Documents isn't used. Maybe Photos, Music, and whatever else
> aren't used either. Who knows, we don't have metrics, right?
>
> Nevertheless, removing platform functionality without an adequate process
> for it is problematic in many ways, a shockingly small amount of which are
> technical:
>
>  - 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?
>  - 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.
>  - we have a set of potential core applications and not enough people
> writing them; if our platform isn't stable enough for first parties, if our
> expectations about what can happen to it aren't communicated well enough
> *amongst ourselves* then we can pack our bags, and go home, because we're
> done.
>
> So, yes: we have to deal with "political" issues, here, because we are a
> complex project with maintainers that have the right/tendency to do
> whatever they want.
>
> I do think that GNOME is better served caring about a small subset of
>> providers and services - those that we are serious about supporting,
>> and have (or will have) high quality applications offering the user
>> facing features. We should evolve the design and code in whichever
>> direction that takes us.
>>
>> What we shouldn't do is get into architecture astronauting and
>> political arguments about getting everybody's favourite logo into the
>> Online Accounts panel.
>>
>
> I hope you realise that my objections in this thread are not about
> astronauting things, outside of a side note about I always found GOA a
> missed opportunity to build our platform; I'm more concerned about the lack
> of process that seems to plague GNOME (from time immemorial, I might add)
> and the fact that every time this is brought up, people scream "stop
> energy" or "architecture astronauting" or "maintainer rights" or "what
> would YOU do", instead of understanding that GNOME is a complex project and
> the only way we can make it work is to communicate plainly and honestly
> what people need to know in order to be a part of it.
>
> By all means: work on making GOA smaller and more maintainable. If the
> process to achieve that goal is that we should archive applications, then
> it's absolutely fine to say so, write it down on the wiki, and point people
> to it. What should *not* happen is telling people that apps will be dropped
> from the release, and that's all there is to it, because that sets up the
> wrong expectations that you can still build the application, distribute it,
> or use it, and it'll work the same way—it just won't be part of the GNOME
> release (which nobody is using anyway, because nobody here uses GNOME from
> the release tarballs). What should *not* happen is asking people to
> integrate their apps with GOA as part of making them feel more "GNOME-y"
> without also telling them that we reserve the right to change GOA's
> offerings because of our chronic resource shortage, or because our designs
> change.
>

+1 Emmanuele hits the nail on the head here as far as I'm concerned.

I think maybe it will be useful to recognize explicitly that there are two
seemingly irreconcilable problems.

1. It's not 

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

[Michael Terry]

On Sun, Jan 27, 2019, at 11:14, mcatanz...@gnome.org wrote:
> Err... well this seems like as good a time as any to mention it: Philip 
> and I both noticed emails from Google warning that they'll shut us down 
> unless we do a huge amount of work in a very short amount of time. 
> Neither of us plan to work on this. My only use of the Google 
> integration is for Safe Browsing, which doesn't use 
> gnome-online-accounts at all and which I'm just hoping won't be 
> affected.
> 
> If anyone wants to help, see 
> https://gitlab.gnome.org/Infrastructure/ansible/issues/2. We have three 
> weeks left.

Ooof. A while back I excitedly integrated GOA support for Google Drive into the 
deja-dup backup program, using the gvfs backend to handle the actual file 
access.

I totally understand the difficulty GNOME is in here, and I'm not expecting you 
folks to do work that you don't have the time for. I don't have the time to 
maintain GNOME's Google support either, so no shade thrown by me. But it sure 
is a bummer. And a lesson to me about relying on GNOME's platform.

So it seems that for apps like mine which had supported Google accounts through 
GOA, the next steps would be to register their own OAuth developer account with 
Google and write their own custom access backend to replace the generic gvfs 
one? Ideally within the next three weeks and then backporting the change for 
all existing stable releases in the wild before users hit errors from the GNOME 
key being revoked.

I understand the party line in this thread to be that I should have already 
been doing that and never should have used GNOME's code in the first place. 
Fair enough. I misunderstood GNOME's stance on that. Maybe libgoa should have 
you define -DGOA_API_YES_I_AM_A_CORE_GNOME_APP to help prevent this 
misunderstanding in the future.

Well, thank you to the folks that did work on Google integration. I appreciate 
it, and the feature was good while it lasted.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[mcatanzaro]

On Sun, Jan 27, 2019 at 4:27 AM, Debarshi Ray  
wrote:

It so happens that we have half a dozen notifications from Facebook
and Google about our uses of their APIs at varying degrees of
seriousness. They are still on my todo list.  Thankfully, Philip
Withnall and Michael Catanzaro are on top of the Google part, but only
barely.  I am worried that most of our Facebook integration has
stopped working.


Err... well this seems like as good a time as any to mention it: Philip 
and I both noticed emails from Google warning that they'll shut us down 
unless we do a huge amount of work in a very short amount of time. 
Neither of us plan to work on this. My only use of the Google 
integration is for Safe Browsing, which doesn't use 
gnome-online-accounts at all and which I'm just hoping won't be 
affected.


If anyone wants to help, see 
https://gitlab.gnome.org/Infrastructure/ansible/issues/2. We have three 
weeks left.


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Emmanuele Bassi via desktop-devel-list]

On Sun, 27 Jan 2019 at 10:27, Debarshi Ray  wrote:


> The tl;dr here is that a lot of people care about political arguments
> but nobody shows up to bear the burden of dealing with the code.
>

"Political" in the sense that you're not maintaining a leaf node in the
dependency graph, that can come and go, but a service that has
repercussions on other projects.

The issue is not that Documents is going away; the problem is that
Documents is, by design, heavily dependent on a session service, and that
it can't be easily moved from that to its own implementation.

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.

But…

GNOME has various core applications that depend on the same mechanism. We
actually made a point of integrating with remote services, because
apparently that's a thing. We don't really have a policy for moving
applications from second/third party to core, but if that policy existed,
"integrating with the Online Accounts platform" would be on it. For
applications that migrate from second/third parties to core, that would be
an additional feature; for first party application, we would *only* have
that kind of integration.

The "political" issue I'm trying to raise is that not only we lack the "how
do we move an app into core" policy, but we also lack the "how do we move
an app out of core" one, especially when it comes to services integration.
Second/third party apps that integrate with web services can be moved out
of core by ripping the GOA integration, and falling back to their own—if
they still have it. First party applications that never had anything else
don't have that fallback path in place.

Again: maybe Documents isn't used. Maybe Photos, Music, and whatever else
aren't used either. Who knows, we don't have metrics, right?

Nevertheless, removing platform functionality without an adequate process
for it is problematic in many ways, a shockingly small amount of which are
technical:

 - 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?
 - 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.
 - we have a set of potential core applications and not enough people
writing them; if our platform isn't stable enough for first parties, if our
expectations about what can happen to it aren't communicated well enough
*amongst ourselves* then we can pack our bags, and go home, because we're
done.

So, yes: we have to deal with "political" issues, here, because we are a
complex project with maintainers that have the right/tendency to do
whatever they want.

I do think that GNOME is better served caring about a small subset of
> providers and services - those that we are serious about supporting,
> and have (or will have) high quality applications offering the user
> facing features. We should evolve the design and code in whichever
> direction that takes us.
>
> What we shouldn't do is get into architecture astronauting and
> political arguments about getting everybody's favourite logo into the
> Online Accounts panel.
>

I hope you realise that my objections in this thread are not about
astronauting things, outside of a side note about I always found GOA a
missed opportunity to build our platform; I'm more concerned about the lack
of process that seems to plague GNOME (from time immemorial, I might add)
and the fact that every time this is brought up, people scream "stop
energy" or "architecture astronauting" or "maintainer rights" or "what
would YOU do", instead of understanding that GNOME is a complex project and
the only way we can make it work is to communicate plainly and honestly
what people need to know in order to be a part of it.

By all means: work on making GOA smaller and more maintainable. If the
process to achieve that goal is that we should archive applications, then
it's absolutely fine to say so, write it down on the wiki, and point people
to it. What should *not* happen is telling people that apps will be dropped
from the release, and that's all there is to it, because that sets up the
wrong expectations that you can still build the application, distribute it,
or use it, and it'll work the same way—it just won't be part of 

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

[Emmanuele Bassi via desktop-devel-list]

On Sun, 27 Jan 2019 at 09:24, Debarshi Ray  wrote:

> On Thu, Jan 24, 2019 at 11:00:58AM +0100, Bastien Nocera wrote:
> > I don't think that feature requests should be treated on the same level
> > as existing, merged, features
>
> I can't change my theme, I can't change my fonts, no minimize button,
> no wallpaper options, my laptop insists on suspending ...
>
> Can I have those back?
>

Install Tweaks.

See, that's kind of the difference between removing infrastructure and
removing UI for it.

Even if you're removing infrastructure, we do have mechanisms and policies
for transitioning between the initial and final points: versioned
interfaces, soname bumps, new dependencies, deprecations.

What I've been asking is to come up with a process that lets us move an
application from core to third party, so that we can communicate this
appropriately to users and app developers alike. Because today is
Documents, and tomorrow is Music, and the day after that is Photos.

I understand that you're pissed because it seems we're doing backseat
driving on your maintainer role, but you're doing something that affects
the whole of the project, and that might happen again, so it's better to
have a process in place the first time—otherwise it *will* happen again and
we won't have a process at all.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

On Mon, Jan 21, 2019 at 02:03:18PM +, Debarshi Ray wrote:
> It's true that GNOME Documents was conceived as a way to seamlessly
> access all files local and remote. In that sense, the Online Accounts
> integration is crucial for it.
> 
> However, it has turned out to be more complicated than that.  I also
> don't know how excited the GNOME designers are about GNOME Documents
> today.

Oh, and GTK4 happened. GNOME Documents is doomed to stay GTK3 until
LibreOffice gets ported.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

On Thu, Jan 24, 2019 at 10:56:49AM +0100, Bastien Nocera wrote:
> You dropped maintainership of gnome-documents, we're now dropping it
> from core GNOME, and by removing the Documents integration from GOA,
> you're crippling the application, whoever the new maintainer ends up
> being.

No, wrong.

I dropped maintainership of GNOME Documents when it was clear that we
are better off refocusing our efforts elsewhere. I started a follow-up
thread with Michael, Allan, Jakub and Cosimo to formalize our thoughts
on this subject before pulling the plug.

And I still don't see anybody willing to do the heavy-lifting to tackle
those issues (already mentioned elsewhere in this thread) head on.

So what you are saying may sound true in theory, but in practice,
doesn't make any sense.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

Hey Emmanuele,

(I am summarizing a few other sub-threads here.)

On Wed, Jan 23, 2019 at 06:45:50PM +, Emmanuele Bassi wrote:
> On Wed, 23 Jan 2019 at 18:36, Debarshi Ray  wrote:
> > What isn't possible is to mix and match API keys with account types at
> > run-time. That doesn't seem trivial to implement - neither from a code
> > nor a design perspective. Possible, sure; trivial, no.
> 
> I didn't say "trivial", but I didn't expect this to be hard. You, of
> course, know better than me how hard it would be, so I'll defer to your
> assessment.

The tl;dr here is that a lot of people care about political arguments
but nobody shows up to bear the burden of dealing with the code.

While we have lots of arguments about where the Google or Facebook logo
should come from, and which switch should go where, etc. nobody is
interested in implementing the Google or Facebook SDKs or keeping up
with changes as the provider evolves their services. Nobody.

I bet there are less than 10 people who know what libzapojit is. ;)

So, unless the number of people working on our SDKs (ie. libgdata,
libgfbgraph, etc.) increase dramatically, all these grand plans that
people put forward are meaningless. We would spent a ton of design and
coding effort into building the perfect single sign-on framework, but
you won't be able to use Google Drive because the over-the-wire
communication would be broken.

This is why, from my point of view, it's better to have a simpler,
more straightforward GOA, because then we can invest whatever little
resources we have to keep our SDKs alive.

People here are up in arms about Google Drive support. Strangely
enough, I was the one who kept it alive by rewriting libgdata, and
wrote the GVfs backend for it. Eventually I dumped it all on Ondrej
Holy, and I am sure he now feels as if the sky is falling on his head.

It so happens that we have half a dozen notifications from Facebook
and Google about our uses of their APIs at varying degrees of
seriousness. They are still on my todo list.  Thankfully, Philip
Withnall and Michael Catanzaro are on top of the Google part, but only
barely.  I am worried that most of our Facebook integration has
stopped working.

Secondly, applications like Empathy, Evolution, Geary and Shotwell
were never interested in betting the farm on GNOME and GOA. Some just
didn't want to use GOA - plain and simple.

For example, I recall talking to Jim Nelson from Yorba during GUADEC
2012, and he said that Yorba really cared about presenting their own
brand identity when interacting with Flickr using Shotwell. It would
have been terribly rude if a GNOME distributor decided to downstream
patch Shotwell to make it use GOA and replaced the Yorba brand with
something else. This is what Ubuntu did, by the way, for their own
Ubuntu Online Accounts stuff. Jim was bitter about how the patches
introduced crashes, etc. etc..

Others like Evolution cared a lot about working well on XFCE or GNOME
forks like the Unity-based Ubuntu, which didn't have GOA.

Whatever, the specific story was, they had their own separate
account management anyway.

Now in 2019, Geary has GOA support, but that's neither because they
chose to be GNOME Mail nor because I encouraged them. I helped answer
questions, that's all. See:
  https://bugzilla.gnome.org/show_bug.cgi?id=714876
  https://bugzilla.gnome.org/show_bug.cgi?id=746705

Maybe it will be GNOME Mail now? I don't know.

Also, this thread has nothing to do with email or Geary or whatever.
It's about a weakly maintained application that nobody used, and
one which we chose to retire to refocus our efforts elsewhere.

I do think that GNOME is better served caring about a small subset of
providers and services - those that we are serious about supporting,
and have (or will have) high quality applications offering the user
facing features. We should evolve the design and code in whichever
direction that takes us.

What we shouldn't do is get into architecture astronauting and
political arguments about getting everybody's favourite logo into the
Online Accounts panel.

Cheers,
Rishi
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

On Thu, Jan 24, 2019 at 11:00:58AM +0100, Bastien Nocera wrote:
> I don't think that feature requests should be treated on the same level
> as existing, merged, features

I can't change my theme, I can't change my fonts, no minimize button,
no wallpaper options, my laptop insists on suspending ...

Can I have those back?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

On Thu, Jan 24, 2019 at 01:38:57PM +1100, Michael Gratton wrote:
> On Thu, 24 Jan, 2019 at 5:52 AM, Debarshi Ray  
> wrote:
> > On Wed, Jan 23, 2019 at 04:03:41PM +0100, Bastien Nocera wrote:
> >> On Wed, 2019-01-23 at 14:33 +, Allan Day wrote: > That's not 
> >> what's happening here. Until very recently, Debarshi was > the 
> >> Documents maintainer, and he's obviously been fully involved. It is 
> >> what is happening in GNOME Online Accounts in general. Pocket is 
> >> disabled in Fedora 29, and there's a good chance that the mail 
> >> configuration bits will be disabled in Fedora 30.
> >  Grep for "Future of Pocket in GNOME" from 24th August 2018 in your 
> > inbox.
> 
> Was there a similar announcement for the Mail component that I missed? 
> Debarshi you knew I landed support for this in Geary master earlier 
> this year, a head-up would have been appreciated.
> 
> If GOA Mail is going to be removed from Fedora can there at least be a 
> method to programatically determine what is supported and what isn't, 
> so Geary can avoid launching the control center when people want to add 
> an account on Fedora?

This is a GNOME mailing list and it was a thread about documents.  I
didn't say anything about Fedora or email.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Allan Day]

Hi Matthew,

[replying selectively!]

Matthew Paul Thomas via desktop-devel-list  wrote:
...
> ... gnome-initial-setup is pretty
> much the worst possible time to expect someone to know which accounts,
> if any, are useful to configure. At that point, someone is unlikely to
> know even what apps are preinstalled, let alone which of them they’ll
> want to use, let alone which of them use GOA. ...

Feel free to file an issue about this. I'd be happy to discuss it
there in more detail.

...
> *   As demonstrated by Michael Gratton in this discussion, app vendors
> can’t rely on GOA including the account type and service type they
> need in any particular release. This is impractical if they don’t
> read desktop-devel-list@ frequently, or if their release schedule
> doesn’t happen to coincide with Gnome’s, or if it doesn’t happen to
> allow time for suddenly introducing their own account UI because
> somewhere someone altered a selection of “default apps”.

I think this depends on how widely you imagine Online Accounts being
used: if it's a relatively small number of apps that have a close
relationship with the GNOME project, then keeping people informed and
providing guarantees is feasible. It's only if you imagine wider usage
by 3rd party developers that we don't have a relationship with when it
becomes an issue.

...
> *   For some reason that isn’t clear to me, GOA cares what you use each
> account for, rather than merely recording which apps the user has
> granted access to each account.
...

This might well be down to implementation details and I'd be
interested to know how Online Accounts works under the hood, in terms
of turning access on and off.

From a design perspective I think we've always thought of Online
Accounts as a kind of system-level access rather than per-application
access. For example, the calendar switch affects not just the Calendar
app, but also the calendar provided by gnome-shell.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Nathan Graule via desktop-devel-list]

Le jeu. 24 janv. 2019 à 14:29, Matthew Paul Thomas via 
desktop-devel-list  a écrit :
None of that is to say that GOA shouldn’t exist. It has the 
potential to
save people time. “I set up an account in App A. Now it will be 
quicker

to use the same account in App B.” Anything more than that is noise.


While currently the case, GNOME basically is responsible for every app 
that uses GOA to connect to accounts, when said account uses OAuth. 
Which means that it takes one app to badly behave for the account 
provider to shut down access to GNOME, and thus GOA and all the apps 
that depend on it. This is why the idea of having applications use 
their own keys is better - not only you won't GNOME own the keys 
(better UX since from the account dashboard, under applications 
connected, the user won't just see "GNOME" but every application they 
have granted access to), but one misbehaving app won't trip the whole 
system.


Now, by adding application-provided keys, the user will have to sign in 
to every application in order to grant access, which defeats the 
purpose of having GOA as a "centralized user account repository". 
Therefore GOA would need to basically be redesigned from the ground up.


The underlying idea of GOA is good, however it will need to gain more 
features, and not less, to stay useful; for example have application be 
able to share content through those accounts, instead of only being 
able to send emails (although, maybe another implementation of a 
sharing feature could work with application that would provide and 
consume sharing endpoints).


As for Documents, I had come across Paperwork while exploring the 
Flathub repository, which seems like what Documents should have been to 
me. It has tags support, automatic OCR, and global text search, among 
other things.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Adrien Plazas via desktop-devel-list]

Le jeu. 24 janv. 2019 à 19:32, mcatanz...@gnome.org a écrit :
> It's been a while, but IIRC I wanted a reading list mode to not be
> totally dependent on Pocket. We could sync it to Pocket though, since
> that fits in nicely with our existing Firefox Sync support, but there
> should be local storage too.

If support for a more ethical alternative to Pocket, e.g. Wallabag, was
added using the same API (note, I don't know how GOA work and I am just
assuming things) then the hard dependency on Pocket would be dropped,
even though it's not a local solution.

Cheers,
Adrien Plazas
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Adrien Plazas via desktop-devel-list]

Le jeu. 24 janv. 2019 à 19:32, mcatanz...@gnome.org a écrit :
It's been a while, but IIRC I wanted a reading list mode to not be 
totally dependent on Pocket. We could sync it to Pocket though, since 
that fits in nicely with our existing Firefox Sync support, but there 
should be local storage too.


If support for a more ethical alternative to Pocket, e.g. Wallabag, was 
added using the same API (note, I don't know how GOA work and I am just 
assuming things) then the hard dependency on Pocket would be dropped, 
even though it's not a local solution.


Cheers,
Adrien Plazas
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[mcatanzaro]

On Thu, Jan 24, 2019 at 4:00 AM, Allan Day  wrote:

I'd personally like us to keep the path open for you and provide some
guarantees about Geary being able to use Online Accounts in the
future. I wonder if this should be part of a wider conversation about
Geary becoming GNOME Mail? :)


Seems like reasonable conversation to be having, indeed. If we add 
Geary, we could drop the discussion about whether to remove email from 
g-o-a.


On Thu, Jan 24, 2019 at 4:00 AM, Bastien Nocera  
wrote:

Mostly because the various integration points didn't exist. We (GNOME)
were pining for a sharing interface which didn't, and still doesn't,
exist, and epiphany maintainers didn't want to integrate the patch 
that

was already written.


It's been a while, but IIRC I wanted a reading list mode to not be 
totally dependent on Pocket. We could sync it to Pocket though, since 
that fits in nicely with our existing Firefox Sync support, but there 
should be local storage too.


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Matthew Paul Thomas via desktop-devel-list]

(Hopping on to desktop-devel@ to follow up to this)

Jeremy Bicha wrote on 23/01/2019 8:21 pm:
>…
> A few months ago, I talked with mpt about GNOME Online Accounts being
> added to Ubuntu's version of gnome-initial-setup. I believe his
> opinion was that the app itself should offer the "add a new account"
> feature instead of the Initial Setup or Settings apps.
>…

Yes. This was for two main reasons. First, gnome-initial-setup is pretty
much the worst possible time to expect someone to know which accounts,
if any, are useful to configure. At that point, someone is unlikely to
know even what apps are preinstalled, let alone which of them they’ll
want to use, let alone which of them use GOA. For example, even if
someone knew that Firefox is preinstalled, and knew in advance that
they wanted to use Firefox rather than Chrome or Opera or another
browser, and knew that Firefox integrates with Pocket, so they set up
a Pocket GOA account from gnome-initial-setup … Even if all those stars
aligned, eventually they’d discover that g-i-s had wasted their time,
because Firefox doesn’t integrate with GOA.

The second reason is more relevant to this discussion: It’s not sensible
for any app to be beholden to GOA for its account setup in the first
place. This in turn has many factors:

*   Many of the apps, that Gnome users spend their time using, also run
in other environments where GOA doesn’t exist. So the developer has
to do their own account UI for those platforms anyway.

*   As demonstrated by Michael Gratton in this discussion, app vendors
can’t rely on GOA including the account type and service type they
need in any particular release. This is impractical if they don’t
read desktop-devel-list@ frequently, or if their release schedule
doesn’t happen to coincide with Gnome’s, or if it doesn’t happen to
allow time for suddenly introducing their own account UI because
somewhere someone altered a selection of “default apps”.

*   For some reason that isn’t clear to me, GOA cares what you use each
account for, rather than merely recording which apps the user has
granted access to each account. Why was there such a thing as
“Documents support” in GOA in the first place? This suggests that if
Facebook or Google or Microsoft announced and released a new chat
app XYZ tomorrow, which integrated with their usual account
system, it couldn’t use your Facebook or Google or Microsoft account
stored in GOA, because GOA wouldn’t include “XYZ support”.

*   Even if GOA does contain both the account and the toggle relevant to
a particular app, the app may have settings that are
account-specific, but which GOA does not include (for example,
“which folder should sent messages be filed in” or “which words
should be muted in this timeline”). In those cases the app needs
per-account settings UI anyway, resulting in a weird bifurcation.

*   The combination of those reasons, plus all those apps that use
accounts of types that GOA doesn’t provide in the first place,
reinforces a mental model where GOA is generally not where people
expect to find account UI.

None of that is to say that GOA shouldn’t exist. It has the potential to
save people time. “I set up an account in App A. Now it will be quicker
to use the same account in App B.” Anything more than that is noise.

Cheers
-- 
mpt
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Allan Day]

Bastien Nocera  wrote:
...
> It's not Documents. It's Documents, and Pocket, and email integration,
> which brings about the viability of applications ever integrating with
> gnome-online-accounts, lest they be crippled.

In my mind, Documents, Pocket and email are all fairly different
(speaking from a UX perspective).

In the Documents case, it seems what's basically happening is that the
app is being retired, and there's really no equivalent replacement
from an Online Accounts perspective. You could argue that it shouldn't
be retired yet, or that the retirement should happen in such a way
Documents can live on in another form, of course, and those seem like
good conversations to have.

Pocket integration always felt like an online account that didn't have
a strong reason to be there. I agree that sharing would be a really
good reason to keep it, and that's a feature that I would love to have
(and have wanted for years!) but since we don't have it, you do have
to question what Pocket is there for.

Email is different again, in that there are potentially multiple apps
that could use it, and it's unlikely to cause too much confusion. I
don't think anyone is going to be perplexed by the email switch in the
Online Accounts settings.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Allan Day]

Michael Gratton  wrote:
...
> > I don't understand the need to remove those when they are still used
> > (albeit not as much as it could be), when they don't seem to cause
> > maintenance problems (compared to, say, Kerberos...). [1]:
> > 
>
> Well that's terrible news, I'm putting a release of Geary out release
> out with GOA support in a week or two.

It's great to hear about Online Accounts integration!

I'd personally like us to keep the path open for you and provide some
guarantees about Geary being able to use Online Accounts in the
future. I wonder if this should be part of a wider conversation about
Geary becoming GNOME Mail? :)

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Bastien Nocera]

On Wed, 2019-01-23 at 20:10 +, Debarshi Ray wrote:
> On Wed, Jan 23, 2019 at 08:02:16PM +0100, Bastien Nocera wrote:
> > On Wed, 2019-01-23 at 18:52 +, Debarshi Ray wrote:
> > > Grep for "Future of Pocket in GNOME" from 24th August 2018 in
> > > your
> > > inbox.
> > 
> > Which solves what? You're removing the Documents and Mail
> > categories,
> > you're removing Pocket support.
> 
> Two things.
> 
> First, we are talking about GNOME Documents, GNOME Online Accounts,
> GNOME ..., etc.. We are talking about GNOME.
> 
> If you are not going to respond to a thread that has run for six
> months, on a topic that you care about, then I am sorry, I can't
> assume good faith. Those who participated agreed that they don't have
> time to work on Pocket, nor is the current state of affairs very
> good. That's how we decided to drop it.

Having to constantly repeat that, yes, this was of interest to me was
soul-sapping.

> > Reading that mail you mentioned won't bring those features back.
> > It's
> > far from the first time you've wanted to remove Pocket support from
> > GOA, as if it was a time sink, and a maintenance pain.
> > 
> > I just don't understand the strategy of disabling/removing features
> > and
> > services, breaking apps on newer hosts.
> 
> We have always, since the very first days when David Zeuthen was
> around, pushed back against adding random accounts to GOA. We have
> always said that the integration should be meaningful to a good cross
> section of users, that there should be a default application or OS
> component, etc..
> 
> This is nothing new. We eventually wrote it down as
> https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals
> 
> The Pocket integration doesn't do much. You yourself said that you
> seldom use it.

Mostly because the various integration points didn't exist. We (GNOME)
were pining for a sharing interface which didn't, and still doesn't,
exist, and epiphany maintainers didn't want to integrate the patch that
was already written.

> We regularly refuse requests to add random accounts to GOA. Just look
> at the enhancement requests left open on Bugzilla. There are lots
> more
> that I have dealt with from other channels. It isn't fair that we
> turn
> down other requests, but keep Pocket in.

I don't think that feature requests should be treated on the same level
as existing, merged, features, and I don't see any merge requests for
new account types, or providers.

> It certainly is a maintenance burden. It's a burden when one has to
> port away from deprecated GLib and WebKit APIs, it's a burden
> when someone has to tweak the base-classes to accommodate yet
> another quirky service provider or to just repay some technical debt
> and clean things up.

I wish that was brought forward earlier in the thread. Seeing as it's a
maintenance burden, and it's impossible to write an application with
some reasonable degree of expectation that Pocket support will be
present in the host gnome-online-accounts framework, I think it best
for it to be removed completely, so that applications don't try to use
it in lieu of in-application independent support:
https://gitlab.gnome.org/GNOME/gnome-online-accounts/merge_requests/18

> But it's a burden we can carry as long as we have someone committed
> to
> push it forward towards a better future. That future need not be in
> two months time, but it has to be something that's more realistic
> than
> unicorns.

Sorry, I don't understand what unicorns have to do with this
discussion.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Bastien Nocera]

On Wed, 2019-01-23 at 19:47 +, Debarshi Ray wrote:
> On Wed, Jan 23, 2019 at 05:39:44PM +0100, Bastien Nocera wrote:
> > As Emmanuele mentioned, the problem isn't so much that services
> > will
> > disappear from under the applications (but it's a problem
> > nonetheless),
> > it's that there was no communication explaining that applications
> > shouldn't have relied on GNOME Online Accounts in the first place,
> > as
> > the functionality could disappear for reasons not caused by those
> > services, or applications.
> 
> You are talking as if the application maintainer and the GNOME Online
> Account maintainer are two disjoint entities. As if an active
> community of contributors have been jeopardized by the arbitrary will
> of the mythical GOA maintainer.
> 
> That's false.

You dropped maintainership of gnome-documents, we're now dropping it
from core GNOME, and by removing the Documents integration from GOA,
you're crippling the application, whoever the new maintainer ends up
being.

> [rishi@kolache gnome-documents]$ git shortlog -ns | head
>   1036 Cosimo Cecchi
>357 Debarshi Ray
> 78 Alessandro Bono
> 76 Daniel Mustieles
> 68 Piotr Drag
> 59 Bastien Nocera
> 52 Kjartan Maraas
> 39 Marek Cernocky
> 36 Matej Urbancic
> 36 William Jon McCann
> 
> Since everybody is concerned about the Online Accounts integration,
> let's look at gnome-online-miners.git. That's where the said
> integration lives.
> 
> [rishi@kolache gnome-online-miners]$ git shortlog -ns | head
>101 Debarshi Ray
>  6 Pranav Kant
> 
> And I am just not going to bother digging up review statistics from
> Bugzilla. ;)
> 
> I was also the only maintainer at least pretending to keep up with
> the
> GNOME schedule.
> 
> 
> There wasn't any active community.
> 
> We regularly released with glaring bugs that some of our downstreams
> would consider blockers.  Fedora releases would have blocked, had
> those bugs been known. They weren't known because very few people, if
> any, ever used the application, so nobody ever reported them.
> 
> RHEL 7.x releases actually did block on those bugs. That's how those
> eventually got noticed, fixed and backported.
> 
> Boy, did I spend hours diligently backporting all those fixes,
> spinning tarballs, doing downstream builds. Sometimes the backports
> went across three or four stable branches - that's how glaring and
> old
> some of the bugs were. Not a soul cared.
> 
> These bugs were regressions introduced by the occasional patch that
> would get merged, or by changes in our JavaScript stack, or something
> else. The upshot being that the reviewers themselves weren't using
> the
> application much, or didn't have enough time to diligently review the
> patches; nor did it have any users in the wider GNOME community and
> beyond.
> 
> It was also clear that the GNOME designers weren't that excited about
> GNOME Documents any more.
> 
> 
> Yes, I could have started by listing all the reasons behind why
> Documents is considered a dead-end. I didn't do that, so I am very
> sorry about that.

Right, this is it. Thanks.

> However, I did give a brief background in my very next email to this
> thread. Cosimo, Michael, Jakub and Allan were all part of the
> discussions about it's future.
> 
> But then, I haven't yet found anybody honestly asking why we gave up
> on it. Instead people went ahead and drew whatever conclusions they
> wanted to draw. I find that odd.
> 
> It's not like this is the first time we have dropped things from
> GNOME
> Online Accounts. Back in 2017 [1] we had dropped Telepathy. I had
> written a wall of text explaining that decision. Guess how many
> replies that thread got.  Surely, Telepathy has had a lot more users
> in its time than Documents.
> 
> So, I do find it strange that people are suddenly coming out of the
> woodwork passionately fighting for the survival of GNOME Documents.

It's not Documents. It's Documents, and Pocket, and email integration,
which brings about the viability of applications ever integrating with
gnome-online-accounts, lest they be crippled.

> 
> [1] 
> https://mail.gnome.org/archives/desktop-devel-list/2017-October/msg00040.html

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Allan Day]

Jeremy Bicha  wrote:
...
> A few months ago, I talked with mpt about GNOME Online Accounts being
> added to Ubuntu's version of gnome-initial-setup. I believe his
> opinion was that the app itself should offer the "add a new account"
> feature instead of the Initial Setup or Settings apps.
...

I agree that having app configuration live in the app is better than
having it in Settings.

One thing we've explored in the past is having the online account
configuration in the app *and* in Online Accounts - so you can add a
Google account in, say, Calander, and then it will show up in Online
Accounts too. There are some mockups [1] for this and it's a pattern
that I'd love to elaborate and see adopted more widely!

Allan
-- 
[1] 
https://github.com/gnome-design-team/gnome-mockups/blob/master/calendar/calendar-settings.png
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Milan Crha via desktop-devel-list]

On Wed, 2019-01-23 at 11:54 -0600, mcatanz...@gnome.org wrote:
> Thing is, we don't have any email apps in core. It just doesn't make 
> sense to have email settings in gnome-online-accounts when none of
> the core apps (the apps installed by default) actually use those
> settings. It's just going to confuse users with settings that don't
> do anything.

Hi,
I guess, in that case, you can safely drop also the Microsoft Exchange
accounts from GOA. The main consumer, as far as I know, is
evolution-data-server, through evolution-ews. While the mail accounts
configured with evolution-ews can work without Evolution, evolution-ews 
depends on Evolution, thus it brings it in. The evolution-ews also runs
on the background evolution-data-server processes (factories and the
source registry). You can access calendars/contacts/tasks/memos without
using the mail part, but the main advantage of the Microsoft Exchange
is the integration of all those 5 parts (something which is against
GNOME design and the way it is led in the last years, I know).

I mean, hiding the Mail switch from GOA for Microsoft Exchange accounts
doesn't make sense. It may even confuse the users.

It also seems like using GOA by core apps (is evolution-data-server
considered an app, maybe it's just 'core') is meant only from GNOME
desktop. At least according to gnome-control-central behavior, which
rejects to access GOA when not running under GNOME for couple releases
now [1]. It got better, because it's crashing in 3.30.2, while it
opened an empty tab before. This is probably unrelated, unless it's an
intention, similar to drop documents support from GOA.
Bye,
Milan

[1] Evolution adds "Open Settings" button for GOA accounts, to make
life easier to the users. It calls:
   gnome-control-central online-accounts
which did work several releases ago, regardless which desktop
environment the user used.
https://gitlab.gnome.org/GNOME/gnome-control-center/issues/66
Maybe if GOA settings could be called out of the
gnome-control-central? Users do need to go there from time to time.
On the other hand, with flatpak and its inaccessibility of
the system gnome-control-central it doesn't matter as that much.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Michael Gratton]

On Thu, 24 Jan, 2019 at 5:52 AM, Debarshi Ray  
wrote:

On Wed, Jan 23, 2019 at 04:03:41PM +0100, Bastien Nocera wrote:
On Wed, 2019-01-23 at 14:33 +, Allan Day wrote: > That's not 
what's happening here. Until very recently, Debarshi was > the 
Documents maintainer, and he's obviously been fully involved. It is 
what is happening in GNOME Online Accounts in general. Pocket is 
disabled in Fedora 29, and there's a good chance that the mail 
configuration bits will be disabled in Fedora 30.
 Grep for "Future of Pocket in GNOME" from 24th August 2018 in your 
inbox.


Was there a similar announcement for the Mail component that I missed? 
Debarshi you knew I landed support for this in Geary master earlier 
this year, a head-up would have been appreciated.


If GOA Mail is going to be removed from Fedora can there at least be a 
method to programatically determine what is supported and what isn't, 
so Geary can avoid launching the control center when people want to add 
an account on Fedora?


Thanks.

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Michael Gratton]

On Wed, 23 Jan, 2019 at 9:26 PM, Bastien Nocera  
wrote:
The Pocket provider (used by FeedReader, and GNOME Videos) was also 
disabled from Fedora, and is apparently targeted to be removed. And 
the "Mail" category is also targeted to be removed in Fedora[1], 
already setup mail accounts be damned.


I don't understand the need to remove those when they are still used 
(albeit not as much as it could be), when they don't seem to cause 
maintenance problems (compared to, say, Kerberos...). [1]: 



Well that's terrible news, I'm putting a release of Geary out release 
out with GOA support in a week or two.


Why not just depreciate GOA completely if it's just going to keep on 
losing features? Could this at least have been communicated on the GOA 
list?


//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Jeremy Bicha]

On Wed, Jan 23, 2019 at 2:47 PM Debarshi Ray  wrote:
> It's not like this is the first time we have dropped things from GNOME
> Online Accounts. Back in 2017 [1] we had dropped Telepathy. I had
> written a wall of text explaining that decision. Guess how many
> replies that thread got.  Surely, Telepathy has had a lot more users
> in its time than Documents.

I clearly remember the Telepathy removal from GOA. It made me slightly
uncomfortable that people would lose their account configuration on
upgrading, but at least Empathy still had a way to add those accounts
back. Empathy has lost so many users by now that I didn't receive any
complaints about that either.

But you're talking about removing even more online accounts providers
even though apps that support them have not yet implemented a
replacement. That's a completely different thing than a one-time
reauthentication after upgrading. (Google asks me for my password
frequently (at least monthly) in my web browser. I think users are
used to having to re-enter their password periodically.)

And it's not just Documents. I'm a bit concerned over the user
experience for Evolution if Fedora (or GNOME!!) removes the GOA
support for email. I know that Evolution has its own accounts system.
I'm just not sure that Evolution is designed to handle adding a
replacement account when the GOA provider is ripped away when users
upgrade.

I understand the user confusion problem about having additional
services and providers that are visible in GOA when the computer
doesn't have installed apps that use those. Ubuntu feels that even
more painfully than Fedora since we never included the Documents app
by default or Photos and Thunderbird (which doesn't use GOA) is our
default email client.

A few months ago, I talked with mpt about GNOME Online Accounts being
added to Ubuntu's version of gnome-initial-setup. I believe his
opinion was that the app itself should offer the "add a new account"
feature instead of the Initial Setup or Settings apps. If we wanted to
go that direction, we could make the Online Accounts panel be
integrated into the Applications panel (like we do in 3.32 with the
Location service).

Interestingly, Ubuntu Online Accounts was ahead of its time here. What
it offers in Ubuntu 16.04 LTS sort of foreshadows how this could work.
You can select Google and see which apps support the Google UOA
service before signing in to the Google provider. Once signed in,
there are on/off switches for each app so you could have Evolution
have access to your Google account but not Shotwell if you wanted. If
we add portals for this, I think this could be very useful with
sandboxed apps.

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

On Wed, Jan 23, 2019 at 08:02:16PM +0100, Bastien Nocera wrote:
> On Wed, 2019-01-23 at 18:52 +, Debarshi Ray wrote:
> > Grep for "Future of Pocket in GNOME" from 24th August 2018 in your
> > inbox.
> 
> Which solves what? You're removing the Documents and Mail categories,
> you're removing Pocket support.

Two things.

First, we are talking about GNOME Documents, GNOME Online Accounts,
GNOME ..., etc.. We are talking about GNOME.

If you are not going to respond to a thread that has run for six
months, on a topic that you care about, then I am sorry, I can't
assume good faith. Those who participated agreed that they don't have
time to work on Pocket, nor is the current state of affairs very
good. That's how we decided to drop it.

> Reading that mail you mentioned won't bring those features back. It's
> far from the first time you've wanted to remove Pocket support from
> GOA, as if it was a time sink, and a maintenance pain.
> 
> I just don't understand the strategy of disabling/removing features and
> services, breaking apps on newer hosts.

We have always, since the very first days when David Zeuthen was
around, pushed back against adding random accounts to GOA. We have
always said that the integration should be meaningful to a good cross
section of users, that there should be a default application or OS
component, etc..

This is nothing new. We eventually wrote it down as
https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals

The Pocket integration doesn't do much. You yourself said that you
seldom use it.

We regularly refuse requests to add random accounts to GOA. Just look
at the enhancement requests left open on Bugzilla. There are lots more
that I have dealt with from other channels. It isn't fair that we turn
down other requests, but keep Pocket in.

It certainly is a maintenance burden. It's a burden when one has to
port away from deprecated GLib and WebKit APIs, it's a burden
when someone has to tweak the base-classes to accommodate yet
another quirky service provider or to just repay some technical debt
and clean things up.

But it's a burden we can carry as long as we have someone committed to
push it forward towards a better future. That future need not be in
two months time, but it has to be something that's more realistic than
unicorns.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

On Wed, Jan 23, 2019 at 05:39:44PM +0100, Bastien Nocera wrote:
> As Emmanuele mentioned, the problem isn't so much that services will
> disappear from under the applications (but it's a problem nonetheless),
> it's that there was no communication explaining that applications
> shouldn't have relied on GNOME Online Accounts in the first place, as
> the functionality could disappear for reasons not caused by those
> services, or applications.


You are talking as if the application maintainer and the GNOME Online
Account maintainer are two disjoint entities. As if an active
community of contributors have been jeopardized by the arbitrary will
of the mythical GOA maintainer.

That's false.


[rishi@kolache gnome-documents]$ git shortlog -ns | head
  1036 Cosimo Cecchi
   357 Debarshi Ray
78 Alessandro Bono
76 Daniel Mustieles
68 Piotr Drag
59 Bastien Nocera
52 Kjartan Maraas
39 Marek Cernocky
36 Matej Urbancic
36 William Jon McCann

Since everybody is concerned about the Online Accounts integration,
let's look at gnome-online-miners.git. That's where the said
integration lives.

[rishi@kolache gnome-online-miners]$ git shortlog -ns | head
   101 Debarshi Ray
 6 Pranav Kant

And I am just not going to bother digging up review statistics from
Bugzilla. ;)

I was also the only maintainer at least pretending to keep up with the
GNOME schedule.


There wasn't any active community.

We regularly released with glaring bugs that some of our downstreams
would consider blockers.  Fedora releases would have blocked, had
those bugs been known. They weren't known because very few people, if
any, ever used the application, so nobody ever reported them.

RHEL 7.x releases actually did block on those bugs. That's how those
eventually got noticed, fixed and backported.

Boy, did I spend hours diligently backporting all those fixes,
spinning tarballs, doing downstream builds. Sometimes the backports
went across three or four stable branches - that's how glaring and old
some of the bugs were. Not a soul cared.

These bugs were regressions introduced by the occasional patch that
would get merged, or by changes in our JavaScript stack, or something
else. The upshot being that the reviewers themselves weren't using the
application much, or didn't have enough time to diligently review the
patches; nor did it have any users in the wider GNOME community and
beyond.

It was also clear that the GNOME designers weren't that excited about
GNOME Documents any more.


Yes, I could have started by listing all the reasons behind why
Documents is considered a dead-end. I didn't do that, so I am very
sorry about that.

However, I did give a brief background in my very next email to this
thread. Cosimo, Michael, Jakub and Allan were all part of the
discussions about it's future.

But then, I haven't yet found anybody honestly asking why we gave up
on it. Instead people went ahead and drew whatever conclusions they
wanted to draw. I find that odd.

It's not like this is the first time we have dropped things from GNOME
Online Accounts. Back in 2017 [1] we had dropped Telepathy. I had
written a wall of text explaining that decision. Guess how many
replies that thread got.  Surely, Telepathy has had a lot more users
in its time than Documents.

So, I do find it strange that people are suddenly coming out of the
woodwork passionately fighting for the survival of GNOME Documents.


[1] 
https://mail.gnome.org/archives/desktop-devel-list/2017-October/msg00040.html
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Bastien Nocera]

On Wed, 2019-01-23 at 11:54 -0600, mcatanz...@gnome.org wrote:
> On Wed, Jan 23, 2019 at 9:03 AM, Bastien Nocera  
> wrote:
> > It is what is happening in GNOME Online Accounts in general. Pocket
> > is
> > disabled in Fedora 29, and there's a good chance that the mail
> > configuration bits will be disabled in Fedora 30.
> > 
> > I don't know whether those changes will also be done upstream, but
> > the
> > result will be the same, it won't be possible for applications
> > shipped
> > through Flatpak to know that certain configuration options will be
> > available in GNOME Online Accounts.
> 
> Thing is, we don't have any email apps in core. It just doesn't make 
> sense to have email settings in gnome-online-accounts when none of
> the 
> core apps (the apps installed by default) actually use those
> settings. 
> It's just going to confuse users with settings that don't do
> anything.

And those upgrading will lose those mail accounts, right?

> I don't really have strong opinions on the future of 
> gnome-online-accounts, but unless there are major design changes
> along 
> the lines that have been suggested in this thread, then yes, I would 
> certainly advise against using it outside of the core apps.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Bastien Nocera]

On Wed, 2019-01-23 at 18:52 +, Debarshi Ray wrote:
> On Wed, Jan 23, 2019 at 04:03:41PM +0100, Bastien Nocera wrote:
> > On Wed, 2019-01-23 at 14:33 +, Allan Day wrote:
> > > That's not what's happening here. Until very recently, Debarshi
> > > was
> > > the Documents maintainer, and he's obviously been fully involved.
> > 
> > It is what is happening in GNOME Online Accounts in general. Pocket
> > is
> > disabled in Fedora 29, and there's a good chance that the mail
> > configuration bits will be disabled in Fedora 30.
> 
> Grep for "Future of Pocket in GNOME" from 24th August 2018 in your
> inbox.

Which solves what? You're removing the Documents and Mail categories,
you're removing Pocket support.

I'm more than annoyed because I didn't think that you'd disable and/or
remove support for things that were already supported if they weren't
broken, and I've spent a long while adding GOA support to grilo Lua
sources so we could have Last.fm covers in Music, and watch Pocket'ed
videos.

I use GNOME Documents with Google Docs, I have a GMail mail account
setup with GNOME Online Accounts, and I (seldom) watch Pocket'ed
videos.

Reading that mail you mentioned won't bring those features back. It's
far from the first time you've wanted to remove Pocket support from
GOA, as if it was a time sink, and a maintenance pain.

I just don't understand the strategy of disabling/removing features and
services, breaking apps on newer hosts.

Please explicitely, "don't use GNOME Online Accounts if you're not a
core app that's part of the system", if that's what it's going to be.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

On Wed, Jan 23, 2019 at 04:03:41PM +0100, Bastien Nocera wrote:
> On Wed, 2019-01-23 at 14:33 +, Allan Day wrote:
> > That's not what's happening here. Until very recently, Debarshi was
> > the Documents maintainer, and he's obviously been fully involved.
> 
> It is what is happening in GNOME Online Accounts in general. Pocket is
> disabled in Fedora 29, and there's a good chance that the mail
> configuration bits will be disabled in Fedora 30.

Grep for "Future of Pocket in GNOME" from 24th August 2018 in your
inbox.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Emmanuele Bassi via desktop-devel-list]

On Wed, 23 Jan 2019 at 18:36, Debarshi Ray  wrote:

> On Wed, Jan 23, 2019 at 02:49:55PM +, Emmanuele Bassi via
> desktop-devel-list wrote:
> > On Wed, 23 Jan 2019 at 14:21, Allan Day  wrote:
> > > If apps could provide their own keys that would certainly change the
> > > picture (I didn't actually know it was a possibility.) It would also
> > > change the nature of Online Accounts of course; it's always been
> > > designed as part of the system, that's used by the system and the core
> > > apps. Might take a little thought.
> > >
> >
> > We had a key store for web services API keys in Moblin/MeeGo, as part of
> > libsocialweb, mostly because we couldn't have OEMs ship with Intel OTC
> > keys, and OEMs didn't want to make their key public either. :-)
> >
> > Re-implementing that would not be hard, especially if we make it a
> > prerequisite that new services must come with their own key.
> Additionally,
> > it would let downstream vendors ship their own keys, if they are so
> > inclined.
>
> I don't understand.
>
> Say, we had a GNOME API key for Google and another for application
> Foo.  For all intents and purposes, those would need to be presented
> separately to the user. The user would have to sign in separately to
> GNOME and Foo and grant permission to each key, and so on. That's just
> how the services work.
>

If the "GNOME" API key is marked as the "system" key, then we only show the
GNOME key; if the system key does not exist, we show the Foo application
key.

It's already feasible for a downstream to replace all the default
> GNOME upstream keys shipped with GOA with their own using the build
> flags. For example, Fedora could do that, as long as they are careful
> enough to configure their keys properly.
>

I'm proposing adding run time discovery on top of build time.


> What isn't possible is to mix and match API keys with account types at
> run-time. That doesn't seem trivial to implement - neither from a code
> nor a design perspective. Possible, sure; trivial, no.
>

I didn't say "trivial", but I didn't expect this to be hard. You, of
course, know better than me how hard it would be, so I'll defer to your
assessment.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

On Wed, Jan 23, 2019 at 02:49:55PM +, Emmanuele Bassi via 
desktop-devel-list wrote:
> On Wed, 23 Jan 2019 at 14:21, Allan Day  wrote:
> > If apps could provide their own keys that would certainly change the
> > picture (I didn't actually know it was a possibility.) It would also
> > change the nature of Online Accounts of course; it's always been
> > designed as part of the system, that's used by the system and the core
> > apps. Might take a little thought.
> >
> 
> We had a key store for web services API keys in Moblin/MeeGo, as part of
> libsocialweb, mostly because we couldn't have OEMs ship with Intel OTC
> keys, and OEMs didn't want to make their key public either. :-)
> 
> Re-implementing that would not be hard, especially if we make it a
> prerequisite that new services must come with their own key. Additionally,
> it would let downstream vendors ship their own keys, if they are so
> inclined.

I don't understand.

Say, we had a GNOME API key for Google and another for application
Foo.  For all intents and purposes, those would need to be presented
separately to the user. The user would have to sign in separately to
GNOME and Foo and grant permission to each key, and so on. That's just
how the services work.

It's already feasible for a downstream to replace all the default
GNOME upstream keys shipped with GOA with their own using the build
flags. For example, Fedora could do that, as long as they are careful
enough to configure their keys properly.

What isn't possible is to mix and match API keys with account types at
run-time. That doesn't seem trivial to implement - neither from a code
nor a design perspective. Possible, sure; trivial, no.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Christopher Davis via desktop-devel-list]

Maybe not in core, but Geary will soon support IMAP/SMTP from GOA.
For that work to be undone in the next release because of a technicality
would be a shame.

Regards,
Chris

On Wed, Jan 23, 2019 at 12:54 PM, mcatanz...@gnome.org wrote:
On Wed, Jan 23, 2019 at 9:03 AM, Bastien Nocera  
wrote:
It is what is happening in GNOME Online Accounts in general. Pocket 
is

disabled in Fedora 29, and there's a good chance that the mail
configuration bits will be disabled in Fedora 30.

I don't know whether those changes will also be done upstream, but 
the
result will be the same, it won't be possible for applications 
shipped

through Flatpak to know that certain configuration options will be
available in GNOME Online Accounts.


Thing is, we don't have any email apps in core. It just doesn't make 
sense to have email settings in gnome-online-accounts when none of 
the core apps (the apps installed by default) actually use those 
settings. It's just going to confuse users with settings that don't 
do anything.


I don't really have strong opinions on the future of 
gnome-online-accounts, but unless there are major design changes 
along the lines that have been suggested in this thread, then yes, I 
would certainly advise against using it outside of the core apps.


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Emmanuele Bassi via desktop-devel-list]

On Wed, 23 Jan 2019 at 17:55,  wrote:

> On Wed, Jan 23, 2019 at 9:03 AM, Bastien Nocera 
> wrote:
> > It is what is happening in GNOME Online Accounts in general. Pocket is
> > disabled in Fedora 29, and there's a good chance that the mail
> > configuration bits will be disabled in Fedora 30.
> >
> > I don't know whether those changes will also be done upstream, but the
> > result will be the same, it won't be possible for applications shipped
> > through Flatpak to know that certain configuration options will be
> > available in GNOME Online Accounts.
>
> Thing is, we don't have any email apps in core. It just doesn't make
> sense to have email settings in gnome-online-accounts when none of the
> core apps (the apps installed by default) actually use those settings.
> It's just going to confuse users with settings that don't do anything.
>
> I don't really have strong opinions on the future of
> gnome-online-accounts, but unless there are major design changes along
> the lines that have been suggested in this thread, then yes, I would
> certainly advise against using it outside of the core apps.
>

This position is fundamentally at odds with the statement that we should
move towards containerised (flatpak/snap) core apps.

If the system service that provides single-sign-on for web services is not
stable—i.e. it can drop capabilities across minor releases—then we cannot
tell people to use Photos, Music, or whatever else as flatpaks/snaps.

Again, this is fine if we *explicitly* say that people can only use core
GNOME apps as part of the system; since we've been saying something else
entirely, we cannot use the fig leaf of "users will be confused" because I
can guarantee you that users will be much more confused (and angrier) if
they install an application, update the OS, and suddenly the application
won't work any more, which is something we *explicitly* said would not
happen.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[mcatanzaro]

On Wed, Jan 23, 2019 at 9:03 AM, Bastien Nocera  
wrote:

It is what is happening in GNOME Online Accounts in general. Pocket is
disabled in Fedora 29, and there's a good chance that the mail
configuration bits will be disabled in Fedora 30.

I don't know whether those changes will also be done upstream, but the
result will be the same, it won't be possible for applications shipped
through Flatpak to know that certain configuration options will be
available in GNOME Online Accounts.


Thing is, we don't have any email apps in core. It just doesn't make 
sense to have email settings in gnome-online-accounts when none of the 
core apps (the apps installed by default) actually use those settings. 
It's just going to confuse users with settings that don't do anything.


I don't really have strong opinions on the future of 
gnome-online-accounts, but unless there are major design changes along 
the lines that have been suggested in this thread, then yes, I would 
certainly advise against using it outside of the core apps.


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Emmanuele Bassi via desktop-devel-list]

On Wed, 23 Jan 2019 at 16:41, Allan Day  wrote:

> Emmanuele Bassi  wrote:
> ...
> >> > This is because we never specified a way to get third party keys
> stored inside GOA as part of a process to get third party modules to it.
> >>
> >> If apps could provide their own keys that would certainly change the
> >> picture (I didn't actually know it was a possibility.) It would also
> >> change the nature of Online Accounts of course; it's always been
> >> designed as part of the system, that's used by the system and the core
> >> apps. Might take a little thought.
> ...
> > We had a key store for web services API keys in Moblin/MeeGo, as part of
> libsocialweb, mostly because we couldn't have OEMs ship with Intel OTC
> keys, and OEMs didn't want to make their key public either. :-)
> >
> > Re-implementing that would not be hard, especially if we make it a
> prerequisite that new services must come with their own key. Additionally,
> it would let downstream vendors ship their own keys, if they are so
> inclined.
>
> Thinking about this idea a little more, I wonder what the value would
> be for users, over apps implementing online auth themselves.
>
> The original goal of Online Accounts was single sign-in: it was to
> avoid users having to repeatedly log into the same account, and to
> avoid multiple apps from carrying the UI to do so. If apps provide
> their own keys, then I assume that users will have to authenticate for
> each key, so the main advantage to users wouldn't apply.
>

The way this was designed in Moblin was not for apps to ship secret keys
for web services, but to have a semi-centralised way of shipping secrets
for system integrated services; then you could get your single-sign-on
platform. Think of it as a gsettings-desktop-schemas kind of scenario: a
repository of the secrets, with the ability to override them on a
per-OEM/per-installation basis.

Of course, if GNOME decided to remove a service, apps would still fall
over; but for that case we could move the secret to a separate "external"
repository that apps can depend on in a new release.

Alternatively, we could have priorities dictated by search paths, and apps
could always install their secret at a lower priority than the system one;
this way, if GNOME removes a service from GOA, it will fall back to the
application's own secret without degrading the user experience further than
"you now have to authenticate yourself when you use this app". This would
also work for sandboxed apps, because then they could avoid the API break
when the system's GOA changes capabilities.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Allan Day]

Emmanuele Bassi  wrote:
...
>> > This is because we never specified a way to get third party keys stored 
>> > inside GOA as part of a process to get third party modules to it.
>>
>> If apps could provide their own keys that would certainly change the
>> picture (I didn't actually know it was a possibility.) It would also
>> change the nature of Online Accounts of course; it's always been
>> designed as part of the system, that's used by the system and the core
>> apps. Might take a little thought.
...
> We had a key store for web services API keys in Moblin/MeeGo, as part of 
> libsocialweb, mostly because we couldn't have OEMs ship with Intel OTC keys, 
> and OEMs didn't want to make their key public either. :-)
>
> Re-implementing that would not be hard, especially if we make it a 
> prerequisite that new services must come with their own key. Additionally, it 
> would let downstream vendors ship their own keys, if they are so inclined.

Thinking about this idea a little more, I wonder what the value would
be for users, over apps implementing online auth themselves.

The original goal of Online Accounts was single sign-in: it was to
avoid users having to repeatedly log into the same account, and to
avoid multiple apps from carrying the UI to do so. If apps provide
their own keys, then I assume that users will have to authenticate for
each key, so the main advantage to users wouldn't apply.

The main other advantage that I can think of would be that it would
make Online Accounts into a convenient place where someone can get an
overview of apps using online accounts, although quite how compelling
that is I'm not sure, particularly since it's not going to cover every
app and account on the system.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Bastien Nocera]

On Wed, 2019-01-23 at 10:27 -0500, Matthias Clasen wrote:
> 
> 
> On Wed, Jan 23, 2019 at 10:03 AM Bastien Nocera 
> wrote:
> > On Wed, 2019-01-23 at 14:33 +, Allan Day wrote:
> > > Bastien Nocera  wrote:
> > > 
> > > > Flip it on its head and please suggest why, nowadays, any
> > > > application
> > > > developer, whether for a GNOME application or a third-party,
> > would
> > > > spend time integrating services into gnome-online-accounts, or
> > > > using
> > > > gnome-online-accounts for functionality that's somewhat core to
> > the
> > > > application experience, when the rug can be pulled from under
> > your
> > > > app
> > > > at any point?
> > > 
> > > That's not what's happening here. Until very recently, Debarshi
> > was
> > > the Documents maintainer, and he's obviously been fully involved.
> > 
> > It is what is happening in GNOME Online Accounts in general. Pocket
> > is
> > disabled in Fedora 29, and there's a good chance that the mail
> > configuration bits will be disabled in Fedora 30.
> > 
> > I don't know whether those changes will also be done upstream, but
> > the
> > result will be the same, it won't be possible for applications
> > shipped
> > through Flatpak to know that certain configuration options will be
> > available in GNOME Online Accounts.
> > 
> 
> I believe in the larger picture, this is a logical consequence of
> taking the boundary between desktop and apps seriously.

Right, and a functional regression for applications (core or not) that
relied on GNOME Online Accounts to enumerate services the user had
setup and authenticate with them.

As Emmanuele mentioned, the problem isn't so much that services will
disappear from under the applications (but it's a problem nonetheless),
it's that there was no communication explaining that applications
shouldn't have relied on GNOME Online Accounts in the first place, as
the functionality could disappear for reasons not caused by those
services, or applications.

> It is just not right to give all 3rd party apps that show up in a
> flatpak access to the GNOME api keys and identity.
> They need to use their own keys. Offering a centralized service for
> storing such keys, as Emmanuele suggests,
> might still be useful. 

With a per-app key usage, you end up losing the single sign-on, for
example if you had 2 separate contacts applications, you'd need to
login twice to authorise 2 contacts applications separately.

The only thing you'd gain from this is that the application wouldn't
need to reimplement the authentication. It would greatly reduce GNOME
Online Account's "system" integration, turning it into a library to
help with authentication.

My own take away from this thread is that, as an application developer,
I shouldn't count on GNOME Online Accounts at all for my app's core
experience. Is that a fair assessment?

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Matthias Clasen via desktop-devel-list]

On Wed, Jan 23, 2019 at 10:03 AM Bastien Nocera  wrote:

> On Wed, 2019-01-23 at 14:33 +, Allan Day wrote:
> > Bastien Nocera  wrote:
> > 
> > > Flip it on its head and please suggest why, nowadays, any
> > > application
> > > developer, whether for a GNOME application or a third-party, would
> > > spend time integrating services into gnome-online-accounts, or
> > > using
> > > gnome-online-accounts for functionality that's somewhat core to the
> > > application experience, when the rug can be pulled from under your
> > > app
> > > at any point?
> >
> > That's not what's happening here. Until very recently, Debarshi was
> > the Documents maintainer, and he's obviously been fully involved.
>
> It is what is happening in GNOME Online Accounts in general. Pocket is
> disabled in Fedora 29, and there's a good chance that the mail
> configuration bits will be disabled in Fedora 30.
>
> I don't know whether those changes will also be done upstream, but the
> result will be the same, it won't be possible for applications shipped
> through Flatpak to know that certain configuration options will be
> available in GNOME Online Accounts.
>
>
I believe in the larger picture, this is a logical consequence of taking
the boundary between desktop and apps seriously.
It is just not right to give all 3rd party apps that show up in a flatpak
access to the GNOME api keys and identity.
They need to use their own keys. Offering a centralized service for storing
such keys, as Emmanuele suggests,
might still be useful.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Bastien Nocera]

On Wed, 2019-01-23 at 14:33 +, Allan Day wrote:
> Bastien Nocera  wrote:
> 
> > Flip it on its head and please suggest why, nowadays, any
> > application
> > developer, whether for a GNOME application or a third-party, would
> > spend time integrating services into gnome-online-accounts, or
> > using
> > gnome-online-accounts for functionality that's somewhat core to the
> > application experience, when the rug can be pulled from under your
> > app
> > at any point?
> 
> That's not what's happening here. Until very recently, Debarshi was
> the Documents maintainer, and he's obviously been fully involved.

It is what is happening in GNOME Online Accounts in general. Pocket is
disabled in Fedora 29, and there's a good chance that the mail
configuration bits will be disabled in Fedora 30.

I don't know whether those changes will also be done upstream, but the
result will be the same, it won't be possible for applications shipped
through Flatpak to know that certain configuration options will be
available in GNOME Online Accounts.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Emmanuele Bassi via desktop-devel-list]

On Wed, 23 Jan 2019 at 14:21, Allan Day  wrote:

> [Responding selectively, this thread is getting long.]
>
> Emmanuele Bassi  wrote:
> ...
> >> The main factor has always been about how we handle identity. If we
> >> give online accounts access to 3rd party apps, we're giving them
> >> access to the GNOME keys. They appear as "GNOME" to online providers
> >> and their access is bundled up with our own. As a result, we lose the
> >> ability to ensure that the GNOME keys are being used in accordance
> >> with providers' terms and conditions.
> >
> > This is because we never specified a way to get third party keys stored
> inside GOA as part of a process to get third party modules to it.
>
> If apps could provide their own keys that would certainly change the
> picture (I didn't actually know it was a possibility.) It would also
> change the nature of Online Accounts of course; it's always been
> designed as part of the system, that's used by the system and the core
> apps. Might take a little thought.
>

We had a key store for web services API keys in Moblin/MeeGo, as part of
libsocialweb, mostly because we couldn't have OEMs ship with Intel OTC
keys, and OEMs didn't want to make their key public either. :-)

Re-implementing that would not be hard, especially if we make it a
prerequisite that new services must come with their own key. Additionally,
it would let downstream vendors ship their own keys, if they are so
inclined.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Jeremy Bicha]

On Wed, Jan 23, 2019 at 9:34 AM Allan Day  wrote:
> It's important that we have the ability to correct problems when they
> do happen. To me that implies that only our software should use our
> keys.

You could also encourage distros to use their own keys.

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Allan Day]

Bastien Nocera  wrote:
...
> GNOME apps are not, and were never the only consumers of the gnome-
> online-accounts capabilities,

There's been a rather big grey area around Online Accounts. The UX was
always designed as a system service, for use by the core apps, but we
never enforced this, partly because we haven't had sandboxing in the
past.

Of course, if we're taking app isolation seriously then we obviously
ought to limit access to online accounts. The grey area has to be made
black and white.

> and, correct me if I'm wrong, but the
> only problems we had with applications doing something that wasn't
> liked in the past were in *platform* components, not even in core
> applications.

It's important that we have the ability to correct problems when they
do happen. To me that implies that only our software should use our
keys.

...
> Flip it on its head and please suggest why, nowadays, any application
> developer, whether for a GNOME application or a third-party, would
> spend time integrating services into gnome-online-accounts, or using
> gnome-online-accounts for functionality that's somewhat core to the
> application experience, when the rug can be pulled from under your app
> at any point?

That's not what's happening here. Until very recently, Debarshi was
the Documents maintainer, and he's obviously been fully involved.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Allan Day]

[Responding selectively, this thread is getting long.]

Emmanuele Bassi  wrote:
...
>> The main factor has always been about how we handle identity. If we
>> give online accounts access to 3rd party apps, we're giving them
>> access to the GNOME keys. They appear as "GNOME" to online providers
>> and their access is bundled up with our own. As a result, we lose the
>> ability to ensure that the GNOME keys are being used in accordance
>> with providers' terms and conditions.
>
> This is because we never specified a way to get third party keys stored 
> inside GOA as part of a process to get third party modules to it.

If apps could provide their own keys that would certainly change the
picture (I didn't actually know it was a possibility.) It would also
change the nature of Online Accounts of course; it's always been
designed as part of the system, that's used by the system and the core
apps. Might take a little thought.

>> From a design perspective that's never been something we've wanted to
>> do, both from a branding and identity perspective, as well as from a
>> "oh shit we can't access Google any more, because some random app did
>> something they didn't like".
>
> We can communicate that a key has been revoked by a service in the same way 
> we communicate that the user needs to re-authenticate themselves.

That would work if apps can provide their own keys. The concern in the
past has always been around GNOME's keys potentially being
blacklisted.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Bastien Nocera]

On Wed, 2019-01-23 at 12:25 +, Allan Day wrote:
> Emmanuele Bassi  wrote:
> ...
> > > This approach isn't new, and you can read more detail here:
> > > https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals
> > > 
> > 
> > I know the rationale. I never particularly agreed with it, because
> > it felt like an ex post rationalisation about not having third
> > party modules, and getting people to commit functionality upstream.
> > ...
> 
> I don't think that was the reason. At least, it's not what's been on
> my mind, and I don't remember others putting that view forward.
> 
> The main factor has always been about how we handle identity. If we
> give online accounts access to 3rd party apps, we're giving them
> access to the GNOME keys. They appear as "GNOME" to online providers
> and their access is bundled up with our own. As a result, we lose the
> ability to ensure that the GNOME keys are being used in accordance
> with providers' terms and conditions.
> 
> From a design perspective that's never been something we've wanted to
> do, both from a branding and identity perspective, as well as from a
> "oh shit we can't access Google any more, because some random app did
> something they didn't like".

GNOME apps are not, and were never the only consumers of the gnome-
online-accounts capabilities, and, correct me if I'm wrong, but the
only problems we had with applications doing something that wasn't
liked in the past were in *platform* components, not even in core
applications.

> > What I'm objecting to is the wishy-washy approach of telling
> > people: "Sure, you can keep working on Documents, it's just not
> > going to be installed any more" without telling the whole story.
> > 
> > If Documents is removed, then all the Documents integration within
> > GNOME is also removed, which means that the project *in its current
> > incarnation* should just be archived. People should be encouraged
> > to fork it, if they find it useful, and implement that integration
> > inside Documents itself. This gives the proper context and
> > communicates the proper expectations to people willing to maintain
> > the Documents code base.
> 
> If you think something can be done better, just suggest how it can be
> done better.

Flip it on its head and please suggest why, nowadays, any application
developer, whether for a GNOME application or a third-party, would
spend time integrating services into gnome-online-accounts, or using
gnome-online-accounts for functionality that's somewhat core to the
application experience, when the rug can be pulled from under your app
at any point?

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Emmanuele Bassi via desktop-devel-list]

On Wed, 23 Jan 2019 at 12:26, Allan Day  wrote:

> Emmanuele Bassi  wrote:
> ...
> >> This approach isn't new, and you can read more detail here:
> >> https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals
> >>
> >
> > I know the rationale. I never particularly agreed with it, because it
> felt like an ex post rationalisation about not having third party modules,
> and getting people to commit functionality upstream. ...
>
> I don't think that was the reason. At least, it's not what's been on
> my mind, and I don't remember others putting that view forward.
>

"It felt like".


> The main factor has always been about how we handle identity. If we
> give online accounts access to 3rd party apps, we're giving them
> access to the GNOME keys. They appear as "GNOME" to online providers
> and their access is bundled up with our own. As a result, we lose the
> ability to ensure that the GNOME keys are being used in accordance
> with providers' terms and conditions.
>

This is because we never specified a way to get third party keys stored
inside GOA as part of a process to get third party modules to it.

>From a design perspective that's never been something we've wanted to
> do, both from a branding and identity perspective, as well as from a
> "oh shit we can't access Google any more, because some random app did
> something they didn't like".
>

We can communicate that a key has been revoked by a service in the same way
we communicate that the user needs to re-authenticate themselves.


> > What I'm objecting to is the wishy-washy approach of telling people:
> "Sure, you can keep working on Documents, it's just not going to be
> installed any more" without telling the whole story.
> >
> > If Documents is removed, then all the Documents integration within GNOME
> is also removed, which means that the project *in its current incarnation*
> should just be archived. People should be encouraged to fork it, if they
> find it useful, and implement that integration inside Documents itself.
> This gives the proper context and communicates the proper expectations to
> people willing to maintain the Documents code base.
>
> If you think something can be done better, just suggest how it can be
> done better.
>
>
I believe I just did that: make the consequences of picking up Documents—or
any other core application we decide to drop because the design is fuzzy,
or the resources are too few to make a design work—explicit. Do not say:
"we are simply dropping Documents from the release", or "we are removing
Documents integration from GOA because we're dropping Documents"; instead,
explain what that means for somebody picking up a former-core application.
An even more explicit action is: archive the Git repository after removing
Documents from the release, and tell people to fork it and rename it.

Create a process for moving apps from "core" to "external".

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Allan Day]

Emmanuele Bassi  wrote:
...
>> This approach isn't new, and you can read more detail here:
>> https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals
>>
>
> I know the rationale. I never particularly agreed with it, because it felt 
> like an ex post rationalisation about not having third party modules, and 
> getting people to commit functionality upstream. ...

I don't think that was the reason. At least, it's not what's been on
my mind, and I don't remember others putting that view forward.

The main factor has always been about how we handle identity. If we
give online accounts access to 3rd party apps, we're giving them
access to the GNOME keys. They appear as "GNOME" to online providers
and their access is bundled up with our own. As a result, we lose the
ability to ensure that the GNOME keys are being used in accordance
with providers' terms and conditions.

>From a design perspective that's never been something we've wanted to
do, both from a branding and identity perspective, as well as from a
"oh shit we can't access Google any more, because some random app did
something they didn't like".

> What I'm objecting to is the wishy-washy approach of telling people: "Sure, 
> you can keep working on Documents, it's just not going to be installed any 
> more" without telling the whole story.
>
> If Documents is removed, then all the Documents integration within GNOME is 
> also removed, which means that the project *in its current incarnation* 
> should just be archived. People should be encouraged to fork it, if they find 
> it useful, and implement that integration inside Documents itself. This gives 
> the proper context and communicates the proper expectations to people willing 
> to maintain the Documents code base.

If you think something can be done better, just suggest how it can be
done better.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Bastien Nocera]

On Wed, 2019-01-23 at 10:48 +, Allan Day wrote:
> Bastien Nocera  wrote:
> ...
> > Removing GNOME Documents from the release is fine. The problem is
> > that
> > as it is removed from the release, it's an excuse for GNOME Online
> > Accounts to remove the "Documents" category.
> 
> My perspective: it's not great for our users if we have a Documents
> switch in the settings, which from their perspective doesn't do
> anything. I don't think we want people scratching their heads trying
> to figure out what the controls do.

The amount of resources needed to reimplement Documents support inside
GNOME Documents for the 3 services that implemented it (Google, Windows
Live and OwnCloud) would be higher than the amount of work needed to
maintain that one toggle in GNOME Online Accounts and maintain GNOME
Documents on top of that.

Finding a way to have the Documents toggle be available to applications
but not visible to users "browsing" the Online Accounts section of the
Settings (or the equivalent page in the initial setup) would help a
lot, rather than removing integration points that are much harder for
applications to reimplement.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Allan Day]

Bastien Nocera  wrote:
...
> Removing GNOME Documents from the release is fine. The problem is that
> as it is removed from the release, it's an excuse for GNOME Online
> Accounts to remove the "Documents" category.

My perspective: it's not great for our users if we have a Documents
switch in the settings, which from their perspective doesn't do
anything. I don't think we want people scratching their heads trying
to figure out what the controls do.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Bastien Nocera]

On Wed, 2019-01-23 at 10:39 +, Allan Day wrote:
> Emmanuele Bassi via desktop-devel-list 
> wrote:
> ...
> > > We have a rule though: the account types exposed in
> > > gnome-online-accounts must be used by at least one core
> > > application.
> > > It's a good rule because it doesn't make sense to have settings
> > > in
> > > control-center for apps that aren't installed by default.
> 
> From a UX perspective I think this makes sense. It's a bit strange if
> we have an out of the box experience where the switches in the online
> accounts settings don't do anything.
> 
> This approach isn't new, and you can read more detail here:
> https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals
> 
> > > So unless we
> > > reverse course and add gnome-documents back to core, the
> > > documents
> > > account configuration settings should move from control-center to
> > > gnome-documents itself.
> > 
> > So you're asking that an application with known resource problems
> > re-implements functionality that was offloaded to a GNOME component
> > in the first place. This work, by the way, may or may not be
> > dropped in case we change our minds, and find a use case for
> > Documents to be in the core apps in the future.
> > 
> > At this point it would be much more honest to come forward and say:
> > "GNOME Documents is no more. If you want to work on it, fork it and
> > call it whatever".
> 
> I don't think it's fair to make accusations of dishonesty. Michael
> and
> Debarshi have been open about what's happening and the consequences,
> and I think that's to be commended.
> 
> My impression is that Documents isn't getting used very much, and we
> don't seem to have a compelling story for it. It therefore seems
> reasonable to stop integrating it into the core experience, unless
> you
> have a better idea?

Removing GNOME Documents from the release is fine. The problem is that
as it is removed from the release, it's an excuse for GNOME Online
Accounts to remove the "Documents" category.

You thought GNOME Documents wasn't useful? Wait until it can't access
your online documents anymore!

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Allan Day]

Emmanuele Bassi via desktop-devel-list  wrote:
...
>> We have a rule though: the account types exposed in
>> gnome-online-accounts must be used by at least one core application.
>> It's a good rule because it doesn't make sense to have settings in
>> control-center for apps that aren't installed by default.

>From a UX perspective I think this makes sense. It's a bit strange if
we have an out of the box experience where the switches in the online
accounts settings don't do anything.

This approach isn't new, and you can read more detail here:
https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals

>> So unless we
>> reverse course and add gnome-documents back to core, the documents
>> account configuration settings should move from control-center to
>> gnome-documents itself.
>
> So you're asking that an application with known resource problems 
> re-implements functionality that was offloaded to a GNOME component in the 
> first place. This work, by the way, may or may not be dropped in case we 
> change our minds, and find a use case for Documents to be in the core apps in 
> the future.
>
> At this point it would be much more honest to come forward and say: "GNOME 
> Documents is no more. If you want to work on it, fork it and call it 
> whatever".

I don't think it's fair to make accusations of dishonesty. Michael and
Debarshi have been open about what's happening and the consequences,
and I think that's to be commended.

My impression is that Documents isn't getting used very much, and we
don't seem to have a compelling story for it. It therefore seems
reasonable to stop integrating it into the core experience, unless you
have a better idea?

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Bastien Nocera]

On Wed, 2019-01-23 at 10:17 +, Emmanuele Bassi via desktop-devel-
list wrote:
> On Mon, 21 Jan 2019 at 16:32,  wrote:
>  
> > We have a rule though: the account types exposed in 
> > gnome-online-accounts must be used by at least one core
> > application. 
> > It's a good rule because it doesn't make sense to have settings in 
> > control-center for apps that aren't installed by default. So unless
> > we 
> > reverse course and add gnome-documents back to core, the documents 
> > account configuration settings should move from control-center to 
> > gnome-documents itself.
> > 
> 
> So you're asking that an application with known resource problems re-
> implements functionality that was offloaded to a GNOME component in
> the first place. This work, by the way, may or may not be dropped in
> case we change our minds, and find a use case for Documents to be in
> the core apps in the future.
> 
> At this point it would be much more honest to come forward and say:
> "GNOME Documents is no more. If you want to work on it, fork it and
> call it whatever".

The Pocket provider (used by FeedReader, and GNOME Videos) was also
disabled from Fedora, and is apparently targeted to be removed. And the
"Mail" category is also targeted to be removed in Fedora[1], already
setup mail accounts be damned.

I don't understand the need to remove those when they are still used
(albeit not as much as it could be), when they don't seem to cause
maintenance problems (compared to, say, Kerberos...).

[1]: https://pagure.io/fedora-workstation/issue/67

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Emmanuele Bassi via desktop-devel-list]

On Mon, 21 Jan 2019 at 16:32,  wrote:


> We have a rule though: the account types exposed in
> gnome-online-accounts must be used by at least one core application.
> It's a good rule because it doesn't make sense to have settings in
> control-center for apps that aren't installed by default. So unless we
> reverse course and add gnome-documents back to core, the documents
> account configuration settings should move from control-center to
> gnome-documents itself.
>
>
So you're asking that an application with known resource problems
re-implements functionality that was offloaded to a GNOME component in the
first place. This work, by the way, may or may not be dropped in case we
change our minds, and find a use case for Documents to be in the core apps
in the future.

At this point it would be much more honest to come forward and say: "GNOME
Documents is no more. If you want to work on it, fork it and call it
whatever".

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Bastien Nocera]

On Mon, 2019-01-21 at 10:32 -0600, mcatanz...@gnome.org wrote:
> On Mon, Jan 21, 2019 at 9:14 AM, Christopher Davis via 
> desktop-devel-list  wrote:
> > Hi Rishi,
> > 
> > Cloud documents is an important part of where I want to move
> > forward 
> > with the application,
> > so Online Accounts integration would still be critical.
> > 
> > A file previewer is definitely a priority, and an editor could be 
> > considered.
> > 
> > Regards,
> > Chris
> 
> We have a rule though: the account types exposed in 
> gnome-online-accounts must be used by at least one core application. 
> It's a good rule because it doesn't make sense to have settings in 
> control-center for apps that aren't installed by default. So unless
> we 
> reverse course and add gnome-documents back to core, the documents 
> account configuration settings should move from control-center to 
> gnome-documents itself.

That would mean making the application not able to use a single facet
of an account that's otherwise already setup (because there are 6 other
toggles for Google accounts for example), and require the application
to reimplement all the login procedure, re-authentication, etc.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Christopher Davis via desktop-devel-list]

A large part of why it was removed as it being effectively 
non-functional. With 3.30.1 that's been fixed,
and Documents can be used as it was previously intended to. So, I would 
vote that we keep it in core for

now, and then refine it during the 3.34 cycle.

Chris

On Mon, Jan 21, 2019 at 11:32 AM, mcatanz...@gnome.org wrote:


We have a rule though: the account types exposed in 
gnome-online-accounts must be used by at least one core application. 
It's a good rule because it doesn't make sense to have settings in 
control-center for apps that aren't installed by default. So unless 
we reverse course and add gnome-documents back to core, the documents 
account configuration settings should move from control-center to 
gnome-documents itself.


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[mcatanzaro]

On Mon, Jan 21, 2019 at 9:14 AM, Christopher Davis via 
desktop-devel-list  wrote:

Hi Rishi,

Cloud documents is an important part of where I want to move forward 
with the application,

so Online Accounts integration would still be critical.

A file previewer is definitely a priority, and an editor could be 
considered.


Regards,
Chris


We have a rule though: the account types exposed in 
gnome-online-accounts must be used by at least one core application. 
It's a good rule because it doesn't make sense to have settings in 
control-center for apps that aren't installed by default. So unless we 
reverse course and add gnome-documents back to core, the documents 
account configuration settings should move from control-center to 
gnome-documents itself.


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Allan Day]

Christopher Davis  wrote:
...
> As the new maintaner I would be against making Documents a Google Drive 
> client, or at least
> a Drive-specific one.

I was just raising further Google Drive integration as one possible
direction to explore - I'm not specifically pushing for it. (My
recollection is that Documents is already fairly Google-specific, so
it's an obvious possibility.)

> It would need to have as much support for free providers like Owncloud or 
> Nextcloud.

I wasn't aware that Nextcloud has the concept of documents - I thought
it was all just "files". Do you have any ideas for what you want to do
here?

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Christopher Davis via desktop-devel-list]

Hey Allan,

As the new maintaner I would be against making Documents a Google Drive 
client, or at least
a Drive-specific one. It would need to have as much support for free 
providers like Owncloud or Nextcloud.


Chris

On Mon, Jan 21, 2019 at 9:31 AM, Allan Day  wrote:

Bastien Nocera  wrote:
...

 > We are currently in the 3.31.x / 3.32 development cycle. Once the
 > GNOME 3.32 release is done, starting from 3.33.1, I will be 
removing

 > the GNOME Documents specific integration points from GNOME Online
 > Accounts because we no longer encourage distributors to ship this
 > application as part of the default set.

...
 That also means that GNOME Documents is as good as dead if you do 
this,

 because the main use for it was to have a single point of entry for
 Cloud and local documents.


I've spent a fair while trying to figure out what the future is for
Documents and I haven't been able to come up with a good answer.
However, that doesn't mean I'm closed to the idea!

The key issue, I think, is what Michael alluded to in the other thread
- what the value proposition for Documents is. My feeling is that
aggregating local files and Google Docs isn't all that compelling.

My impression is that "documents" is quite an amorphous category,
which nowadays is often equated with "files". Documents was always
closely tied to Google Docs, but then Google Drive came out and that's
what people generally seem to care about nowadays.

Having a top-notch Google Drive client would be great and who knows,
maybe that's something that Documents could become? (Not sure how that
would relate to GVFS's Google Drive support though.)


 I think the release team is wrong in the first place. Lack of
 maintainership and bugs don't equate to removal. Otherwise there 
would

 be plenty more applications to remove there...


Yes I think we need a good UX vision and an understanding of the role
we want each app to play. Design obviously has a role to play in
communicating that, so I'm sorry if we haven't done that.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Christopher Davis via desktop-devel-list]

Hi Rishi,

Cloud documents is an important part of where I want to move forward 
with the application,

so Online Accounts integration would still be critical.

A file previewer is definitely a priority, and an editor could be 
considered.


Regards,
Chris

On Mon, Jan 21, 2019 at 9:03 AM, Debarshi Ray  
wrote:

Hey,

I hadn't expected this to garner so much interest!

Instead of replying to each message separately, I'll try to summarize
a few things into this message.

First of all, this thread doesn't have anything to do with GNOME
Books. It's a separate application and doesn't have any Online
Accounts integration whatsoever. Books shares the gnome-documents Git
repository with GNOME Documents, and that's all. I can't even find it
in gnome-build-meta, which is again a separate discussion:
  [rishi@kolache gnome-build-meta]$ git grep gnome-books
  [rishi@kolache gnome-build-meta]$

Second, "evince" is a lot of different things. It could mean:
* everything that's in evince.git
* the libevdocument3.so.4 and libevview3.so.3 APIs
* /usr/bin/evince - the thing that opens files from Nautilus
* /usr/bin/evince-previewer - this is used for the GTK print preview,
  as Emmanuele pointed out, and has NoDisplay=true
* /usr/bin/evince-thumbnailer

So, for some definition of "evince", GNOME Documents has a hard
dependency on it. Ideally, the evince Git repository would be split to
disambiguate some of these components as far upstream as possible,
instead of relying on the various downstreams to get their packaging
right. But that's also a separate discussion. :)

It's true that GNOME Documents was conceived as a way to seamlessly
access all files local and remote. In that sense, the Online Accounts
integration is crucial for it.

However, it has turned out to be more complicated than that.  I also
don't know how excited the GNOME designers are about GNOME Documents
today.

For various reasons, it doesn't stand any chance of adoption unless it
can open files like /usr/bin/evince.

"Documents" are also notoriously complicated, as compared to music,
photos or videos. For example, if somebody is working on a thesis,
then everything from graphs to PDFs to the textual LaTeX sources to
screenshots can be considered a document.  That's almost impossible to
accommodate within the current reality of GNOME Documents.

Lack of prior art. Every major OS out there has some equivalent of a
music, photos or videos application, but I haven't come across
anything like GNOME Documents with the possible exception of Google
Documents.

It's somewhat difficult to get people excited about, and is related to
the above point. It's much easier to get people excited about music,
photos or videos, because those are "fun", while documents are
"boring".  See how people go crazy about Google Photos at Google I/O,
or Instagram, etc.. I don't see that many people go crazy about their
PDF viewer.

So, can it be saved? Maybe; if we are willing to diverge from it's
original goals.

If somebody (hey, Christopher) wants to give GNOME Documents a fresh
lease of life, I think the addition of a file previewer has to be the
first priority. GNOME Documents supports a lot more formats than
Evince, so, done right, this could be an advantage. The widgets for
rendering ebooks, Evince and LibreOffice formats would need some
scrubbing for this.

Exploiting the capabilities of the LOKView widget, plus some work on
LibreOffice itself, could turn GNOME Documents into a sleek and
stripped down word processor. That's another idea.

Neither of these things require the Online Accounts integration,
though.

Cheers,
Rishi
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Germán Poo-Caamaño]

On Mon, 2019-01-21 at 14:03 +, Debarshi Ray wrote:
> Hey,
> 
> I hadn't expected this to garner so much interest!
> 
> Instead of replying to each message separately, I'll try to summarize
> a few things into this message.
> 
> First of all, this thread doesn't have anything to do with GNOME
> Books. It's a separate application and doesn't have any Online
> Accounts integration whatsoever. Books shares the gnome-documents Git
> repository with GNOME Documents, and that's all. I can't even find it
> in gnome-build-meta, which is again a separate discussion:
>   [rishi@kolache gnome-build-meta]$ git grep gnome-books
>   [rishi@kolache gnome-build-meta]$
> 
> Second, "evince" is a lot of different things. It could mean:
> * everything that's in evince.git
> * the libevdocument3.so.4 and libevview3.so.3 APIs
> * /usr/bin/evince - the thing that opens files from Nautilus
> * /usr/bin/evince-previewer - this is used for the GTK print preview,
>   as Emmanuele pointed out, and has NoDisplay=true
> * /usr/bin/evince-thumbnailer
> 
> So, for some definition of "evince", GNOME Documents has a hard
> dependency on it. Ideally, the evince Git repository would be split
> to disambiguate some of these components as far upstream as possible,
> instead of relying on the various downstreams to get their packaging
> right. But that's also a separate discussion. :)

So far, the only proposal or request I had seen is to build evince
without UI: https://gitlab.gnome.org/GNOME/evince/issues/1048
IIUC, the outcome would be the same.

> [...]
> "Documents" are also notoriously complicated, as compared to music,
> photos or videos. For example, if somebody is working on a thesis,
> then everything from graphs to PDFs to the textual LaTeX sources to
> screenshots can be considered a document.  That's almost impossible
> to accommodate within the current reality of GNOME Documents.

The thesis user case looks to me like a corner case, and Documents
might be noisy because its scope of broader than a thesis. In a thesis,
a challenging part is to keep all the references (mostly papers)
"together", and hopefully to manage them in a way that is easier to
search, and cite.

I think Documents should not bother with that, because then it would
need features (or subset of them) provided by tools like Mendeley. I
mean, other than searching text in a collection of documents.

-- 
Germán Poo-Caamaño
http://calcifer.org/


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Allan Day]

Bastien Nocera  wrote:
...
> > We are currently in the 3.31.x / 3.32 development cycle. Once the
> > GNOME 3.32 release is done, starting from 3.33.1, I will be removing
> > the GNOME Documents specific integration points from GNOME Online
> > Accounts because we no longer encourage distributors to ship this
> > application as part of the default set.
...
> That also means that GNOME Documents is as good as dead if you do this,
> because the main use for it was to have a single point of entry for
> Cloud and local documents.

I've spent a fair while trying to figure out what the future is for
Documents and I haven't been able to come up with a good answer.
However, that doesn't mean I'm closed to the idea!

The key issue, I think, is what Michael alluded to in the other thread
- what the value proposition for Documents is. My feeling is that
aggregating local files and Google Docs isn't all that compelling.

My impression is that "documents" is quite an amorphous category,
which nowadays is often equated with "files". Documents was always
closely tied to Google Docs, but then Google Drive came out and that's
what people generally seem to care about nowadays.

Having a top-notch Google Drive client would be great and who knows,
maybe that's something that Documents could become? (Not sure how that
would relate to GVFS's Google Drive support though.)

> I think the release team is wrong in the first place. Lack of
> maintainership and bugs don't equate to removal. Otherwise there would
> be plenty more applications to remove there...

Yes I think we need a good UX vision and an understanding of the role
we want each app to play. Design obviously has a role to play in
communicating that, so I'm sorry if we haven't done that.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

Hey,

I hadn't expected this to garner so much interest!

Instead of replying to each message separately, I'll try to summarize
a few things into this message.

First of all, this thread doesn't have anything to do with GNOME
Books. It's a separate application and doesn't have any Online
Accounts integration whatsoever. Books shares the gnome-documents Git
repository with GNOME Documents, and that's all. I can't even find it
in gnome-build-meta, which is again a separate discussion:
  [rishi@kolache gnome-build-meta]$ git grep gnome-books
  [rishi@kolache gnome-build-meta]$

Second, "evince" is a lot of different things. It could mean:
* everything that's in evince.git
* the libevdocument3.so.4 and libevview3.so.3 APIs
* /usr/bin/evince - the thing that opens files from Nautilus
* /usr/bin/evince-previewer - this is used for the GTK print preview,
  as Emmanuele pointed out, and has NoDisplay=true
* /usr/bin/evince-thumbnailer

So, for some definition of "evince", GNOME Documents has a hard
dependency on it. Ideally, the evince Git repository would be split to
disambiguate some of these components as far upstream as possible,
instead of relying on the various downstreams to get their packaging
right. But that's also a separate discussion. :)

It's true that GNOME Documents was conceived as a way to seamlessly
access all files local and remote. In that sense, the Online Accounts
integration is crucial for it.

However, it has turned out to be more complicated than that.  I also
don't know how excited the GNOME designers are about GNOME Documents
today.

For various reasons, it doesn't stand any chance of adoption unless it
can open files like /usr/bin/evince.

"Documents" are also notoriously complicated, as compared to music,
photos or videos. For example, if somebody is working on a thesis,
then everything from graphs to PDFs to the textual LaTeX sources to
screenshots can be considered a document.  That's almost impossible to
accommodate within the current reality of GNOME Documents.

Lack of prior art. Every major OS out there has some equivalent of a
music, photos or videos application, but I haven't come across
anything like GNOME Documents with the possible exception of Google
Documents.

It's somewhat difficult to get people excited about, and is related to
the above point. It's much easier to get people excited about music,
photos or videos, because those are "fun", while documents are
"boring".  See how people go crazy about Google Photos at Google I/O,
or Instagram, etc.. I don't see that many people go crazy about their
PDF viewer.

So, can it be saved? Maybe; if we are willing to diverge from it's
original goals.

If somebody (hey, Christopher) wants to give GNOME Documents a fresh
lease of life, I think the addition of a file previewer has to be the
first priority. GNOME Documents supports a lot more formats than
Evince, so, done right, this could be an advantage. The widgets for
rendering ebooks, Evince and LibreOffice formats would need some
scrubbing for this.

Exploiting the capabilities of the LOKView widget, plus some work on
LibreOffice itself, could turn GNOME Documents into a sleek and
stripped down word processor. That's another idea.

Neither of these things require the Online Accounts integration,
though.

Cheers,
Rishi
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Debarshi Ray]

On Thu, Jan 17, 2019 at 10:38:50AM -0500, Jeremy Bicha wrote:
> Similarly, Todoist support was dropped from GOA 3.32.
> 
> https://gitlab.gnome.org/GNOME/gnome-online-accounts/commit/bf77325d8
> 
> The commit message has a few mistakes: the Recipes app does not yet
> have its own Todoist support.

[rishi@kolache recipes]$ git grep -i todoist src | wc -l
43

Select a recipe
-> Buy ingredients
-> View shopping list
-> Share
-> Add service
-> Todoist

> And it's wrong to say that GNOME To Do
> does not follow the GNOME release schedule.

https://download.gnome.org/sources/gnome-todo/3.91/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Jeremy Bicha]

On Thu, Jan 17, 2019 at 10:25 AM Bastien Nocera  wrote:
> On Thu, 2019-01-17 at 15:17 +, Debarshi Ray wrote:
> > It's been a month since GNOME Documents was removed from the set of
> > core utilities by the release team. See:
> > https://gitlab.gnome.org/GNOME/gnome-build-meta/merge_requests/157
> >
> > We are currently in the 3.31.x / 3.32 development cycle. Once the
> > GNOME 3.32 release is done, starting from 3.33.1, I will be removing
> > the GNOME Documents specific integration points from GNOME Online
> > Accounts because we no longer encourage distributors to ship this
> > application as part of the default set.
> >
> That also means that GNOME Documents is as good as dead if you do this,
> because the main use for it was to have a single point of entry for
> Cloud and local documents.

Similarly, Todoist support was dropped from GOA 3.32.

https://gitlab.gnome.org/GNOME/gnome-online-accounts/commit/bf77325d8

The commit message has a few mistakes: the Recipes app does not yet
have its own Todoist support. And it's wrong to say that GNOME To Do
does not follow the GNOME release schedule.

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Bastien Nocera]

On Thu, 2019-01-17 at 15:17 +, Debarshi Ray wrote:
> Hello everybody,
> 
> It's been a month since GNOME Documents was removed from the set of
> core utilities by the release team. See:
> https://gitlab.gnome.org/GNOME/gnome-build-meta/merge_requests/157
> 
> We are currently in the 3.31.x / 3.32 development cycle. Once the
> GNOME 3.32 release is done, starting from 3.33.1, I will be removing
> the GNOME Documents specific integration points from GNOME Online
> Accounts because we no longer encourage distributors to ship this
> application as part of the default set.
> 
> Have a nice day & happy hacking,

That also means that GNOME Documents is as good as dead if you do this,
because the main use for it was to have a single point of entry for
Cloud and local documents.

I think the release team is wrong in the first place. Lack of
maintainership and bugs don't equate to removal. Otherwise there would
be plenty more applications to remove there...

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Christopher Davis via desktop-devel-list]

As asked on the fedora issue, will this mean that cloud documents will 
no longer be available within the app?


Regards,
Chris

On Thu, Jan 17, 2019 at 10:17 AM, Debarshi Ray  
wrote:

Hello everybody,

It's been a month since GNOME Documents was removed from the set of
core utilities by the release team. See:
https://gitlab.gnome.org/GNOME/gnome-build-meta/merge_requests/157

We are currently in the 3.31.x / 3.32 development cycle. Once the
GNOME 3.32 release is done, starting from 3.33.1, I will be removing
the GNOME Documents specific integration points from GNOME Online
Accounts because we no longer encourage distributors to ship this
application as part of the default set.

Have a nice day & happy hacking,
Rishi
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list