That will only work if programs adhere to UX guidelines.
15.11.2018 13:30 tarihinde Dick yazdı:
> i think the chance ereactos has is to develop accessibility as part of
> the os instead of depending on a screenreader. when reactos does all
> accessibillity stuff itself it can make things
i think the chance ereactos has is to develop accessibility as part of the
os instead of depending on a screenreader. when reactos does all
accessibillity stuff itself it can make things accessibel that are not
accessibel with screenreaders because the accessibility is built into the
os
Stefan, I know the aim of ReactOS. However, Windows XP setup lacks
accessibility and this is a new functionality to ReactOS. Hence no
compatibility issues. In addition, you cannot use ReactOS setup to
install Windows XP nor vice versa.
15.11.2018 13:05 tarihinde Stefan L. yazdı:
> Hi,
>
> you
Hi,
you might want to take a look at the goal of ReactOS again. Out current
focus should target that goal. Writing screenreader stuff should be the
same task and use exactly the same OS functions as in Windows. Thus,
develop screen readers for Windows (possibly replacing / extending windows'
gui
Windows NT console API is based on Matrix TUI concept, not TTY serial
(means you get to handle line buffering yourself). However, unlike
userspace, we can modify setup however we like as long as it has the
desired end result.
Yours, faithfully
Erkin Alp
why not just run brltty driver in the boot process? when installer is
textmode the only thing would be it has to be able to detect the
usb/serial braille display
___
Ros-dev mailing list
Ros-dev@reactos.org
assume all 8 dots may be input or
> output over the single channels most compilers support.
>
> -- Original message--
> *From: *Erkin Alp Güney
> *Date: *Thu, Nov 15, 2018 1:04 AM
> *To: *ros-dev@reactos.org;
> *Cc: *
> *Subject:*Re: [ros-dev] no replies about
I'm not saying it isn't possible to support the hardware, just I have not seen
any pre-boot environment that the installer might need to communicate with
attempt to provide this support, so it is also available to whatever gets
installed, after reboot. The installer may be fine using only 6-dot
Braille will not be output by GPU, it will be output by CPU onto either
USB or serial Braille bumper. Two different output channels may use two
different codepages. If they were somewhat dependent as in multi-monitor
situation, you would need to drive both via GPU. However they are
independent
The console itself is still a graphical user mode app; it or a DOS box simply
uses a DefConsoleProc (sic) instead of DefWindowProc behind the scenes to
manage the GUI aspects and system menu, and may use an OEM code page instead of
an ANSI one in full screen mode. Windows may eventually be able
Interesting! So I was *completely* wrong ;).
How would *you* go about making the installer accessible?
Den ons 14 nov. 2018 kl 19:10 skrev Erkin Alp Güney :
> WINE's accessibility stuff is handled by underlying desktop's UI kit,
> not by WINE itself.
>
> 14.11.2018 17:51 tarihinde Magnus
WINE's accessibility stuff is handled by underlying desktop's UI kit,
not by WINE itself.
14.11.2018 17:51 tarihinde Magnus Johnsson yazdı:
> Jumping in here with a quick reply as a *lurker*, not a developer:
>
> Don't think anyone would mind if you supplied patches :). You have to
> understand,
why not? i am not a programmer myself, but maybe there is a
workaround(emulating graphics mode but not displaying them for example),
maybe things that are not possible in microsoft windows can be made
possible in the windows-environment reactos creates
On Wed, 14 Nov 2018, Javier Agustìn
You can if you implement a Win32 to console translator. Nothing is
impossible.
14.11.2018 20:13 tarihinde Javier Agustìn Fernàndez Arroyo yazdı:
> This is not Linux, Windows software can NOT run with no graphics ;)
>
___
Ros-dev mailing list
This is not Linux, Windows software can NOT run with no graphics ;)
El mié., 14 nov. 2018 17:36, Dick escribió:
> of course, you are right. but like in linux, much software can be ran
> headless without graphics.
>
> On Wed, 14 Nov 2018, Erkin Alp Güney wrote:
>
> >> the main problem of
of course, you are right. but like in linux, much software can be ran
headless without graphics.
On Wed, 14 Nov 2018, Erkin Alp Güney wrote:
the main problem of screenreaders is they have to find out what
developers had done to make an app accessible. for example, when a
screenreader give
> the main problem of screenreaders is they have to find out what
> developers had done to make an app accessible. for example, when a
> screenreader give access to firefox version 40 that same version will
> probably run into problems when running version 60, the screen reader
> needs to be
Hi magnus,
unfortunately this is not how screenreaders work. screenreaders rely on
accessibility libraries built into the operating system. running a windows
screenreader in linux will not work, you need to use orc(the linux
screenreader).
fortunately some realy helpfull packages are already
The installer itself needs to be accessible enough. WINE does not use a
Windows style installer by itself.
14.11.2018 17:51 tarihinde Magnus Johnsson yazdı:
> Jumping in here with a quick reply as a *lurker*, not a developer:
>
> Don't think anyone would mind if you supplied patches :). You have
Jumping in here with a quick reply as a *lurker*, not a developer:
Don't think anyone would mind if you supplied patches :). You have to
understand, with people still working on kernel things, making applications
actually work, stop crashing, hardware support...
Most that would interface with
20 matches
Mail list logo
