GeoGebra Layout Manager Documentation

Views

(see ​feature video)

Drag'n'Drop

GeoGebra's user interface consists of multiple separate components called views (e.g. the graphic pad or the algebra view), which can be made visible/invisible in the current major release but the general position can't be changed. The GeoGebra Layout Manager should make it possible for the user to move the position of a view by dragging the title bar of the view and drop it at the wished position.

External Windows

Views may also be opened in separated windows, closing such a window will cause the view to be hidden. By using a special button the user may also dock the view back to the main window. The position and dimension of a window is restored if the user makes the view visible again after it was closed as a window, even after docking these settings are restored automatically if the view is opened as a window again.

Title Bar

The view title bar bundles all view-related features of this extension for the user and is displayed on top of each individual view if the title bar is enabled. It displays the view name and two buttons to open the view in an additional window and to close the view. Views may also define their own styling bar (see below) for which the visibility may be toggled using a third button which is just displayed if the view actually defines such a bar.

The title bar is also used as a starting point for drag'n'drop. If the user opens a view in an additional window this title bar is still visible, but with changed buttons (e.g. a button to dock the view back to the main window). Users may also disable the title bar altogether (see Options), in this case most features of the Layout Manager are not accessible anymore — which is the intended use of this option.

Styling Bar

Views may define their own styling bar which bundles useful features which may not fit into the normal tool bar. A styling bar can be toggled by using a special button located in the title bar of each view, it is displayed directly below the title bar. The styling bar can contain arbitrary content, the visibility of such a bar is restored on each file load.

Perspectives

A perspective is a storage container for the current GUI configuration, including the view layout, toolbar buttons and other GUI related options. If a material is saved the current perspective is stored in the file as a starting point to restore the GUI configuration on loading. The user can also use predefined perspectives which are available in GeoGebra by default (see below) or can store the current GUI configuration as a perspective without associating it with the current material. These custom perspectives are stored permanently and can be accessed from each GeoGebra window.

Default perspectives

GeoGebra ships with a number of perspectives which are always available to the user. The following table lists the current perspectives and their visible views, this list is certainly not used in the release (e.g. no perspective uses the CAS at the moment).

Name	Euclidian View	Algebra View	Spreadsheet View	CAS View
Algebra & Geometry	Yes (+Axes)	Yes	No	No
Basic Geometry	Yes	No	No	No
Geometry	Yes (+Axes +Grid)	No	No	No
Table & Graphics	Yes	No	Yes	No

It is also noteworthy that different versions of GeoGebra probably define their own default perspectives, the 3D view is only available in GeoGebra3D for example.

Custom perspectives

Users may also store the layout of their current workspace in custom perspectives. Those are stored as part of the user preferences and document and may be reused by using the View menu at any time. One cannot modify stored perspectives directly, but after loading a perspective the user may make his changes and overwrite the old perspective with his new workspace layout. Custom perspectives can be removed using the options dialog.

Included Data

• View related information
  • ID -- Identifier for the view
  • Visibility -- Is the view visible?
  • Open In Window -- Should the view open in a new window?
  • Window Bounds -- Bounds (location + size) of the view-window
  • Embedded Size -- Width / Height of the view if included in the main window
  • Embeded Def -- Location of the view in the main window, stored in a special string format to describe the exact position of the view
  • Style Bar Visibility -- Is the style bar of this view visible? (just taken into consideration if the view has a style bar of course)
• General information
  • Tool Bar -- Definition string of the tool bar, has to be replaced by view-specific tool bars in the future
  • Tool Bar Visibility
  • Grid Visibility
  • Axes Visibility
  • Input Panel Visibility -- The input panel contains the text field to insert commands, the command list, etc.)
    • Command List Visibility -- The list with commands in the input panel may be hidden as well
    • On Top -- For whiteboard users the input panel might also be moved to the bottom of the screen (better to reach)

Options

Options for the perspectives are available in the option dialog (at the moment just in the menu). As described in the title bar section the title bar can be hidden altogether, which will make it impossible to move views by accident. This options is mainly intended for student PCs to focus GeoGebra's user interface on the most important functionalities. Users can also choose to fix their current window layout, in this mode the perspective found in loaded documents is ignored, a feature mainly intended for expert users who have setup their workspace to their needs. Due to the nature of those two options they are just stored on a per-user and not per-document level. The perspective management feature mentioned in the Custom Perspectives section is also located in the option dialog.

Conclusion / Outlook

Not everything could be finished as part of this GSoC project, many minor and some major tasks are still flooding on my ToDo list, the most important one is probably the ability to create view-dependent tool bars. Minor enhancements are the welcome screen and accessibility features, a more complete list can be found on my developer page.

Implementation

I am not going into too much detail here, the source code should contain enough comments to understand the details (if someone is really that venturesome). The layout manager is mainly a nested tree of DockSplitPanes (JSplitPanes with some minor extensions) which contain DockPanels. A DockPanel is a hull for any kind of JComponent which is surrounded with a title bar and some logic to allow saving / loading in Perspectives. A Perspective is nothing more than the dock panel and split pane data necessary to rebuild the layout, plus some settings. Perspectives are also used internally to store the workspace layout while saving the document or the preferences (called the tmp perspective). Drag'n'drop is mostly handled by the DockGlassPane which determines the target split pane, calculates the position of the dragged panel and draws the preview rectangle on top of the screen.

Usage

This paragraph is intended to help those who want to add new panels to the layout manager.

As said above the DockPanel class contains the logic related to each draggable panel, to add a new panel one has to subclass DockPanel first. The whole layout manager was build with a very loose coupling between the layout manager and the actual components in mind, so the component which should be added to the layout manager does not have to implement DockPanel directly (one should never do that, actually).

DockPanel defines some abstract methods like DockPanel::loadComponent() instead which should return the component-to-be-added at runtime. This method is just called if the DockPanel is made visible the first time, so components do not even have to be loaded if their views are not visible. Similar methods are Dockpanel::loadStyleBar() which returns the component which should be displayed as the style bar for this view and DockPanel::getIcon() to retrieve the menu icon for the panel, both methods are optional though.

After subclassing DockPanel it is necessary to inform the layout manager about the new panel of course, to do this one simply has to call Layout.registerPanel() with an instance of the subclass as parameter. While the register method can be called at any time in theory, it is necessary to register all dock panels before file loading if the document may contain panels of that type. It is recommended to register all panels in GuiManager::initLayoutPanels().

The following snippet shows a complete example how to subclass DockPanel and register that view. This is all done in one single step with anonymous classes in this case:

layout.registerPanel(
	new DockPanel(
			...,		// view id (has to be unique)
			"...", 		// view title (has to be located in plain.properties)
			false,		// style bar?
			1		// menu order
	) {
		// if omitted this will return the correct empty icon 
		public ImageIcon getIcon() {
			return app.getImageIcon("...");
		}

		// mandatory if "style bar?" construction parameter is true
		protected JComponent loadStyleBar() { 
			return ...;
		}
		
		// mandatory
		protected JComponent loadComponent() {
			return ...;
		}
	}
);

UML

This diagram shows all classes of the layout manager and their most important relations. Methods important for users (in the sense of the Usage section above) are also visible, all other methods and all class attributes have been omitted.