RE: [FR-devel] My thoughts... (re-sending)

[Curt Hibbs]

Hal E. Fulton wrote:
>
> Hello, all.
>
> Many thanks and much appreciation to
> you who are making FreeRIDE happen.
>
> So far I've been very unhelpful in the
> development of FreeRIDE. But it's a
> project I believe in very much.

Until recently we really haven't had a stable and usable foundation for
devlopers like yourself to use.

> Two questions I have for the community
> are:
> 1. What can we do to make installation
> and configuration as painless as possible?

Yes, yes, yes -- I'll add my comments to your expanded descriptions below.

> 2. What subproject should I work on to
> make a genuine contribution to FR?
>
> To expand on this a little:
>
> 1. Painless installation
> I'm a *huge* believer in this. Lately I
> can't even get FOX to compile properly
> on RedHat 8. That means that I can't even
> dream of using FXRuby, and thus can't
> begin to use FreeRIDE.
> Normally I don't like to have my intelligence
> insulted. But when it comes to installing
> a software package, I say: Insult me! Give me
> something so easy that a drooling idiot could
> use it. Sure, I have a master's degree in
> computer science. That doesn't mean I always
> want to go poking around in makefiles or shell
> scripts or C source. I could probably fix it
> given enough hours or days or weeks. But I
> just want it to work simply, out of the box,
> as advertised, no errors, no warnings, no
> fine print.

Well, this is primarily why I am still a Windows users and a Linux wanna-be.
And, in fact, the Windows installer for FreeRIDE does simply work out of the
box.

> And yes, I know that is easier said than done.
> But it is a direction we should at least move
> toward.
> Where dependencies are concerned, we should
> (perhaps) have code that will determine a) whether
> a package is installed, b) what version it is,
> and c) is this version adequate for this install.
> I wouldn't mind seeing a tool that would actually
> go to the net and grab the latest package and
> install it. Maybe we could depend on an existing
> tool like raainstall (though I haven't played
> with that one much).

I think we should use the same approach on Linux that we are using on
Windows (Rich gets the credit for this, not me). FreeRIDE should be
independent of the user's Ruby installation by including its own private
build of Ruby that includes all of the needed packages.

>
>
> 2. My understanding is that even if/when we
> ditch FOX, we'll still be married to Scintilla.
> I've looked at the API for this, and it seems
> rather obtuse to me.
> I can't help but feel there is room for at least
> one, perhaps two levels of Rubyesque API on top
> of Scintilla.
> That's where I'm leaning toward wanting to work.
> Comments? Laurent, Curt, Rich, anyone?

You should talk to Rich about this as he is doing some work in this area
right now.

> These levels would be used in two or three ways,
> depending on how you look at it: 1. "Code assist"
> stuff -- user types a partial statement and the
> editor optionally responds with a fillable template
> or some such thing. 2. Refactoring support. When
> refactoring is done, the code ultimately has to be
> manipulated at the textual level. 3. Simple user
> scripts such as shortcuts, templates, and macros.

Many of the more complicated things (like refactoring) will depend heavily
on a good Ruby code parser. We are currently using ripper, but we have
problems with it and would like to replace it. We really should be using the
real Ruby parser (the one Ruby itself uses). Bob Calco was supposedly
working this, but I haven't heard anything in a long time, so it may be that
someone else needs to pick this up.

Some of the simpler things you mentioned (shortcuts, templates, macros,
etc.) might fit in with something I was planning to do soon -- a preferences
framework. Right now, these preferences are being set by manually editing
each plugin's yaml properties file. Many plugins will want to allow the user
to set preferences or configuration information. Rather than have each and
every such plugin roll its own, I want to create a generic GUI preferences
facility that provides a simple way for each plugin include its settable
properties without having to do the GUI grunt work.

Curt