Squirrel

Greetings,

This is sort of an anouncement, but since the application (FWB) uses Squirrel/SqPlus quite heavily, it's relevant to this forum I hope.

I've worked with File Workbench on/off for some time and it has turned rather useful (IMHO). So, it's time for the project to go more official.

The app uses Squirrel for macros / addon functionality and there's an interactive Squirrel prompt from which one can control the app. The scripting side is not so documented yet... improvement to come.

More info below. Feel free to try it out (and report issues).

Regards
// ATS.


FileWorkbench (FWB) - Cross Platform File Manager
=================================================

Web site: http://www.assembla.com/spaces/files/FileWorkbench

FWB is an open source, cross platform file manager environment
that works on Windows, Unix/Linux (and other desktop platforms
[for which there is a solid wxWidgets port]).

A large part of the feature set is shared between platforms,
while platform specific parts are handled through interfaces
(to binary plugin objects), specific to a given platform.

Feature subset:

- Configurable main window(s). MiniApps are added into panes in the
  main window layout manager (wxRL).

- Current MiniApps: File browsers, tree browsers, text editors,
  command prompts and event logs.

- Embedded script engine (Squirrel). Several parts of the app have
  script bindings and new commands can be developed/added from inside
  FWB. A script prompt gives interactive testing. Script snippets can
  be attached to toolbars or to the keyboard.

- Deep / recursive file selections. Work with selection criteria
  that spans multiple directories (example: select all *.html files
  that were modified during the last 4 weeks and contain the word
  'football').
 
- Concurrent file operations: Lengthy open / copy / select operations
  run in their own threads and don't block the main UI.
 
- Compound and quick file filtering (show subsets of directories).

- Support for in-place browsing of Zip/Tar/gz/bz2. Support for other
  archive types can be added as plugins.
 
- Single directory or combined tree/file browsing.

- Configurable/extensible file popup menus that makes it easy to
  bind shell / Squirrel scripts to right-click popup menus.

- Generic command prompt. Can host any prompt like Bash, DOS/CMD,
  script prompts, ...etc. The command prompt can interacts with
  text editors and file browsers using script bindings. Examples:
  From a file browser: Goto prompt window on current directory,
  From a text editor: Goto browser window for current file.
 
- Text editor. Based on Scintilla component. Syntax hi-lighting for
  80+ languages. Text editor actions (build, compile, run, ...) can
  be written as Squirrel script snippets.
 
- Open source. If you can improve / add new useful functionality /
  fix bugs, then contibutions / involvement is welcome.
 
 

This is an interesting use of Squirrel outside games.  Can there be more information on this, such as

is Squirrel used to drive the WxWindows GUI framework? Or they are not connected directly

How much code of the whole app is in Squirrel (say comparing to the recent case of the use of Squirrel in a game where Squirrel is used for 80% or more of the logic)...

How well does Squirrel support large software development, if the body of Squirrel code is large?

The scripting model is more build around a number of interface classes (think C++ classes with virtual functions). The interfaces form the applications 'key metaphores'. Squirrel scripts interacts with these interfaces in two ways:

• It uses them (and has a Squirrel class hierarchy representing them)
• It implements them (Squirrel classes inheriting/extending C++ classes)

Extending C++ classes in Squirrel requires some template/bidning trickery but it works fine.

So, the bindings are at a higher level than wxWidgets raw functions. Scripts usually don't interact with wxWidgets directly. Scripting API:s are directly exposed to the user, so it's important that the available APIs don't leave the app in any intermediate states (which wxWidgets call very well may do).

For example, there is an interface class CmdPromptExtI (it extends the functionality of generic command/script prompts). It has overridable functions like:

   OnEnterCommand( ... )  // Allows for preprocessing an input line before sent to std IO object
   OnOutput( ... )  // Allows parsing and acting on output from std IO object
   OnComplete( ... ) // User requests completion of a word/file name/...
   OnPopupMenuOpen( ) // Allows for adding customized items to a popup menu before opened
    OnMenuSelect( ... ) // User has selected an item we added
    OnMouse( ...  ) // Mouse was clicked in command prompt, jump to file/error line/...
    ...

So, to build an custom extension to a command prompt, we implement the parts of this interface we want to override in Squirrel. Then we register our object and through a negotiation process we get connected with the right instances of command prompts. A prompt may have any number of extensions registered with it. The Squirrel class can then do callbacks into the app (adding text in the editor, showing a message box, colorizing output, ...).

Different MiniApps have specific such extension interfaces. But we can also have more generic extensions that registers it's very own commands. The commands are really plain data structures (small Squirrel tables) that the app framework parses and binds with toolbars / keyboard accels (and it can be customized by the user).

Perhaps the most important enabling script/native binding feature is something called Instance Binders. Their job is to make sure that a C++ references and Squirrel references to objects are always safe, and that all object pointers are 'dismantled' whenever an object goes out of scope. Some different ownership models are supported:

• C++ ref counted
• C++ single point of ownership
• Squirrel owned instances

Instance binders also make sure that there are never several Squirrel object representing the same C++ object, and that scripts always have access to the most derived class (a C++ class can use virtual functions in derived classes, while Squirrel classes can not). Some caching of Squirrel objects happens also, so that we avoid recreating the script side of the object each time it is used.

For each case, the object tracking and dismantling logic is slightly different.

Without these instance binders (or something quite similar), it is difficult to provide safe scripting in a larger project.

There's not so much documentation around this except for what is in the source code currently. Probably, from Squirrel side of things, the easiest way to understand what's going on is to read some script snippets in the directory scripts/squirrel/*.nut. I'm working on adding some examples and more documentation to the FWB site.

Regards
// ATS.