[FR-devel] Re: FXScintilla interface (was: First Post)

[Richard Kilmer]

Lyle, Gillis, et al-

Sorry for the delay in this...I was in fact working on the iface_gen.rb 
file (Ruby generator for Scintilla.iface).  Anyway, this file is part 
of the FreeRIDE project and is available in the CVS repository located 
on Savannah.

http://savannah.nongnu.org/projects/freeride/

I have reworked the generator quite a bit to get rid of CamelCase 
methods and replace them with underscore_methods and alias the set and 
get methods with Ruby accessors (foo, foo=, foo?, etc) which aligns 
more with the 'Ruby way'.  I have posted the API here:

http://www.infoether.com/ruby/freeride/scintilla_doc/

These are only the (two) generated mixin modules. The first mixin is 
the Scintilla module which gives you the Ruby API for sending messages 
based on calling methods.  To use this you simply mix it into a class 
that implements 'send_message(id, wp, lp).

There is now an ScintillaEvents module that you can mixin to give you a 
better API for handling events.  You just dispatch the fxscintilla 
'scn' object to the handler method like this:

scintilla = FXScintilla.new(myframe, nil, 0, 
LAYOUT_FILL_X|LAYOUT_FILL_Y)
scintilla.connect(SEL_COMMAND) do |sender, sel, scn|
  MyHandler.new.handle_notification(scn.nmhdr.idFrom, scn.nmhdr.code, 
scn)
end

class MyHandler
  include Scintilla::ScintillaEvents
end

This mixin gives you empty methods you can override with a nice syntax:

def on_style_needed(position)
end
def on_char_added(ch)
end
def on_save_point_reached
end
def on_save_point_left
end
def on_modify_attempt_ro
end
def on_key(ch, modifiers)
end
def on_double_click
end
def on_update_ui
end
def on_modified(position, modification_type, text, length, lines_added, 
line, fold_level_now, fold_level_prev)
end
def on_macro_record(message, w_param, l_param)
end
def on_margin_click(modifiers, position, margin)
end
def on_need_shown(position, length)
end
def on_painted
end
def on_user_list_selection(list_type, text)
end
def on_uri_dropped(text)
end
def on_dwell_start(position)
end
def on_dwell_end(position)
end
def on_zoom
end
def on_pos_changed(position)
end

I also wrote a 'port' of the setup done for SciTE on the component 
based on parameters.  These are all found in the fxscintilla directory 
under:

freeride/plugins/rubyide_fox_gui/fxscintilla

There is a fxscintilla_test.rb file that creates a FXScintilla widget 
and sets it up to syntax highlite Ruby code.

If you look in the freeride/plugins/rubyide_fox_gui/fxscintilla/util 
directory you will find my emitter.

This is what we are using for FreeRIDE.  If you want the API 
wrapped/emitted just use the iface_gen.rb file to generate the 
scintilla_wrapper.rb file.  That may be enough for the FXRuby 
distro...that is up to you Lyle.

Best,

Rich

On Wednesday, April 30, 2003, at 03:59  PM, Gilles Filippini wrote:

> "address@hidden" wrote:
> > On Tue, 29 Apr 2003 08:13:54 -0400, Richard Kilmer 
> > <address@hidden> wrote :
> >
> > > Just a note for you (and others).  I just refactored the Scintilla 
> > > API
> > > (it is generated) in a major way (got rid of CamelCase by emitting
> > > underscore_methods). Also, I am going to modify the EditPane to 
> > > support
> > > an 'extended' API which will surface ALL of the Scintilla methods to
> > > enable exactly what you are talking about without changing the core 
> > > code.
> > > Will upload all that later today.  Oh, and my updates to Scintilla 
> > > bring
> > > it up to current (FXScintilla) scintilla.iface format (including a 
> > > nicely
> > > generated event handling mechanism.
> >
> > Rich & Gilles,
> >
> > I admittedly haven't paid much attention to the maintenance of the
> > 'fox/scintilla.rb' file included with FXRuby, since I personally 
> > don't use
> > the FXScintilla widget much. I do make a point of updating its 
> > contents from
> > the latest 'Scintilla.iface' file whenever Gilles makes a new 
> > FXScintilla
> > release, and I'm using a translator script (named 'iface.rb') that 
> > Gilles
> > updated for me recently.
> >
> > The question is, should I instead be using Rich's translator script? 
> > Does it
> > matter? I just want to do what makes sense here, so that we don't 
> > have two
> > completely different APIs floating around ;)
> >
> > Thanks in advance for your guidance,
>
> Lyle, use whatever translator script you want. I've had to maintain my
> own script just because I didn't succeed obtaining the Rich's one. When
> his script is made public, I'll have a good reason to drop mine.
>
> Cheers,
> _gilles.