From: Phlip <phlip_cpp@...>
Date: 2001-12-31T14:41:32+09:00
Subject: [ruby-talk:29811] RE:  FXRuby FreeRIDE Spike uploaded.

Curt Hibbs sez:

> http://www.rubyide.org/cgi-bin/wiki.pl?FoxSpikeDiscussion -- but I
> thought I would start here as other's may have some input as well).

Use newsgroups for temporary question-and-answer and Wikis for permanent
results.
 
> Background:
> Rich Kilmer did a Spike of his own using the Scintilla editing component
> (http://www.scintilla.org/) wrapped in ruby code. This seems like a very
> viable approach since the Scintilla component is 1) written in C; 2)
> specifically designed to be embedded; 3) Scintilla is designed for code
> editing and already has the features you would expect; 4) there is a Fox
> port of Scintilla (currently in beta).

Si.

> My basic questions to you and others are: - What a the relative merits
> of using the c-based Scintilla as FreeRIDE's embedded editor vs. an
> editor written in Ruby? - If a pure-Ruby editor was the best way to go,
> what about starting off with an existing implementation?

Wha? Which do you mean?

 - everything's in ruby down to the display graphics - Ruby hosts some
 toolkit's editor
 - Ruby hosts a toolkit and an embedded 4th party editor

If that's what you are saying, I'd prefer the middle one. It's the
difference between primitive details and higher-level app-specific ones,
or getting features crammed down your throat.

My RUedit concept, based on UEdit, is that the core editor exposes to the
embedded language a set of primitives. "loadFile(fileName)", for example,
tries to load a file into a new buffer and throws a simple exception if it
fails. So one writes the Open File method like this:

ue.addCommand ("Ctrl+O", ['File', 'Open']) { |ue|
	 fileName = chooseFile
	 if fileName != nil then
		 ue.newBuffer.loadFile fileName
		"`#{fileName}' loaded"  #  `' so spaces are visible
	 else
	 	'canceled'
	 end
	 }

The editor provided primitives and between >every< command and the
primitives is a bit of script, no matter how short, written >inside< the
editor.

When you used UEdit, if you thought of a keystroke you needed for the task
at hand, you wrote it on the spot. If it was generic, you saved it. Edit
heaven.

> Keep in mind that the editing component of FreeRIDE is one of many
> components (obviously its a highly visible component of central
> importance). We want to build FreeRIDE with a central plug-in
> architecture where most (if not all) features are implemented via
> plug-in components. This would include the editing component.

I would not have a problem with putting every plug-in inside an
'addCommand' call. require the library needed, warm it up, and stick it on
the screen. But...

Lapidary must be integral, below the level of 'addCommand'. We are going
to be test-first, right?

I envision any debuggery to invoke a Lapidary GUI with a sliding green
bar. If it fails we stack the failures up in a list box, and when the user
enters on one (or double-clicks on it) we navigate to the offending line
of code.

Even if the error were inside an 'addCommand' in our own keystroke set.

> My next step on the FreeRIDE wiki is going to be to take the current set
> of comments/ideas/features/etc. that have been contributed to the
> FreeRIDE wiki (http://www.rubyide.org/cgi-bin/wiki.pl) and organize them
> into line-item features/tasks that we can categorize and order by
> priority, such that work can begin on the most critical pieces first.
> 
> Once the core plug-in architecture is in place, the other pieces
> (implemented as plug-ins) can be worked on independently. There could
> even be multiple implementations of a component (like the editor),
> although I wouldn't want to encourage that at the beginning because it
> would be better to maximize our results by not duplicating work. But
> certainly, someone may wish to propose a new feature by doing a Spike
> implementation as a demonstration.

Do you know "kant" - the KDE Advanced Editor? If so, do you like it?

I tried to work on it when it first started. And I tried to like it. But
its author succeeded in getting KDE's maintainers to add "kant" to their
CVS head.

I could never compile that f5g head just to compile "kant". I would have
needed to quit my day job (or get a divorce) just to keep up with it.

Worse, the other developers took off with just the "plug-in architecture"
you envision. I consider the program heavy, inflexible and user hostile
now, whenever I can manage to compile one.

Fear BigDesignUpFront. Collate your feature list, but pretend we have a
customer, and that she wants real features to type with now, not internal
architectures. She wants to start with a simple editor with 'addCommand'
in it. Write that, test-first. Ruby plugs in already for us, so
refactoring in that direction after we have something simple with an
agreeable UI will be easy.

-- 
  Phlip                          phlip_cpp@yahoo.com
          http://www.greencheese.org/ParodyMode
  --  Personally qualified to snub Mensa  --