Class: stx_libwidg

• Inheritance
• Description
• Class protocol
  • description
  • description - compilation
  • description - contents
  • description - project information

Inheritance:

   Object
   |
   +--ProjectDefinition
      |
      +--LibraryDefinition
         |
         +--stx_libwidg

Package:

stx:libwidg

Category:

* Projects & Packages *

Version:

rev: 1.54 date: 2017/11/25 12:35:04

user: cg

file: stx_libwidg.st directory: libwidg

module: stx stc-classLibrary: libwidg

Author:

cg

Description:

Package Documentation

This library contains elementary GUI components (widgets), such as Buttons, InputFields,
TextEditors, Scrollbars etc.

All of these widgets are written in 100% pure Smalltalk. 
They do not depend upon any particular underlying graphic system (by the operating system). 
Instead, they build upon the abstraction layer as provided by libview.
Arguably, this has both advantages and disadvantages:
for one, the ST/X widgets may not look&feel 100% like their native counterparts, especially
on systems which constantly change (i.e. Windows).
On the other hand, this frees us completely from any development there, 
and gets us rid of big problems when looks, feels or even APIs change.
(btw.: and also makes us independent of any bugs found in those)

Just consider the following historic fact:
    when motif was modern, people asked for a native motif style...
    ... a few years later for qt, then gnome, and what next?
    We'd be constantly adapting to new frameworks and not get any work done,
    if we were depending on native widgets

Also, this might even make problems, if widget frameorks on different systems 
(i.e. X vs. Windows vs. Cocoa) provide different levels of functionality.


[primary maintainer:]
    cg

Class protocol:

 excludedFromPreRequisites

JavaScriptParser - referenced by Workspace>>browseImplementorsOfIt

 mandatoryPreRequisites

list all required mandatory packages.
Packages are mandatory, if they contain superclasses of the package's classes
or classes which are extended by this package.
This list can be maintained manually or (better) generated and
updated by scanning the superclass hierarchies
(the browser has a menu function for that)

 referencedPreRequisites

list all packages containing classes referenced by the packages's members.
This list can be maintained manually or (better) generated and
updated by looking for global variable accesses
(the browser has a menu function for that)
However, often too much is found, and you may want to explicitely
exclude individual packages in the #excludedFromPreRequisites method.

 subProjects

list packages which are known as subprojects.
The generated makefile will enter those and make there as well.
However: they are not forced to be loaded when a package is loaded;
for those, redefine requiredPrerequisites

 additionalBaseAddressDefinition_bc_dot_mak

this is an optional definition, which (if present) may speed up the dll-loading a little
on win32 systems.

 stcOptimizationOptions

 stcWarningOptions

 classNamesAndAttributes

lists the classes which are to be included in the project.
Each entry in the list may be: a single class-name (symbol),
or an array-literal consisting of class name and attributes.
Attributes are: #autoload or #<os> where os is one of win32, unix,...

 extensionMethodNames

lists the extension methods which are to be included in the project.
Entries are 2-element array literals, consisting of class-name and selector.

 companyName

Return a companyname which will appear in <lib>.rc

 description

Return a description string which will appear in nt.def / bc.def

 legalCopyright

Return a copyright string which will appear in <lib>.rc

 productName

Return a product name which will appear in <lib>.rc