torios team mailing list archive

[Israel Dahl <israeldahl@xxxxxxxxx>]

Hi both,
(inlines)
On 7/22/20 8:19 AM, ml@xxxxxxxxxxxx wrote:
> On Wed, July 22, 2020 12:20 am, Paul Sutton wrote:
>> So we have some text to speech support what about OCR support if that is
>> more mature
> Tesseract comes to mind for OCR.  There are others too, but none of them
> seem to match the quality of a commercial solution.
>
> I also recently ran across this library:
> https://github.com/liblouis/liblouis

Wow, Braille?  That would be awesome to include everything like this in
a specific accessibility-centric distro!

I know TTS (and vice versa) is spotty.  TTS options like espeak are ok,
and have huge capability.... but the Speech to Text is, as you say. 
Though I think Mozilla is working on something in that realm, IIRC.

What about modifying an existing solution, like gettext.  Perhaps make a
wrapper library that uses gettext, but also can TTS (I can't remember
the base lib for espeak off the top of my head) by
overloading/inheriting the function.  Then you could simply patch
programs to use it, instead of the default gettext.

>> Can we make it really easy to switch between boot to gui and boot to cli
>> pleasek  there is an option on the raspberry pi configuration tool (which
>> has both a curses (text) and gui widget, you just click a tick box.
> On Debian I do that by installing and uninstalling the login manager. 
> Haven't run across any Linux distributions that offered an easier way to
> do it.  Have seen distros that let you swap window managers easily.

We would need a different login manager.  LightDM is cool, but limited
in those areas.  We would need something from scratch, unless someone
knows of a display/login manager that handles that?


>>> Make a collaborative effort.  It doesn't need to support more than you
>>> want.  A simple dialog-type library that can be easily used in more
>>> complicated programs would be great!
> What would we need beyond what's already available in current dialog style
> libraries?  Maybe we should look into adding things to a project that is
> already out there rather than starting from scratch.  I thought yad
> handled a lot of things.  There are also projects like Electron and NW.js
> that could be used to create custom screens and script with them.

Then, I suppose we need to focus on toolkits, and making toolkits
adaptable, as well as running on non X11 platforms.


>> So if we find the ones with similar goals, and can work together,  this
>> may prove that idea works and other groups of distros may be inspired to do
>> the same in their way.
> Might be a good time to quantify our goals then.
>
>> agreed here,  the lxde people told me when i mentioned this on sourceforge
>> that there is a perfectly good text file to manually edit the menu,  this
>> is exactly the attitude that makes Linux seem elitist rather than for
>> everyone.
> I happen to like a good XML file myself (like the one jwm uses).  I've
> seen a few menu editors around.  Again, might be good to catalog what's
> out there and see if we can add features to an existing project rather
> than starting from scratch.

I actually meant common libraries to generate menus from desktop file
entries.

There are no libraries dedicated to Linux specific stuff (XDG stuff in
particular), so finding out a user's bookmarks, or generating a menu is
something you just do however you want.  It would be nice if there were
libraries (not tied to GUI toolkits) for common GNU/Linux operations.


>>> Think about it, if Debian, RHEL, Ubuntu, Suse, and Arch worked together
>>>  on a safer chroot/jail that worked cross distro, it would help
>>> everyone.
>>>
>> Good point,  I am guessing this is like running each application but
>> keeping the application isolated from other apps and to some extent the
>> wider system, for security reasons.
> There's proot which is supposed to be a safer chroot.
>
> Applications working together from different distributions sounds a lot
> like what Bedrock Linux is doing.

I meant different distributions working on the *SAME* *applications*.

I know this is done (GTK for example, though it is pretty much RHEL's
toolkit)

Remember the whole Mir/Wayland debacle?  I think it is fine for each to
work on their own thing, but should have made a COMMON library they both
used, and kept their specific use case code  in their separate
libraries.  Both need common things, and could have written both
together to keep similar API calls, etc...


-- 
Regards,
 Israel