GUI

Description

SuperCollider currently supports three operating system platforms: Macintosh OSX, UNIX (Linux and FreeBSD) and Windows (with some limitations).

Graphical User Interface (GUI) code, for the most part, does not need to worry about which platform is executing the code because of the view redirect system. At any time, one and only one GUI kit is active. This determines which GUI classes will be used for rendering. These classes, the active views, have prefixes for the GUI kit that created the view object: SCWindow vs. JSCWindow vs. QWindow.

GUI kit	Code to activate	Supported platform(s)	Framework	Prefix
Cocoa	GUI.cocoa	Mac OSX only	Cocoa	SC-
SwingOSC	GUI.swing	All	Java + Swing	JSC-
Qt	GUI.qt	All	Qt	Q-

In general, users should not concern themselves with the prefixes. Instead, work with the redirect classes, which have no prefix: Window, Button, Slider, etc. The redirect class will ask the currently-selected kit which implementation class should be used.

The GUI kit (CocoaGUI, QtGUI, SwingGUI) maps the generic view names to the implementing classes: Window --> SCWindow, QWindow or JSCWindow. These schemes are in turn used by ViewRedirect to provide a simple cross-platform gui syntax. The GUI class provides utilities for switching kits and other cross platform tasks.

You can get your available schemes (depending on what you installed) with:

GUI.schemes;

For a complete list of gui classes and redirects, see List of GUI classes.

Switching and Referring to GUI Kits

As of this writing, three GUI kits are available through the GUI class: QtGUI (Qt framework), CocoaGUI (Mac OS X native) and SwingGUI (Java). Note that SwingOSC is not part of every SuperCollider distribution, so you may have to install it separately.

You can switch the GUI kit by calling one of the following class methods:

GUI.qt;        // use Qt in subsequent GUI creation procedures
GUI.cocoa;    // use cocoa in subsequent GUI creation procedures
GUI.swing;    // use swing in subsequent GUI creation procedures
        // NOTE: If you do not have SwingOSC installed, you get
        // a warning only, and do not switch; so you cannot
        // accidentally disable your gui system.

These methods return the new GUI kit implementation. The current implementation can be queried by calling

GUI.current;    // returns the current GUI kit implementation

If you want to make a GUI kit specific switch (e.g. in a class), then you should use the following instead, as on non-OSX systems the class CocoaGUI is not in the class library path, and you cannot check for an undefined class:

GUI.id;    // returns the current GUI kit implementation id; this is currently either \cocoa or \swing

For persistency, you can store the identifier of the kit implementation and recall the kit through the class method fromID:

x = GUI.cocoa;
y = x.id;        // store the identifier of a kit implementation
y.postln;        // the id could be stored in a preferences file for example
GUI.swing;
// now switch back to the kit implementation with identifier y
GUI.fromID( y );
GUI.current.id.postln;    // --> cocoa

The *use and *useID methods allow you to temporarily switch the kit, so as to use it only for a dedicated block of statements:

GUI.cocoa;
GUI.useID(\swing, { Array.rand( 1000, 0.0, 1.0 ).plot });
GUI.current.id.postln;    // --> still cocoa

You can get a particular kit using the *get method. You can switch to a particular kit using the *set method:

x = GUI.get( \swing );    // note: unlike *swing and *cocoa, this does not _switch_ the current kit!
GUI.current.id.postln;    // --> still cocoa
GUI.set( x );            // now we make SwingOSC the current kit
GUI.window.viewPalette;

Extending GUI Kits

GUI Kits can be extended with custom classes by using their respective put methods:

GUI.get( \cocoa ).put( \myText, SCStaticText );
GUI.get( \swing ).put( \myText, JSCStaticText );

GUI.cocoa;
GUI.swing;
(
    w = GUI.window.new;
    GUI.myText.new( w, w.view.bounds.insetBy( 20, 20 )).string_( "schoko" ).background_( Color.red );
    w.front;
)

If you intend to add extensions from within your own classes upon class library initialization time, the preferred way is to do this in the startup process:

MyGUIExtension {
    *initClass {
        StartUp.add({
            var scheme;

            scheme = GUI.get( \cocoa );
            if( scheme.notNil, {scheme.put( \myText, SCStaticText )});
            scheme = GUI.get( \swing );
            if( scheme.notNil, {scheme.put( \myText, JSCStaticText )});
        });
    }
}

Class Methods

Methods and Variables for GUI

*new (key)

*makeGUI (key, args, properties)

*initClass

fontSpecs: ["Helvetica", 10],
fontColor: Color.black,
background: Color(0.8, 0.85, 0.7, 0.5),
foreground: Color.grey(0.95),
onColor: Color(0.5, 1, 0.5),
offColor: Color.clear,
gap: 0@0,
margin: 2@2,
buttonHeight: 16

*cocoa: METHOD NOT FOUND!

*swing

*fromID (id)

*current

*get (id)

*set (aScheme)

*use (aScheme, func)

*useID (id, func)

*add (aScheme)

*doesNotUnderstand (selector ... args)

*setSkin (skinName)

*scheme

*schemes

*skin

*skins

Inherited class methods

Undocumented class methods

*qt

Instance Methods

Inherited instance methods