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

List:       vim-dev
Subject:    Re: using vim with gtk2, gnome2, bonobo
From:       Mickael Marchand <lists () freenux ! org>
Date:       2002-11-20 17:14:21
[Download RAW message or body]

Hi,

Le Mercredi 20 Novembre 2002 17:11, vous avez écrit :
> On Wed, 2002-11-20 at 03:59, Philippe FREMY wrote:
> > Jason, do you plan to put the bonobo code directly in vim or will you
> > make the bonobo component use the GtkSocketPlug to access the vim ?
>
> Hi Philippe,
>
> I am planning to put the code directly into vim.  As far as I understand
> it, the socket/plug approach offers no capability to merge the menus and
> toolbars into those of the container application -- it's pretty much
> just like embedding an X-Window, right?  But by putting the bonobo code
> directly in vim, this should be possible.
>
> What approach did you take with kvim?  I saw in (some) of your
> screenshots that you have toolbars.  Did you have to write your own
> toolbar code in kvim, or were you able to use some of the code in vim
> for that?
let me answer to that :)

the vimpart uses the kpart technology, we have a real/complete kpart as KDE 
wants it which is a fully independent widget. This widget starts and embeds a 
GUI vim (the gvim window is created then embedded in the kpart widget) then 
it communicates with vim using clientserver and/or DCOP (KDE communication 
system)

in our 'kpart' we can define 'actions'. An action is a menu entry and a 
toolbar entry. KDE takes care of building the toolbar and showing/hiding 
active actions. 
Sadly for each Vim "action" (feature), we need to redefine a KDE action in our 
kpart which translates that into keystrokes, send them using clientserver (or 
DCOP) then vim processes it

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

I've been thinking today (while reading the thread) to xparts which has been 
developed one or two years ago. 
I never used them (but Phil worked on them), so maybe I will tell some 
mistakes :)
These were designed to be a portable model of "components". It allows 
konqueror to embed gecko (mozilla's renderer) for example instead of the 
default khtml. XParts were done to be usable with any toolkit (GTK,KDE, 
Motif...). Sadly noone used it... (it's still in KDE's CVS, module 
kdebindings)
If we could fix the event loop stuff in Vim GUI then we could make a common 
XPart that we could use in gnome and in kde and other toolkits and we could 
do everything we wants with Vim, controlling directly Vim without the need of 
a communication system. 

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

IMHO, xparts are the only good way to make a "usable and usefull" component 
with Vim. 
We really do need in-process, we need to be "inside" Vim to make a good 
integration.

I want to believe this is a possible thing ;)

Phil, did I say something wrong ? 

Mik

-- 
Mickael Marchand, marchand@kde.org, marchand@freenux.org
KVim maintainer, http://freehackers.org/kvim
"Leading Vim to the K Desktop Environment !"

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