Re: I believe we should reconsider our sys-tray removal
I agree with Britt. In Endless we currently ship an in-tree copy of TopIcons, but this won't fly in a Wayland world, so we're considering what to do in future. On Mon, 25 Mar 2019, at 11:20, Emmanuele Bassi via desktop-devel-list wrote: > Sadly, this means a complete API change, which makes the point moot: > applications would need to be changed. > > […] > > The appindicator API/StatusNotifier specification comes close to this, but: > > - [… several major shortcomings …] For another example off the top of my head, the spec at https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/StatusNotifierItem/ says that apps should register a name of the form “org.freedesktop.StatusNotifierItem-PID-ID”, which in a Flatpak world means allowing the app to own any name in the “org.freedesktop.*” namespace. On the other hand: this API under its various names is already widely-supported both by (non-GNOME) apps, and by widely-used desktop environments – a virtuous cycle. In particular, several third-party, non-free apps like Dropbox which are partially or totally unusable without a status notifier already support it. (Not to make this all about Dropbox – it's just an app I use that falls into the "totally unusable" category.) I'm sure it's not as simple as "copy https://github.com/ubuntu/gnome-shell-extension-appindicator into the gnome-shell tree" – though it seems to work fine after a few days' testing – but supporting and improving this API would at least mean that many existing apps would behave as intended by their developers without needing to be changed (immediately). > >> Permanently adding the extension code to the shell (which, if I've >> undesrtood properly, "moves" icons from tray to topbar) will be a dirty but >> effective solution. > > Which would achieve nothing except, once again, shoving icons and menus into > one of the most important pieces of screen real estate we have just because > some application developers simply cannot live without their application > icons being visible at all times. If you want to do that, use the extension. > It's there for a reason. The problem with the extension route is that it shifts the burden onto each individual user (assuming app developers don't redesign their apps to remove the indicators, which many haven't, and assuming distributors don't intervene as described by Britt). If Shell supported indicators out of the box, then there would be two cases: 1. user doesn't use any apps which show indicators: great, no junk on the panel. 2. user does: their panel has some icons on it. (Ideally, some mechanism would exist for them to be disabled just like Settings → Notifications.) If there were a blessed extension, the two cases would be: 1. they don't use any apps which show indicators: great, no junk on the panel. 2. they do: these apps don't work properly. Each user has to independently discover that an extension exists; they enable it and now their apps work. The status quo is: 1. they don't use any apps which show indicators: great, no junk on the panel. 2. they do: these apps don't work properly. Each user has to independently discover that many different extensions exist which purport to make their apps work, decide which one to use, and enable it. A blessed extension in gnome-shell-extensions would be an improvement but I don't really see the advantage of not enabling it by default. > The tray icons were designed and meant for system status notifications: > network state connectivity, volume level, battery level, IM status (when it > was a thing). They were hijacked by application developers to have panel > applets that would work across desktop environments. It was a bad idea then, > and nothing has changed in that regard. I agree that status icon proliferation is a bad experience, but they exist and apps rely on them being shown. Perhaps a design similar to what Chromium does with extensions, where icons overflow into the hamburger menu, could be a reasonable compromise. – Will___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On Tue, 15 Jan 2019, at 10:04, Bastien Nocera wrote: > On Tue, 2019-01-15 at 10:58 +0100, Emilio Pozuelo Monfort wrote: > > It should still be easy to fork the project, push a branch to your > > namespace, > > and then submit a MR. Or did I misunderstand? > > Too many trips to the web browser, too many re-clones of the repo (or > esoteric git command-lines), and too many left-over repos in your own > namespace. It's a problem I have with github as well, it's the same > workflow. I have found the 'hub' and 'lab' tools very useful for avoiding trips to the web browser. https://github.com/github/hub https://github.com/zaquestion/lab ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git submodules vs translators
On 28/06/13 01:01, Colin Walters wrote: Any other thoughts? Last time I accidentally reverted a submodule update, I took a look at the recently-added 'git subtree' as a possible replacement. I haven't actually tried it in practice, and perhaps it would just replace one set of confusing gotchas with another, but I'm pretty sure it resolves this problem of having to remember to run 'git submodule update' after every pull. (Not to be confused with the subtree merge strategy: see http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/ for an introduction.) Irrespective of technology, ideally one wouldn't have to care about embedded libraries unless one is actually working on code that actually uses them, whereas right now everyone has to care or risk breaking the build. -- Will ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Redesign Gnote as Notes?
On 21/05/12 14:02, Richard Hughes wrote: On 21 May 2012 13:48, Matthias Clasenmatthias.cla...@gmail.com wrote: Thanks for considering the new design. I would really love to see gnote move towards that, so that the many happy gnote users can remain happy in GNOME 3. Yes, I'm a heavy gnotes user and would also appreciate the gnotes codebase being transformed into notes. On a related topic, I'll buy the person who makes my notes searchable from the shell several beers. That would be Casey Harkins: https://github.com/charkins/gnome-shell-extension-notesearch works with both Gnote and Tomboy. (As the README says, it would be nice if Gnote and Tomboy implemented this themselves.) -- Will ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
On 13/05/11 15:20, David Zeuthen wrote:
So my current experiments [1] actually reflect this thinking .. in
fact, right now I'm working on the Mail experience, basically trying
to implement something like these mockups
https://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Email
For that, I have code (hundreds, not thousands of LOC) in the Shell
that talks to this interface exported by GOA
http://people.freedesktop.org/~david/goa-20110512/gdbus-org.gnome.OnlineAccounts.Mail.html
http://people.freedesktop.org/~david/goa-20110512/gdbus-org.gnome.OnlineAccounts.Mail.Query.html
It works great, see
http://people.freedesktop.org/~david/mail-notif-1.png
http://people.freedesktop.org/~david/mail-notif-2.png
http://people.freedesktop.org/~david/mail-notif-3.png
How is this implemented at the network level? Ah, I just found the footnote:
[1] : Emphasis on _experiment_ here.. for production use, maybe we
should use the IMAP client code from Evo instead of the simple
hand-rolled IMAP client that I put together in a couple of days. Then
again, I don't know.
More on this story later in this mail, but: out of interest, were you
aware that Telepathy already supports mail notifications on (off the top
of my head) Google Talk, Yahoo!, MSN and AIM?
http://telepathy.freedesktop.org/spec/Connection_Interface_Mail_Notification.html
I was thinking of adding a method such on the
org.gnome.OnlineAccounts.Mail interface like this
GetAuthenticatedImapConnection (OUT h file_descriptor);
GetAuthenticatedSmtpConnection (OUT h file_descriptor);
that your mail application can use. For Chat, my thinking is that we
could have something similar e.g.
GetAuthenticatedXmppConnection (OUT h file_descriptor);
that Telepathy can use. Does that sounds OK?
No, not really.
To check I'm not misunderstanding: you're proposing that Gabble
(Telepathy's XMPP backend), rather than using its XMPP library to open a
connection to the server, would call out to GOA, which would have its
own implementation of the XMPP session initiation, certificate checking,
authentication, etc. code; once the session is established, GOA would
hand back an FD which Gabble would have to assume was in the right state
to pick up right after the authentication step?
This doesn't sound like a good idea to me at all. Do you really want to
bake detailed knowledge of all these disparate protocols into GOA?
Surely it makes more sense to keep the generic IMAP and SMTP code in the
mail client, the XMPP code in the XMPP service—and by inevitable
extension, the AIM code in the AIM service, etc.?
File descriptor passing is cool and all, but I really don't think it's
appropriate here for (say) the XMPP connection. Establishing a session
is not actually trivial (and in the future it could get even less
trivial—for example, we might want to support BOSH
http://en.wikipedia.org/wiki/BOSH). But in any case, it's already been
implemented, with the necessary hooks to plug into GOA for the SASL
authentication step already in place. These hooks have been used to
integrate with GOA-esque services (including Bisho on MeeGo Netbook, and
libaccounts and signon, and of course Gnome-Keyring) without needing to
include knowledge of all N keyring implementations in all M
protocol-specific Telepathy backends.
For what it's worth, this is what the Telepathy D-Bus API for SASL looks
like:
http://telepathy.freedesktop.org/spec/Channel_Interface_SASL_Authentication.html.
From my brief research into the world of IMAP, I think something similar
could be done there too. So then GOA's Google backend would understand
the custom SASL mechanisms Google uses on various protocols, but would
not need any details of the protocols themselves.
Anyway, how we balance where to put implementations is a very hard
question that I'm still thinking about. I'm leaning towards
- For every service type (Mail, Calendar, etc.) should provide a
simple interface that the Shell can use for notification
- One example is the org.g.OA.{Mail,MailQuery} interfaces
If the user's connected to Google *anyway* for XMPP, it makes sense to
use the XMPP mail notifications, rather than maintaining a separate
connection. Ditto IMAP and Evolution. (Inevitably there will be services
where the IM protocol doesn't do mail notification: I guess Facebook is
a likely example here.)
Having some kind of commonality between the different sources of mail
notifications would be a big win for the Shell, of course. It would be
great for it not to have to care whether the notifications were
piggy-backing on an IM protocol, on an IMAP IDLE session, or anything else.
But: I think this would be best achieved by having Evolution, Telepathy,
etc. implement a common API the Shell can monitor (or push their
notifications into GOA, so the Shell can listen to that), rather than
moving non-authentication-related network protocol code into GOA.
- but it could also be that a provider
Re: Online Accounts panel for 3.2
On 16/05/11 18:20, David Zeuthen wrote:
Hi,
On Mon, May 16, 2011 at 12:55 PM, Will Thompson
will.thomp...@collabora.co.uk wrote:
that your mail application can use. For Chat, my thinking is that we
could have something similar e.g.
GetAuthenticatedXmppConnection (OUT h file_descriptor);
that Telepathy can use. Does that sounds OK?
No, not really.
That's fine and, sure, in retrospect probably easiest if GOA doesn't
get involved with XMPP. I was mostly thinking out loud. And I was just
under the impression that you actually asked for GOA to make things
easier here.
Ah! My suggestion was, concretely: rather than
method GetGoogleToken() → s
method GetFacebookToken() → s
method GetOAuthToken() → s
GOA could have either an API which resembles SASL, or…
http://telepathy.freedesktop.org/spec/Channel_Interface_SASL_Authentication.html
I don't think GOA needs to know about such interfaces at all - we just
hand you either the OAuth (or OAuth2) token and you can do this
yourself, yes?
… (thinking out loud) GOA could have a simple API for the degenerate
custom SASL mechanisms like X-GOOGLE-TOKEN where the client provides (a
hash of) the token when telling the server it's selected a mechanism,
and the server says yes or no:
property SupportedMechanisms: as
method GetToken(s: Mechanism) → s
Given that GOA already knows the account type etc., it already knows
what kind of mechanisms are appropriate. This would let the Telepathy
GOA plugin avoid needing specific knowledge of each custom XMPP server,
at the cost of GOA itself's providers knowing a little more than just
OAuth2, but not much: X-GOOGLE-TOKEN, for example, is (IIRC) sha1('\0' +
username + '\0' + token), which is to say SASL PLAIN.
One thing to be aware of is that GOA might change a
provider from e.g. OAuth 1.x to OAuth 2.x at any point (for example,
Google appears to be switching to OAuth 2.0 but not all services have
been switched over yet) - so we just need to ensure that whatever ends
up interacting with GOA is ready for such a change.
Right. We have GNOME releases as kind of built-in synchronisation
points, I suppose. This might also affect things like libsocialweb more
acutely?
I'm not sure this is really an optimization that is worth it - it
seems to really muddy the picture a lot and I can imagine a future
where we allow the user to choose what GMail labels to notify for -
not sure how this would work with XMPP.
Good point. In any case: it's there if we want Hotmail/Yahoo!/other
webmail notifications with relatively effort.
But: I think this would be best achieved by having Evolution, Telepathy,
etc. implement a common API the Shell can monitor (or push their
notifications into GOA, so the Shell can listen to that), rather than
moving non-authentication-related network protocol code into GOA.
Sure, ideally GOA would only be concerned about dishing out tokens and
not care about getting involved in the actual protocol used for each
service. And with Telepathy it looks like it could work well.
Yup: great.
But for Mail and Calendar I'm not so sure - so that's why I'm adding
very simple interfaces to GOA that the shell can use for mail
notifications and calendaring in 3.2 (As a side-effect, this gives you
Mail notifications and Shell calendaring functionality even when Evo
is not installed). Once we have a good story for Mail and Calendar in
place, we can easily move it there.
I'd actually forgotten I had my calendars configured in Evolution until
I saw the beautiful agenda panel in the shell. :)
Cheers,
--
Will
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Belatedly,
On 02/05/11 14:14, David Zeuthen wrote:
The workflow in an app (such as Evo) would be like this
accounts = goa.get_accounts_of_type('mail')
for a in accounts:
if a is OAuthBased:
(oauth_access_token, oauth_access_token_secret) =
a.OAuthBased.GetAccessToken()
elif a is OAuth2Based:
oauth2_access_token = a.OAuthBased2.GetAccessToken()
elif ...
if a is GoogleAccount:
use API from http://code.google.com/apis/gmail/
with one of the credentials you got above
elif a is YahooAccount
use API from http://developer.yahoo.com/mail/
with one of the credentials you got above
elif ...
For example, for GMail, you can use the OAuth token when
authenticating the IMAP and SMTP connection cf.
http://code.google.com/apis/gmail/oauth/
This big-switch-statement-in-every-application approach concerns me: it
would be better to essentially delegate the SASL exchange to GOA. Doing
so would minimize the number of components that need to be updated to
support a new custom authentication mechanism for an otherwise standard
protocol. Obviously I'm going to use Telepathy and XMPP for an example
of why :), but I think the same reasoning holds for IMAP, based on that
link above, and other services.
Google Talk is just another XMPP server that happens to support an
X-GOOGLE-TOKEN SASL mechanism. Facebook is just another XMPP server
which supports an X-FACEBOOK-PLATFORM mechanism. Gabble (the XMPP
backend for Telepathy) doesn't implement either mechanism: it just
exposes the SASL challenge over D-Bus. Empathy has a client for that API
that uses gnome-keyring to get the password; on MeeGo Netbook there's a
client that implements X-FACEBOOK-PLATFORM. In a GOA world, we'd ideally
like to avoid the handler having to have a big switch statement for
every supported account type: GOA already has Google-specific code, and
it already knows that this account is a Google account, so it could
implement the X-GOOGLE-TOKEN mechanism in the Google-specific code there.
Then, to support a hypothetical Flickr XMPP/IMAP/c service with
X-PICTURES-OF-CATS authentication, we'd only have to add Flickr code to
GOA; we wouldn't have to touch the authentication code in Evolution or
Telepathy.
(This is one beef I have with Nokia's Signon framework: the Telepathy
bridge for that has to have a big switch statement for each supported
account type, on top of the account type-specific plugins for signond.
It would be nice to not repeat that.)
Cheers,
--
Will
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On 19/04/11 10:39, Alexander Larsson wrote: On Tue, 2011-04-19 at 09:53 +0100, Philip Withnall wrote: Empathy uses the “text/individual-id” and “text/persona-id” drag targets for dragging and dropping folks individuals and personas. Shouldn't you be using x-something for nonstandard types like these? Anyway, we'd need to add corresponding support to evolution too. Also, i think the current evolution contacts dialog dnds a vcard, which seems like a good thing to do too. Pidgin supports dragging and dropping application/x-im-contact and text/x-vcard. Obviously it's unlikely that anyone will ever dnd between Pidgin and Empathy, but it would be nice if Empathy supported these MIME types for interoperability with hypothetical other apps that speak these formats. (Perhaps Evo already understands both? I can't think where else x-im-contact would be used.) Cheers, -- Will ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.2 ideas and plans
On 22/03/11 16:13, Alexander Larsson wrote: It would be nice to have some level of integration with web applications in the desktop. For instance, I would like to update my facebook status or tweet easily via the user status menu in the shell. I would also like facebook message notification with the message tray, and facebook chat support. You should get the last item for free: Telepathy already supports Facebook Chat. Regards, -- Will ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.2 ideas and plans
On 22/03/11 16:39, Bastien Nocera wrote: As Will mentioned, those should be supported through Telepathy already. A clarification: Facebook doesn't expose their email-like messages over XMPP, so those are not supported through Telepathy's mail notification system. But the chat stuff should work. -- Will ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
