Missing tooltips for icon labelled panel applets in classic GNOME session?
Hy, I using Natty live CD for classic GNOME session. I see an interesting think, with I don't no possible resolving or not, or how can possible resolving, I would like ask your hint: Longer time known issue, some panel applets not have accessible descriptions (for example network manager icon in the top panel, keyboard layout indicator), this situation need pressing Orca+F1 key combination to listen the panel applet tooltip message (not have network connection, vired connection auto eth0 is active, etc), this is not problem prewious, because Orca+F1 keystroke spokened the textual tooltips with this icon labelled panel applets. Now, when I press Orca+F1 keystroke this icon labelled panel applets, Orca not spokening any tooltips this panel applets. Missing this tooltips, removed this tooltips, or why happening this? When I generated a modifyed live CD, I simple copyed my original Lucid system good working .gconf folder in /etc/skel folder, of course I applied required Natty specific synchronisations. Perhaps I mistake, or this is an upstream bug for this panel applets? In my Lucid system all icon labelled panel applets have tooltips, and Maverick I not remember this issue. Another interesting issue, I using Window Chooser panel applet the bottom panel. Prewious when I landing the Window Chooser panel applet, I hear right textual name for this panel applet. Now, I hear "Vnck-applet" name. Similar problem have the "Trash" panel applet, now I hear "Trashapplet" name. I no, general Ubuntu configuration have limited applets for top and bottom panels. My customizations are bad? Possible easy resolving this missing panel applet tooltips problem for Natty? Attila -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: One desktop environment announce message is wrong marked for translation in src/orca/scripts/default.py file
On Tue, Mar 29, 2011 at 10:01:12PM EST, Hammer Attila wrote: > Hy, > > Luke, unfortunately one %s style desktop environment announce > message is wrong marked for translation in > src/orca/scripts/default.py filename. > I reported this issue, and attached two style fix patch with > following bugreport, if possible, please review the proper patch: > https://bugs.launchpad.net/bugs/744875 Thanks, will get this fixed after beta, along with the new orca upstream release. > I have got a technical question with future: > If Ubuntu specific gnome-orca package debian/patches directory > already containing a patch with implementing a function, and need > fixing a problem with patched version for a function implementation > patch, what place need doing the fixes? For example, if I want > easyest attaching a fix, what format you prefer better: a fix with > you already doed complete patch, or direct fix patch with original > already patched source file (now src/orca/scripts/default.py > filename)? > Now, I both two way make the patch. > This situation need attaching both two style patches, or enough > modifying original devian/patches directory already existing > function implementation patch? Whatever suits you, I can work either way. The only thing I request is that you create your patches with diff -u, i.e when running the diff command, please use the -u argument to produce a unified diff, which is the same format to the orca patches. Unified diffs are much easier to read. Luke -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Fwd: Re: Integrating new console colors in D-I (was Re: Call for testing: Aubergine-love for Server folks!)
I have not tested this yet, but it sounds like good news for the a11y perspective and those who struggled with the colours on the aubergine accessible installer Alan. Original Message Subject: Re: Integrating new console colors in D-I (was Re: Call for testing: Aubergine-love for Server folks!) Date: Tue, 29 Mar 2011 15:10:48 -0500 From: Dustin Kirkland To: ubuntu-de...@lists.ubuntu.com CC: Colin Watson On Sat, Mar 26, 2011 at 10:21 AM, Colin Watson wrote: It would have to go on the kernel command line, not in the CD preseed file. The latter is read too late for this. It would probably be better to add new values for the existing FRONTEND_BACKGROUND environment variable (which can also go on the kernel command line) rather than inventing a new preseeded template which would basically just be a synonym for it. Great idea, Colin. I have this now working, with an upload of cdebconf-0.154ubuntu2 to Natty archive. This will not make Beta1, but should absolutely land in Beta2, and will need release-team approval. Note that it will also require a re-spin of debian-installer. I'm tracking this in Bug #730672. There's a debdiff for cdebconf there. As of that upload, any user of the text installer will be able to optionally specify a FRONTEND_BACKGROUND value on the kernel command line. The cdebconf-newt-udeb package provides the following: * dark -- high contrast, accessibility theme * original -- the traditional, legacy newt theme * ubuntu -- the aubergine theme (basically, s/blue/magenta/g) These are installed to: * /etc/newt/palette.dark * /etc/newt/palette.original * /etc/newt/palette.ubuntu By default, there is a symlink installed by cdebconf-newt-udeb in the ISO filesystem: * /etc/newt/palette -> /etc/newt/palette.ubuntu At debian-installer/cdebconf initialization of the newt frontend, if a kernel parameter FRONTEND_BACKGROUND= is found, then the symlink at /etc/newt/palette is broken and replaced with a symlink to /etc/newt/palette.. In this way, any derivative of Ubuntu can ship their own palette in a udeb that's included in their ISO build, install that palette at /etc/newt/palette.kubuntu, for example, and append FRONTEND_BACKGROUND=kubuntu to the kernel parameters. If you (or your Ubuntu derivative) just want the legacy behavior, then don't bother shipping your own palette, but simply append FRONTEND_BACKGROUND=original to the kernel parameters. I hope this helps with your calls for reconfigurability! I've enjoyed working with everyone on this ;-) Cheers, -- :-Dustin Dustin Kirkland Ubuntu Server, Core Developer Canonical, LTD -- ubuntu-devel mailing list ubuntu-de...@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
One desktop environment announce message is wrong marked for translation in src/orca/scripts/default.py file
Hy, Luke, unfortunately one %s style desktop environment announce message is wrong marked for translation in src/orca/scripts/default.py filename. I reported this issue, and attached two style fix patch with following bugreport, if possible, please review the proper patch: https://bugs.launchpad.net/bugs/744875 Of course, gnome-orca package is full translated with hungarian language both upstream level and Launchpad translation system. The problem is happening only if I press Orca modifier+e keystroke, if the verbosity setting is verbose. I tested the src/orca/scripts/default.py filename style fix patch. When I rebuilded and installed gnome-orca package after applied the patch, and press Orca modifier+e keystroke, Orca wonderful hungarian language spokened the current desktop environment announce message. I have got a technical question with future: If Ubuntu specific gnome-orca package debian/patches directory already containing a patch with implementing a function, and need fixing a problem with patched version for a function implementation patch, what place need doing the fixes? For example, if I want easyest attaching a fix, what format you prefer better: a fix with you already doed complete patch, or direct fix patch with original already patched source file (now src/orca/scripts/default.py filename)? Now, I both two way make the patch. This situation need attaching both two style patches, or enough modifying original devian/patches directory already existing function implementation patch? Attila -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Gdm user chooser is first time not accessible before I not press for example Tab or Escape key
Hy, In Natty have gdm-2.32.0-0ubuntu12 package version If accessible login is enabled with screen reader mode, the user chooser list is not accessible for Orca before I not press for example Tab or Escape key. Upstream level already reported this issue with following bugreport, with not fixed yet Gdm upstream developers: https://bugzilla.gnome.org/show_bug.cgi?id=641730 Before I reporting this issue with Ubuntu level, your openion have a chance fix this problem with Ubuntu level or upstream level before final Natty release? Or too short the time to fix this issue before final release? Attila -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Two another 30accessibility related bugs for Natty packaged casper package
Hy Luke, For /etc/skel/.local/share/user-settings.conf file owerwrite related: If for example a Vinux developer would like put this folder a preconfigured Orca configuration file to turn on default beginner users like functions, now used method resulting configuration file owerwriting, because automaticaly I think created a factory setted user-settings.conf file without verifying existing already a live user home directory/.local/share/orca folder an user-settings.conf file. For example, I always turning on default following functions, with not enabled automaticaly: 1. Turning on tutorial messages. 2. Turning on speak child position check box. 3. Turning on speak object mnemonics (result Orca spokening objects mnemonics automaticaly). 4. Decrease speech pitch with 3.0 value. Etc. When live user creating, all /etc/skel folder inside have directoryes and files are copyed right with live user home directory, this is general true, but unfortunately now right putted user-settings.conf file is owerwrited automaticaly without examine have a preconfigured user-settings.conf file or not in /etc/skel/.local/share/orca folder or live user home directory/.local/share/orca folder after live user and home directory is created. So you fix this problem after beta1 is released? Attila -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
