Re: Is libgd still a thing?

[Allan Day]

Emmanuele Bassi via desktop-devel-list  wrote:
...
>  - nautilus
>  - evince
>  - totem
>  - gnome-photos
>  - gedit

In terms of the platform, we're working to consolidate around
libhandy/libadwaita. That's what the new HIG documents, and is what
we're trying to constrain ourselves to on the design side. So it would
be interesting to know what these apps are using libgd for, and
potentially track what needs to be done to migrate them away from it.
I think that it would be beneficial to have our core apps use the same
platform that we make available to 3rd parties.


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

Re: Fonts Has Two New Maintainers

[Allan Day]

Christopher Davis  wrote:
...
> As of today, Evan Welsh and I are taking on the role of maintainer for Fonts 
> (gnome-font-viewer).
> Cosimo Cecchi has been inactive as of late, and Evan and I are both 
> interested in keeping fonts
> functional and up-to-date.

Fantastic news! Thanks for stepping up, Chris and Evan!

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

Re: New GNOME Account password reset tool is live!

[Allan Day]

Andrea Veri  wrote:
...
> the GNOME Infrastructure is making available a new web based tool that will 
> help you resetting your account password in case it was lost. As many of you 
> know, the current way of updating your password was running a command on your 
> terminal making sure your SSH key was up-to-date with the one we have on our 
> systems. That was creating a barrier to contributors which aren't comfortable 
> using a terminal, SSH or other developer oriented toolings. The new solution 
> will ease the process and remove the need of utilizing a console and/or 
> owning an SSH key.

Awesome! Will this allow us to phase out SSH keys for LDAP accounts
and foundation memberships? (I thought I'd filed a ticket for that but
may have dreamt it.)

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

Official proposal for defining GNOME software

[Allan Day]

Hi everyone,

The Board of Directors has been working on some new arrangements for
how GNOME's software is classified and defined. I've described the
proposal over on Discourse, and it would be great to get comments and
feedback:

https://discourse.gnome.org/t/official-proposal-how-we-define-gnome-software/3371/

Thanks,

Allan
-- 
Chair & Vice-President, GNOME Foundation Board of Directors
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: System-wide dark mode

[Allan Day]

Matthias Clasen  wrote:
>> ... We can't implement that without design changes in GTK since
>> for that we need the ability to *very quickly* switch between different
>> themes in the same process, and that's currently too slow.
>
>
> Unlikely to change, tbh. If your theme is loading too slowly, it is too big...

If the size of the theme is the issue, do we know what size is acceptable?

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

Re: System-wide dark mode

[Allan Day]

 wrote:

> On Wed, May 29, 2019 at 8:35 AM, Allan Day  wrote:
> > Therefore, before we get too far into planning and implementing this
> > feature: does anyone know of any serious obstacles they'd face, if we
> > were to support a dark mode?
>
> WebKit is having trouble with this now:
>
> https://bugs.webkit.org/show_bug.cgi?id=126907
>

How does this relate to the dark mode in WebKit?

I was hoping that Web would follow the system-wide dark mode preference,
and expose it to websites...

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

System-wide dark mode

[Allan Day]

Hi everyone,

Whether you love dark modes or hate them, they're becoming fairly
ubiquitous nowadays, and I think that it's time for GNOME to seriously
think about having one of its own.

If we were to support a system-wide dark preference in GNOME, the
implication is that we'd generally support it: the desktop and the core
apps would be expected to use a dark variant of the theme when it is
selected by the user. Therefore, before we get too far into planning and
implementing this feature: does anyone know of any serious obstacles they'd
face, if we were to support a dark mode?

If you're responsible for any core GNOME UI, you can test this by setting
the Adwaita-dark theme in Tweaks.

Thanks,

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

Please run for the board!

[Allan Day]

Hi everyone,

In case you didn't notice, we've had to extend the deadline for the GNOME
Foundation Board of Directors elections, because not enough candidates put
themselves forward.

Please consider running in the elections. Being on the board is actually
quite nice. It's also a great way to see the project from a high level, and
to develop new skills and expertise.

The revised deadline for candidates is 2nd June, and instructions on how to
put yourself forward can be found here [1].

Thanks,

Allan
-- 
[1]
https://mail.gnome.org/archives/foundation-announce/2019-April/msg2.html
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Good read from a new GNOME user

[Allan Day]

Thanks Britt for starting this discussion, and thanks to Carmen for
the useful summary. I don't agree with every point raised, but there
are a lot of valid ones.

I'll provide some brief comments from a design perspective. Obviously
there are a lot of issues here: individual discussions should probably
happen elsewhere.

Carmen Bianca Bakker  wrote:
...
> 1. The desktop does nothing. There is no functionality other than on
> the top bar. ...

This is a long-known issue that was discussed around the time of the
original GNOME 3 designs, and is currently being discussed again by
the design team [1]. It's a tricky issue that's the result of some of
the core GNOME 3 design choices.

...
> 2b. No battery percentage on status bar.

I'd be interested in showing the percentage when the status menu is
open [2], but having an option to permanently show it seems fine too
[3].

> 2c. No app indicators.

Yes, I think we need to return to that discussion.

> 2d. No suspend button.

I agree we can improve this, and I did some design work for it a
little while ago [4].

> 3a. It is difficult to reach the app drawer.

I've explored this previously; it's a bit tricky and depends on some
other more fundamental questions (do we have dock, what do we show in
the top bar, etc).

> 3b. Application names are cut off.

This is a long-standing issue which I believe has a design agreed. We
just need to land the MR [5].

> 3c. Folders in the app drawer aren't customisable.

We've been wanting to have Endless's drag and drop app folders
upstreamed for some time now: we're just waiting for it to happen.

> 4. Unnecessary notifications (e.g., "Application is ready")

Indeed, my feeling is that those notifications do more harm than good.
I can't see an issue for this; does anyone know of one?

...
> 5b. Icons in Nautilus are confusing.

That doesn't look like GNOME's icon theme - it would be clearer if it
was. My understanding is that the lack of tooltips is a technical
limitation of popover menus.

On a related topic: the design team is currently evaluating these
buttons in menus, and are waiting on the menus to be updated in order
to do some usability testing [6].

> 5d. The file picker isn't very good.

I did a review of our file picker a little while ago [7] and it
generally looked OK to me. The main issue seems to be the lack of icon
view, which I agree would be good to have, and have included in my
latest experimental mockups.

...
> 8b. Difficult to set custom wallpaper.

The latest designs [8] have a button to select a file. However, I
think we'd like to revisit these designs before anything gets
implemented, and they've been stuck in our design backlog for a little
while.

A concluding remark: quite a few of these issues relate to the shell,
and on the design side we've wanted to make improvements in that area
for a long time, but have been held back due to a lack of developer
resources. It would be amazing if we had more developers working in
that area, to help us resolve these prominent issues.

Allan
-- 
[1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/1216
[2] https://gitlab.gnome.org/GNOME/gnome-shell/issues/1241
[3] https://gitlab.gnome.org/GNOME/gnome-control-center/issues/481
[4] https://gitlab.gnome.org/GNOME/gnome-shell/issues/270
[5] https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/109
[6] 
https://discourse.gnome.org/t/gtk-support-for-gnome-design-patterns/551/20?u=allanday
[7] https://wiki.gnome.org/Design/OS/FileSelection#Tentative_Design
[8] https://wiki.gnome.org/Design/SystemSettings/Background#Tentative_Design
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: I believe we should reconsider our sys-tray removal

[Allan Day]

Hi Britt,

Just commenting on the parts I have answers to...

Britt Yazel  wrote:
...
> 2) Back in early GNOME3 we had the slide up tray from the bottom. Am I the 
> only one who thought that was super cool? It had nice big icons for touch and 
> accessibility purposes, and it was just really cool looking imo. I was sad 
> when that went away for usability reasons. Is there any chance on 
> resurrecting that and polishing it's usability issues as a solution?

I thought the tray was cool too! Unfortunately, we could never get it
behave reliably for everyone (and we really did try). I think this was
mostly a combination of variable hardware and the ergonomics of
exerting pressure on the bottom screen-edge. We also had ongoing
issues with the position of the notifications at the bottom of the
screen: people didn't notice them.

> 3) realistically what are the chances of us working with the other interested 
> parties and creating a functional/unified spec once and for all. We could do 
> the whole Mantle-->Vulkan transition with appindicator-->XDG-appicon or 
> something of the sort. My dream is to create a solution for everyone, not 
> just GNOME

The challenge with doing anything new is adoption. One of the main
issues we face with status icons today is the long tail - all those
old apps that don't follow upstream all that closely (if at all).
Getting all of those on a new protocol is unlikely to happen.

A more general comment: back when we last made changes to status
icons, we had a two-part strategy:

 1. Push libcloudproviders as the way for apps like Dropbox to integrate
 2. Make sure there was a well-publicised, well-functioning extension
for when people do need status icons

Unfortunately it seems like 1 hasn't really happened, and poking
around this morning I couldn't find a single functioning extension for
status icons. So there's that. :(

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

Re: I believe we should reconsider our sys-tray removal

[Allan Day]

Link Dupont  wrote:
...

>  Is there a place
> in the System menu (the top-right corner menu) where these application
> icons + menus could live? The GSConnect extension adds an entry there.
>
...

Unfortunately, GtkStatusIcon is limited in what it allows us to do: you
can't embed the icons in another place like this.

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

Re: I believe we should reconsider our sys-tray removal

[Allan Day via desktop-devel-list]

Hey Britt,

Britt Yazel  wrote:

>
> I want to re-poen an old argument now that we have seen the effects of
> removing the sys-tray/app-indicator tray for well over a year. In short,
> the users are not happy.
>

As I recently wrote on GitLab [1], I'm open to re-evaluating this from a
design perspective. However, I think we'd need a different implementation
from GtkStatusIcon, and to my knowledge acceptable alternative isn't
available.


> I believe our goals of putting pressure on application developers to ditch
> the antiquated app-indicator model fell mostly on deaf ears
>

The goal was never to force app developers to do anything, and they can
include a status indicator if they want. It's just that it won't be shown
by default. If you haven't seen it, I wrote a lengthy account on my blog
[2].


> An example of this biting us in the arse is that with 3.32 TopIcons is
> causing the CPU usage to run through the roof, and people are blaming the
> Shell for the CPU usage, not the extension, leaving our users with a bad
> taste in their mouths.
>

Can we can do a better job at sign-posting which extension people should
use?

Allan
-- 
[1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/1014#note_457856
[2] https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

[Allan Day]

On Mon, 18 Feb 2019 at 15:53,  wrote:
...
> I suggest we don't continue to willfully violate Google's terms of
> service now that the issue has been brought to our attention. The only
> reasonable option seems to be to shut down our Google integration. Not
> just from g-o-a, but also the Safe Browsing support in Epiphany.

I don't think it's a good idea to speculate about terms of service
like this (nor is it a great idea to discuss legal issues on a public
mailing list!) There may well be grey areas involved, and it's
probably best to get legal advice.

Until we know more, let's not throw dramatic suggestions around. The
original post in this thread still stands.

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

Clarifications regarding GNOME Online Accounts

[Allan Day]

Hi all,

Recently there has been quite a lot of debate on this mailing list
about GNOME Online Accounts. Debarshi (the Online Accounts maintainer)
and I wanted to clear up any confusion that might have resulted from
that discussion, and clarify exactly what the situation is with Online
Accounts today, as well as what is being planned for the future.

Right now, there is only one change planned for Online Accounts. This
is the removal of the “documents” source type, which is being planned
for GNOME 3.34 (due for release in September 2019). As far as we are
aware, the only application that will be affected by this change is
GNOME Documents.

The “documents” source type is primarily used by GNOME Documents to
access Google Drive. It is one of two methods through which Google
Drive can be accessed. The other is the “files” source type, which is
the more widely used of the two, and which is going to continue to be
supported.

GNOME Documents is able to use the “files” source type as an
alternative to the documents type, and can be converted so that it can
continue to access Google Drive [1].

The “documents” source type is also used by GNOME Documents to access
Microsoft OneDrive, and there is no replacement planned for this.
However, the existing OneDrive support isn’t in fantastic shape (it
uses of an old API and has only received very minimal maintenance), so
we only see this as a minor regression..

There are no plans to retire any of the other source types.

That’s the main substance of what has been proposed recently: there is
one proposed change for GNOME 3.34, which we think will only affect a
single application.

The other aspect of GNOME Online Accounts that has been discussed is
which applications it can be used by. Strictly speaking, GNOME Online
Accounts has only ever been intended for use by GNOME applications.
The reason for this is simple: any app using GNOME Online Accounts
uses GNOME’s API keys to access online services. In order to ensure
that those keys continue to work, we have to conform to service
providers’ terms and conditions, and that means restricting access to
only our own software.

If this is news to you, then we are genuinely sorry. Effort was put
into communicating the role of GNOME Online Accounts (it’s documented
on the wiki [2], and there has been a blog post [3], and we’ve tried
to have conversations with developers about it when necessary), but
this clearly wasn’t enough, and we should have done a better job.
We’re going to add details to the API docs so the guidelines are
better advertised in the future [4].

We also want to emphasise that there are no plans to enforce the
existing policy around which apps can use GNOME Online Accounts. As
far as we are concerned, GNOME Online Accounts will continue to
function as it has done since it was first introduced.

If your application already uses GNOME Online Accounts, it can
continue to do so. If you are currently in the process of adding
Online Accounts support to an application, or are interested in adding
it, then you can continue to work on it, although we would encourage
you to get in touch with Debarshi, if you haven’t already.

We realise that this does not provide complete clarity around GNOME
Online Accounts, and this is something that we will work towards
during the next development cycle (3.33.x). Having discussed this,
we’ve identified three things that will be needed:

 - A clear framework for defining “GNOME software”. This isn’t
something we can provide ourselves, but we understand that the GNOME
Foundation is working on it.
 - A technical design for managing access to online accounts,
particularly for sandboxed applications.
 - An updated design for the Online Accounts service, which will
follow on from an evaluation of potential architectures [5].

If anyone wants to participate in these lines of enquiry, you’d be very welcome.

Once we have a proposal we’ll present it for feedback and discussion.
If new arrangements do come into effect, there will be plenty of
advance notice, and we’ll do our best to provide migration paths
should they be necessary.

We hope that this helps to clarify where we are today, and we hope
that it goes some way to addressing concerns that people might have.
We’re happy to answer any questions, either here or privately.

Many thanks,

Allan
-- 
[1] https://gitlab.gnome.org/GNOME/gnome-documents/issues/34
[2] https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals/
[3] https://debarshiray.wordpress.com/2012/10/06/goa-why-it-is-the-way-it-is/
[4] https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues/44
[5] https://wiki.gnome.org/Design/OS/OnlineAccounts/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.32 milestone review

[Allan Day]

Bastien Nocera  wrote:
...
> > Regarding the app menu retirement initiative, the lack of progress on
> > Totem [1] is also a concern.
>
> I already said this was on my todo list though.

Ah great, I hadn't realised. Thanks Bastien!

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

Re: GNOME 3.32 milestone review

[Allan Day via desktop-devel-list]

Great initiative, Carlos!

Carlos Soriano  wrote:
...
> gnome-screenshot, retire app menu - Part of the GNOME initiative to remove 
> app menus. There is a MR, needs some review. Deadline 4th February, UI freeze.

The thing we're missing here is participation from a maintainer. Is
gnome-screenshot actually maintained nowadays? If not, can assign a
new maintainer?

Regarding the app menu retirement initiative, the lack of progress on
Totem [1] is also a concern.

Allan

[1] https://gitlab.gnome.org/GNOME/totem/issues/265
___
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

[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

[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

[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

[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

[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

[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

[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

[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

[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: App menu retirement: outstanding MRs

[Allan Day]

Jeremy Bicha  wrote:
...
> > > The Videos change would also require a great deal of work
> > I thought it was just shuffling some menu items around...?
>
> My merge request was incomplete. It didn't handle the Python console
> menu for instance. I submitted it anyway in case it would help someone
> fix up the remaining issues.

Thanks Jeremy. It would be good to get as close to the desired UI as
we can, even if we can't get there 100%.

It would be a shame if one of our core apps ends up completely out of
step with the rest of the desktop.

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

App menu retirement: outstanding MRs

[Allan Day]

Hi all,

With a little over three weeks until UI freeze, I wanted to share a summary
of the outstanding tasks for the app menu retirement initiative [1].

Every one of the target apps now has an MR to retire the app menu (great
work everyone!) The challenge now is to get them all merged in time. The
outstanding MRs are:

   - Cheese 
   - Dictionary
   
   - Disks 
   - Documents 
   - Help 
   - Photos 
   - Polari 
   - Rythmbox  (this
   is an outstanding X11/Wayland bug)
   - Screenshot 
   - Videos 

Help getting these merged would be most appreciated.

Also, the screenshot change seems to have evolved into a more general
redesign. Who do I speak to about that?

Allan
-- 
[1] https://gitlab.gnome.org/GNOME/Initiatives/issues/4
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Annual GNOME Bugzilla statistics for 2018 (One last time)

[Allan Day]

Andre Klapper  wrote:
...
> one last quick look at some basic GNOME Bugzilla activity in 2018.

It's the end of an era! Thanks Andre.

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

Re: GitLab postmortem

[Allan Day]

Hey Carlos,

The GitLab transition has been really positive from a design
perspective. I would definitely say that our work feels easier and
more productive than it was. I think that GitLab is also helping us to
maintain a healthy design team.

Some highlights:

 - It's allowed us to migrate all our repos from GitHub back to GNOME
infrastructure, where they belong.
 - Just having formatting and screenshots in issues makes a huge
difference, and make it much easier to have conversations about
design. We've actually started using issue tracking against our mockup
repositories, which makes a lot of sense and is a good way to have
exploratory design discussions before engaging developers.
 - Another thing I've found is that we've become more willing to
create repos, which is really useful for experimentation.
 - Having a team space with all our repos is fantastic from a
team/community perspective.
 - Being able to view diffs between image commits is great (although
this not new to us, because we were using GitHub before).

Areas for improvement - the ability to have discussions in relation to
mockups is limited - you can only comment on a single commit, not on
an image file or a set of image files. It's awkward referring to
mockups from issues (do you embed the mockup in the issue, link to the
latest commit, or link to the file?) Ideally I'd want to mention the
mockup file and have GitLab take care of the rest - show a preview,
but also indicate if the image has changed since the comment was
posted.

Allan

On Tue, 11 Dec 2018 at 13:23, Carlos Soriano  wrote:
>
> Hey,
>
> It has been a few months since we moved to GitLab. Apart of spurious issues, 
> specific annoyances and frustrations, seems it has been generally good. I 
> would like to gather some general feeling about it. Things that really made a 
> constant impact to you and your work, both bad or good. Feel free to provide 
> feedback about the transition or the administration of GitLab instance too. 
> Free form.
>
> Please keep the mail chain one way from you towards the world, so we don't 
> get trapped on specifics, we can address stuff raised here individually out 
> of list. Personally, I'll ping you on IRC or so if I can do something to help.
>
> Of course, feel free to msg me directly on IRC/email too.
>
> Thanks all!
> ___
> 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

Help wanted with the shell's top bar

[Allan Day]

Hi all,

Back in 3.26 we introduced semi-transparency to the shell's top bar. On the
design side we were never all that happy with where the UI landed and have
wanted to improve it since then. However, we've been unable to make any
progress.

We don't want to have another release with the current top bar appearance,
so we've decided that, if we can't improve the appearance before the 3.32
UI freeze, we'd prefer to revert back to the always opaque black bar.

So, if you care about the semi-transparent top bar, please help us to
improve it this cycle, because otherwise it's going away. :)

The relevant issue: https://gitlab.gnome.org/GNOME/gnome-shell/issues/408

Thanks,

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

Re: App menu retirement: progress update

[Allan Day]

On Thu, 1 Nov 2018 at 11:37, Richard Hughes  wrote:
>
> On Wed, 31 Oct 2018 at 17:09, Allan Day  wrote:
> > gnome-multi-writer
>
> Removed in master.

Thanks Richard! To make sure, in Multiwriter's case there should be a
primary menu with the following items:

   Import ISO File...
   ---
   About MultiWriter

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

Re: App menu retirement: progress update

[Allan Day]

Alberto Fanjul Alonso  wrote:
>
> gitg has issue filed at least https://gitlab.gnome.org/GNOME/gitg/issues/141

Thanks Alberto and Jan, I've added these issues to the tracker.

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

App menu retirement: progress update

[Allan Day]

Hi everyone,

Hopefully everyone should be aware of the ongoing initiative to retire
application menus .
It's almost a month since I announced the initiative, so I wanted to
provide a progress update.

The headline is that 23 out of 62 apps have had their app menus removed. A
breakdown of the 39 apps that are still to be fixed:

   - Merge request pending: 7
   - Issue filed but no merge request: 6
   - No issue filed: 26

So we've made some good progress, but there's also a way to go. In
particular, we're going to need help with those apps that might not be
actively maintained. So, if you have time, do take a look at the list and
help out, either by filing issues or fixing them.

A full list of unfixed apps is in the footer to this email.

Allan
-- 

*Apps that still have app menus*

Pending merge request

   - cheese
   - eog
   - gnome-characters
   - gnome-mahjongg
   - gnome-sudoku
   - nautilus
   - polari

Issue filed

   - gnome-calendar
   - gnome-photos
   - gnome-screenshot
   - gnome-system-monitor
   - rhythmbox
   - totem
   - gnome-disk-utility
   - yelp

No issue filed

   - accerciser
   - evolution?
   - file-roller
   - four-in-a-row
   - geary
   - gitg
   - gnome-chess
   - gnome-dictionary
   - gnome-documents
   - gnome-klotski
   - gnome-multi-writer
   - gnome-nettool
   - gnome-nibbles
   - gnome-robots
   - gnome-sound-recorder
   - gnome-taquin
   - gnome-tetravex
   - gnome-tweaks
   - gnome-usage
   - gnome-weather
   - hitori
   - iagno
   - quadrapassel
   - tali
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Retiring app menus - happening now!

[Allan Day]

Hi all,

Thanks to everyone who contributed to the previous thread on this subject.
I've now started filing issues against individual modules. This is being
tracked here:

https://gitlab.gnome.org/GNOME/Initiatives/issues/4#affected-projects

There are a lot of modules to cover, so help would be appreciated both
creating issues and fixing them, particularly for apps that aren't so
actively maintained.

Thanks,

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

Re: Retiring app menus - planning for 3.32.0

[Allan Day]

Allan Day  wrote:
...
> > With regard to dropping the 'quit' action, is there any guidance for
> > background applications? That is, apps where closing all windows does
> > *not* exit the application, but the explicit 'quit' action does.
...

GIven that this is only relevant to apps that run in the background, I
don't think it makes sense to show it as a standard menu item. Third
party apps can provide their own Quit item if they want to, since I
know there's some different behaviours out there for that.

In general I think I'd probably go for no Quit item in GNOME apps that
run in the background, mostly because I think it's cleaner and easier
to understand if you separate the running state from whether a window
is open. For example, a chat app can be online/offline as well as
open/closed.

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

Re: Retiring app menus - planning for 3.32.0

[Allan Day]

Florian Müllner  wrote:
>
> With regard to dropping the 'quit' action, is there any guidance for
> background applications? That is, apps where closing all windows does
> *not* exit the application, but the explicit 'quit' action does.

Sorry for the slow reply - it's been a busy week.

This question is something that has been on my mind too. Having an
explicit way to stop an app from running in the background is
interesting, but then I wonder how desirable it is to have an action
to completely quit just once. I also wonder how obvious the function
is. How does someone know that quit stops the app completely, whereas
close doesn't? And would we just show quit in the case that an app
runs in the background...?

Another issue about quit which has occurred to me is that we show it
in the dash context menus...

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

Re: Retiring app menus - planning for 3.32.0

[Allan Day]

On Fri, 21 Sep 2018 at 12:54,  wrote:
>
> On Fri, Sep 21, 2018 at 5:36 AM, Bastien Nocera 
> wrote:
> > It's faster to access for users, has terser explanations (no need to
> > create sentences to describe actions) and it's usually better updated
> > as it lives in the code, as opposed to being separate in the docs.
>
> It's also larger, well-designed, easier to read and use.

But what if the docs were similar...? This is a hypothetical future,
not what we have today.

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

Re: Retiring app menus - planning for 3.32.0

[Allan Day via desktop-devel-list]

Christian Hergert  wrote:
...
> > "There is no need for the Quit menu item and the recommendation is to
> remove it from all locations."
>
>  - What about applications that have multiple windows? It seems
> cumbersome to track down all your windows to ensure the application exits.

My answer right now is, well, users will have to close each window
individually, and that's probably a good thing. For one thing, it will
help to prevent accidental closure.

However, if there are specific cases where closing multiple windows at
once is important, that would be good to explore.

>  - If we were to do this in conjunction with systemd/cgroup2 CPU
> priority for foreground/background applications (like Android) I'd feel
> a lot better about it.
>
>  - I'm also concerned due to how many applications we've had over the
> years that get themselves into various types of spin loops. Do we want
> to rely on the compositor/shell for force quit?
>
>  - Perhaps this also should be attempted in conjunction with
> save/restore session APIs like the old days of SMClient so that we are
> more free to kill/freeze background applications on constrained devices?

These all sound like good things to investigate, and if this change
pushes us to do that, then all the better!

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

Re: Retiring app menus - planning for 3.32.0

[Allan Day]

Bastien Nocera  wrote:
...
> > Putting aside the issue of outdated user docs,
>
> Well, it's a pretty big factor here.

Can't we just remove out of date user docs?

I realise that my line of reasoning is somewhat hypothetical here, but
if there are issues with the user docs, we ought to fix them.

> >  do you experience any
> > advantages having keyboard shortcuts in the shortcuts window, as
> > opposed to the help?
>
> It's faster to access for users, has terser explanations (no need to
> create sentences to describe actions) and

To be clear, I'm still thinking this through but, if you had a page in
the user docs which was a simple table of keyboard shortcuts, which
was one click away in the user docs, there wouldn't be all that much
to separate it from the keyboard shortcuts windows. And the advantage
would be more integrated user documentation (I think that's
essentially what the keyboard shortcut windows are). This would reduce
the number of menu items, allows cross-linking, and so on.

> it's usually better updated
> as it lives in the code, as opposed to being separate in the docs.

I can see how that's an advantage, but it also feels like a bit of a
workaround, if we assume that we need up-to-date user docs one way or
another...

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

Re: Retiring app menus - planning for 3.32.0

[Allan Day]

Nathan Graule  wrote:
...
> I feel like having the primary menu hidden in an in-window navigation app 
> would be a regression from current, as a primary menu may apply anywhere, and 
> having the user modify (and especially here, undo) application state in order 
> to access a particular menu item (that, again, by its definition can apply 
> anywhere in the app) would lead to end-user frustration.

That's a fair point. For example, it's certainly possible that someone
would want to change a setting in Videos while they're playing a
video.

My main hesitation to having the app level menu items (preferences,
keyboard shortcuts, help, about) always available is that it could
make the menus unpredictable - there is a clarity in having a definite
place for those items. Also, given that many of them are infrequently
used, requiring the user to navigate up a level to access them doesn't
seem all that terrible.

That said, what we could do - and this has been discussed a little -
is expose some of those items in the secondary menus, as necessary. In
the video playback example, you could have a "Video Playback Help" in
the secondary menu, for instance.

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

Re: Retiring app menus - planning for 3.32.0

[Allan Day]

Bastien Nocera  wrote:
...
> ... The keyboard shortcuts dialogue in Videos is invaluable.
>
> Its contents used to be in the README file, which users wouldn't see,
> the user documentation still shows the old interface (from 4 years
> ago), and I'd rather not rely on user docs if I can help it.

Putting aside the issue of outdated user docs, do you experience any
advantages having keyboard shortcuts in the shortcuts window, as
opposed to the help?

I can see the advantage for a large and complex app, where you might
want to regularly check shortcuts, as a quick reference. In the case
of a simple app, it's less clear to me what the advantage is over
having shortcuts in the docs.

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

Re: Retiring app menus - planning for 3.32.0

[Allan Day]

Alexandre Franke  wrote:

> Allan Day  wrote:
> > To be honest, I'm not sure how successful the keyboard shortcut windows
> > have been and I suspect that they're not being used a great deal.
>
> What are you basing this on?


Anecdotal evidence, primarily - my own usage, talking to other designers
and developers. It would certainly be good to have more reliable data.


> I have the exact
> opposite feeling, solely based on my own experience: I do use the
> shortcut window often and I find it very valuable.
>

That's interesting! Let's talk some more about it.

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

Re: Retiring app menus - planning for 3.32.0

[Allan Day via desktop-devel-list]

Andre Klapper  wrote:
...

> Personally I've always wondered how the "Keyboard Shortcuts" item
> potentially duplicates dedicated pages in some user docs
>

It would certainly be good to have a coordinated strategy. One obvious
question is whether to list shortcuts in a separate section or sprinkle
them throughout the docs (or both). The other question is the issue that
Adrien brought up - where to document gestures (could be touchpad or
touchscreen).

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

Re: Retiring app menus - planning for 3.32.0

[Allan Day]

Adrien Plazas  wrote:
...
> What about updating the name ofthe "Keyboard Shortcuts" entry? The
windows they trigger also contain gestures and in Games they also contain
gamepad controls, making them being about way more than keyboards.
>
> "Shortcuts" is a simple replacement but any other idea is welcome.

To be honest, I'm not sure how successful the keyboard shortcut windows
have been and I suspect that they're not being used a great deal.

The main problems as I see them:

   - They're a special place you have to go to with the specific intention
   of learning shortcuts. This isn't something that a lot of people do,
   especially for simple apps.
   - They aren't playing the role of a quick reference, since we haven't
   successfully advertised how to quickly open them (ironically, this is
   through a shortcut).
   - They're often available in simple apps where keyboard shortcuts aren't
   that interesting. This negatively reinforces how people perceive their
   usefulness.

One option would be to reframe the shortcut windows as purely a quick
reference for keyboard shortcuts. As part of this, we'd need to publicise
the shortcut for raising the shortcuts window (possibly by exposing it in
the menu).

I realise that you probably have an interest from a Games perspective, but
I think it would be fine to special-case that and come up with a bespoke
solution.

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

Retiring app menus - planning for 3.32.0

[Allan Day]

Hi all,

As previously discussed, we're planning to retire app menus this
development cycle. The aim is to remove all application menus by 3.32.0.

I've written some updated guidelines for the initiative
, and
I'd appreciate it if people could check them over.

We're also hoping to sneak in a couple of other UI changes at the same
time. I wanted to flag these here, in case there are any objections. They
are:

   1. Grouping the Preferences menu item with the other "app" menu items
   (Keyboard Shortcuts, Help, About).
   2. Changing the name of the about menu item from "About" to "About
   ".

If this all seems OK, I'll announce the initiative more widely and start
filing issues against the affected applications.

Thanks,

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

Re: No app menu changes for GNOME 3.30, please!

[Allan Day]

Isaque Galdino  wrote:
>
> Humm, from [1], I understood we could start the migration.
> "Summer 2018
> (...)
> Apps can start migrating during the 3.30 cycle
> Fall 2018
> (...)
> 3.30 ships with app menu support in the shell, but most apps don't use it 
> anymore "

I know that's what Tobias put on the original whiteboard. However, it
felt like too short a time period to complete the transition and
communicate the plan to the wider world. That's why, when I proposed
the GNOME Goal, I proposed 3.31.x as the target development cycle.

I'd expected there to be some discussion about the timeline and a
decision by the Release Team.

As it is, we're less than a week away from UI freeze and most apps
haven't changed their app menus. For consistency's sake, it would be
better to hold off until next release.

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

No app menu changes for GNOME 3.30, please!

[Allan Day]

Hi everyone,

I've noticed some apps have started removing their app menus, or
copying their app menu items elsewhere. Please, don't make any changes
to your menus yet! Unless we have a mass migration over a single
cycle, we'll end up with a complete mess.

The plan that I previously sent to this list [1] was to migrate away
from app menus next cycle (3.31.x). I had been hoping to get a
response to this...

Allan
-- 
[1] https://wiki.gnome.org/Initiatives/GnomeGoals/AppMenuRetirement
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Goal proposal: app menu retirement

[Allan Day]

Milan Crha via desktop-devel-list  wrote:
...
> this seems to be aimed to applications which use header bar in the
> title bar. I suppose this doesn't cover the applications which do not
> use anything like that, does it?

I've added a few notes about what to do if your application has a menu bar.

> By the way, App menu, Primary menu, Secondary menu, for someone not
> following the terminology closely it looks confusing. Maybe if the page
>  has also screenshot of "before", not  only "after", thus one less
> educated could compare, would be a plus.

My advice would be not to get too hung up on the terminology!

I think I'd prefer not to explode the mockups. What I have done is
added a few more labels...

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

GNOME Goal proposal: app menu retirement

[Allan Day]

Hi everyone,

We've been talking for a while about removing app menus, and the
designs have now matured to the point where we can propose a concrete
plan. Specifics can be found on the GNOME goal page:

https://wiki.gnome.org/Initiatives/GnomeGoals/AppMenuRetirement

Those of us on the design side are interested to hear what people
think of this, particularly if there are any apps out there that might
have issues following the guidelines.

The initial proposal is to try and complete this goal within the next
development cycle (3.31.x), so there is no immediate development
action required. (Of course, if people think that we could complete it
for 3.30, that would be great!)

Thanks,

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

Re: Documentation - language default

[Allan Day]

Michael Hall  wrote:
...
> Is the design for the site used on
> https://people.collabora.com/~meh/gdd/index.html#getstarted still valid?

As valid as it ever was... It was primarily meant as a proof of
concept, particularly in terms of whether we could produce a decent
site with only a limited amount of new documentation being written.

The design was always intended to be worked up by a visual designer
(the grey was a placeholder).

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

Re: Documentation - language default

[Allan Day]

Michael Hall  wrote:
...
>> I've been involved in quite a few discussions
>> about GNOME's developer documentation over the years, and have done a
>> fair amount of work on developer documentation design in the past [1]
>> (this came out of a meeting we had at GUADEC in 2016), including
>> creating a new prototype site last year.
>
> Do you have links to notes or anything from that GUADEC meeting?

At the time we were evaluating HotDoc, and the meeting was a fairly
limited discussion to figure out what steps would be needed to move
that initiative forward. The page I created about HotDoc [1] can be
seen as an outcome. (To be clear, I'm not pushing HotDoc here,
although it is my understanding that it's a potential solution to the
API docs for introspected languages problem.)

> I wasn't at
> that one, and wasn't aware of previous work on this.

There have been numerous planning and design discussions for developer
documentation over the years. The DX hackfest pages probably contain
additional material.

> Also is your prototype
> still live somewhere?

Not at the moment, but it shouldn't be too hard to reinstate it...

Allan
-- 
[1]  https://wiki.gnome.org/Initiatives/HotDoc
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Documentation - language default

[Allan Day]

Michael Hall  wrote:
...
> We have a project
> on GNOME's Gitlab, a Telegram channel, and have been trying to hold regular
> meetings on it.

This is all news to me... it would have been good to have heard about
the initiative sooner - I've been involved in quite a few discussions
about GNOME's developer documentation over the years, and have done a
fair amount of work on developer documentation design in the past [1]
(this came out of a meeting we had at GUADEC in 2016), including
creating a new prototype site last year.

Have you spoken with any of the relevant maintainers, like Shaun
McCance, Frederic Peters, or David King? Christian Hergert's also done
some work around developer documentation...

>>> using Django CMS and are working on getting an instance up
>>> and running
...
>> It would be helpful to have some more information about this.
...
> We chose this primarily because it was used by the Ubuntu Developer Portal
> in the past and we know it will work for the intended purpose. When I was
> working on the Ubuntu site we considered various other options, but Django
> CMS had the best combination of multi-language support, online editing,
> staged editing, content management and scalability. API documentation will
> be imported into Django (code for this was written for the Ubuntu portal
> already) to be integrated with the rest of the site. Content is stored in
> the Django database (it is a CMS after all). Contributors can be given login
> access to draft changes that an admin can publish.

Thanks for this. As someone who's active on the developer
documentation side, I would really appreciate it if there was a write
up of the goals for this project, along with what you have in mind for
the final product.

Allan
--
[1] https://wiki.gnome.org/Design/Whiteboards/DeveloperDocs
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Documentation - language default

[Allan Day]

Michael Hall  wrote:
...
>> Some of these are within reach, although as Bastian pointed out,
>> having the necessary infrastructure has been a stumbling block in the
>> past.
>
> We've settled on

Who is "we"? Where is the planning and discussion happening for this?

> using Django CMS and are working on getting an instance up
> and running. I used this when we built the Ubuntu Developer Portal to
> promote the Ubuntu SDK and it worked really well for that.

It would be helpful to have some more information about this. What
other options were considered? What were your requirements? How does
it integrate with API documentation? How is the content formatted?
What's the contributor workflow?

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

Re: Documentation - language default

[Allan Day]

Emmanuele Bassi  wrote:>:
...
> This was the conclusion of the 2013 DX hackfest:
>
>   https://treitter.livejournal.com/14871.html
...
>  - the announcement was made without resourcing, in the *hope* somebody
> would turn up

I don't think that's entirely true - my recollection is that there
were some people working in this area at the time. Also, it's worth
remembering that a lot of really awesome things that came out of that
hackfest, like GTK Inspector, popovers and baseline alignment. That
was also the event where we had a lot of critical discussions about
Flatpak and portals.

...
> That's probably the understatement of the year — *but* I think we'd be
> better served by actually going a bit deeper than just "let's evaluate a
> single language for our platform".
...
> What does "validate" mean? You want to write an application? What kind of an
> application?
>
> What does "good support in Flatpak" mean?
>
> What does "debugging toolchain" mean?
...

These are all important questions and you're right that there needs to
be a vision for what the developer experience ought to look like. My
best memory of GNOME doing this is actually the 2013 DX hackfest,
where we started out with a general discussion about who the target
audience was and what we wanted the overall experience to look like,
before breaking it down into individual pieces.

My view is that the challenge isn't so much coming up with a vision so
much as pushing it forward. For that to happen I think we need someone
to take a DX lead role in the project.

...
> While good documentation is a necessary stepping stone towards a decent SDK
> and application development experience, it's nowhere near sufficient.
>
> You can have the best documentation in the world — but if you don't have
> people working on the tooling and the actual integration between the
> language and the platform, then you don't have anything that other people
> can use.

You're right that documentation alone doesn't make a great developer
experience, and we ought to be aware of and be working on gaps in the
experience.

However, we have some great technologies and tools available today
that we ought to be highlighting, and there are some relatively
achievable improvements that could be made to our documentation which
would have a massive impact. For example, it would be an incredible
improvement if we had:

 - a nicely designed documentation portal, which pointed to the best
resources we have available today
 - a page that provides a high-level overview of the development
process, along with the main tools
 - API docs for the interpreted languages
 - examples that we can point people to

Some of these are within reach, although as Bastian pointed out,
having the necessary infrastructure has been a stumbling block in the
past.

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

Re: Documentation - language default

[Allan Day]

Sriram Ramkrishna  wrote:
> Some of you may be aware that we have started a documentation effort in
> order to give application developers a proper set of documentation for them
> to write applications.

I'm not aware of this. Can you provide some more information? (Who's
involved, what the scope is, etc?)

...
> We would like to validate what the
> current state of javascript is for writing applications and whether we now
> have good support in flatpak, debugging toolchains (eg gjs and builder) and
> other factors we might have not considered but should be identified.

My suggestion would be to speak directly to the relevant maintainers,
and to a few maintainers of apps using JavaScript...

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

3.28 Release Notes

[Allan Day]

Hi everyone,

The Engagement Team is about to start work on the release notes for
3.28. If you know of any changes that ought to be mentioned, please
add them to the wiki page:

https://wiki.gnome.org/ThreePointTwentyseven/ReleaseNotes

If you are in any doubt about whether to mention a change or feature,
please just add it to the page - the more information we have, the
better. Also, don't worry about writing perfect prose - rough notes
are fine.

Thanks,

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

Please add items to the 3.28 release notes page

[Allan Day]

Hi everyone,

The Engagement Team is starting the release notes process a little
early for 3.28. This is partly to support the release videos that
Bastian Ilso does, which require information about the release and
have a long lead time.

So, if you know about any features that are going to be in 3.28, it
would be really really helpful if you could add them to the wiki page:

https://wiki.gnome.org/ThreePointTwentyseven/ReleaseNotes

Don't worry about adding changes that are too small - it's all useful
information.

Many thanks,

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

Re: GitLab update: Moving to the next step

[Allan Day]

Emmanuele Bassi  wrote:
...
> This raises the question of who is going to review the currently
> insufficient-bordering-on-useless code of conduct that we have for
> GNOME online services and, more generally, for the community?
...

As you know, I'm also on the Foundation Board of Directors. I'd like
to reassure you that the board takes these issues very seriously and
has recently been discussing the best way forward.

I'm also currently chairing the Code of Conduct Working Group. While I
can't speak for that group, from a personal point of view I think it
makes sense to try and wrap up the Events Code of Conduct before
looking at the one for online behaviour. Thankfully we're on the cusp
of having that done, and much of the work that we've done in that area
may well be transferable to online conduct, so we should hopefully be
in a good position to move forward.

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

Re: GitLab update: Moving to the next step

[Allan Day]

Emmanuele Bassi  wrote:
...
> And, yes: diversity is still an issue that we need to tackle [insert
> subtle reminder here about the code of conduct rework that the board
> is still working on and that I hope I'll see in my lifetime].
...

Small clarification - it's the working group [1] that's working on the
code of conduct, not the board. Also, it's an events code of conduct,
not one for online behaviour.

Allan
-- 
[1] https://wiki.gnome.org/Diversity/CoCWorkingGroup/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for reducing the number of unremovable apps in GNOME Software

[Allan Day]

Bastien Nocera  wrote:
...

> I don't think that applications such as Calendar, Contacts, or finding
> and reminding apps should be removed from the requirements for a well-
> rounded, default desktop. How they're installed is a technical question
> that's not relevant to the fact that they're needed.
>

That's certainly true. I'm mostly coming it this from a direction of a)
trying to figure out what the user experience will look like on a
flatpak-based system and b) having done some digging, feeling somewhat
dissatisfied with the current use of . Particular
issues that I see:

1.  is only respected by Software or other "app
centers", so you get different behaviour with the command line, which lets
you install and remove apps that Software doesn't. This adds complexity,
makes testing difficult, and introduces bugs. It also creates ambiguity; I
don't think anyone is really sure what the experience is supposed to be.

2. In Software,  is used to hide apps that belong to
other desktops. In part I think this is motivated by the desire not to end
up with identical apps (because stock apps tend to use the icon theme and
often have identical names). However, it has the side-effect that
applications that could easily be installed can't be. This is because it
equates something being essential to an environment as meaning that it
shouldn't be available outside of it, which I don't think is always the
case - we might well say that Photos is essential to GNOME 3, but that
doesn't necessarily mean that it shouldn't be installable on a non-GNOME
system.

3. I guess I just find it strange that this mechanism is so decentralised.
Can anyone use ? Who makes the decisions about
what's included and what isn't? How is that monitored and managed?

Relying an the ostree/flatpak split to determine which apps are removable
has some advantages in relation to this - it would remove a layer of
configuration, you'd get a consistent experience and GUI tools would be
transparent in how they operate, it would be the OS builder who decides
what forms part of the product, and projects could decide what to make
available as standalone apps simply by making them available as flatpaks or
not.

Maybe there are issues with this approach - and I certainly take the point
about updates - but maybe it's also illustrative of what we ought to be
aiming for.

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

Re: Proposal for reducing the number of unremovable apps in GNOME Software

[Allan Day]

Bastien Nocera  wrote:
...

> > > I don't see the relation between sandboxable and unremovable.
> > >
> >
> > On an image-based OS, wouldn't it be the case that anything that's
> > not a flatpak would be part of the image, and therefore unremovable?
> > I've been looking at this issue recently from a slightly different
> > perspective and wondered whether "part of the base OS" might be a
> > simpler and more natural replacement for .
>
> Seems to me that the whole problem is that gnome-software keeps the
> "package" uninstallable even if the same application is installed via
> Flatpak.
>
> Fix that, and you don't need to make any changes to the appdata files.
>

I'm thinking about a "pure" system that doesn't have any packages - it's
just an ostree-based image with flatpaks installed on it. My understanding
is that, in this situation, some apps would be shipped as part of the
image, and that these apps wouldn't be removable.

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

Re: Proposal for reducing the number of unremovable apps in GNOME Software

[Allan Day]

Emmanuele Bassi  wrote:
...
>
> This does not mean that gnome-screenshot should be made unremovable,
> but it definitely needs some additional thought.
>

Documentation is another factor to consider. Currently, if you look up how
to take a screenshot, the docs tell you to use the screenshot app [1].

Allan

[1]
https://git.gnome.org/browse/gnome-user-docs/tree/gnome-help/C/screen-shot-record.page?h=gnome-3-26
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for reducing the number of unremovable apps in GNOME Software

[Allan Day]

Matthias Clasen  wrote:
...

> I don't see the relation between sandboxable and unremovable.
>

On an image-based OS, wouldn't it be the case that anything that's not a
flatpak would be part of the image, and therefore unremovable? I've been
looking at this issue recently from a slightly different perspective and
wondered whether "part of the base OS" might be a simpler and more natural
replacement for .

The argument for making some things unremovable has always been that their
> absence leads to a broken system. I can see how that applies to
> gnome-software (can't install apps anymore when it is missing) and to yelp
> (every apps help menuitem is broken when yelp is missing). But I don't see
> how this applies to gnome-screenshot (as Florian pointed out, the keyboard
> shortcuts for sceenshots don't rely on it anymore) or to nautilus (no icons
> on the desktop in GNOME3).
>
...

I guess the question there is "what does it mean to be broken?" Is a system
without a web browser broken? What about if there's no way to view an image
or view a PDF? What about a terminal, or other apps that could be used in a
support context (Logs, Usage, Problem Reporting, Screenshot, etc)?

Defining what the essential apps are would likely have design repercussions
(not necessarily unresolvable ones). As already mentioned in this thread,
there are links between the the apps (an example - just recently we've been
talking about having a link from the background setting to Photos). At a
higher level, we do tend to think of the core apps a integral part of the
product, both in terms of how they integrate with one-another and how
essential functionality is distributed.

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

Re: Application name strings consistency

[Allan Day]

Hi all,

Having spent some time studying this issue, I think it's best to keep the
app names stable and improve how we provide more detailed information about
each app (particularly the program name and developer). I've written up my
research and a set of proposals on the wiki page I mentioned previously
[1]. There's also some new design work for Software and for GTK's about
dialogs, which came out of this.

Allan

[1]
https://wiki.gnome.org/Design/Whiteboards/CoreAppPresentation#Tentative_Design
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Application name strings consistency

[Allan Day]

Jeremy Bicha  wrote:
>>The other thing we can do in Software is think
>> about making the developer more prominent.
>
> Like using "GNOME Files" in GNOME Software as was suggested by
> everyone in this thread who expressed a preference?

I'm thinking more of what you often see in other software stores,
where the developer will appear in small text below the application
name. That way the app name remains intact but the creator is also
shown.

> Files also suffers from the problem of zero info in the About dialog
> to tell you where the app came from or what the app really is. It
> doesn't link to a homepage. It doesn't mention GNOME. It doesn't
> mention that you'll need to know the word "nautilus" in order to file
> a bug or find the source code.

Yes, I think we should investigate this more closely. Although,
Bastien has been agitating against About dialogs in general!

...
> I recommend that GNOME apps follow this pattern (using
> gnome-tweak-tool as an example).
> Primary user visible name: Tweaks
> About dialog: GNOME Tweaks
> Appstream metadata: GNOME Tweaks
...

I'm not sure that those changes alone will be sufficient. Actually,
the more I think about this issue, the more complex it seems. I think
it's worth studying it in a little more detail before committing to
any changes. I've started a whiteboard page where we can collect notes
[1].

Thanks,

Allan

[1] https://wiki.gnome.org/Design/Whiteboards/CoreAppPresentation
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Application name strings consistency

[Allan Day]

Matthias Clasen  wrote:
...

> But names also need to sufficiently identify the named item. Ending up
> with 5 "Clocks" and 4 "Maps" in gnome-software isn't really the best user
> experience.
>
...

I don't see that issue.

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

Re: Application name strings consistency

[Allan Day]

Alexandre Franke  wrote:
...

> > 1. App names should be consistent.
> > 2. We generally don't expect users to know what GNOME is.
> > 3. There are other, better, places we can advertise the project, if
> that's
> > what we want to do.
>
> That’s for the name used in GNOME Software though, which is in the
> AppStream data and as such is also the name that will be picked up by
> other software catalog apps. Do you really want the KDE app store to
> show “Music” as such, which could be misleading to their users?
>

The GNOME core apps are designed and developed in order to be a core part
of GNOME. They are meant to be integrated, consistent, generic. How they
appear outside of GNOME is a secondary concern, as far as I'm concerned.

That said, I'd imagine that the same principles I described in my previous
mail would apply in other contexts: the name in the "store" should match
the name you see when you run the app.

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

Re: Application name strings consistency

[Allan Day]

Michael Catanzaro  wrote:
...

> * Maps appears as GNOME Maps in Software, Maps in about dialog
>> * Clocks appears as GNOME Clocks in Software, Clocks in about dialog
>> * Music appears as GNOME Music in Software, Music in about dialog
>> * Software appears as GNOME Software in Software, Software in about dialog
>>
>
> I like this style. The app shouldn't have a totally generic name in the
> software center, so we prepend GNOME to the generic display name there.


I disagree. For some time I've argued that we should drop the "GNOME".
Reasons for this:

1. App names should be consistent.
2. We generally don't expect users to know what GNOME is.
3. There are other, better, places we can advertise the project, if that's
what we want to do.

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

Re: Updating GNOME Goals?

[Allan Day]

Bastien Nocera  wrote:
...

> > I have a list of about 12 apps that don't have search providers and
> > probably should. I'd love for us to make some progress on that -
> > would it make a good goal?
>
> Let's fix the search providers infrastructure first. They're unusable
> on slow machines, and slow down faster machines.
>

I'm really keen for us to make progress on search coverage. It's an area
where we can deliver real value to our users and we have historically
failed to make progress. If our search infrastructure needs more work, it
would be great if we could make it happen sooner rather than later!

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

Re: Updating GNOME Goals?

[Allan Day]

I have a list of about 12 apps that don't have search providers and
probably should. I'd love for us to make some progress on that - would it
make a good goal?

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

GNOME 3.26 release notes

[Allan Day]

Hi everyone,

UI freeze is upon us, so now's a good time to think about release
notes! Please provide information about any user or developer changes
that have been made this development cycle, by adding them to the wiki
page:

https://wiki.gnome.org/ThreePointTwentyfive/ReleaseNotes

Don't worry about properly writing up details about the changes - what
we want is pure information. Also, we love to get details about small
changes as well as big ones! Do try and provide details from a user or
developer point of view though - why the changes are good, what they
are useful for, and so on.

Thanks!

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

Re: Proposal to deploy GitLab on gnome.org

[Allan Day]

On Tue, May 16, 2017 at 5:36 PM,  wrote:
...

> We need a much better migration plan than that. If we don't have a script
> to migrate Bugzilla issues, comments, and attachments to our new GitLab
> instance, then we should not be considering using GitLab's issue tracker at
> all.
>

We're committed to creating the necessary migration tooling; I think that
Alberto already has something in the works.

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

Re: Proposal to deploy GitLab on gnome.org

[Allan Day]

On Tue, May 16, 2017 at 3:51 PM, Shaun McCance <sha...@gnome.org> wrote:

> On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote:
> > The outcome of this evaluation process is that we are recommending
> > that GNOME sets up its own GitLab instance, as a replacement for
> > Bugzilla and cgit.
>
> I 100% support this move. There are inevitably going to be some pain
> points, but the end result will be worth it.
>
> That said, here's a potential pain point: in Bugzilla, you can have
> different components auto-assign to different accounts, and we made
> these @gnome.bugs fake accounts for teams. The docs team uses this to
> make it easy to follow docs bugs across products. I don't think GitLab
> has any sense of components, preferring the more casual labels for
> categorization.
>

That's a good point. There have been a number of pertinent issues and
concerns raised already in this thread. We'll make sure that we review them
and provide some feedback.

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

Re: Proposal to deploy GitLab on gnome.org

[Allan Day]

Alexandre Franke <afra...@gnome.org> wrote:

> On Tue, May 16, 2017 at 3:22 PM, Allan Day <a...@gnome.org> wrote:
> > In recent months we have got together to examine the possibilities for
> > GNOME’s development infrastructure. We’ve spent a lot of time on this,
> > because we want the community to have faith in our conclusions. If you
> are
> > interested in this, you can read our research on the wiki [1].
>
> Excellent. I think most will agree it’s time we implement such changes.
>

I agree. My view is that it's more important to move on, rather than
exactly which option we choose.

> The outcome of this evaluation process is that we are recommending that
> > GNOME sets up its own GitLab instance, as a replacement for Bugzilla and
> > cgit.
>
> This mail mentions Gitlab as the only alternative. I know some people
> suggested to consider Phabricator, yet your proposal doesn’t mention
> it and by the looks of the wiki pages your research has been focused
> around Gitlab.


As far as I'm concerned, we seriously considered both. I actually thought
that both alternatives were well represented on the wiki pages...

We had a number of people involved in the process (Daniel Stone, Emmanuele
Bassi, Andre Klapper to a certain extent) who are really familiar with
Phabricator and advocated for at it points.



> Now I know very little about both Gitlab and
> Phabricator so I won’t push or block anything, but I’m a bit worried
> that this wasn’t given enough scrutiny. In particular, I saw that
> Phabricator has a tool for mockups/design (Pholio [0]) that really
> looked like something we’d make good use of.


I agree that Pholio looks fantastic, and would love to have access to
something like that. That said, it is one additional feature, when I think
the core common feature set (code hosting, issue tracking) is the most
important thing. Also, my impression is that Phab is best suited to more
rigorously structured and managed development processes than our own, so
I'm not 100% sure exactly what role Pholio would take. We'd have to
experiment to see if it has a place in our overall methodology.



> It would allow our
> designers to stop using Github, Dropbox, and such non free,
> not-on-our-infrastructure tools.
>

I not sure that Pholio is necessary for us to give up Github and Dropbox.
We'll still need a repo for mockups, and the blocker for free
infrastructure in the past has been performance - both rendering and
serving the images, and handling the massive repository size.


So did you just look at Gitlab and think it’s good enough, or did you
> actually consider Phabricator (and maybe other alternatives) and pick
> Gitlab as the best fit?
>

I think early in the process there was greater interest in Gitlab, but as
it went on Phabricator was given serious consideration.

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

Proposal to deploy GitLab on gnome.org

[Allan Day]

[Written on behalf of Alberto Ruiz, Carlos Soriano, Andrea Veri, Emmanuele
Bassi and myself.]

Dear community,

Over the years, many of us have become increasingly frustrated about the
state of our development infrastructure, Bugzilla in particular. Pretty
much everyone we’ve spoken to doesn’t like it, and it’s not hard to see
why: it is littered with usability issues, code review is a pain, and it is
light-years behind more modern development platforms.

In the past, there haven’t been many other options, but we’re now in the
fortunate position of having viable alternatives and the sysadmin resources
to set one of them up and maintain it.

In recent months we have got together to examine the possibilities for
GNOME’s development infrastructure. We’ve spent a lot of time on this,
because we want the community to have faith in our conclusions. If you are
interested in this, you can read our research on the wiki [1].

The outcome of this evaluation process is that we are recommending that
GNOME sets up its own GitLab instance, as a replacement for Bugzilla and
cgit.

We are confident that GitLab is a good choice for GNOME, and we can’t wait
for GNOME to modernise our developer experience with it. It will provide us
with vastly more effective tools, an easier landing for newcomers, and lots
of opportunities to improve the way that we work. We're ready to start
working on the migration.

Please bear in mind that this is just a recommendation! We are not claiming
to have complete knowledge and we would like to hear questions and
comments. At the same time, we do ask that members of the community
approach this proposal with an open mind: please read the wiki pages and
try to resist making assumptions about GitLab without familiarising
yourself with it.

Yours,

Allan Day


[1] https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Mycroft GNOME Shell Extension & Request to join the community

[Allan Day]

Hey Rahul!

Rahul Mehra  wrote:
...

> I recently released the Mycroft AI Gnome Shell Extension for the Gnome
> Shell Desktop Environment. The shell extension is a front end to
> Mycroft AI which can be described as an open source digital assistant
> for the Linux platform. The gnome shell extension with Mycroft Core
> provides users a number of intelligent skills which can be interacted
> with via text and voice input. One of the main goals of my work on the
> gnome shell extension is to get a smart open source digital assistant
> like Mycroft to interact with the gnome desktop environment via voice
> and/or a graphical interface, with a possibility of a deeper
> integration with the desktop environment and other gnome applications
> that are included with the desktop.
>
> I am posting this email as I would like the Mycroft gnome shell
> extension project to be a part of the gnome community and get a chance
> to host my extension on gnome infrastructure.


In my experience getting hosted on GNOME infrastructure isn't the most
important thing to get involved in the community. Instead, I think the best
thing to do is join the most popular IRC channels and mailing lists, and to
help out with an existing module. The newcomers guide [1] is a great way to
get started, if that's what you want to do.

Alternatively, if you'd like to talk about how to integrate Mycroft into
GNOME, it would be great to chat on #gnome-design. I'm sure we could come
up with some ideas for how to take your work further!

Allan

[1] https://wiki.gnome.org/Newcomers/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Paperwork : a personal document manager (scanned and PDFs)

[Allan Day]

Hey Jerome!

Great to hear from you, and welcome to the GNOME project!

Jerome Flesch  wrote:
...

> (sorry if it's not the correct mailing-list for this kind of discussions)
>
> On Github, someone told me that there is someone else in the Gnome
> design team working on mockups for a new document manager / scan
> application[1][2]. It looks quite similar to an application I've been
> working on for a while: Paperwork.
> Website: https://openpaper.work/
> Sources: https://github.com/openpaperwork/paperwork/#readme
> Demo: https://www.youtube.com/watch?v=RMazTTM6ltg


It's really fantastic to see new apps being worked on for GNOME,
particularly when they follow the HIG! Paperwork looks really interesting.

I work on design and I was the one who drew those mockups you linked to.
They are indeed intended as potential updates to Simple Scan (they're still
pretty new and experimental).

...

> Assuming this is actually a good fit for Gnome, I'm not sure where to
> start either. Any indications would be welcome.
>

It looks to me like Paperwork probably has a specific set of use cases
involved - particularly someone who scans lots of text documents.
Concentrating on that use case seems like a perfectly good goal to me.

I'm not 100% confident where GNOME's strategy is long-term in this area and
would be happy to discuss it with you (just call into #gnome-design
whenever you want). One thing that having a standalone scanning utility (in
the shape of Simple Scan) does give us is the ability to scan different
types of documents, that might end up in different places. Likewise, while
we may want to look at Documents' role in the future, it does fit well into
the triumvirate of Documents/Photos/Music. :)

Best,

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

3.26 Feature Planning

[Allan Day]

Hi everyone,

If any of you are planning features for the next GNOME release, feel free
to add them to the list on the wiki:

https://wiki.gnome.org/ReleasePlanning/FeaturePlans

This is mostly for downstreams and partners, so they can get advance notice
of what's being worked on. It doesn't do any harm to include things that
might not land in time.

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

Re: GNOME Logo Licensing

[Allan Day]

On Mon, Mar 13, 2017 at 12:55 PM, Bastien Nocera  wrote:
...

> That was what I would have said, if Simon didn't put it so eloquently.
> So +1 for a permissive license for the artwork itself, we can control
> its usage through the GNOME trademark.
>

Thanks for the contributions so far.

The main thing the board wants from this thread is to find out which
modules are already shipping the logo and which licenses they're using. It
would also help to know if LGPLv3/CC-BY-SA-4.0 would conflict with those
existing licensing arrangements.

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

Re: Final call for the 3.24 release notes!

[Allan Day]

 wrote:
...

> I'm currently writing up the release notes for 3.24, and would like to
>> have the text finalised next week. If you know of anything that should be
>> included, now's the time to add it to the wiki:
>>
>> https://wiki.gnome.org/ThreePointTwentythree/ReleaseNotes
>>
>> We particularly need details for the developers page.
>>
> ...

> What kind of details are you looking for? I can definitely expand on the
> new Javascript language features that we support, but how much detail is
> appropriate?
>

We're mostly looking for a high-level description of what's changed and why
it is good/helpful/relevant. Having a list of the features would be good,
but we probably don't want to go into a huge amount of detail on each one.
It is good to have links to more information though, such as blog posts or
documentation.

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

Final call for the 3.24 release notes!

[Allan Day]

Hi all,

I'm currently writing up the release notes for 3.24, and would like to have
the text finalised next week. If you know of anything that should be
included, now's the time to add it to the wiki:

https://wiki.gnome.org/ThreePointTwentythree/ReleaseNotes

We particularly need details for the developers page.

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

Release notes for 3.24 are open!

[Allan Day]

Hi everyone,

UI freeze is just under two weeks away, so now's a good time to think about
what we want to put in the release notes for 3.24. If you know about
anything that might be interesting to users or developers, please add it to
the wiki page:

https://wiki.gnome.org/ThreePointTwentythree/ReleaseNotes

It is good to know about small changes as well as large ones, and it isn't
always the features that require a lot of work that are interesting. More
information is always better than less.

Thanks,

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

Re: Thoughs about communication

[Allan Day]

On Thu, Jan 26, 2017 at 8:56 PM, Sriram Ramkrishna 
wrote:
...

> My two cents, and bear with me on my slight rant - I really hate the idea
> of depending on a web app like riot.  It's like admitting that we've lost
> the whole application space and that we're going browser.  I know that is
> not what is intended, but that will be the perception.
>
> I'd like to do this, but I'd like to start putting resources into creating
> a viable chat client that works and is designed as a competition to a web
> app.  Maybe that means some kind of contest or something.  I'm not really
> worried about actually writing one after all matrix is an open standard,
> but the design one that shows the advantage of running something native
> should be a challenge that we need to meet head on.
>
...

While a native chat application would be nice, making it a requirement
would be a real mistake in my opinion. A couple of reasons for that:

First, chat is fragmented. There's no common standard, and whatever we
choose is going to be one player among many. That puts it in a different
category from many of our core applications.

Second, the GNOME developer community is already spread too thin. One of
the most pressing questions we have right now is how we can focus our
efforts on critical areas. In order to do that, we need to leverage other
projects and initiatives when it benefits us. Because when we try to do
everything in house, it hurts us, whether it's maintaining our own
infrastructure, writing our own tools, or implementing every app ourselves.
We end up being stuck behind the curve.

Obviously we're a community project and people will work on whatever itch
they want to scratch. I wouldn't discourage someone from working on
something if that's what they want to do. But that's different from making
native apps a hard requirement in cases like this.

We need to learn to tread lightly, embrace new things, and recognise that
we can't do everything ourselves. If we do that, I think we could find
ourselves in a pretty exciting place.

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

Re: Thoughs about communication

[Allan Day]

I agree with pretty much everything you've written here, Emmanuele. Just
one comment...

On Fri, Jan 13, 2017 at 1:32 PM, Emmanuele Bassi  wrote:
...

> >> pros/cons irc:
> >>
> >> pros:
> >> 
> >> - is widespread
> >> - integrated in gnome environment (bots, bugzilla)
> >
> > I would argue these two features are critical to any prospective chat
> > platform. If people can't access chat in a way that suits their
> workflow, they
> > probably won't. And it'd be a step backwards if automation suddenly
> became a
> > stumbling block.
>
> I guess the issue, here, is whether or not we care about reaching
> other people than the existing pool of contributors.
>

Attracting and retaining contributors has to be the most important
consideration. It's worth noting that IRC cuts in a few different
directions here: on the one hand, IRC means there's no barrier between us
and all the existing Free Software contributors/projects who are also using
IRC. On the other hand, for contributors who are used to modern tools, IRC
probably feels like a huge step backwards - it isn't user friendly, isn't
attractive, and it doesn't work well if you're not in one of the time zones
that are popular with our community.

In some ways, GNOME has the worst of both worlds - we're using poor tech
which has the advantage of adoption, and then we go and use a relatively
isolated server, so we miss out on the additional traffic we might get on
Freenode.

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

Re: Thoughs about communication

[Allan Day]

Alberto Fanjul Alonso  wrote:
...

> Do anybody though about trying new services for communication?
>
> - signal https://whispersystems.org/
> - telegram https://telegram.org/
> - matrix.org http://matrix.org/
> - gitter https://gitter.im/
>
  - Rocket.Chat https://rocket.chat/
  - Mattermost https://about.mattermost.com/
...

pros/cons irc:
>
> pros:
> - can be accesed through command line
> - is widespread
> - integrated in gnome environment (bots, bugzilla)
> cons:
> - syntax highlight
> - multimedia
>

IRC is lacking in almost all respects. Some of the main issues:

 - no built-in logging, server-side assistance for search
 - doesn't really track identity; nicks clash, people get renamed, etc
 - inaccurate tracking of online/offline status
...

Yes you can get around some of these things, using a bouncer or IRCCloud,
but that's not ideal. We've also done our best to improve the experience in
our own IRC client, Polari, but there's only so far you can take it on the
client side.

IRCv3 is aiming to improve the protocol/server situation but there's a long
way to go.

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

UX features for 3.24

[Allan Day]

Hi everyone!

Below is a list of UX features that would be great to have from a design
point of view. I thought I'd share it, in case it helps with 3.24 planning.
It's not a complete list and I think that some of them are already being
worked on.

It would be really great to have a bunch of these ready for the next
release!

Allan
---

Shell/Cross-desktop
- Weather integration in gnome-shell (bug 754031)
- A nicer avatar chooser for User settings, Initial Setup and Contacts (bug
766670)
- Sleep assistance (integrated screen shader; bug 741224)
- Sharing framework (
https://wiki.gnome.org/Design/OS/Sharing/#Tentative_Guidelines)
- Presentation mode for displays (bug 706432 and bug 706432)

GTK+
 - New tab widget (https://wiki.gnome.org/Design/OS/Tabs#Tab_Strip - bug
725079 [1])
 - Combobox replacement widget (
https://wiki.gnome.org/Design/OS/DropDowns#Tentative_Design [2])

Settings
 - Prepare for the new settings shell - updates to user accounts (bug
767065), printers (bug 767600), online accounts (bug 702345)
 - Revamp the network settings - (
https://wiki.gnome.org/Design/SystemSettings/Network#Tentative_Guidelines)
 - Revamp the display settings (depends on presentation mode above; bug
773147)

Videos
 - Series grouping (bug 732515)
 - Show something helpful when a video ends (bug 732544)
 - Welcome screen (bug 743697)
 - Type to search (bug 733218)

Music
 - Improve playlists (smart playlists - bug 760208; manual playlists - bug
760207)
 - Play queue popover (bug 724229)

Photos
 - Thumbnails don't reflect edited state (bug 763329)
 - Import from device (bug 751212)
 - Slideshows (bug 759159)
 - Revamp the UI for albums (bug 756133)
 - Revamp the photo grid, add date headings (bug 751114 and 740415)
 - Add a welcome screen (bug 743686)

Notes
 - Port to WebKit2 or drop WebKit for GTK+ (bug 728293)
 - Revamp the settings (bug 731447)
 - Fix background color (bug 761765)
 - Fixed width notes (bug 751442)
 - A nicer notes grid (bug 748706)
 - Fix formatting controls (bug 728859)
 - Fix last updated label (bug 689171)

Polari
 - Search (bug 758902)
 - Link previews (bug 768802)

Calculator
 - Make it look nicer (bug 743538)

Tweak Tool
 - General revamp - (
https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/tweak-tool/tweak-tool-wires.png
)

[1] Initial implementation -
https://git.gnome.org/browse/gtk+/log/?h=wip/matthiasc/tab-strip
[2] Initial implementation -
https://git.gnome.org/browse/gtk+/log/?h=wip/combo
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

3.22 Release Notes: Final Call!

[Allan Day]

Hi all,

We'll be freezing the 3.22 release notes in the next day or two, so if you
have anything that should be added to them, now's the time.

Just add the details to:

https://wiki.gnome.org/ThreePointTwentyone/ReleaseNotes

Thanks,

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

Re: Maybe deprecating libgweather

[Allan Day]

Giovanni Campagna  wrote:
...

> Any comments / opinions?
>

The dropdown list of search results that libgweather provides isn't great,
so  +1 from me.

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

Release Notes for GNOME 3.22

[Allan Day]

Hi everyone!

3.22 is getting scarily close, so it's time to start thinking about the
release notes.

If you have worked on any user or developer visible changes that will be
included in the release, please list them on the wiki page:

https://wiki.gnome.org/ThreePointTwentyone/ReleaseNotes

Don't worry about whether the change is too small - all the information we
get is useful. Wherever possible, describe the change and why it is an
improvement, and link to bugs, blog posts or screenshots.

Thanks!

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

Re: GNOME Photos plans for 3.22

[Allan Day]

On Mon, Apr 4, 2016 at 5:12 PM, Bastien Nocera  wrote:
...
>> * Import from device: Importing images from cameras, SD cards and
>>   USB sticks [3].
>>
>>   This is another thing that has, so far, been missing from the
>>   content applications, and I think it is a crucial feature when
>>   dealing with images.
>
> FWIW, I consider "importing" through browsing with the file browser to
> be more important than importing from devices.

You can already import with the file browser, by moving images to ~/Pictures.

> Eg. opening image files
> in Photos through the filemanager should work, and allow importing.
>
> (Both gnome-photos and gnome-music can't be selected as the defaults in
> the Details settings panel, which is pretty weird...)

I think you know that this is a question we're interested in - we
discussed it at the content apps hackfest in December. That said,
whatever we do for this, I'm not sure that it's a solution for bulk
import.

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

Re: Release notes time!

[Allan Day]

We are starting to write the release notes now, so please add any
changes to the wiki if you haven't already!

Allan

On Wed, Feb 24, 2016 at 4:23 PM, Allan Day <a...@gnome.org> wrote:
> Hi everyone!
>
> The 3.19.x cycle is drawing to a close. With the UI freeze behind us, it is
> time to think about all the cool stuff that will be released with 3.20. So,
> please spend a minute to add any user or developer facing changes to the
> wiki page:
>
> https://wiki.gnome.org/ThreePointNineteen/ReleaseNotes
>
> It really doesn't matter how big or small the feature is: it is all valuable
> material that we can write about.
>
> Thanks,
>
> Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.20 Test Days

[Allan Day]

Hello!

The third and final test day of the 3.19.x series is scheduled for
next Monday, March 7. The test days have been really useful, but we do
need more volunteers to help out.

Instructions on how to conduct the tests are provided on the wiki [1],
and there is a page set up for collecting results [2]. Note that
there's a graphics issue with Wayland at the moment, so you'll
probably need to use an xorg session to conduct the tests.

Thanks,

Allan

[1] https://wiki.gnome.org/ThreePointNineteen/TestDays/
[2] https://wiki.gnome.org/ThreePointNineteen/TestDays/2016-03-07
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Release notes time!

[Allan Day]

Hi everyone!

The 3.19.x cycle is drawing to a close. With the UI freeze behind us, it is
time to think about all the cool stuff that will be released with 3.20. So,
please spend a minute to add any user or developer facing changes to the
wiki page:

https://wiki.gnome.org/ThreePointNineteen/ReleaseNotes

It really doesn't matter how big or small the feature is: it is all
valuable material that we can write about.

Thanks,

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

Re: 3.20 Test Days

[Allan Day]

Hi everyone!

The previous test day was a big success! We discovered issues early, and
quite a lot of fixes have been committed based on the test results.

The next test day is scheduled for next Monday (22 February), and it would
be great if anyone wanted to join in and help out. There are instructions
on the test days page [1], and there's an empty page [2] ready to have
notes added to it.

We can probably use #gnome-hackers for discussion on the day.

Allan

[1] https://wiki.gnome.org/ThreePointNineteen/TestDays/
[2] https://wiki.gnome.org/ThreePointNineteen/TestDays/2016-02-22

On Tue, Feb 9, 2016 at 1:02 PM Allan Day <a...@gnome.org> wrote:

> For this cycle, I wanted to make sure that we do a more thorough job of
> testing prior to release. To that end, I've scheduled three days where I
> plan to do testing.
>
> The idea is to do a simple walk through of the release, as a new user
> would experience it, making notes and taking screenshots along the way. It
> is intended as a light weight exercise, and I'm happy to conduct it on my
> own. Other testers would be more than welcome though! Some initial
> instructions can be found on the wiki:
>
> https://wiki.gnome.org/ThreePointNineteen/TestDays
>
> I conducted the first test yesterday, and have put my notes and
> screenshots on the wiki:
>
> https://wiki.gnome.org/ThreePointNineteen/TestDays/2016-02-08
>
> There are plenty of issues in there, so developers and release team please
> take a look!
>
> In the future, it would be good to try and make this a standard part of
> the release schedule.
>
> Allan
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Remembering Thomas Wood

[Allan Day]

Hi everyone,

As some of you might have heard, Thomas Wood passed away last month. This
is extremely sad news for those of us who knew him: he was a great guy, who
was always supportive of the GNOME project.

There's a short post about Thomas on gnome.org:

https://www.gnome.org/news/2016/02/remembering-thomas-wood/

Best wishes,

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

3.20 Test Days

[Allan Day]

For this cycle, I wanted to make sure that we do a more thorough job of
testing prior to release. To that end, I've scheduled three days where I
plan to do testing.

The idea is to do a simple walk through of the release, as a new user would
experience it, making notes and taking screenshots along the way. It is
intended as a light weight exercise, and I'm happy to conduct it on my own.
Other testers would be more than welcome though! Some initial instructions
can be found on the wiki:

https://wiki.gnome.org/ThreePointNineteen/TestDays

I conducted the first test yesterday, and have put my notes and screenshots
on the wiki:

https://wiki.gnome.org/ThreePointNineteen/TestDays/2016-02-08

There are plenty of issues in there, so developers and release team please
take a look!

In the future, it would be good to try and make this a standard part of the
release schedule.

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

Re: New GNOME goal: shortcuts windows

[Allan Day]

Hi everyone!

A little update on how this goal is going! 14 apps have been given
shortcut windows so far. These are:

Boxes
Builder
Clocks
Documents
Eye of GNOME
Evince
Files
gedit
Logs
Maps
Photos
Polari
Settings
Videos

That's pretty good progress! In terms of outstanding work, I count
around 8 apps that it would be really good to have shortcut windows by
the end of the cycle:

Calendar
Contacts
DevHelp
Help
Music
Notes
Rhythmbox
Terminal

There are bugs listed for each of these on the GNOME Goal page. These
could be good for newcomers...

Allan

[1] https://wiki.gnome.org/Initiatives/GnomeGoals/ShortcutWindows
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list