Hey Michael, Thanks for the excellent feedback! I've tried to fix all of these points [1].
Michael Catanzaro <[email protected]> wrote: ... > On the header bar page: "Header bars are incompatible with menu bars." > On the menu bar page: "menu bars can still be an appropriate choice, > particularly for applications that already incorporate a header > bar." (So that's a contradiction.) That's weird - obvious mistake. Fixed. > The menu bar page specifies that the menu bar should contain all of the > functionality of the app, so surely items in the app menu should be > duplicated in the menu bar. Is this the intended advice? (It's contrary > to what we've been advised in the past.) Either way, it'd be good to > mention this on the app menu page as well, so that it's more visible. I would consider an application menu to be part of the menu modal that the menu bar belongs to. Added some guidance on that. > In the section on app menus, we really need more guidance on the Quit > menu item. Some apps use Quit to close all windows of the app (which > seems to be intended), some use it to close the current window only (to > prevent the user from accidentally closing windows on other desktops, > which is a real problem with the former approach), and others omit Quit > entirely to avoid the issue. We discussed this in the past but didn't > really come to any conclusion. Agree that there needs to be more specific guidance here. Added something. > On the spinners page, you recommend not using spinners if the range is > limited on both ends. Isn't that a little strict? What about, for > example, the time control in the preferences of GNOME Chess? Yes, agree. (That was copied over from the old HIG, I think.) Updated. > In the section on tabs: "Use tabs that are proportional to the width of > their labels. Don't just set all the tabs to the same width...." But > nowadays, tabs actually are all the same width. Dynamic tabs always have equal widths, fixed tabs don't - which is what you're referencing here. I've tried to make it a bit clearer, but let me know if you think it's problematic still. > Also, I'm not sure about the advice at the very bottom of the tabs page. > For example, Epiphany surely needs a new tab button in its header bar, > but I don't think it'd look good to display the tab bar when only one > tab is open. Ah yes. Fixed. > On the toolbars page: "the first few buttons in a browser application > should always include Back, Forward, Stop and Reload, in that order." > That advice seems dated. Good catch! Thanks again, Allan [1] https://git.gnome.org/browse/gnome-devel-docs/commit/?id=33340f4563e996a7b22759c59010243c76977980 _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
