[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vim-dev
Subject:    RE: [vimdev] Re: Vim's future ?
From:       Philippe FREMY <P.FREMY () OBERTHURCS ! com>
Date:       2002-11-06 16:44:22
[Download RAW message or body]


> On Wed, Nov 06, 2002 at 11:30:17AM +0100, Philippe FREMY wrote:
> > > I don't really understand what you mean with "blocking" here.  Every
GUI
> > > normally handles one event at a time.  Vim does the same thing: waits
> > > for a character, does something, then waits for the next.  
> > 
> > The problem, which you seem to be aware of, is that all GUI have an
event
> > loop. They receive events (mouse move, focus, key pressed), they pass it
to
> > the application and expect the application to return, so that they can
fetch
> > the next event.
> > 
> > Vim doesn't have an event loop. It takes one character in one place,
then
> > (almost) blocks until the next character is entered (it then does not
return
> > to the gui). There is a timer that calls a function to tell the gui to
> > process some events, put them in the vim queue and return.
>  ---------------------------------------------------------------------
> 
> Seems to me that usually systems sporting guis support threads in some
> fashion.  How about a thread to handle mouse moves/gui-interactions with
> one thread where the rest of Vim occupies another thread.  Wire
> key-presses into a queue which the "gui-thread" feeds during otherwise
> blocked times to the vim thread, which continues to "think" it has
> normal keypress access.

That sounds like the right solution for kvim. I know Qt can be used with
threads, but you have to manage a protected event queue. The reason we
haven't done it yet is that I have never used threads before. And the hacky
solution was working although not perfectely. Our first step was to have
something working, then to improve it.

Mickael is the one working on kvim now, so he is the one who says if he is
going to implement it. Mickael, what do you think ?

I still think this is not right long term solution. This blocking call to
vim cripples every gui. This adds an unnecessary complexity to the coding of
a GUI for vim. So I would be all for an improvement of vim's internal code.

Thinking more about it, it is not as simple as it sounds. I think Qt works
well with one GUI threads, and other non gui threads. This is not the case
here as both threads would be considered gui threads. Need to check the code
in detail before answering clearly.

	regards,

	Philippe
###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
[prev in list] [next in list] [prev in thread] [next in thread]