Re: Proposal: revisiting menus in Gnome
Hi Michael, Alberto and Hashem, First off, thank you for your welcoming and positive responses! I did know GUADEC was coming to Manchester, and I've been intending to look into it in more detail. Judging by last year's schedule I think I just need to get on with it and register. (For the completely uninitiated, perhaps GUADEC's website could include some links to info about last year's event, as a rough guide to what to expect?) Hashem, thank you for your suggestions. I hadn't thought of removing Quit completely, and it's worthwhile to consider, but on balance I think there are good reasons to keep it: - Some apps continue running when their last window is closed (or might want to) – for example music players, Transmission and some messaging clients can be configured to do this. In this case, Quit is a different action from just closing the last window. Firefox doesn't have this to worry about. - Some apps are commonly used with multiple windows, for example LibreOffice, Eye of Gnome, GIMP and Nautilus. A single button to quit the app is more useful than having to close each window individually. - It's already there, so we should only remove it if we have a compelling reason. I wasn't aware Firefox was switching away from icons in their menu. I actually had the idea to copy the system menu before I realised Firefox was already doing something similar. I guess the fact Firefox ever did it shows it can work in practice. Perhaps the reason jump list options aren't used often is that they're difficult to discover? :) The intent is that these are major entry-points into the app – an email client's might be “Inbox” and “Compose New Message”, and a web browser might have “New Window”, “New Private Window”, “Bookmarks” and “History”; Evolution and LibreOffice could show each of their components. And remember, the dash menu also contains options to switch between windows, plus the options to manage the app itself, which we can show even for uncooperative third-party apps. I think that's a reasonably useful menu. I see your point about having a dock in the top panel. Personally I like the focus of only showing the active app. I also wanted to avoid proposing such a substantial change, which might be less likely to get agreement. The App Indicators suggestion is really a whole other proposal, but very briefly: an App Indicator comprises a status icon for a running app, plus some menu items that are relevant now. Instead of having a separate system tray, let's treat these as what they are: running apps – show the app's icon in the dash, overlay the status icon as an emblem, and put those menu items in the app's dash menu. The protocol is supported well enough that we could finally get rid of legacy system tray icons, and we wouldn't end up with loads of apps polluting the top bar's system status area. And lastly, I've made some mockups. The mailing list doesn't seem to like large attachments, so: http://gkn.me.uk/stuff/gnome/gnome-menu-proposal.png http://gkn.me.uk/stuff/gnome/gnome-menu-proposal-annotated.png http://gkn.me.uk/stuff/gnome/gnome-menu-proposal-help-submenu.png Cheers, -- Greg K Nicholson ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fwd: Proposal: revisiting menus in Gnome
Thanks for writing this up, Greg! The pamel menu has always been a pet peeve of mine in GNOME. You've argued well why it hasn't worked out, and I hope the the design and gnome-shell teams engage with your ideas. Couple things come to mind: * Maybe you could add your ideas to the wiki under a candidate GNOME goal? https://wiki.gnome.org/Initiatives/GnomeGoals/ * Some design mockups would help understand some of your suggestions, like having icon buttons in the headerbar menu, and your comment about supporting AppIndicators in the panel menu. * gedit, at least, changes its ui when it detects that there is no panel menu in the current desktop environment. It moves the app-wide menu items into the headerbar menu. This is workable, but I really like your idea of a Help> menu item group. Gedit (updates ui): http://i.imgur.com/VDde5XE.png nautilus (like most gnome apps, just shows icon button in top left): http://i.imgur.com/gCQ5jFy.png * Firefox currently uses icons in the last row of their menu for help and quit. With the new redesign though I wonder what they've learned... From a design screenshots: http://www.omgubuntu.co.uk/wp-content/uploads/2017/04/firefox-photon-main-menu.jpg via http://www.omgubuntu.co.uk/2017/04/screenshots-firefoxs-photon-redesign-surface-online - it seems like they're moving away from the button group in the last row of the app menu. - They don't show Help being a submenu, but in the current version of firefox the Help icon indeed is a submenu so I think this might just be an oversight in the design screenshot. - they don't show Quit any more: this makes sense to me as the most common way of closing an app is just clicking the [x] in the titlebar. This makes it clear to me that we don't need to have 'Quit' in the headerbar menu. * I'm unconvinced that duplicating the jumplist menu in the panel menu is the right way to go. I never use the jumplist options in GNOME. I asked my friend who uses Mac and iPhone, and she never uses the dock right-click jumplist on the Mac, or the pressure-activated app icon jumplist on the iPhone. * For such seldom-used functionality, it seems wrong to me to dedicate space in the top pamel to that. I'd maybe propose as an interim, we can leave the functionality of the pamel menu as is, and merely duplicate Help and Preferences in the headerbar menu of apps. We can say the panel menu is deprecated and will soon go away, and then we can think about better utilizing the screen real estate instead of showing the app icon and panel menu. I don't think the panel has been well received, and has been the cause of much of the push-back from GNOME. Perhaps integrating something like https://github.com/jderose9/dash-to-panel would better suit our users by being more similar to most other desktop operating systems (well-understood and established designs, making the switch to using GNOME easier) and also allowing for faster app switching (so "power users" don't complain about GNOME as much). While I love the look of the vanilla GNOME 3 panel, I've taken to using this extension because app switching with the Activities popover (or with Alt+Tab) doesn't work well when there are 10+ windows. Again, thanks for thinking about this and writing a very clear proposal. I hope we can run with this. -Hashem On 04/10/2017 05:07 PM, Greg K Nicholson wrote: 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
Gnome3 shell is still poor, needs changes
Hello everybody. I'm a old user of unity7 I am new here, well I wanted to share with you the reason for my resistance to the use of gnome3. I was gnome user when this was gnome2. When this arrived I felt very frustrated by the interface with no functionality. I was kind of frustrated when I came back from unity7 to gnome 3.20. It gave me the impression that nothing has changed since the release of gnome3. But let's go. 1 You need to organize this shell structure. There is no sorting filter 2º The dock disappears all the time. (I know there is a "dash to dock" ). That is not a way to easy hold this together with a browser 3º There is not a easy way to keyboard shortcuts like unit7 does(to show the help from keyboard shortcuts unity we just need need to hold the window botton (super) by 3 at 5 seconds to show a graphic help. 4º The problem of 2º problem is because if i have 30 windows opened and i just want to see the tree from only one like nautilus windows i need to open the windows botton and see all windows togetther, this is a problem. I hope I have helped I'm not adept at putting extension to change anything, I'm very uncomfortable with that. Please do not get frustrated with me. Some fetures from this link are something we would like have as default https://ubuntugk.wordpress.com/2012/08/22/9-extensoes- uteis-para-seu-gnome-shell-2/ -- *Erik Chendo Tegon* Web Page : www.erikchendo.com.br Linkedin: br.linkedin.com/in/ErikChendoTegon ___ 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
Hi. On So, 2017-04-09 at 15:44 -0400, Walter Vargas wrote: > > 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, Hah. Before it was the Cloud™, SOA, IVI, other form factors, ... I think it's fair to say that we've felt this threat for at least a decade. Now that doesn't necessarily make your point moot, but it may give a perspective on why people seem to be relatively calm about the newest coolest kid on the block. > > and now GitHub is the world leading development platform. True. But it wasn't the case five years ago and it might not be the case anymore in five years. I interpret your statement such that we should focus more on being on Github, because it's where everybody else is and we surely want them to make GNOME better. I don't think we want to pay any price associated with getting the maximum number of potential contributors. The question then becomes whether we are willing to pay the price associated with "switching to Github". For certain values of "switching to Github", the answer is probably no; see below. > > Since the primary goal is to provide a developer experience that does not act > as > a barrier to new contributors, I believe our primary goal is to produce excellent Free Software to enable as many people as possible to do their computing. But there will surely be someone who would argue otherwise and the more people you ask the more answers you will get. Providing a smooth contribution experience is certainly a means to achieve that goal. And I think we have to work on making it much more smooth for people to produce code. > > Should we be more pragmatic about that and reconsider GitHub as an option? That's a fair question to ask. I am wondering about that myself for a while now. I believe we are reluctant to accept having to rely on a party sitting between us and the people wanting to make GNOME better. The reasons are manyfold. My personal objection is that requiring someone to agree to the ToS of a third party is a lot to ask for. We don't control the third party and it may very well decide to not conduct business with certain people we would want to be able to contribute. Just to invent a scenario: American companies may not be allowed to deal with embargoed countries or people living there. Now that's not a concrete issue right now (AFAIK) but it may well become one. (Also, the Github ToS, in particular, have stirred up some debate recently) On the other hand, it's probably fair to say that most people do have a Github (Google, Facebook, ...) account already, so we're arriving here: > > Is it a dogmatic foundational decision not to evaluate GitHub because it is > not > Free Software? To me, not being Free Software feels like the straw that breaks the camel's back. But it's not that we're not using Github. We have invested some time to have our self-hosted git mirrored to Github. Some people also accept patches via Github. Are you thinking of using Github more? Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
