Re: [bug-gtypist] ideas, implementations, patches.

[Felix Natter]

clutton <address@hidden> writes:

hello Clutton,

Sorry for the delay, I am somewhat busy in my day job.  What geoffroy
said is definitely true: We welcome new developers (and users) and you
definitely won't be ignored :-) Also, having a "good company" among
developers and users is one of our goals for this project :-)

> Hi, I have some ideas about how to improve gtypist.

Sounds good! Currently it is difficult to add new CLI options (master
branch) because the command line parsing code is generated using a
development version of GNU gengetopt (Tim add the ability to translate
--help output which AFAIK has not yet been merged upstream).

--> @Tim: shall we switch back to manually handling options until this
is fixed?

> Would you consider accepting patches?

Sure! But we may ask you to check the users' opinion and to clean up a
bit, so that we can continue to maintain the code.

> 1) Two lines typing should be reduced to one, something should be done
> with init_pair to make colours, I mean that after you typed it it'll be
> nice to shade it a little, and highlight the current letter with
> cursor, I don't know yet, how is better need to try.

I think this is a good idea, but I think we should make this change
optional. *What do the users think about this? Please join the
discussion?*

You will have to write alternative implementations of do_drill()
and do_speedtest() and modify other parts of GTypist.

One thing that would be easy to do and easy to add optionally [1] is
color support in drills ("two-line" or "one-line") which would be good
IMHO.

[1] e.g. Tim (another developer) mentioned that he would not like
coloring so much.

> 2) Probably autohell improvements, I think it'll be better to test

There is one thing we would really like to fix in auto*:
A gentoo user complained that if you disable Native Language
Support (--disable-nls), then not only translation support
is disabled, but UTF8 support is broken, too. See [2].

A patch for this would be very welcome! If you don't do it,
then I will do it.

[2] https://lists.gnu.org/archive/html/bug-gtypist/2016-01/msg00002.html

> capabilities of library, and make decision if this is ncursesw. Include
> headers <curses> rather then ncursesw, but link to ncursesw if we have
> ncursesw otherwise don't build at all. In that way it'll work
> everywhere (BSD, Solaris), without hacking around.

I am not sure I understand this: Does BSD not have ncursesw (we need
ncurses*w* for the essential multibyte support)?

> 3) probably more improved window

What do you mean by this?

Looking forward to your improvements and ideas.

Cheers and Best Regards,
-- 
Felix Natter