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

[Benoît Minisini]

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