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

[Tim Marston]

Hi,

My apologies for not getting back to you sooner.  I'm quite overworked
at the moment.  You weren't being ignored, I assure you.  :)

On Thu, May 12, 2016 at 07:34:31AM +0300, clutton wrote:
> Hi, I have some ideas about how to improve gtypist.

Excellent!

I would be remiss if I didn't also point you towards our general list
of stuff we are thinking of doing in the future, though.  You can find
it here:

  http://git.savannah.gnu.org/cgit/gtypist.git/plain/TODO

> Would you consider accepting patches?

Yes, of course.  Or, if you work with git, you can also make changes
there and we can merge them.

It would be helpful if you work on features separately, though.  For
example, if you submit patches, submit one per feature.  Or, if you
work with git, you could work on each feature in a separate branch (or
just keep track of which revisions make up a feature).

> 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.

This is an interesting idea.

My impression is that the terminal code in gtypist is steeped in
history (it includes command line options to use a terminal's hardware
cursor, or provide its own flashing one, which is outdated to the point
that it's no longer a useful feature at all, I think).  So I'm not sure
how this would work, or whether it would push us to removing support
for outdated terminal stuff.

Also, I'd like to get some other opinions on this.  :)  I quite like
the two-line approach, but I'm probably just used to it.  What are the
benefits and drawbacks of the two approaches?

> 2) Probably autohell improvements, I think it'll be better to test
> 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 think we removed support for ncurses/curses in 2.9 (or was it 2.9.1?)
when we added full utf-8 support.  IIRC, plain curses didn't support
wide characters or something.

> 3) probably more improved window

Yes, we've been discussing abstracting the UI code at some point and
providing different UIs (e.g., curses, GTK).  But this is a slightly
more long-term goal.  We're in the middle of switching to using GNU
gengetopt to handle command line arguments and the configuration file
for version 2.10 (master, in git).  But thus has required that we add
support for internationalisation to GNU gengetopt...

Good to hear from you, and looking forwards to any contributions you'd
like to make!  Get in touch if you have any questions!

Kind regards,

--
Tim Marston
ed.am