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

[tobi]

On Sat, 14 Apr 2012, Benoît Minisini wrote:
> Le 14/04/2012 01:04, tobi a écrit :
> >
> > Yes, I'm currently exploring svn conflicts, more or less wishing...
> > It's weird that even tough, I reverted everything there are no changes visible...
> >
> > - The thing with the refresh() ncurses routine is that one is able to temporarily leave ncurses mode
> >    (endwin()) and come back later to the exact same state as when you left ncurses. The latter is done
> >    by a call to refresh().
> 
> So you mean endwin() == leave ncurses and refresh() == come back ? Mmm.
> 
> Anyway, I think that the "normal" of gb.ncurses should be the common 
> one, i.e. effectively use ncurses. This is the reason why we should 
> enter ncurses mode automatically during the main hook, and leave it at 
> the end of the program.
> 
> >
> > - For now I did: gbx3 2>err to see what's going on, but a hook seems to be the only user-friendly
> >    solution. Great! (Btw: gb.ncurses programs)
> >
> > - You deem it better to have the signal in the interpreter itself (sorry, didn't dig that far into
> >    it yet)? Hmm, I have to think about the Resize event, there may be several windows in a screen but
> >    only one can be focused. It's easy to let it dispatch the Resize event but if the terminal is
> >    resized when another window - which has no corresponding event handler - is focused, it won't work
> >    at all.
> 
> I would grant you through the interpreter API two functions : one to 
> register a signal handler, and one to unregister it, with a 
> documentation on how to use it.
> 
> Because two libraries may want to handle the same signal, so the 
> interpreter must manage that.
> 
> And then we can imagine that I could make an interpreter API that make 
> the pipe for you, so that you just tell him a callback that would not be 
> a signal handler, but a normal function that can raise event and do 
> whatever you want. I think it is the better solution.
> 
> >
> > - You mean: Don't call GB.Watch() all over again, you have the @focussed pointer.
> >    I definitely missed that approach... (as you can see, I used to change the parameter to the
> >    callback with GB.Watch() to reflect the last focused object, but that's just not necessary)
> 
> Don't forget to reference the focused window while you hold its pointer 
> inside a global variable, and to unreference it when the focus change or 
> when the program ends.
> 
> >
> > - You know better what's an appropriate outward appearance of an object interface, don't hesitate to
> >    tell me ;)
> 
> I will. I have already did. :-)
> 
> >
> > - Yes, I had Application_Read() in mind, too, but the component takes over the whole terminal upon
> >    class load. From then it is obvious that any stdin has to go through that very component.
> >    Nevertheless, I worry about pipes and file redirection that are not possible with the current
> >    NCurses._init().
> 
> Why? Redirecting standard input and output is not useful with ncurses 
> program, is it?
> 
> >
> > I really wish, I could see the code because a few things were added to complete my approach on a
> > Pong game and they rely heavily on the REFRESH() macro :D (But nothing which is not to be fixed
> > within a few minutes with a function)
> 
> You are talking about the conflicts? Sorry for that. Maybe you did a lot 
> of changes that were not committed before I did my own one? I didn't 
> change a lot of thing nevertheless.
> 
> Regards,
> 
> -- 
> Benoît Minisini
> 
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
> 

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.

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.
One word about the naming of internal functions and variables... I have to problem to rename my
functions or yours but I just can't stand two different naming schemes in an integral piece of
code ;) What'd be the way to go?

For my Pong, I added the following:
* Window.Refresh(): Refreshes the screen (rationale: s.b.)
* Window.Buffered: Whether calls to REFRESH() shall produce any output on the physical screen. If
  set, they won't and the user has to use Window.Refresh(), as one would do C ncurses
  (rationale: in games, such as Pong, one may redraw several items after each other in shorter
  time intervals. With my terminal (180*75) this is a rather flickering concern, so during this
  redraw routine one may buffer one's changes and plot to screen once at the end - works
  beautifully with that solution)
* 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)
* Window.PrintCenter(): Takes a string and places it vertically centered (the whole string. which
  means that the middle line of the string shall be the closest to the middle of the screen) and
  horizontally (line by line. means that the middle character of each line is the closest to the
  horizontal centre of the screen) (rational: looks good for initial prompts (it's the way, I used
  it however))

The reason for that I'm telling you now is to leave you a chance to improve their names while I'm
typing - which seems to be most true for the latter two ;)

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.

Regards,
Tobi