Gral - Graphical Adaption Layer - the vishia Gui

See also Positions, syntax, possibilities

Often a so named "float layout" is favored. This simplifies the positioning of widgets. But the float layout is simple as also quick and - dirty. The position of widgets in an application should be a little bit substantiated. The float layout is not supported by Gral.

Usual graphic positions are pixel oriented, the pixel of the screen. But from user’s eyes, the pixel are subordinated. It is a high effort to calculate the pixel position, height and width, the numbers are not related to user’s thinking.

That’s why another system is used: Grid positions.

The basic grid is oriented to the normal text size. A normal text with a font in the standard proper read-able size is presented by 2 units of the Gral-position in vertical direction (line) and approximately 1 unit per character in horizontal direction. Of course the horizontal character size depends on the font properties. A text can be presented in a smaller or larger font. The text height depends on the height given in the position of the text. A very small font is presented by 1 vertical gral-unit. Such a text can be used as short title for text input fields (prompt) or adequate.

A button is able to proper present with 3 or 2 vertical gral units. A small check box may be presented with 1 x 1 gral unit. The size of a window in Grid units is approximately 80 x 120 (height x width), this is 720 x 480 pixel on small solution till 1200 x 1800 pixel in a fine solution. It means it fills the screen of a raw solution monitor (640 x 480 is 80 x 106 grid units, 6 pixel/grid) as also on a standard monitor (1920 x 1080 with 12 pixel/grid).

A gral unit should be have the same distance in vertical as in horizontal direction. It depends on the graphical implementation. One gral unit can have 6 to 18 pixel, depending on the requested size of appearance in comparison with the given display pixel size. Any graphic can be shown in several sizes of appearance, given with a start parameter of the application (see {@link org.vishia.gral.area9.GuiCallingArgs#sSize}) respectively the parameter size of {@link GralGridProperties#GralGridProperties(char size)} as character 'A' till 'H'.

Fine positions

Either the positions are given with 2 integer values as 'fundamental positions'. That are the position described above. Or they can be given with a float value or a second int named 'fractional part'. From the float value only the first digit after point is used, a fractional part can be given with a value from 0 to 9.

The fine position divides one gral position into 5 or into 6 fine positions. The odd numbers divide into 6 positions. In this kind a gral position is able to divide by 2, 3 and 6:

The even numbers divide into 5 positions:

The fine positioning enables a fine positioning of widgets in respect to the fundamental positions.

With a grid size of 10 (represented by letter 'E', see ../../docuSrcJava_vishiaGui/org/vishia/gral/base/GralGridProperties.html) a fine unit is exact one pixel. On a more raw solution (lesser pixel per grid unit) not any fine unit can be really represented. But the division in 1/6 …​5/6 is proper (odd number), and also the division in 1/5..4/5 (even number), but not any combination.

Look on the appearance of texts in the Graphic (GralLabel) with different sizes and screen resolutions:

This are texts with different size for the real raw solution, -size=A, for a small monitor for example Standard VGA. The image has original 157 x 101 pixel, it is ~ 1/4 in both directions of the area of a standard VGA monitor with 640x480 pixel. The font size of 1.0 is borderline, but able to guess what is meant. It is only for example known promps for fields. The font size of 2.0 is proper readable also in this solution, it is the standard text font. If you have a monitor with a fine pixel size, you may increase your zoom to read it.

This is -size=C, i guess readable on a monitor with raw solution (greater pixel size).

This is -size=E, one fine grid unit is one pixel.

And this -size=H, is only sensible on a large monitor with fine pixel. The programm is anywhere the same, only the size character as argument on start of the GUI is different.

The script to produce this output is the following, no programming is necessary, using link:

String or numeric given positions

The positions can be specified numerically, absolute or relative. For scripting it is necessary to process position specifications in textual form. This textual form is also usable for normal Java programming. Parsing of the position String is not an high effort, it is better write- and readable.

Usual the name of a widget and the position is joined in one String, for example given as

For this example the panel where to place is given. The widget, for example a text input field, should be placed in the 10^th line (y) with 2 lines height, and 12 grid units in horizontal direction from left, 15 grid units from right. It means the widget has a width depending from the panel or windows size, and of course, the widget is only visible if the window/panel has at least a width of 28 grid units.

For more capabilities see Position writing style in a gral script

Relative positions

A position of the next widget to define can be derived from the position before, with a relative number. Also the next position in the desired direction can be used automatically without manual given position. This is similar such approaches as float layout.

Resizing

Of course if a window or panel is resized, the pixel positions of the widget are calculated newly from the given grid positions with all relative relations. To get a proper layout on different windows sizes it is possible to define some widgets as distance from left and right, or in percents from the size. Hence the windows can be shifted lesser, only the important widgets are visible to get an overview on the screen, and on demand the window can be increased to the necessary size.

In vishiaGui - Gral the definition of the Graphical appearance is separated and independent of the Graphic implementation. All Widgets are simple instances from the Java Gral widget classes, first unrelated to graphic implementation.

All Gral widget classes are derived from org.vishia.gral.base.GralWidget and/or …​gral.base.GralWidgetBase. They contains:

It means, all appearance and data exists without the implementation graphic. One advantage is: the implementation graphic can be removed, unloaded and built newly, for example if any crash or trouble situation occurs. The implementation can also be existing in a separated device, only connected by communication lines.

This concept was not present in the beginning in 2010. In 2010 the implementation graphic was created in the same moment as the GUI was defined. The interface ../../docuSrcJava_vishiaGui/org/vishia/gral/ifc/GralMngBuild_ifc.html was responsible to creating both, the implementation parts of the GUI and the Gral independent wrapping classes of the gral. Hence the implementing functions should regard already the implementation graphic.

This interface GralMngBuild_ifc is still existing, but now only the Gral classes are created with.

The other new possibility, firstly developed ~2015..16 is: Creating the Gral classes by their constructor immediately, not using the GralMngBuild_ifc. This seems to be more obviously in programming. Both approaches are usable, see Templates / examples for creating the graphic appearance

The implementation of the Graphic with the specific graphic classes is done after the definition of the appearance with the Gral Graphic classes . It can be repeated on trouble situations as mentioned above: See Template / example to start the graphic implementation

In Java-Swing only basic capabilities of the operation system are used from Java level. Hence the appearance and the features are full defined on Java level.

The SWT has chosen a different way, just because of bad experience with Swing in calculation time (the computers in the 1990^{^th}^ were a little bit slower) and the better approach: Subordinate under appearance rules of the operation system with other non Java applications.

Both ways have advantages and disadvantages.

Often an Operation system offers appearances of the Graphic which are really not necessary, but nice or smart. This may be interested for users which likes nice and smart, but not for technician. For example rounded corners, smart (but bad distinguishable) colors of title bars and such. That are (partial specific) capabilities of one operation system - with lesser relevance. The advantage of a operation system-related graphic is: You can use it.

On the other hand the basic capabilities to draw proper widgets are given for all operation systems in a relative standardized form. If simple forms are used in an well-thought-out kind, you get a proper appearance which does not need too much calculation time and runs also on simple systems.

Hence drawing some widgets by simple basic solutions are reasonable.

For example, the representations of buttons in Gral are programmed with very simple lines, showing a pressed or not pressed button, also with some colors for checked or not checked buttons. The problem was, that the original MS-Windows button was very nice and smart, but can’t deal with color on the button (in ~2010, XP). Hence the button was replaced by this simple solution, which is still present and proper.

Another problem was operate with tables. Windows has only support selecting a full line, not selecting a cell with a color. That’s why, also in 2010, a table was not built with the SWT access to the Windows OS-API table, but with some simple text fields. The additional advantage was also, the data are completely separated from the graphical table content. The data are stored in ordinary Java container, independent from the Graphic. Only for showing (and also input) data in table cells, the data are transprorted to the graphic widgets and updated from there. This is a very fast operation (for the computers after the 2000^th), and it is better for handling. See chapter The GralTable

The term "widget" should be known, it is one part of the GUI in a window or a panel. A panel is either the whole window area, or some sub areas, or "tabbed panels" with selection tab. A panel is a container of widgets.

A widget is:

For b) only a few widgets from the implementation level are necessary. Some implementation level widget possibilities are not used, instead the Gral widgets are implemented by other standard widgets. This is especially for a table, which is usual supported from the operation system, but not in a sufficient form. Hence it is implemented by a set of simple text fields, which are visible or not (changing the size of the table). This is a proven solution also since 2010, see chapter The GralTable

For d) the operation system should offer a minimal set of graphic capabilities:

All others can be built by proper draw operations of the implementation widgets.

It is possible to use more capabilities of the operation system and the implementation graphic, if that is proper.

See also chapter Threads and callback operations in user threads

In Swing it is sometimes possible to access values from a Widget in another thread. In SWT this is consequently: All access or set operations can only be executed in the graphic thread. Elsewhere an Exception is thrown: org.eclipse.swt.SWT.ERROR_THREAD_INVALID_ACCESS With that decision some possible non obvious thread problems are prevented.

What are the usual approaches for GUI operations:

Often, the first small things are programmed immediately in the event handler, than the algorithm are growing, some file accesses are done, the files are in network, the network hangs sometimes, and then you have the rotating wheel in the graphic and you cannot abort your operation which accesses the file in the network. You know, the network is not available. But the computer does not know it (too long timeouts). You cannot react. You are not the master of the disaster, the system is determining you. It’s stupid.

For the Gral graphic, all accesses to the data of the widgets are possible in any thread without access the implementation widgets (which is not possible or complicated). That is done with two mechanism:

Hence, the user can program evaluating and influencing the graphic operations in any thread, without own effort for thread synchronization and event handling. All is done in the ready coded implementation level of Gral.

Read more in chapter Threads and callback operations in user threads

First programming in Java is shown and explained. You find the example in the sources of testJava_vishiaGui on https://github.com/JzHartmut in the file

class Header

Widget references

Widget references are only necessary if the processing of data need the access to the widgets. In this example the wdgInputText is necessary to access, but the wdgButton isn’t really. But for enhancements, for example change the text of the button, it may be usefully. Only widgets which should be never accessed needs a reference to. The reference is not necessary for the graphic itself, only to reference the widgets for processing data.

The widgets can also be accessed by getting the reference by name from the GralMng. This is shown in the chapter Determine the graphic via script.

Specificating the graphic appearance in the constructor

Firstly the ctor of the super class GuiCfg is called, That ctor creates the Window instance at Gral Level with the first panel. The window’s panel is the current one. Hence the refPos refer it and can be used immediately.

The GralWidget instances are defined here all with construction and assignment to the final references if necessary. If a widget don’t need to be referenced, only new Gral…​`widget should be written without assignment. The widget is references in its panel and in the [Java]`super.gralMng instance mediated by the refPos.

For the wdgButton an action is used which is defined below.

Example operation for the button

This operation is called by the button and accesses the text field, only as example.

Main command line start

The main creates an instance of GuiCallingArgs which are necessary for the constructor of GuiCfg (the super class). Normally this instance can be used to gather command line arguments. But for this example it is not necessary. If the sTitle is set (by command line argument, or direct), it is used as title for the window.

Style to define actions

The actions for buttons are instances of GralUserAction. Its operation exec(…​) should be overridden. But it is proper to call an operation in the main class there. It is also recommended to wrap all Actions with this here shown Actions class. Then it is more structured to view and understand the software.

That’s all

for a simple application and the pattern of an application.

this is old.

The java coded graphic is not too expensive, and it is able to understand (debug) what is done. Using a script is very more similar, most of the necessities are also possible. In the script the access to Java code parts is possible.

Look for the same example as above but with script. The class can be found as srcJava_vishiaGui/java/vishiaGui/org/vishia/gral/example/ExampleScriptSimpleButton.java:

class Header and Gui script

Here you see the class head and the script in String given form. The script can also come from a file, or it can be prepared by any other Java program, for example with configuration data what should be shown. Only for this simple example it is a simple text.

Specific class for Gui stuff (possible and recommended)

As also in the example of the chapter before, the Gui stuff is written in an inner class. One of substantial differences is: The constructor may throw an ParseException, because of course the script is not checked on compile time, but on run time. With the exception a elaborately error message is written, so that the user can fix it. The application is here terminated, the catch is in main, because with the error it cannot be run. Adequate is done if the script does not contain the expected widgets.

The advantage is, this code is independent from the design of the gui appearance.

More fields and ctor of the application class builds the Gral graphic part

Now some fields of the user class are defined, especially the Gui class, and the constructor of the application. Because the Constructor calls the new GuiElements, this constructor can also throw, it means the application throws. It is consequently for this case, in other cases somewhat can be further executed.

Initialization of the implementation Graphic

This is the init() operation after construction. Because the content of the gui script may be syntactically correct but may not contain all necessary widgets, firstly a report is written to console. Then the necessary widgets are checked whether they are existing. Because they are mandatory, also an Exception is thrown. It is also possible, depending from the content of the gui script, to determine which functionality are used. If widgets are not contained in the script, its functionality may be conditional in the application. It means, the script, maybe given by a file, can determine some behavior of the application.

The rest of the example application is identically to the non script version above. Also the steps of the life cycle are similar as described above.

Any widget can have a context menu. A context menu can be defined by

Content sensitive help is expectable in a well formed GUI application. The GRAL offers a GralInfoBox which is represented by a sub window or only by a special panel content inside the given window. It uses a browser (in SWT available) to show also content from the internet, or local html sides.

For a context sensitive help all widgets have a reference able to set: Gralwidget.setHtmlHelp

Generally they are two systems to define positions:

The string form from 2010 was basically only used in the scripts, translate to numbers. But later the parsing of the textual given positions is integrated in the basic capability of Gral, so it can be used for programming too. It is a simple understandable form. The next idea was, combination of name of the widget with the position on creation, with the writing style:

A position as reference for a widget can be set immediately, either with string or numerical:

Both sets the given position. But the other variant is: Set the position with using for a new Widget:

In this construction the refPos is changed while the Widget is created, regarding the position String on creating the Widget. The next TextField have the proper position below the wdg1 because of the increment in line and the not specified new position. The position will be incremented on next usage. This approach comes firstly from the script programming, but it is also usable and recommended for Java programming.

Sometimes the refPos should not just changed by usage. This is especially if the refPos is a really static reference for a comprehensive widget and all positions should follow exact this reference. Then it should be written:

The refPos remains its value though usage for the widget construction. All positions are referred to the original given refPos. But of course then the capability to increment the position for the next widget cannot be used. Any widget should have an absolute position regarding to the unchanged refPos. See org.vishia.gral.base.GralPos#setAsFrame()

The appearance of a graphic can be given with a script using org.vishia.gral.cfg.GralCfgZbnf. The writing style of positions in the script regards a stinting short style to give positions, because a hand written script should not cause a lot of calculations for positions by the writer. It should be simple. The syntax of a position in the gral script is given in the variable {@link #syntaxZbnf}. The method {@link #setPosition(CharSequence, GralPos)} uses that syntax.

Generally a widget is defined in the script with the following example (see also chapter Possibilities to determine the graphic appearance and functions via a script)

It means on the tabbed panel in tab1 an input field with the given symbolic name should be placed on the given position. The next input field is below, because the ++ as line increment is given on the widget before. This is simple and obviously. Note that the script is only for one panel in one window, which may be tabbed.

But see in next chapter, also relative positions can be used (regarding to the position before), and positions from right and sizable and proportional to the panel size, as also in Java programmed given positions.

Positions may be given with absolute values of grid units regarded to the actual panel, or also relative to the position before or a related position, and also (not full ready yet) as The position is given in form 'from..to' for the line and column or in form 'from' and 'size'. The size may be given positive or negative. A positive size is counted from top or left to bottom or right. It means that the 'from' position is top or left. But a negative size is counted from right or bottom and the 'from' position is the right or bottom column and line.

The resize starts any time from a Window resize listener. This listener (org.vishia.gral.swt.SwtSubWindow#resizeListener for SWT implementation) calls firstly …​base/GralWindow.WindowImplAccess#resizeWidgets(clientArea). For the associated mainPanel of the window and all children then org.vishia.gral.base.GralWidgBase.GralWidgComposite#resizeWidgets(parentPixelRectangle, recursion) is called.

This operation organizes recursively resizing for all widgets, which can be also panels or also composite widgets (consist of more as one member widgets). The size in pixel is calculated controlled by its position values in GralPos. That can contain proportional positions or positions from the right side, and also composite widgets consist of more as one GralWidget but without a panel in the implementation level (uses a part of a implementation panel).

For specific resize approaches the override able operation org.vishia.gral.base.GralWidgetBase#resizePostPreparation() can be do widget-specific preparations after resizing the implementation widget and before redraw. For instance on a table this controls the number of visible lines.

This is the same example shown in chapter Simple example Window with text field and button programmed in Java code with a script

…​TODO

The threading is most consequently on SWT graphic. A simple program using SWT needs only one thread, the given main-thread:

This code snippet shows the activity in the graphic thread, maybe the only one thread in the life time of a displayed window. The queueOrdersToExecute is an additional element of the Gral, it executes changing of the graphic appearance which is forced in other threads using this Gral specific event queue. The other source of graphic events are the callback operations of the graphic itself, not shown here but attached to the widgets.

For the SWT Gral implementation three threads are present:

SWT throws an exception if widgets are used in a faulty thread. The widgets can only touched in the SWT graphic thread.

AWT was the first graphic implementation in Java from 1995. In that time the idea of {J]synchronized was present as helper overall. The problem with longer waiting times for the operation system scheduler on the synchronization points were not recognized at that time.

The events from the application to the graphic thread (as well as also from the timer thread) are all organized by ordinary GralWidget operations, such as setText(…​), changeColor(…​) or adequate. The queue to store this event is a java.util.concurrent.ConcurrentLinkedQueue, it means it is thread safe by the atomic access approach which is faster than synchronized. The type of events are stored are type of GraphicTimeOrder which are derived from org.vishia.event.TimeOrder. An instance of that refers to an virtual given parameterless void operation executeOrder().

Instances of such events are created statically on instantiation of the appropriate widget. They are not created on demand on the heap, as often usual. For example inside the GralWidget:

The event is used for redraw, the instance of the event is given, it is not necessary to use it twice. If the event is not necessary in the moment, it remains as instance but it is not in a queue. This is also the concept of the org.vishia.event.TimeOrder.

This is a graphic independent thread, but helpfully. See ../../docuSrcJava_vishiaBase/org/vishia/event/EventTimerThread.html

Actions to change the graphic appearance are either forced in callback operations of the widgets in the graphic thread, or they are forced in other threads. In both case the question should be able to ask: "Should the reaction be executed immediately, so fast as possible?" For simple actions, change a text in a text field or such, "yes, should be done, why not__". But if the actions are more complicated, for example pressing a button, then some calculations are started, and the results shoud be present in tables or in a curve view, it is not necessary that any action forces change of the graphic. Because the eyes of a human are not so fast. A time of 100 ms may be often possible and not disturbing. If a value of a text field comes from a communication with a frequency of 1/10 ms, then not only any value should be shown. It is possible to suppress fast values (or maybe build a middle value, but it’s a question of the application requirements). If a new value comes,

need to be call, to present the value in the graphic appearance. But redraw in a time cycle of 10 ms or 1 ms needs unnecessary CPU and graphic calculation time.

Hence it is better to write

The first value is the delay = 100 ms, the second value is the last action. Supposed, a new redraw(100, 100) comes in a lesser time, the redrawing should not be deferred in the future, again after 100 ms, it should be done from the first redraw in just 100 ms from it. Both values are typically the same. On repeated value setting and redraw(100) calls last not least any 100 ms the last given value is shown. It needs graphical calculation time only in a 100 ms step, independent of the setValue(…​) and redraw calls in the other threads.

That is managed by the timer thread. The timer thread works outside of the graphic. In the event executing operations Events for the graphic thread are sent.

The timer thread and the event system is documented in

../../docuSrcJava_vishiaBase/org/vishia/event/EventTimerThread.html

The callback operation types from the implementing graphic widgets are equalized to a virtual operation exec(…​) in an instance of type GralUserAction. The original callback operations invokes that ones. It can be well programmed on user level without knowledge of the graphic specifics. For example look on a button callback:

It is recommended to call an operation outside of this anonymous class as shown. This operation is called in the graphical thread. If the operation may need a longer time, it should send an event to or weak up a user operation in any other user thread. This is recommended to prevent longer times in the graphic, where the graphic looks like frozen.

The operations for the GralWidget and all derived widgets can be usual done in any user thread. With that operations firstly only data in the GralWidget instance are changed. In specific fields of GralWidget it is remarked what is changed (color, text etc). Then a redraw(…​) is invoked. This activates the event described in the chapter above Events to the graphic thread and hence the event operation which calls the correct _wdgImpl.redrawGthread() for the implementation level. In this redraw operation it is tested which is changed, to transport the information from the GralWidget instance to the implementation graphic widget. This occurs in the graphic thread, hence is is proper.

It seems to be that all actions are done twice, firstly change data in the GralWidget, then in the implementation widget. That is true. But it is efficient, because setting data in ordinary Java instances are not an calculation effort. The possibility to separate actions from the graphic thread, which may hang (needs waiting times etc), this is the advantage.

The redraw of the implementation widget is anytime executed in the implementation of any widget defined as as gral.base.GralWidgImplAccess_ifc#redrawGthread(). This execution is done in the graphic thread.

The gral.base.GralWidgImplAccess_ifc#redraw() and also redraw(delay, latest) can be called in any thread. It should be called for one widget usual if any data of a widget are changed.

How both works together?

If you are in the graphic thread and redraw(0,0) is called, means immediate, without delay, then the redrawGthread() for the appropriate implementation widgets are called immediately. This is a special case.

If you call redraw() then this redrawing is delayed with the constant time of 50 ms, max after 100 ms. This is because some other changes may also be done in the same thread in a less time after (less milli seconds). Then only one redrawGthread() is called for the implementation graphic, which saves calculation time.

For example you change a text for a widget, and also a color. Then both changes invokes redraw(). But only one redrawGthread() is necessary for the widget with the given text and color. The 50 ms delay are enough to receive both changes, and less enough to visible it fastly.

The delay is organized by the [J]'GralGraphicTimeOrder' GralWidget#redrawRequ, see also chapter Events to the graphic thread.

Any user thread can call setFocus() to any widget on Gral level to get it in focus of usage. For the implementation level it means, that not only the appropriate widget should get the focus (in Swt: Control#setFocus or Control.#forceFocus), but all parent widgets should be visible if they are not, and also a primary widget of a focused panel should be focused. If the focused widget is in a yet hidden tab of a tabbed panel the tab should be activated, and also a hidden window should be get visible. That is all done in the Gral adaption.

If the focus was set with user action (usually the mouse selects a field) then a focus event in the implementation graphic should catch this action and should call gral.base.GralWidgetBase.setFocus(gained). This operation marks in the Gral widget the property gral.base.GralWidgetBase.hasFocus() which can be used to decide some actions on handling with this widget, for example copy to clipboard by selecting a field or evaluate the content of a field while selecting not only with the mouse. Any forced action can quest hssFocus() and with this information decide about reaction.

If one widget has gained the focus, also all parents (comprehensive widgets, panel, window) are set in the state hssFocus() because just its actions should decide also. For example if a cell in a table was focused, an algorithm of the widget containing the table can evaluate the table’s content.

See also https://help.eclipse.org/latest/nftopic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/widgets/Control.html#forceFocus().

If an user handling activates the focus of another widget (by mouse click, by selection keys etc.), then the implementation graphic invokes an event focusGained or also focusLost for the other widget which losses the focus.

A graphic needs one instance of the gral.base.GralMng It contains

GralWidgetBase

The class gral.base.GralWidgetBase is the base class for all widgets, also for comprehensive ones. It contains

The operation createImplWidget_Gthread() is or should be overridden by comprehensive widgets, calling the appropriate gral.base.GralMng.ImplAccess.createImplWidget_Gthread(GralWidget wdg) for all contained widgets on Gral level. Hence no specific implementation code is necessary.

The operation createImplWidget_Gthread() is overridden by the GralPanelContent and GralWindow to build the contained widgets.

GralWidget

This class gral.base.GralWidget is the base class for that all widgets, which have an counterpart in the implementation level.

Additionally that basic class contains common properties of the widget such as

A GralWindow is a window of the application. An application can have not only the main window but also some sub windows. All of the are type of gral.base.GralWindow

The first window which is created in a Gral initialization is automatically the main window. Only the main window is unconditionally set to visible, all other windows are set to invisible per default. This is organized by the gral.base.GralMng#runGraphicThread():

A field to show a text (values) or input a text has a frame with a specific background color and with a dedicated size, also for a show-field. In opposite a simple text output (usual named as Label) has not a frame and not a background color. Secondly a text field can have a label to explain what is it.

image:../../img/todo

Such text fields as show fields can be used especially to show process values as numerics with units etc. as for example used in the Inspector GUI or a operation and monitoring GUI.

The gral.base.GralTable is a basic widget (which has its specific implementation, see gral.swt.SwtTable) But this implementation does not follow the offer of a table widget of the operation system.

Why not? Some operation system’s table widgets have a too less capability. The additonal capabilities of a GralTable are:

The basically decision to build a table was also in 2010:

Depending of the visible size of the table not all text fields are visible. The maximal visible length of a table can be determined by construction. Usual no more than 100 fields should be used (for a long table), or for example only 10 fields per column if the table should anytime be shown only by a simple section. But the data length of the table (number of existing lines) can be any size. The table lines are not selected by such as a panel with vertical selection slider, which contains a lot of lines. The selected visible range of the table is always presented in the few text fields. There content is changed by selection. It means the content of the table is not persistent present in the implementation fields, it is present in the data of the GralTable (in the rootline and all of its nodes of type gral.base.GralTable.TableLineData. The nodes are a structure of vishia.util.TreeNodeBase which is a basically node structure.

On showing a part of the table content the appropriate gral.base.GralTable.TableLineData.cellTexts are copied in the appropriate text fields of the implementing graphic, as also the gral.base.GralTable.TableLineData.cellColorBack or the general colorBackMarked etc. depending of the state of the line. If the table content is shifted, the cellTexts etc. are copied just newly. This copy process from internal Java data to the implementation widgets needs not too much time.

To show any what, lines, curves, polygons, also text, a canvas can be used. It’s for "free drawing".

Commonly, the canvas has its draw-background operation which can be specifically programmed to draw all what is possible with the implementing graphic. In Eclipse SWT it is https://help.eclipse.org/latest/nftopic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/widgets/Canvas.html#drawBackground(org.eclipse.swt.graphics.GC,int,int,int,int). You can use the capabilities of the GC (Graphic Control) class https://help.eclipse.org/latest/nftopic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/graphics/GC.html to draw lines, figures and text.

But programming in eclipse SWT immediately is specific. If you do the same in AWT, you have the capability of java.awt.Graphics with similar functionality, but a little bit (or more) different: https://cr.openjdk.java.net/~iris/se/17/latestSpec/api/java.desktop/java/awt/Graphics.html.

If you use instead Python, or the old pearl, or whatever, similar the same but a little bit other and specific.

And if you have dynamic data outside of the graphic, you have problems to write proper thread safe stuff.

The Gral concept gives another answer:

../../docuSrcJava_vishiaGui/org/vishia/gral/base/GralCanvasStorage.html is a graphic independent storage for the appearance of the graphic. It consists of Figure and each figure has any lines, areas, text etc. This data are independent of all implementing graphics, only coordinates and GralPos and GralColor. You can modify them in any thread. To apply to a graphic you have two possibilities:

The canvas is represented either with a specifc ../../docuSrcJava_vishiaGui/org/vishia/gral/widget/GralCanvasArea.html or it can be a part of a ../../docuSrcJava_vishiaGui/org/vishia/gral/base/GralPanelContent.html.

The GralCanvasArea as widget can be placed beside other widgets to show specific forms as vector graphic instead using a image. Also animated content is possible.

A normal GralPanelContent contains standard widgets, but can also contain free lines and figures.