GEdit OPI plugin

[Yves Jaradin]

Le dimanche 17 février 2008 à 10:14 +0100, Antoine Cailliau a écrit :
> Hi,
> 
> I'm also one of the student who would like to develop a plugin for
> Gedit. Our goal is not to port the Emacs plugin to Gedit, with all
> functionnalities. Our goal is more to do a plugin which will be usable
> for everyone. We would like to keep the plugin quiet simple and
> usable. 
If anything, I feel the Emacs plugin is too short (no intelligent code
completion, no source outline, etc.) To be usable by everyone, a plugin
has to be usable by really everyone, including advanced users. I
wouldn't like to have used it for let's say two years and when wanting
to do something more complex, be told "Umh, you will have to use the
Emacs OPI to do this."
> 
> The idea, as explained by Simon, is to have a browser a bit like the
> console of python plugin, simple and integrated to Gnome. I'm (really)
> not a big fan of the Oz Browser, I think it is a very good browser but
> may be a bit too complicated and, in a gnome environment, a bit ugly,
> not really integrated. 
The main difference between Python and Oz in this respect is
concurrency. While it is reasonnabvle in Python to show the content of a
variable at the time "print" is called, it is mostly useless in Oz as it
makes it difficult to use threads and lazy computations.
A snapshot at the time of call (Show-like) view is easy to produce with
Value.toVirtualString.
Doing something like Browse is more involved.
The (simplest?) way to do it is:
the Browse procedure does all the introspection, and cycle detection of
the arguments and creates a completely ground description which is sent
on a port. When the browsed value becomes more determined, further
descriptions are sent to the port. When the value is too big, Browse
should cut the description and wait on a variable passed to the port
with Port.sendRecv.
The stream associated to this port is parsed to maintain a
representation of the browsed values. This representation can be queried
and asked to be extended using a simpler protocol since it's on
toplevel.
Finally an output component must be written in Oz. It could be a GUI in
Oz (Tcl/Tk or QTk) or it could interface with OPI messages and in this
way with a GUI written in an OPI plugin (in PyGtk for example)
> 
> Have a nice day,
> 
> Antoine C.
> 
Yves