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

[Milan Crha via desktop-devel-list]

On Wed, 2019-01-23 at 15:21 -0500, Jeremy Bicha wrote:
> 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.

Hi,
users can configure accounts directly in Evolution, and to get close to
GOA, or maybe even a bit further than GOA, so-called Collection
Accounts (Edit->Accounts->Add->Collection Account) can be configured,
which work similarly as those connected to GOA.

The evolution(-data-server) doesn't auto-add accounts non-
working/removed from GOA. I would not do it.
Bye,
Milan

___
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

[Emmanuele Bassi via desktop-devel-list]

On Wed, 23 Jan 2019 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
>
>
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. To be honest, I think it
was a bad idea not to provide a proper platform for this kind of
integration for third party applications and let people reimplement things
in their own silos; but given the constant lack of resources to the
platform, the lack of commitment never actually surprised me.

In any case, I'm not objecting to the rationale at all, nor at removing
Documents, or removing the Documents integration with GOA.

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.

There's no point in calling it "GNOME Documents" if it's not a) part of
core and b) integrated with the facilities GNOME provides to its core
applications.

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

I didn't say it was malicious. I said it wasn't honest in the sense that
we've spent the whole thread justifying dropping Documents, and picking up
a new maintainer, and nobody explicitly communicated the fact that if you
want to work on Documents from now on you'll be doing it as a third party
developer, because there's no integration within GNOME any more.

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