--- Begin Message ---
|
Subject: |
Re: [bug-gtypist] ideas, implementations, patches. |
|
Date: |
Sun, 15 May 2016 10:04:42 +0200 |
|
User-agent: |
Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.4 (gnu/linux) |
clutton <address@hidden> writes:
hello Clutton,
trying again to reply to list, despite "Cc: address@hidden"
my last mail didn't seem to have appeared on list :-(
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
--- End Message ---