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

List:       vim-dev
Subject:    Re: using vim with gtk2, gnome2, bonobo
From:       Jason Hildebrand <jason () peaceworks ! ca>
Date:       2002-11-20 19:01:15
[Download RAW message or body]

On Wed, 2002-11-20 at 11:14, Mickael Marchand wrote:

> The problems we encounter (and which you may face soon) are :
> 1 - we have no idea of what is really doing vim (--remote-send does not give 
> any feedback).
> 2 - there are concurrent access issues : what happens if the user is doing 
> something while the component tries to do something else (imagine the user 
> typing in one buffer and then the component 'decides' to switch to another 
> buffer)
> 3 - our kpart is a special widget (let's call it a hack written by Trolltech 
> and never finished, and apparently they won't finish it soon) which uses the 
> standard XEMBED to embed the (k/g)vim window. 
> We have huge troubles with that part ... I think GTK1 (and 2 ?) has a much 
> better implementation than Qt's one (our gvim can sometime starts out of the 
> embedding application, this is quite ugly...).
> 4 - performance : sending commands with --remote-send is very long (at least 
> when sending many commands), we used Vim's clientserver code to improve that 
> (rewriting the --remote-send command in the component itself) and/or DCOP 
> (DCOP seems more reliable and full-featured btw, see below).
> 5 - signals : Vim is not able to say : "he, I opened a new file" so that your 
> component can transmit it to the embedding application.
> In KDE, we have DCOP signals which I use to know when Vim got new text and 
> when the cursor moved for example but this is a bad hack ...

In my gnome-vim implementation I had these same problems, which is what
has led me to pursue putting the bonobo code right into vim.

When I referred to implementing it as an "out-of-process" component, I
meant that the vim instance will run as a separate process from the
containing application (as opposed to an in-process component which is
part of the same executable as the container app), not that I will be
running the vim instance via remote-control.

> Vim is far from usable as a component even if you can graphically show it as 
> an embedded component. The worst problem will be the control of Vim. 
> Quick example : the component asks Vim to open a file, the user works on it, 
> then opens another file with :e myfile.txt, hey :) the component can't know 
> it and still believe you are on the first file ;). I let you imagine what can 
> happen after that when the component sends other commands :).

These are the kinds of problems I hope to solve in this implementation. 
Since the bonobo code will be "inside" vim (which is a good way of
putting it), I'll be able to keep track of the original buffer with
which the component was activated.  We should be able to generalize
this, so that other component models (kparts, xparts, COM) can use this
code, too.

-- 
Jason D. Hildebrand
jason@peaceworks.ca

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