[Gambas-devel] Fwd: Re: gb.ncurses feedback?

[tobi]

On Sat, 14 Apr 2012, Benoît Minisini wrote:
> Le 14/04/2012 10:53, tobi a écrit :
> >
> > D'accord with the NCurses.On() and .Off(), they will be removed (see
> > manpage for endwin() for the refresh() thing). With the signal
> > handler as well. And so there shall only be a warning regarding
> > Application_Read() in ncurses programs somewhere.
> 
> An explanation in the documentation will be enough I think. And it's
> logical: if you use NCurses, you should let him handle the input.
> 
> >
> > Being new to svn, the only way out for me was to get a fresh copy - I
> > just haven't seen anything in the code I had on my disk regarding
> > conflicts, which I could have solved manually then. (Will visit the
> > documentation which doesn't appear to reside in its manpages). I'll
> > try to incorporate all the suggestions.
> 
> In the Gambas wiki I wrote a little documentation about subversion and
> how to handle conflicts. Did you read it?
> 

Yes, but I never encountered those conflict comments from svn in the sources. I probably did weird
things anyhow just to see the changes.

> > For my Pong, I added the following: * Window.Refresh(): Refreshes the
> > screen (rationale: s.b.)
> 
> Does it refresh the window or the full screen?
> 

Nasty question. I thought the same yesterday. But there it is, the dilemma:
* I cannot call wrefresh() to refresh the particular window as it could mess up the window
  overlapping. Window redraw should be handled by the panel library
* If I call REFRESH(), everything that has changed will be repainted - but with respect to the panel
  stack. So having it in a window is a bit misleading since hW1.Refresh() will ignore
  hW2.Buffered = True but this is less pain, I think? Of course, this won't allow buffering on a
  window when one paints to another but from my point, Buffered is not meant to be enabled throughout the
  program but only on special places where a lot of changes will assemble and interrupts that would
  draw on another unbuffered window causing a complete redraw anyway are unlikely to occur.
* As a third, I could assume that if a window is buffered, it is the top-most on the panel stack
  because there are a lot of drawing operations, meaning visual effects, so given I assumed that I
  could safely call wrefresh() but I don't tend to assume any behaviour of the user.

> > * Window.Ask(): Gets a string consisting of characters to accept and
> > optionally a @tries variable. When one of the given characters was
> > typed or the tries exceeded, the function will return (Null if
> > exceeded, otherwise a string containing the typed choice) (rationale:
> > saves While loops when the programmer only wants to accept certain
> > keys)
> 
> Strange, but why not?
> 

Imagine:

  hW.Print("Press \'n\' for new game or \'q\' to quit")
  Select Case hW.Ask("nq")
    Case "n"
      NewGame()
    Case "q"
      Quit
  End Select

> > I was also experimenting with the Timer object. Before I continue:
> > May it be worth to have a Redraw event, generated by a
> > window-internal timer (a Redraw property according)? The same thing
> > can, of course, be accomplished by having a timer in the application
> > and I did that, works. It would be a pure feature reducing
> > application source code variables.
> 
> Why not? But same remark. Making the timer in Gambas is not a lot of
> lines of code.
> 

This one will be left out. It's overkill and would save just 2/451 lines in my Pong, not worth any
work.

Regards,
Tobi