Package org.luwrain.core

Interface Area

All Superinterfaces:
HotPoint, Lines
All Known Subinterfaces:
Popup, SectionArea
All Known Implementing Classes:
Area, BlockArea, CalendarArea, CcEditPopup, CenteredArea, ChooseMailPopup, CommanderArea, CommanderPopup, ConsoleArea, ContextMenu, DisksPopup, EditableListArea, EditableListPopup, EditArea, EditListPopup, FilePopup, FormArea, FormPopup, ListArea, ListPopup, ListPopup2, ListPopupBase, MainMenu, MarkableListArea, MessageArea, NavigationArea, ProgressArea, ReaderArea, Search, SimpleArea, SimpleEditPopup, SpellCheckingEditArea, TableArea, TreeArea, TreeListArea, WebSearchResultPopup, WizardArea, WizardAreaObj, YesNoPopup
public interface Area extends Lines, HotPoint
Area is a fundamental entity of Luwrain interface. It is an abstraction of any working object, which may be an editable text, a table, a tree view, a form and so on. Area constructs visual representation of its content for low-vision users and behave as an event recipient.

Area has a special point inside, which is called "hot point". It is some generalization of a cursor on the screen. The hot point is meaningful for visual content only and marks for low-vision users where is a point inside of the area he/she should be focused at.

Dealing with the areas, Luwrain core usually doesn't produce any speech announcements automatically. All areas should do it on their own, depending on the desired application behaviour. Roughly speaking, if some change occurred in the area, this area should change its visual representation returned through getLine() and getLineCount() methods, doing speech announcements separately.

If the area changes its content, its name or its hot point position it must notify about these changes the core using methods onAreaNewContent(), onAreaNewName() and onAreaNewHotPoint() of Luwrain class. Otherwise, it could result in application inconsistency. Generally, all areas should conform to the following rules:

  • Area objects never know whether they are visible on the screen or not (meaning, they should expect that they are always visible)
  • The same is also applicable for the activity status (the area should expect that it is also active)
  • Areas may not be nested or composite
  • The area may present on the screen only through showing in single window; if the same document should be shown in different windows on the screen the developer should use different areas
  • Area may not return zero number of lines for visual representation; if the area is empty, it means that it contains single empty line
  • Area may request how many lines it should expect visible on the screen (it is needed for "page down" and "page up" processing), but anyway it never knows which exact lines are visible
  • Real length of the line on the screen is unknown (evidently, it depends on the length of tabs)

  • Method Details

    • getAreaName

      String getAreaName()

    • getHotPointX

      int getHotPointX()
      Specified by:
      getHotPointX in interface HotPoint

    • getHotPointY

      int getHotPointY()
      Specified by:
      getHotPointY in interface HotPoint

    • onInputEvent

      boolean onInputEvent(InputEvent event)

    • onSystemEvent

      boolean onSystemEvent(SystemEvent event)

    • onAreaQuery

      boolean onAreaQuery(AreaQuery areaQuery)

    • getAreaActions

      Action[] getAreaActions()