Re: Proposal: revisiting menus in Gnome

[Alberto Ruiz]

Hey Greg,

First of all, thanks a lot, one can tell about this email that you care
passionately about GNOME, so thanks for reaching out! The design team can
certainly use help :-) I will leave it up to them to route you to the right
venue to have a conversation about your suggestions.

I was just wondering, given that you are from Manchester, are you aware
that we are organising GUADEC in your home town this summer? It could be a
lot easier to discuss these things in person and given that it's in your
home town I'd really encourage you to register and attend!


2017-04-10 22:07 GMT+01:00 Greg K Nicholson :

> Hi folks,
>
> This is going to be a long one. Check you have a cup of tea before you
> dive in.
>
>
> # Summary
>
> We should improve how Gnome apps organise their menus.
>
> We should move the contents of the panel menu into the headerbar menu,
> where Preferences and Quit should be styled like in the Shell's system
> menu. The panel menu should duplicate the contents of the focused
> app's dash menu.
>
> Because:
> - Users expect those options to be inside the application window.
> - Independent apps don't use the panel menu, which leads to an
> inconsistent experience in Gnome Shell.
> - Other desktop environments don't have a panel menu, so Gnome apps
> have to reorganise their menus when used outside Gnome Shell.
>
>
> # About me
>
> I'm Greg K Nicholson. I've used Gnome and followed its development for
> 10 years. I switched to Ubuntu (6.10) from Windows XP because I wanted
> Gnome. I now use Fedora for the same reason.
>
> I live in Manchester, Great Britain. My day job is doing quality
> assurance for a web development company, which involves testing for
> bugs and also testing user experience design from a user's point of
> view. I was part of the team that built the current iteration of
> london.gov.uk, which launched in 2015.
>
>
> # Intent behind the existing design
>
> (This is from my memory of the discussions around the time of Gnome
> 3.0. Corrections and clarifications are welcome!)
>
> - Users think in terms of “documents, which can be manipulated using
> various applications” rather than “applications, which allow
> manipulating their documents”.
> - Applications commonly have multiple windows.
> - Each app window represents 1 document.
> - Menus in the app window should be directly relevant to that document.
> - Application-level options are not relevant to any particular
> document, so they should be outside of any particular app window.
>
>
> # Why change now?
>
> - Users don't understand the distinction between application-level
> options and document-level options, so they don't understand what the
> panel menu is for.
> - The idea that each window represents 1 document hasn't materialised.
> Most apps are a single window. We use tabs liberally, and our tabs
> appear below the toolbar, which reinforces the idea that 1 window can
> contain multiple documents.
> - In some cases there's no way to make a clear distinction between
> application-level and document-level options, for example in Gnome
> Calendar.
> - After six years, there are still many third-party apps commonly used
> in Gnome Shell that we haven't persuaded to switch to our way of doing
> menus, for example Firefox and Chromium.
> - Other desktop environments are using our apps (hi Budgie and
> Pantheon!) and we want our apps to be at their best, even outside of
> Gnome Shell.
> - When we last redesigned menus in Gnome, we didn't yet have popovers.
> We now have more flexibility in how we display menus in app windows.
> - We'll soon have a major influx of new Gnome users thanks to Ubuntu.
> We should make sure our apps are easy for them to use.
>
>
> # Goals
>
> - Feel like Gnome
> - Avoid redesigning the Shell
> - Avoid changing the layout of existing apps' main windows
> - Be easy to switch to in a single 6-month cycle
> - Be simple and easy to understand for experienced Gnome users and
> developers
> - Be simple and familiar for people using Gnome for the first time
> (this is where I avoid using the buzzword “intuitive”)
> - Eliminate inconsistency in menu layouts among modern Gnome apps
> - Reduce the number of different menu layouts that users see
> day-to-day while using modern Gnome apps alongside other apps in Gnome
> Shell
> - Make third-party apps, unlikely to design specifically for Gnome,
> feel more at home inside Gnome Shell
> - Make Gnome apps' menus behave consistently, when the app is used
> inside Gnome Shell and when it's used outside (for example in Budgie
> or Windows)
> - Be better than what we have now, in the opinion of existing Gnome
> users, designers and developers
>
>
> # Nomenclature
>
> I'm going to discuss several different menus, so let's name them all
> clearly:
>
> - The “dash menu” appears when you right-click or long-press an
> application's icon in Gnome Shell's Activities overview.
> - The “panel menu” appears when you click the focused application's
> name in 

Re: Fwd: Proposal: revisiting menus in Gnome

[Michael Catanzaro]

I don't have much to add, but you have a bunch of good points and a
serious design for addressing the problem. I hope the community
considers your suggestions seriously, even if we expect that app/panel
menu adoption will likely improve in the next couple of years with
Ubuntu switching back to GNOME. I don't think the app/panel menu has
worked out as well as we originally hoped. I'm still dealing with users
in 2017 who do not know that the menu exists and don't realize that
Epiphany has preferences, bookmark import feature, etc.

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

Fwd: Proposal: revisiting menus in Gnome

[Greg K Nicholson]

Hi folks,

This is going to be a long one. Check you have a cup of tea before you dive in.


# Summary

We should improve how Gnome apps organise their menus.

We should move the contents of the panel menu into the headerbar menu,
where Preferences and Quit should be styled like in the Shell's system
menu. The panel menu should duplicate the contents of the focused
app's dash menu.

Because:
- Users expect those options to be inside the application window.
- Independent apps don't use the panel menu, which leads to an
inconsistent experience in Gnome Shell.
- Other desktop environments don't have a panel menu, so Gnome apps
have to reorganise their menus when used outside Gnome Shell.


# About me

I'm Greg K Nicholson. I've used Gnome and followed its development for
10 years. I switched to Ubuntu (6.10) from Windows XP because I wanted
Gnome. I now use Fedora for the same reason.

I live in Manchester, Great Britain. My day job is doing quality
assurance for a web development company, which involves testing for
bugs and also testing user experience design from a user's point of
view. I was part of the team that built the current iteration of
london.gov.uk, which launched in 2015.


# Intent behind the existing design

(This is from my memory of the discussions around the time of Gnome
3.0. Corrections and clarifications are welcome!)

- Users think in terms of “documents, which can be manipulated using
various applications” rather than “applications, which allow
manipulating their documents”.
- Applications commonly have multiple windows.
- Each app window represents 1 document.
- Menus in the app window should be directly relevant to that document.
- Application-level options are not relevant to any particular
document, so they should be outside of any particular app window.


# Why change now?

- Users don't understand the distinction between application-level
options and document-level options, so they don't understand what the
panel menu is for.
- The idea that each window represents 1 document hasn't materialised.
Most apps are a single window. We use tabs liberally, and our tabs
appear below the toolbar, which reinforces the idea that 1 window can
contain multiple documents.
- In some cases there's no way to make a clear distinction between
application-level and document-level options, for example in Gnome
Calendar.
- After six years, there are still many third-party apps commonly used
in Gnome Shell that we haven't persuaded to switch to our way of doing
menus, for example Firefox and Chromium.
- Other desktop environments are using our apps (hi Budgie and
Pantheon!) and we want our apps to be at their best, even outside of
Gnome Shell.
- When we last redesigned menus in Gnome, we didn't yet have popovers.
We now have more flexibility in how we display menus in app windows.
- We'll soon have a major influx of new Gnome users thanks to Ubuntu.
We should make sure our apps are easy for them to use.


# Goals

- Feel like Gnome
- Avoid redesigning the Shell
- Avoid changing the layout of existing apps' main windows
- Be easy to switch to in a single 6-month cycle
- Be simple and easy to understand for experienced Gnome users and developers
- Be simple and familiar for people using Gnome for the first time
(this is where I avoid using the buzzword “intuitive”)
- Eliminate inconsistency in menu layouts among modern Gnome apps
- Reduce the number of different menu layouts that users see
day-to-day while using modern Gnome apps alongside other apps in Gnome
Shell
- Make third-party apps, unlikely to design specifically for Gnome,
feel more at home inside Gnome Shell
- Make Gnome apps' menus behave consistently, when the app is used
inside Gnome Shell and when it's used outside (for example in Budgie
or Windows)
- Be better than what we have now, in the opinion of existing Gnome
users, designers and developers


# Nomenclature

I'm going to discuss several different menus, so let's name them all clearly:

- The “dash menu” appears when you right-click or long-press an
application's icon in Gnome Shell's Activities overview.
- The “panel menu” appears when you click the focused application's
name in Gnome Shell's top bar, next to the Activities button.
- The “headerbar menu” exists in many (but not all) Gnome apps. It
appears when you click the three-line icon at the end of the app
window's headerbar.
- The “menu bar” exists in more traditional apps, and in many
third-party apps, near the top of the app window. It typically
contains all of the app's options.
- The “system menu” appears when you click the system-wide status
icons at the right end of Gnome Shell's top bar.


# What we have now

## Modern Gnome apps

Examples: Nautilus, gedit, Epiphany, Totem, Gnome Calendar, dconf
Editor, Geary, Gnome Calculator, Gnome Clocks, Cheese

These apps fully implement Gnome's ideal menu designs, and don't use a menu bar.

The *dash menu* contains options for managing the application itself:
open a new window; add 

Re: GitHub Development Platform for GNOME

[Philip Withnall]

On Mon, 2017-04-10 at 14:09 -0400, Nicolas Dufresne wrote:
> Le lundi 10 avril 2017 à 01:25 +0530, Nirbheek Chauhan a écrit :
> > On Mon, Apr 10, 2017 at 1:14 AM, Walter Vargas  > co
> > m> wrote:
> > > I want to share my humble opinion and thoughts about
> > > GitHub/GitLab:
> > > 
> > 
> > From what I've been hearing, people within GNOME have been
> > evaluating
> > the possibility of running our own GitLab instance, so I would wait
> > and see what the results of their testing is.
> 
> And we need not to forget that a lot of the freedesktop community [0]
> projects are moving to Phabricator (even though it does not come with
> an easy patch submission mechanism).

There’s git-phab, which is pretty good. You do need to install it
though (`pip3 install git-phab`).

If you don’t install git-phab, the patch upload process is basically
the same as Bugzilla: `git format-patch …` then attach it to a form and
submit.

Phabricator explicitly doesn’t support pull requests, and there’s some
justification for that in nudging people towards code review: https://s
ecure.phabricator.com/phame/post/view/766/write_review_merge_publish_ph
abricator_review_workflow/ (written by one of the Phabricator authors).

Phabricator’s patch review system is unsurpassed (in my experience of
GitHub, GitLab, Phabricator and Bugzilla) in its support for patch
sets, inter-diffs, and tracking review comments through multiple
iterations of a review. It’s beautiful. I think I’m in love.

Philip

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

Re: GitHub Development Platform for GNOME

[Nicolas Dufresne]

Le lundi 10 avril 2017 à 01:25 +0530, Nirbheek Chauhan a écrit :
> On Mon, Apr 10, 2017 at 1:14 AM, Walter Vargas  m> wrote:
> > I want to share my humble opinion and thoughts about GitHub/GitLab:
> > 
> 
> From what I've been hearing, people within GNOME have been evaluating
> the possibility of running our own GitLab instance, so I would wait
> and see what the results of their testing is.

And we need not to forget that a lot of the freedesktop community [0]
projects are moving to Phabricator (even though it does not come with
an easy patch submission mechanism).

regards,
Nicolas

[0] https://phabricator.freedesktop.org

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

Re: GitHub Development Platform for GNOME

[Carlos Soriano via desktop-devel-list]

Hello Walter,

Yes, using non-free software for something as important as our infraestructure 
is problematic for most of the GNOME community. GitHub is not a feasible option 
for the time being. Other alternatives that are free software can be and are 
being taken into account, and that's the path we should lead.

Best regards,
Carlos Soriano

 Original Message 
Subject: GitHub Development Platform for GNOME
Local Time: April 9, 2017 9:44 PM
UTC Time: April 9, 2017 7:44 PM
From: waltervar...@linux.com
To: desktop-devel-list@gnome.org

I want to share my humble opinion and thoughts about GitHub/GitLab:

I get worried about the long-term viability of the GNOME project after running
an iteration over OODA Loop (observe, orient, decide, act)[1].

Canonical's recent decision about not maintaining unity for Ubuntu makes it
quite clear that Desktop is not the priority anymore, IoT and Mobile are the
priority now, and now GitHub is the world leading development platform.

Since the primary goal is to provide a developer experience that does not act as
a barrier to new contributors, Should we be more pragmatic about that and
reconsider GitHub as an option?

Is it a dogmatic foundational decision not to evaluate GitHub because it is not
Free Software?

Kind Regards

[1] https://en.wikipedia.org/wiki/OODA_loop___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list