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

[tobi]

On Sat, 14 Apr 2012, Benoît Minisini wrote:
> 
> 
> -------- Message original --------
> Sujet: Re: gb.ncurses feedback?
> Date : Sat, 14 Apr 2012 00:21:43 +0200
> De : Benoît Minisini <gambas at ...1...>
> Pour : tobi <tobias at ...692...>
> 
> Le 13/04/2012 23:44, tobi a écrit :
> > Hi Benoît,
> >
> > still collecting bugs? ;)
> > Since you wanted to inspect the code, am I to expect a short feedback (an "OK" would do in the
> > best case)?
> > Writing an application to demonstrate the Window class I felt that the class needs some more stuff,
> > so it was extended and it's really time to know if it is well enough coded to continue or rewrite.
> >
> > Regards,
> > Tobi
> >
> >
> 
> I have just committed some little changes:
> 
> - I centralize the NCurses initialization and uninitialization in two
> routines.
> 
> - I replaced the REFRESH() macro by a function that checks that the
> library has not been unitialized. Otherwise calling NCurses refresh
> routines after endwin() does strange things to the terminal.
> 
> - I added an interpreter "error hook" that calls endwin(), so that the
> error message is printed by the interpreter on a clean terminal.
> 
> So that you can install the SIGWINCH signal correctly, I will add to the
> interpreter API the needed calls to the interpreter routines that will
> do that for you.
> 
> Then you will need to create a pipe. The signal handler will write to
> the pipe, and you will watch the pipe output and raise event from there.
> 
> Only an object can raise event. I think the Window object that is
> actually the screen will raise the Resize event when the SIGWINCH signal
> is received.
> 
> If you want a window to raise a Read event when a key is pressed, you
> just have to watch the standard input *once*, and then send the event
> from the currently focused window. You don't need to change the watch
> callback!
> 
> Beware that the standard input is automatically watched by the
> interpreter if the user defined a global Application_Read function in
> the startup class. Your callback will replace it, and the
> Application_Read function will never be called.
> 
> I will have other remarks about the function and properties name for
> sure! :-)
> 
> 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
> 

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

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

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

- You know better what's an appropriate outward appearance of an object interface, don't hesitate to
  tell me ;)

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

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)

Regards,
Tobi