-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 hi I'll add my voice into the debate again. The status icons thing needs fixing. I don't particularly care what the final decision is, but it *needs fixing, and very soon. Here's why. When the message tray was removed, the status icons were shunted off into a sort of hidden area of the bottom panel, accessible by pressing control+alt+tab until "status icons" is heard, and released. You land on the first icon in the list. However, accessibility of this area is extremely weird. The icons are usually, though not always, announced as the application name. EG pidgin. However, when you attempt to right click to bring up a context menu, you end up clicking on the applet to the right of the one orca's focus has landed on. Gnome developers cannot simply blow this off as, sorry, status icons is deprecated, blame your app provider. If the status icon for a particular app is not accessible, yes that's a problem with the app. But this is a problem with the area where the icons are themselves. It's all well for gnome developers to say "use an extension", which is doable, except for one thing. Extensions that modify the top panel to add icons, not menus, for those are accessible, but icons, are as far as I can tell, completely and utterly inaccessible. Top icons, as well as panel favorites both suffer from this. Orca simply cannot focus on the icons. It just won't see them. I hate to sound like I"m complaining, but I grow tired of filing accessibility bugs against gnome, and being one of the only people to do so. The gnome designers design a feature, forgetting about accessibility. Usually, it breaks, I find out about it right before a release, panic and start filing bugs, only to get "we don't do any kind of accessibility testing." To be fair, once bugs are filed they get fixed, and quickly. But would it really be too much trouble to use orca, and other accessibility tools with gnome *before* releasing it? I can and do use orca every day, and I can file the bugs where I find them, but I cannot see. So if a sighted gnome developer finds a bug where orca does not read something that it's supposed to, they can see what's supposed to be read, fix it, and be done with it. All I can do is, "well, orca isn't reading this. I have absolutely no idea why, but here it is." I want to do much better than this, but my programming skills are limited. There are currently many many accessibility issues in gnome's control center. Most of them are minor, but there are quite a few situations in which orca cannot see labels for buttons, I've filed bugs against most of these. There are instances where duplicate controlls, which are actually the "all settings" button, are announced to orca, leading to confusion. Extensions usually, though not always, are accessible. There preferences dialog, which is tucked into the tweak tool, however, are full of "button" "toggle button" No labels. None. I don't know how to solve this, other than nagging the extension authors, most of which will simply tell me they don't know a thing about accessibility, to fix them. An alternative is for the gnome developers to add accessibility guidelines and, preferably, accessibility checks into whatever sort of extension API there is. Long story short, this is gnome's, and not the extension author's, problem to solve. You guys do fantastic work, and I don't want to at all sound ungreatful. I could just use a little help from the people who design the desktop I use every day. I'm fine with the level of customization that gnome offers out of the box. Extensions, however, need a lot of a11y work. Just as an aside, epiphany is not very usable with orca. This is not a gnome problem though. If I understand it, it's a problem with orca and webkit, the details of which are completely over my head. Thanks Kendell clark Sent from Fedora GNU/Linux Bastien Nocera wrote: > > > ----- Original Message ----- >> On Tue, 2015-05-12 at 13:58 -0400, Bastien Nocera wrote: >>> >>> ----- Original Message ----- >>>> On Tue, 2015-05-12 at 06:02 -0400, Bastien Nocera wrote: >>>>>> * Shell extensions: As long as we're going to offer them, >>>>>> we shouldn't relegate them to Tweak Tool. Perhaps >>>>>> gnome-software would be a better location than >>>>>> gnome-control-center, but either would be better than >>>>>> Tweak Tool. (But the gnome-shell browser plugin is very >>>>>> crashy at worst and unreliable at best, so we should fix >>>>>> that first.) >>>>> >>>>> Extensions is what happens when designers and developers >>>>> don't agree. If you know you want extensions, installing >>>>> gnome-tweak-tool is only a step away. If people want to >>>>> integrate that better, they can add support to the >>>>> gnome-shell web browser plugin to show whether or not >>>>> gnome -tweak-tool is installed, and launch Software to >>>>> install it through the browser if not. >>>>> >>>> >>>> At the same time, I think it would be very useful to poll >>>> GNOME users for what extensions they are using (if any). I >>>> think you'll find that it's very likely that more users have >>>> installed (for example) the Alternate Tab extension than are >>>> using the default behavior (and it would also be interesting >>>> to know whether those using the default behavior know about >>>> the extension). >>>> >>>> Some other extensions that I personally know a great many >>>> people cannot live without: >>>> >>>> * Topicons: I understand that systray icons are not the way >>>> the GNOME designers want things to work, but FAR too much >>>> software exists today that relies on these icons. Shunting >>>> them to the message tray (pre -3.16) or into a tiny little >>>> expansion box (post-3.16) or hiding them entirely (Wayland) >>>> are not valid solutions for this software. Call it legacy >>>> software if you wish, but not having a sensible >>>> compatibility layer is harmful to users. >>> >>> The sensible compatibility layer is what you see. We don't want >>> to encourage using a functionality that we've been trying to >>> wean ourselves off for a number of years already. >>> >>> We can't keep on indulging applications that are designed like >>> Winamp and ICQ circa 1998. >>> >>> There are alternative ways: >>> https://wiki.gnome.org/Design/OS/MessageTray/Compatibility >>> >> >> >> That is all well and good if we have access to the sources for >> these tools. How about the endless supply of third-party software >> that we don't and can't control? Dropbox, Steam, Chrome >> Hangouts... are just a few. Without the topicons extension, these >> tools are difficult to access. > > They get relegated to the corner... A good experiment would be to > see if changes in the status icon could be transformed into > notifications through an extension. > > And contact your app provider to tell them that the GNOME > integration is bad... > >>>> * Window List: For many users attempting to locate the window >>>> they want across a number of workstations, having the window >>>> list at the bottom of the screen provides a very quick way to >>>> see what is on every workspace. It's far easier to process a >>>> short line of information than to 1) go into the Overview. 2) >>>> start paging through each workspace. 3) scan the entire >>>> screen for the window that matches what you want. >>> >>> 1) Go into the overview 2) type the name of the app followed by >>> enter or 2) click on the app's icon in the dock >>> >>> Maybe GNOME Classic is a better option for this site? >>> >> >> Neither of these options is sufficient if you have more than one >> window for a particular application. Some simple examples: >> >> * I have several browser windows open on different workspaces to >> match what I'm doing in those spaces. > > You should try using Epiphany's Webapps. I have separate apps for > Webmail, web RSS reader and my NAS' "UI in a web browser". > >> * I opened an email composition window and moved it to another >> workspace in order to easily reference something >> >> Neither of those cases work with the above response. > > Worth filing a bug about, with this information. It's kind of weird > that we don't search through opened windows when in the overview, > in some way. > >>>> Don't get me wrong: the GNOME designers have made many >>>> excellent choices: I wouldn't be running the GNOME >>>> environment if I thought otherwise. But some choices have >>>> fallen well into the realm of "perfect is the enemy of good". >>>> It doesn't matter how "clean" an experience feels on paper if >>>> people trying to use it get frustrated. There are many >>>> extensions out there to alleviate some of these pains, but >>>> there are two problems: >>>> >>>> 1) Extensions aren't common knowledge. Most people assume >>>> that GNOME is immutable and limited to only the few choices >>>> allowed by gnome -settings. Related to the above: no matter >>>> how easy it might be to install GNOME Tweak Tool, it's not >>>> *discoverable*. There are no hints anywhere that you might >>>> want or need it. There are no links from Fedora to popular >>>> extension pages, etc. >>>> >>>> 2) Extensions aren't (and as I understand it, cannot be) >>>> stable API. So even when someone has discovered an extension >>>> that they really cannot survive without, there's no guarantee >>>> that it won't be broken on the next update. This problem >>>> isn't solvable by GNOME, but it can be solvable by Fedora: we >>>> could identify a set of high-value extensions and work with >>>> their authors to have them ready before we release new >>>> versions of Workstation. >>> >>> High-value extensions should be in the core of gnome-shell. >>> Support >> >> >> This is absolutely something I would like to see. Some of them >> are: the ones attached to GNOME Classic. So that's definitely a >> step in the right direction. >> >> >>> for non-Gregorian calendars for example: >>> https://bugzilla.gnome.org/show_bug.cgi?id=624959 >>> >>> Or support for media player controls, or builtin weather. >>> >>> I made a list of those for the gnome-shell developers, but >>> cannot for the life of me find them anywhere anymore. >>> >> >> ... >> >>> Everything in gnome-settings-daemon and the >>> gnome-control-center is designed in such a way that "close the >>> lid" means "put the machine to sleep if it's stand-alone, turn >>> off the screen if it's plugged in to a dock/external monitor". >>> >>> As such, any option that might exist changing that behaviour >>> is provided as-is, YMMV, you-get-to-keep-both-pieces. >>> >> >> OK, that's reasonable (and a pretty decent default as well). >> Thank you for explaining. >> >> >>>>>> * Top bar: Maybe show date in clock could live in the >>>>>> Date & Time panel, where the 12/24 hour setting is. >>>>> >>>>> We already show it inside the menu, is that not enough? >>>>> >>>> >>>> When someone wants to know the date, it's usually because >>>> they need to use it for something (like signing a check, >>>> etc.) right now. Needing more than a quick glance to the top >>>> of the screen is wasteful, particularly since the GNOME >>>> design policy is to have none of that space used for anything >>>> else. This is one of those cases where I cannot figure out >>>> why the default doesn't simply include the date. I can >>>> understand having seconds or week numbers in the tweak tool; >>>> those are far less interesting. >>> >>> The full date (compared to the week day and time) would also >>> distract from the more important parts. Do we need the year in >>> the full date? Do we need the month? Feel free to file a bug >>> about that, the default and/or having a visible configuration >>> option can be discussed in its own bug. >>> >> >> >> In this case, I was actually just talking about having the >> default behavior match the "enabled" value of the checkbox in >> Tweak Tool. Right now, on my system that results in the menu bar >> reading: >> >> Tue 12 May, 15:25 >> >> I think this is probably sane and reasonable in general, though >> I'll admit that others might prefer a different representation of >> the date. > > Could you file a bug against gnome-shell about it (upstream)? We'll > discuss it there and see whether gnome-desktop and > gnome-control-center about it. > > Cheers > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVUxpkAAoJEGYgJ5/kqBTdH0MQAIo2xW5D7gpcSV/82lVsQjcb YzL1v0aYMCIAgnmV7dJOrGJzSf/Ak+C2zjG06ywlwp+SZCg/ytE+XS3EmDDMAtFX STpvAbkQkqq7RXYIXz+3WiOgQUBCAmVzHPJtmJ2oZbvxCUXV6npXdlTVAZdcyFoJ mfpNuUwf81o+bxv9GffPxc2z/DpowuKSJ9VGHdTqVZkHzn2F/qA4JJA1z5gbS6WD tVvP8GInPuHVA0wDdyx0GF3WClIOprnOO4oHQp8NshFMgXNfZ+F1CB4QEh1psyXt bBia+dExEOOqQV83ZWciZBuITTPADNyEXRXvF9n6h6IGG9dDrRybSCz6gqUH50US xyVT5w7cEUAyRyK4VbQuH4dO3EmshMDq3Ry5gUrzc0rrFJPbDnqfK+gA1GaFlLrR 5fw/SMvnQxasBHb3smYCJdF/8dGxDB7urueSblV/M+0N/0MP3kC9dGomDbvUw/On J6p2AL84o3Xr1CQwoQwi9DgKI7w19csKIqIVWMo8IsGdiYtFVWpcWgg2hGFB1Ptg crbBjo+c1s+eOiLe9iOhm8I2QBHr0Nn5qhrBSNRahGkId3Xa8qLMnDAtix0/9BKj tvjvdypJprtkxBQSKD3remL2v2xH1VR0ZjZ2n6Q7zTBVKlvmt/GIVgKVZW9VlnkV Pl+1frFRln9/NyKzQiBK =T+M5 -----END PGP SIGNATURE----- -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
