Re: [orca-list] GUI Redesign or clearup and modernization
- From: Devin Prater <r d t prater gmail com>
- To: "B. Henry" <burt1iband gmail com>
- Cc: orca-list gnome org
- Subject: Re: [orca-list] GUI Redesign or clearup and modernization
- Date: Tue, 1 Sep 2015 22:46:03 -0500
My biggest problem with Orca is the braille support. Orca can't even do word-wrapping, so it cuts off words
at the end of lines, making braille reading a very uncomfortable experience. Even Apple does braille fairly
well. Are y'all gonna let Apple, a proprietary company with a little accessibility newbies beat you? This is
the kind of stuff I'm talking about, the embarrassing shortcomings of Linux accessibility.
Sent from my iPhone
On Sep 1, 2015, at 12:24 PM, B. Henry <burt1iband gmail com> wrote:
Well, it's not unreasonalble to ask users to read a bit of documentation to learn a keystroke or two when
trying a new desktop, but unless I'm missing
something folks like myself who use a window manager such as fluxbox and fill in accessibility gaps with
custom scripts would be left out in the cold if
an orca prefs window was done away with.
There are some people using hardware that performs much better running something very light lie this, and
while I can run gnome and even unity with
pretty good responsiveness I have a nicer experience with my fluxbox, and was hoping to turn my setup in to
something others could instal easily on
their distro's minimal installation option, e.g. the debian net-install or a basic talking-arch
installation.
I get that moving prefs to gnome or mate control center is neater on a philisophical level, but is this
somehow much easier for devs? I do not see that
it is easier on end users, perhaps not harder, but not an improvement, and certainly not one that is great
enough that is worth forcing others to
abandon their graphical environment of choice.
There are some people who onlly start orca on demand with one or a few gui aps, e.g. firefox, folks who
prefer to do everything they can in CLI consoles
who would also be left out in the cold.
--
B.H.
Registerd Linux User 521886
kendell clark wrote:
Sun, Aug 30, 2015 at 07:58:23PM -0500
hi
This sounds good to me. Although I don't mind the current orca layout,
being able to change orca settings in the same place I cahnge all otehr
settings would definitely be handy.
Thanks
Kendell clark
On 08/30/2015 05:55 PM, Luke Yelavich wrote:
Re-sending to list, forgot to reply to list.
On 28 Aug 2015, at 8:37 am, chrys87 <chrys87 web de> wrote:
Howdy,
nomnom :) a redesign is a fully redesigned new GUI. so almost written from scratch. newly designed code,
and maybe layout (i looks really stalled, i do not use orca often. but my girlfriend do, she dont like
it because a "card layout" its not the best in things of navigation. I agree with her that a more "list"
orientated layout would be more efficient (also in things like we are more able to keep things more
generic in the codebase, what lead to more easy contribution to orca).
A "clearup and modernization" its mosstly clean up the really stalled code ( its hard to integrate some
new things, thats what i learned in my work on the orca beeps). no real name convention, confuse names
(combobox1, combobox2, combobox3), fix warnings while start the GUI, port to more current techniques. :).
I’d be interested in having a look at what you are working on. I have been working on a GSettings backend
for Orca for a week or so now, just about to start the actual coding, after much planning and writing out
the GSettings metadata. Longer term, to properly support individual desktop environments offering Orca
settings in their system settings control panels, it may be worth moving settings management, both in the
storage and retrieval of settings, as well as presenting settings in the UI to a C library. The desktop
environments that work with Orca now are written in either C/GObject C, or C++. Orca itself would make
use of this C library, and with some planning, we could develop an API that allows a the settings for
Orca to dynamically be presented and updated, such that any new settings only need to be added to Orca,
and the UI in the desktop environments dynamically updates based on what they retrieve via Orca’s
settings API. This library would then take care of s
toring th
e settings, most likely in GSettings.
I suspect one reason why some people are against individual desktop environments offering Orca settings
in their control center, is due to the possibility of Orca settings being out of sync with what is
offered in their control center. I’d argue that it would not be too far fetched, and not too difficult to
implement things such that desktop environment developers only need to implement Orca’s settings API
once, and then any new settings Orca offers are automatically presented when they are added to Orca.
Would that be enough to convince you folks that using the control centre of your desktop environment to
change Orca settings is the way to go?
Luke
_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html
Log bugs and feature requests at http://bugzilla.gnome.org
_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html
Log bugs and feature requests at http://bugzilla.gnome.org
_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html
Log bugs and feature requests at http://bugzilla.gnome.org
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]